From: Armando Miraglia <arma2ff0@gmail.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: neil@brown.name, devel@driverdev.osuosl.org,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
linux-mediatek@lists.infradead.org, sankalpnegi2310@gmail.com,
matthias.bgg@gmail.com, sr@denx.de,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
Date: Thu, 14 Mar 2019 12:13:15 +0100 [thread overview]
Message-ID: <20190314111313.GB8034@google.com> (raw)
In-Reply-To: <20190313123454.GB2202@kadam>
My answers are in-line below. BTW bare with me as this is my attempt to get my
feet wet in how to contribute to the linux kernel for my own pleasure and
interest :)
On Wed, Mar 13, 2019 at 03:34:54PM +0300, Dan Carpenter wrote:
> On Wed, Mar 13, 2019 at 01:24:04PM +0100, Armando Miraglia wrote:
> > Running Lindent on the mt7621-spi.c file in drivers/staging I noticed that the
> > file contained style issues. This change attempts to address such style
> > problems.
> >
>
> Don't run lindent. I think checkpatch.pl has a --fix option that might
> be better, but once the code is merged then our standard become much
> higher for follow up patches.
>
> > Signed-off-by: Armando Miraglia <armax@google.com>
> > ---
> > NOTE: resend this patch to include all mainteners listed by get_mantainers.pl.
> > drivers/staging/mt7621-spi/spi-mt7621.c | 27 +++++++++++++------------
> > 1 file changed, 14 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c b/drivers/staging/mt7621-spi/spi-mt7621.c
> > index b509f9fe3346..03d53845f8c5 100644
> > --- a/drivers/staging/mt7621-spi/spi-mt7621.c
> > +++ b/drivers/staging/mt7621-spi/spi-mt7621.c
> > @@ -52,14 +52,14 @@
> > #define MT7621_LSB_FIRST BIT(3)
> >
> > struct mt7621_spi {
> > - struct spi_master *master;
> > - void __iomem *base;
> > - unsigned int sys_freq;
> > - unsigned int speed;
> > - struct clk *clk;
> > - int pending_write;
> > -
> > - struct mt7621_spi_ops *ops;
> > + struct spi_master *master;
> > + void __iomem *base;
> > + unsigned int sys_freq;
> > + unsigned int speed;
> > + struct clk *clk;
> > + int pending_write;
> > +
> > + struct mt7621_spi_ops *ops;
>
> The original is fine. I don't encourage people to do fancy indenting
> with their local variable declarations inside functions but for a struct
> the declarations aren't going to change a lot so people can get fancy
> if they want.
>
Is there an explicit intent to deprecate Lindent in favor of checkpatch.pl
--fix? If one would like to contribute to fixing the tooling for linting which
of the two would be the right target for such an effort?
> The problem with a local is if you need to add a new variable then you
> have to re-indent a bunch of unrelated lines or have one out of
> alignment line. Most people know this intuitively so they don't get
> fancy.
>
> > };
> >
> > static inline struct mt7621_spi *spidev_to_mt7621_spi(struct spi_device *spi)
> > @@ -303,7 +303,7 @@ static int mt7621_spi_setup(struct spi_device *spi)
> > struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
> >
> > if ((spi->max_speed_hz == 0) ||
> > - (spi->max_speed_hz > (rs->sys_freq / 2)))
> > + (spi->max_speed_hz > (rs->sys_freq / 2)))
>
> Yeah. Lindent is correct here.
Funny enough, this is something I adjusted manually :)
> > spi->max_speed_hz = (rs->sys_freq / 2);
> >
> > if (spi->max_speed_hz < (rs->sys_freq / 4097)) {
> > @@ -316,9 +316,10 @@ static int mt7621_spi_setup(struct spi_device *spi)
> > }
> >
> > static const struct of_device_id mt7621_spi_match[] = {
> > - { .compatible = "ralink,mt7621-spi" },
> > + {.compatible = "ralink,mt7621-spi"},
>
> The original was better.
>
> > {},
> > };
> > +
> > MODULE_DEVICE_TABLE(of, mt7621_spi_match);
>
> No need for a blank. These are closely related.
Ack.
> >
> > static int mt7621_spi_probe(struct platform_device *pdev)
> > @@ -408,9 +409,9 @@ MODULE_ALIAS("platform:" DRIVER_NAME);
> >
> > static struct platform_driver mt7621_spi_driver = {
> > .driver = {
> > - .name = DRIVER_NAME,
> > - .of_match_table = mt7621_spi_match,
> > - },
> > + .name = DRIVER_NAME,
> > + .of_match_table = mt7621_spi_match,
> > + },
>
> The new indenting is very wrong.
Ack. In fact, I was thinking this could be one target to fix the logic in
Lindent to do this appropriately.
I have a process question here: to post a change for the only accepted change I
have in this patch should I send out a new patch?
Thanks for the help and the review!
Cheers,
A.
WARNING: multiple messages have this Message-ID (diff)
From: Armando Miraglia <arma2ff0@gmail.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: devel@driverdev.osuosl.org, sankalpnegi2310@gmail.com,
linux-kernel@vger.kernel.org, matthias.bgg@gmail.com,
linux-mediatek@lists.infradead.org, gregkh@linuxfoundation.org,
neil@brown.name, sr@denx.de,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
Date: Thu, 14 Mar 2019 12:13:15 +0100 [thread overview]
Message-ID: <20190314111313.GB8034@google.com> (raw)
In-Reply-To: <20190313123454.GB2202@kadam>
My answers are in-line below. BTW bare with me as this is my attempt to get my
feet wet in how to contribute to the linux kernel for my own pleasure and
interest :)
On Wed, Mar 13, 2019 at 03:34:54PM +0300, Dan Carpenter wrote:
> On Wed, Mar 13, 2019 at 01:24:04PM +0100, Armando Miraglia wrote:
> > Running Lindent on the mt7621-spi.c file in drivers/staging I noticed that the
> > file contained style issues. This change attempts to address such style
> > problems.
> >
>
> Don't run lindent. I think checkpatch.pl has a --fix option that might
> be better, but once the code is merged then our standard become much
> higher for follow up patches.
>
> > Signed-off-by: Armando Miraglia <armax@google.com>
> > ---
> > NOTE: resend this patch to include all mainteners listed by get_mantainers.pl.
> > drivers/staging/mt7621-spi/spi-mt7621.c | 27 +++++++++++++------------
> > 1 file changed, 14 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c b/drivers/staging/mt7621-spi/spi-mt7621.c
> > index b509f9fe3346..03d53845f8c5 100644
> > --- a/drivers/staging/mt7621-spi/spi-mt7621.c
> > +++ b/drivers/staging/mt7621-spi/spi-mt7621.c
> > @@ -52,14 +52,14 @@
> > #define MT7621_LSB_FIRST BIT(3)
> >
> > struct mt7621_spi {
> > - struct spi_master *master;
> > - void __iomem *base;
> > - unsigned int sys_freq;
> > - unsigned int speed;
> > - struct clk *clk;
> > - int pending_write;
> > -
> > - struct mt7621_spi_ops *ops;
> > + struct spi_master *master;
> > + void __iomem *base;
> > + unsigned int sys_freq;
> > + unsigned int speed;
> > + struct clk *clk;
> > + int pending_write;
> > +
> > + struct mt7621_spi_ops *ops;
>
> The original is fine. I don't encourage people to do fancy indenting
> with their local variable declarations inside functions but for a struct
> the declarations aren't going to change a lot so people can get fancy
> if they want.
>
Is there an explicit intent to deprecate Lindent in favor of checkpatch.pl
--fix? If one would like to contribute to fixing the tooling for linting which
of the two would be the right target for such an effort?
> The problem with a local is if you need to add a new variable then you
> have to re-indent a bunch of unrelated lines or have one out of
> alignment line. Most people know this intuitively so they don't get
> fancy.
>
> > };
> >
> > static inline struct mt7621_spi *spidev_to_mt7621_spi(struct spi_device *spi)
> > @@ -303,7 +303,7 @@ static int mt7621_spi_setup(struct spi_device *spi)
> > struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
> >
> > if ((spi->max_speed_hz == 0) ||
> > - (spi->max_speed_hz > (rs->sys_freq / 2)))
> > + (spi->max_speed_hz > (rs->sys_freq / 2)))
>
> Yeah. Lindent is correct here.
Funny enough, this is something I adjusted manually :)
> > spi->max_speed_hz = (rs->sys_freq / 2);
> >
> > if (spi->max_speed_hz < (rs->sys_freq / 4097)) {
> > @@ -316,9 +316,10 @@ static int mt7621_spi_setup(struct spi_device *spi)
> > }
> >
> > static const struct of_device_id mt7621_spi_match[] = {
> > - { .compatible = "ralink,mt7621-spi" },
> > + {.compatible = "ralink,mt7621-spi"},
>
> The original was better.
>
> > {},
> > };
> > +
> > MODULE_DEVICE_TABLE(of, mt7621_spi_match);
>
> No need for a blank. These are closely related.
Ack.
> >
> > static int mt7621_spi_probe(struct platform_device *pdev)
> > @@ -408,9 +409,9 @@ MODULE_ALIAS("platform:" DRIVER_NAME);
> >
> > static struct platform_driver mt7621_spi_driver = {
> > .driver = {
> > - .name = DRIVER_NAME,
> > - .of_match_table = mt7621_spi_match,
> > - },
> > + .name = DRIVER_NAME,
> > + .of_match_table = mt7621_spi_match,
> > + },
>
> The new indenting is very wrong.
Ack. In fact, I was thinking this could be one target to fix the logic in
Lindent to do this appropriately.
I have a process question here: to post a change for the only accepted change I
have in this patch should I send out a new patch?
Thanks for the help and the review!
Cheers,
A.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-03-14 11:13 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-13 12:24 [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c Armando Miraglia
2019-03-13 12:24 ` Armando Miraglia
2019-03-13 12:28 ` Matthias Brugger
2019-03-13 12:28 ` Matthias Brugger
2019-03-13 12:28 ` Matthias Brugger
2019-03-13 12:31 ` Armando Miraglia
2019-03-13 12:31 ` Armando Miraglia
2019-03-13 16:34 ` Chuanhong Guo
2019-03-13 16:34 ` Chuanhong Guo
2019-03-13 16:46 ` Matthias Brugger
2019-03-13 16:46 ` Matthias Brugger
2019-03-13 16:54 ` Stefan Roese
2019-03-13 16:54 ` Stefan Roese
2019-03-13 22:14 ` NeilBrown
2019-03-13 22:14 ` NeilBrown
2019-03-14 2:26 ` Chuanhong Guo
2019-03-14 2:26 ` Chuanhong Guo
2019-03-14 2:26 ` Chuanhong Guo
2019-03-14 2:36 ` NeilBrown
2019-03-14 2:36 ` NeilBrown
2019-03-13 12:34 ` Dan Carpenter
2019-03-13 12:34 ` Dan Carpenter
2019-03-13 12:34 ` Dan Carpenter
2019-03-13 16:47 ` Matthias Brugger
2019-03-13 16:47 ` Matthias Brugger
2019-03-14 11:13 ` Armando Miraglia [this message]
2019-03-14 11:13 ` Armando Miraglia
2019-03-14 11:27 ` Dan Carpenter
2019-03-14 11:27 ` Dan Carpenter
2019-03-14 11:27 ` Dan Carpenter
2019-03-14 14:07 ` Jean Delvare
2019-03-14 14:07 ` Jean Delvare
2019-03-14 20:50 ` Joe Perches
2019-03-14 20:50 ` Joe Perches
2019-03-14 11:36 ` Stefan Roese
2019-03-14 11:36 ` Stefan Roese
2019-03-14 11:37 ` Armando Miraglia
2019-03-14 11:37 ` Armando Miraglia
2019-03-14 13:14 ` Matthias Brugger
2019-03-14 13:14 ` Matthias Brugger
2019-03-14 13:14 ` Matthias Brugger
2019-03-14 13:24 ` Stefan Roese
2019-03-14 13:24 ` Stefan Roese
2019-03-14 17:01 ` Matthias Brugger
2019-03-14 17:01 ` Matthias Brugger
-- strict thread matches above, loose matches on Subject: below --
2019-03-13 11:57 Armando Miraglia
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=20190314111313.GB8034@google.com \
--to=arma2ff0@gmail.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=neil@brown.name \
--cc=sankalpnegi2310@gmail.com \
--cc=sr@denx.de \
/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.