On Wed, 2024-04-17 at 09:07 +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 16, 2024 at 01:14:52PM -0700, A wrote:
> > > From 6dbcb120581fc7cb45812193227b0a197abd8ba4 Mon Sep 17 00:00:00
> > > 2001
> > From: Ashok Kumar <ashokemailat@xxxxxxxxx>
> > Date: Tue, 16 Apr 2024 09:19:32 -0700
> > Subject: [PATCH] [PATCH] staging: fbtft Removed redundant
> > parentheses on
> > logical expr
> >
> > Adhere to Linux Kernel coding style removed redundant parentheses,
> > multiple blank lines and indentation alignment.
> >
> > Reported by checkpatch.pl
> >
> > ------
> > fb_ili9320.c
> >
> > + if ((devcode != 0x0000) && (devcode != 0x9320))
> >
> > ------
> > fb_ra8875.c
> >
> > CHECK: Unnecessary parentheses around 'par->info->var.xres == 320'
> > + if ((par->info->var.xres == 320) && (par->info->var.yres ==
> > 240)) {
> >
> > ------
> > fb_ssd1325.c
> >
> > CHECK: Please don't use multiple blank lines
> > ------
> >
> > fb_tinylcd.c - indentation adjustment
> >
> > -----
> > fbtft-bus.c
> >
> > CHECK: Unnecessary parentheses around 'par->spi->bits_per_word ==
> > 8'
> >
> > ------
> > fbtft-core.c
> >
> > CHECK: Please don't use multiple blank lines
> >
> > CHECK: Unnecessary parentheses around '!txbuflen'
> >
> > CHECK: Please don't use multiple blank lines
> > ------
> >
> > Signed-off-by: Ashok Kumar <ashokemailat@xxxxxxxxx>
> > ---
> > drivers/staging/fbtft/fb_ili9320.c | 2 +-
> > drivers/staging/fbtft/fb_ra8875.c | 8 ++++----
> > drivers/staging/fbtft/fb_ssd1325.c | 2 --
> > drivers/staging/fbtft/fb_tinylcd.c | 2 +-
> > drivers/staging/fbtft/fbtft-bus.c | 6 +++---
> > drivers/staging/fbtft/fbtft-core.c | 7 +------
> > 6 files changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/staging/fbtft/fb_ili9320.c
> > b/drivers/staging/fbtft/fb_ili9320.c
> > index 0be7c2d51548..409b54cc562e 100644
> > --- a/drivers/staging/fbtft/fb_ili9320.c
> > +++ b/drivers/staging/fbtft/fb_ili9320.c
> > @@ -37,7 +37,7 @@ static int init_display(struct fbtft_par *par)
> > devcode = read_devicecode(par);
> > fbtft_par_dbg(DEBUG_INIT_DISPLAY, par, "Device code:
> > 0x%04X\n",
> > devcode);
> > - if ((devcode != 0x0000) && (devcode != 0x9320))
> > + if (devcode != 0x0000 && devcode != 0x9320)
> > dev_warn(par->info->device,
> > "Unrecognized Device code: 0x%04X
> > (expected
> > 0x9320)\n",
> > devcode);
> > diff --git a/drivers/staging/fbtft/fb_ra8875.c
> > b/drivers/staging/fbtft/fb_ra8875.c
> > index 398bdbf53c9a..4b79fb48c5f0 100644
> > --- a/drivers/staging/fbtft/fb_ra8875.c
> > +++ b/drivers/staging/fbtft/fb_ra8875.c
> > @@ -50,7 +50,7 @@ static int init_display(struct fbtft_par *par)
> >
> > par->fbtftops.reset(par);
> >
> > - if ((par->info->var.xres == 320) && (par->info->var.yres ==
> > 240)) {
> > + if (par->info->var.xres == 320 && par->info->var.yres ==
> > 240)
> > {
> > /* PLL clock frequency */
> > write_reg(par, 0x88, 0x0A);
> > write_reg(par, 0x89, 0x02);
> > @@ -74,8 +74,8 @@ static int init_display(struct fbtft_par *par)
> > write_reg(par, 0x1D, 0x0E);
> > write_reg(par, 0x1E, 0x00);
> > write_reg(par, 0x1F, 0x02);
> > - } else if ((par->info->var.xres == 480) &&
> > - (par->info->var.yres == 272)) {
> > + } else if (par->info->var.xres == 480 &&
> > + par->info->var.yres == 272) {
> > /* PLL clock frequency */
> > write_reg(par, 0x88, 0x0A);
> > write_reg(par, 0x89, 0x02);
> > @@ -111,7 +111,7 @@ static int init_display(struct fbtft_par *par)
> > write_reg(par, 0x04, 0x01);
> > mdelay(1);
> > /* horizontal settings */
> > - write_reg(par, 0x14, 0x4F);
> > +write_reg(par, 0x14, 0x4F);
> > write_reg(par, 0x15, 0x05);
> > write_reg(par, 0x16, 0x0F);
> > write_reg(par, 0x17, 0x01);
> > diff --git a/drivers/staging/fbtft/fb_ssd1325.c
> > b/drivers/staging/fbtft/fb_ssd1325.c
> > index 796a2ac3e194..69aa808c7e23 100644
> > --- a/drivers/staging/fbtft/fb_ssd1325.c
> > +++ b/drivers/staging/fbtft/fb_ssd1325.c
> > @@ -109,8 +109,6 @@ static int set_gamma(struct fbtft_par *par, u32
> > *curves)
> > {
> > int i;
> >
> > - fbtft_par_dbg(DEBUG_INIT_DISPLAY, par, "%s()\n", __func__);
> > -
> > for (i = 0; i < GAMMA_LEN; i++) {
> > if (i > 0 && curves[i] < 1) {
> > dev_err(par->info->device,
> > diff --git a/drivers/staging/fbtft/fb_tinylcd.c
> > b/drivers/staging/fbtft/fb_tinylcd.c
> > index 9469248f2c50..60cda57bcb33 100644
> > --- a/drivers/staging/fbtft/fb_tinylcd.c
> > +++ b/drivers/staging/fbtft/fb_tinylcd.c
> > @@ -38,7 +38,7 @@ static int init_display(struct fbtft_par *par)
> > write_reg(par, 0xE5, 0x00);
> > write_reg(par, 0xF0, 0x36, 0xA5, 0x53);
> > write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
> > - 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
> > + 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
> > write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
> > write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
> > udelay(250);
> > diff --git a/drivers/staging/fbtft/fbtft-bus.c
> > b/drivers/staging/fbtft/fbtft-bus.c
> > index 3d422bc11641..02d7dbd38678 100644
> > --- a/drivers/staging/fbtft/fbtft-bus.c
> > +++ b/drivers/staging/fbtft/fbtft-bus.c
> > @@ -62,9 +62,9 @@
> > out:
> > \
> > }
> >
> > \
> > EXPORT_SYMBOL(func);
> >
> > -define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
> > +define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8,)
> > define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16,
> > cpu_to_be16)
> > -define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
> > +define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16,)
> >
> > void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
> > {
> > @@ -85,7 +85,7 @@ void fbtft_write_reg8_bus9(struct fbtft_par *par,
> > int
> > len, ...)
> > if (len <= 0)
> > return;
> >
> > - if (par->spi && (par->spi->bits_per_word == 8)) {
> > + if (par->spi && par->spi->bits_per_word == 8) {
> > /* we're emulating 9-bit, pad start of buffer with
> > no-
> > ops
> > * (assuming here that zero is a no-op)
> > */
> > diff --git a/drivers/staging/fbtft/fbtft-core.c
> > b/drivers/staging/fbtft/fbtft-core.c
> > index 38845f23023f..98ffca49df81 100644
> > --- a/drivers/staging/fbtft/fbtft-core.c
> > +++ b/drivers/staging/fbtft/fbtft-core.c
> > @@ -216,8 +216,6 @@ static void fbtft_reset(struct fbtft_par *par)
> > if (!par->gpio.reset)
> > return;
> >
> > - fbtft_par_dbg(DEBUG_RESET, par, "%s()\n", __func__);
> > -
> > gpiod_set_value_cansleep(par->gpio.reset, 1);
> > usleep_range(20, 40);
> > gpiod_set_value_cansleep(par->gpio.reset, 0);
> > @@ -667,7 +665,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct
> > fbtft_display *display,
> > txbuflen = 0;
> >
> > #ifdef __LITTLE_ENDIAN
> > - if ((!txbuflen) && (bpp > 8))
> > + if (!txbuflen && bpp > 8)
> > txbuflen = PAGE_SIZE; /* need buffer for
> > byteswapping
> > */
> > #endif
> >
> > @@ -1053,8 +1051,6 @@ static int fbtft_verify_gpios(struct
> > fbtft_par
> > *par)
> > struct fbtft_platform_data *pdata = par->pdata;
> > int i;
> >
> > - fbtft_par_dbg(DEBUG_VERIFY_GPIOS, par, "%s()\n", __func__);
> > -
> > if (pdata->display.buswidth != 9 && par->startbyte == 0 &&
> > !par->gpio.dc) {
> > dev_err(par->info->device,
> > @@ -1159,7 +1155,6 @@ int fbtft_probe_common(struct fbtft_display
> > *display,
> > dev = &pdev->dev;
> >
> > if (unlikely(display->debug & DEBUG_DRIVER_INIT_FUNCTIONS))
> > - dev_info(dev, "%s()\n", __func__);
> >
> > pdata = dev->platform_data;
> > if (!pdata) {
> > --
> > 2.34.1
> >
> >
>
> 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 contains warnings and/or errors noticed by the
> scripts/checkpatch.pl tool.
>
>>> Per guidelines in Newbies site for this 1st submission
>>> picked up "CHECK" type fixes only. Other types in separate
>>> patch.
>>> Also Warnings were not fixed for following reasons as per
>>> PatchPhilosophy guidelines
>>> i) Warnings related to License issues ("Please avoid sending
>>> patches for the Licence related checkpatch.pl warnings. It
>>> requires lot more discussion by driver authors and companies
>>> before doing so and is not often preferred by maintainers to
>>> accept them when sent by newbies")
>>> ii) Warnings related Udelay skipped per Patch Philosophy guidance
>>> ("Changes to udelay are also better to avoid. It is hard to be
>>> sure that such changes are correct without access to the
>>> device for careful testing.")
>>> ERROR type will be a separate patch and not included in this
>>> first patch is contains only "CHECK"
> - Your patch is malformed (tabs converted to spaces, linewrapped,
> etc.)
> and can not be applied. Please read the file,
> Documentation/process/email-clients.rst in order to fix this.
>
> - Your patch was attached, please place it inline so that it can be
> applied directly from the email message itself.
>
>>> Sent it using Evolution as per instruction in the above document
>>> Created Patch using git format-patch command
>>> In Evolution set the Format->Paragraph Style to Preformatted
>>> Then Insert Text file and picked the file formatted by git
>>> having issues in connecting mutt or git sendmail to yahoo email
>>> Trying to get it resolved.
>>> Help from anyone with similar exp welcome.
> - Your patch did many different things all at once, making it
> difficult
> to review. All Linux kernel patches need to only do one thing at a
> time. If you need to do multiple things (such as clean up all
> coding
> style issues in a file/driver), do it in a sequence of patches,
> each
> one doing only one thing. This will make it easier to review the
> patches to ensure that they are correct, and to help alleviate any
> merge issues that larger patches can cause.
>
>>> Will correct it and use patchset concept and resend it again
> - You did not specify a description of why the patch is needed, or
> possibly, any description at all, in the email body. Please read
> the
> section entitled "The canonical patch format" in the kernel file,
> Documentation/process/submitting-patches.rst for what is needed in
> order to properly describe the change.
>
>>> Had description in the body. Any help to refine/reformat welcome
> - You did not write a descriptive Subject: for the patch, allowing
> Greg,
> and everyone else, to know what this patch is all about. Please
> read
> the section entitled "The canonical patch format" in the kernel
> file,
> Documentation/process/submitting-patches.rst for what a proper
> Subject: line should look like.
>
>>> Tried best to put the subject as per document. However
>>> In the body of the mail I see [PATCH] [PATCH] repeated twice
>>> Help to refine/reformat this welcome. The beginning of this
>>> email shows what went out originally
> 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
