>>>> @@ -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 -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
