From: Dan Carpenter <dan.carpenter@oracle.com>
To: Matt Sickler <Matt.Sickler@daktronics.com>
Cc: Chandra Annamaneni <chandra627@gmail.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
"gneukum1@gmail.com" <gneukum1@gmail.com>,
"fabian.krueger@fau.de" <fabian.krueger@fau.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"simon@nikanor.nu" <simon@nikanor.nu>
Subject: Re: [PATCH] KPC2000: kpc2000_spi.c: Fix style issues (line length)
Date: Fri, 11 Oct 2019 13:02:14 +0300 [thread overview]
Message-ID: <20191011100214.GO13286@kadam> (raw)
In-Reply-To: <SN6PR02MB40166D599A07440D26EBE7F1EE940@SN6PR02MB4016.namprd02.prod.outlook.com>
On Thu, Oct 10, 2019 at 02:54:59PM +0000, Matt Sickler wrote:
> > static struct mtd_partition p2kr0_spi1_parts[] = {
> >- { .name = "SLOT_4", .size = 7798784, .offset = 0, },
> >- { .name = "SLOT_5", .size = 7798784, .offset = MTDPART_OFS_NXTBLK},
> >- { .name = "SLOT_6", .size = 7798784, .offset = MTDPART_OFS_NXTBLK},
> >- { .name = "SLOT_7", .size = 7798784, .offset = MTDPART_OFS_NXTBLK},
> >- { .name = "CS1_EXTRA", .size = MTDPART_SIZ_FULL, .offset = MTDPART_OFS_NXTBLK},
> >+ { .name = "SLOT_4", .size = 7798784, .offset = 0,},
> >+ { .name = "SLOT_5", .size = 7798784, .offset = MTDPART_OFS_NXTBLK},
> >+ { .name = "SLOT_6", .size = 7798784, .offset = MTDPART_OFS_NXTBLK},
> >+ { .name = "SLOT_7", .size = 7798784, .offset = MTDPART_OFS_NXTBLK},
> >+ { .name = "CS1_EXTRA", .size = MTDPART_SIZ_FULL, .offset = MTDPART_OFS_NXTBLK},
> > };
> >
> > static struct flash_platform_data p2kr0_spi0_pdata = {
>
> Is the line length limit a hard rule or can exceptions be made? I
> really feel that these data tables are more easily read when they're
> formatted like tables...
Exceptions can be made. It's probably not worth it though because
you have to be really aggressive about shooting down patches. Ask
yourself if there aren't more important battles to fight when human
lifespans are so short? I already rejected one change for you. To me
the new table looks okay, though.
regards,
dan carpenter
prev parent reply other threads:[~2019-10-11 10:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 3:08 [PATCH] KPC2000: kpc2000_spi.c: Fix style issues (line length) Chandra Annamaneni
2019-10-10 8:41 ` Greg KH
2019-10-10 14:54 ` Matt Sickler
2019-10-11 10:02 ` Dan Carpenter [this message]
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=20191011100214.GO13286@kadam \
--to=dan.carpenter@oracle.com \
--cc=Matt.Sickler@daktronics.com \
--cc=chandra627@gmail.com \
--cc=devel@driverdev.osuosl.org \
--cc=fabian.krueger@fau.de \
--cc=gneukum1@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=simon@nikanor.nu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox