public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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