On Thu, Jul 1, 2021 at 2:03 PM Ian Pilcher [off-list ref] wrote:

On 7/1/21 12:59 PM, Greg KH wrote:

quoted

Oh that's horrible, please no, do not do that :)

Indeed it is, but it works, and it meets my main objective, which is to
allow the use of distribution kernel packages and modules.

quoted

How about a third option, the correct one:
      - submit your code changes upstream and they get merged into the
        main kernel tree and no monkeypatching is ever needed at all!

Have you submitted your changes upstream to the existing drivers?  What
is preventing that from happening today?

There are a couple of reasons that I've never attempted to do this.

* Scope of work - Currently, there is simply no mechanism to call an LED
* (Probable) lack of upstream interest - As I mentioned, disk activity
   LEDs really ought to be handled by the hardware.

Are LEDs really that important?
Unless theyre rigged intrinsically into the operation, it seems tertiary



  I don't know of any

   other system that suffers from this particular limitation.  So this
   is a very, very niche use case.  (Most users of this hardware use the
   manufacturer's "firmware".)

   I did ask about this on the linux-ide mailing list long ago when I
   first wrote the modules, but I don't think that I ever received a
   response, which reinforces my belief that upstream isn't likely to be
   receptive.

theres a firehose of patches.

FWIW, now robots watch the list, and will grind your patches on lots
of configs. arches

I've invested significant time in kernel patches in the past, only to
see them ultimately not be accepted, so I would need to know that
upstream was truly interested in such a feature before I would consider
making such a commitment.

no guarantees, but there is staging. (here, more or less)
provisional home for code while quality develops
once youre in-tree, warts and all (to some extent, I dont know)
you may well get help (patches) improving it, surely lots of feedback.



elsewhere, nobody knows it exists.