On Tue, Apr 20, 2021 at 11:13:18AM CDT, Mark Brown wrote:
On Tue, Apr 20, 2021 at 10:19:04AM -0500, Zev Weiss wrote:
Mark, do you have any further input on what a viable approach might look
like?
I already suggested writing a driver or drivers that represent the
hardware you have, that advice remains. It's hard to follow what you
were trying to say with your long mail earlier today but it seems like
That email was an attempt to explain why writing a driver for the
specific hardware devices we're powering seems like a poor fit to me.
To summarize:
- There's a wide variety of different devices potentially behind an
LM25066.
- A hypothetical driver for any one of them would be completely
non-specific to that device and functionally identical to a driver
for any other, because the only hardware it would actually be
touching is the LM25066, and in ways that are again completely
non-specific to anything but the LM25066 itself.
you basically don't want to use any abstraction or framework, but that's
not really suitable for upstream integration
I'm not at all opposed to using a abstractions or frameworks (I'd very
much like to do so in fact). The problem is that I've thus far been
unable to determine exactly what the appropriate one is.
other hardware that looks similar to the end user should look similar
in the kernel too.
Agreed -- hence my disinclination to write drivers artificially specific
to whatever is behind the LM25066. What it looks like to the end user,
and I'd hope evetually the kernel as well, is a simple power switch and
nothing more.
Zev
