Re: [PATCH v2 1/1] misc: hpilo: switch .{read,write} ops to .{read,write}_iter

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Jul 15, 2022 at 04:55:57PM +0800, Matt Hsiao wrote:
> On Wed, Jul 13, 2022 at 08:28:24PM +0200, Greg KH wrote:
> > But my main question is I have no idea what the changelog means here.
> > What is a "dependent driver"?  What does "exclusive" mean here?  What is
> > a iter variant?
> 
> There is an out-of-box driver which is not in the upstream kernel yet
> that uses kernel_{read,write} to access the hpilo driver for talking
> to the iLO ASIC. Before commit 4d03e3cc59828c82ee89 ("fs: don't allow kernel
> reads and writes without iter ops"), kernel_{read,write} would call the
> .{read,write} file ops that hpilo already implemented, so there was no problem;
> But after that commit, kernel_{read,write} would only allow the .{read,write}_iter
> file ops, and disallowed the coexistence of .{read,write} file ops. Accessing
> hpilo now fails since it does not have the .{read,write}_iter file ops. To make it
> work, this patch implements the .{read,write}_iter file ops and removed the
> .{read,write} ones.

For obvious reasons, we can not take any changes for any out-of-tree
code.  Nor would you ever want me to do so.

So we can't take this, sorry.  Please work with your management to get
the drivers upstream and then we will be glad to take these types of
changes, as they well know the price they have to pay to have
out-of-tree code.

Also, your management knows we can't take changes for out-of-tree code.
They know better than to put you into this uncomfortable position.  This
is on them, not you, to resolve.  I suggest you have a stern talking to
with them as they are at fault here.

good luck!

greg k-h