Re: [PATCH 3/4] powerpc/powernv: remove unused NPU DMA code
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2019-06-27 16:51:26
Also in:
lkml
On Thu, Jun 27, 2019 at 09:22:40AM +0200, Christoph Hellwig wrote:
On Thu, Jun 27, 2019 at 10:21:55AM +1000, Alexey Kardashevskiy wrote:quoted
quoted
Which comment? Last time I asked you complaint "it is still used in exactly the same way as before" which you later clarified that you have a hidden out of tree user somewhere, and you only objected toIt is not hidden, anyone can download and inspect that GPL driver.For one no one has ever posted a link. And second as mentioned countless times it doesn't matter, it only matters if it is in mainline, or as a special exception actively trying to go mainline.quoted
quoted
the word "dead". That has been fixed and there were no further comments.You still have it in the cover letter so at very least 3/4 is not a part of this patchset then. And I still want to see a formal statement about out-of-tree drivers support/tolerance. If you manage to remove this code, I'll have to post a revert (again and again) but I would rather know the exact list of what we do and what we do not do about such drivers and if the list 1) exists 2) is reasonable then I could try to come up with a better solution or point others to the policy and push them to do the right thing. Right now it is just you pretending that the nVidia driver does not exist, this is not helping. Thanks,We had that discussion at kernel summit and it was reported. Anyway, adding Greg, who usually has some pretty good prewritten letters for this kind of thing.
I used to have one but it's been so long since anyone tried to even think about defending the removal of functions that are not used in the kernel tree anymore, that I can't seem to find it anymore :) Christoph is completely correct here, if it isn't in the tree, it doesn't matter. We have made this "formal" statement again and again over the years, starting with the old "stable api nonsense" document that is in the kernel tree itself. And he is also correct in that we talked about this specific issue, in detail, at the maintainers summit last year, see lwn.net for the details if you somehow missed it then. thanks, greg k-h