From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Martyn Welch <martyn@welchs.me.uk>, devel <devel@driverdev.osuosl.org>
Cc: Aaron Sierra <asierra@xes-inc.com>,
Alessio Igor Bogani <alessio.bogani@elettra.eu>,
Arnd Bergmann <arnd@arndb.de>,
Augusto Mecking Caringi <augustocaringi@gmail.com>,
Baoyou Xie <baoyou.xie@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Manohar Vanga <manohar.vanga@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 13/14] vme: tsi148: Improve 17 size determinations
Date: Wed, 30 Aug 2017 22:56:54 +0200 [thread overview]
Message-ID: <4cd218be-0b0e-bf9c-e65a-1ba3dd57fc26@users.sourceforge.net> (raw)
In-Reply-To: <CAEccXeea6760kaDw5pLEqDJuLwG3PbFvCKCxY2_PGAe3bJ-YxA@mail.gmail.com>
>>>> @@ -2363,5 +2364,5 @@ static int tsi148_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>>>> master_num--;
>>>>
>>>> tsi148_device->flush_image =
>>>> - kmalloc(sizeof(struct vme_master_resource), GFP_KERNEL);
>>>> + kmalloc(sizeof(*tsi148_device->flush_image), GFP_KERNEL);
>>>
>>> This line is now a tiny bit too long
>>
>> Can you eventually tolerate a line length of 81 characters at such a source code place?
>>
>
> I think there's some irony here. On the one hand you are submitting
> patches that correct coding style issues, on the other you are asking
> whether we can ignore the coding style...
I test somehow how strict you would like to handle the length limit there.
I imagine that the affected source code formatting could also become different
if the involved variable name would be shorter.
>> * It seems that you would not like to perform such a tweak yourself.
>
> To be honest, it is quicker and easier in this instance to do just that.
Interesting …
> So that's now done.
Thanks that you picked some of my ideas up.
> Patches now in my testing branch:
>
> https://gitlab.collabora.com/martyn/linux/commits/vme-testing
I am curious on how the shown change possibilities will evolve from
this repository.
>> * Do you expect a resend for the complete patch series?
>>
>
> Unless the maintainer has commented that they have accepted patches x,
> y and z, then sending the entire series again is generally the right
> thing to do.
Would you like to respond further to Greg's comments (from 2017-08-26)
for this patch series?
Regards,
Markus
next prev parent reply other threads:[~2017-08-30 20:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-25 15:41 [PATCH 00/14] VME: Adjustments for several function implementations SF Markus Elfring
2017-08-25 15:51 ` [PATCH 01/14] vme: Delete 11 error messages for a failed memory allocation SF Markus Elfring
2017-08-25 15:53 ` [PATCH 02/14] vme: Improve 11 size determinations SF Markus Elfring
2017-08-25 15:57 ` [PATCH 03/14] vme: Move an assignment in vme_new_dma_list() SF Markus Elfring
2017-08-25 15:59 ` [PATCH 04/14] vme: Adjust 48 checks for null pointers SF Markus Elfring
2017-08-25 16:00 ` [PATCH 05/14] vme: Return directly in two functions SF Markus Elfring
2017-08-25 16:02 ` [PATCH 06/14] vme: fake: Delete an error message for a failed memory allocation in fake_init() SF Markus Elfring
2017-08-25 16:03 ` [PATCH 07/14] vme: fake: Improve five size determinations " SF Markus Elfring
2017-08-25 16:05 ` [PATCH 08/14] vme: fake: Adjust 11 checks for null pointers SF Markus Elfring
2017-08-25 16:06 ` [PATCH 09/14] vme: ca91cx42: Delete eight error messages for a failed memory allocation SF Markus Elfring
2017-08-25 16:08 ` [PATCH 10/14] vme: ca91cx42: Improve 12 size determinations SF Markus Elfring
2017-08-25 16:10 ` [PATCH 11/14] vme: ca91cx42: Adjust 14 checks for null pointers SF Markus Elfring
2017-08-25 16:13 ` [PATCH 12/14] vme: tsi148: Delete nine error messages for a failed memory allocation SF Markus Elfring
2017-08-25 16:15 ` [PATCH 13/14] vme: tsi148: Improve 17 size determinations SF Markus Elfring
2017-08-25 20:57 ` Martyn Welch
2017-08-26 7:00 ` SF Markus Elfring
2017-08-30 19:47 ` Martyn Welch
2017-08-30 20:56 ` SF Markus Elfring [this message]
2017-08-25 16:17 ` [PATCH 14/14] vme: tsi148: Adjust 14 checks for null pointers SF Markus Elfring
2017-08-25 21:50 ` [PATCH 00/14] VME: Adjustments for several function implementations Martyn Welch
2017-08-26 7:04 ` Greg Kroah-Hartman
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=4cd218be-0b0e-bf9c-e65a-1ba3dd57fc26@users.sourceforge.net \
--to=elfring@users.sourceforge.net \
--cc=alessio.bogani@elettra.eu \
--cc=arnd@arndb.de \
--cc=asierra@xes-inc.com \
--cc=augustocaringi@gmail.com \
--cc=baoyou.xie@linaro.org \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manohar.vanga@gmail.com \
--cc=martyn@welchs.me.uk \
/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