Re: [QUESTION] fan rpm hwmon driver

["Barnabás Pőcze" <pobrn@protonmail.com>]

2020. július 5., vasárnap 1:56 keltezéssel, Guenter Roeck:
> On 7/4/20 4:08 PM, Barnabás Pőcze wrote:
>
> > 2020.  július 5., vasárnap 0:44 keltezéssel, Guenter Roeck írta:
> >
> > > On 7/4/20 2:25 PM, Barnabás Pőcze wrote:
> > >
> > > > 2020.  július 4., szombat 22:54 keltezéssel, Guenter Roeck írta:
> > > >
> > > > > On 7/4/20 12:50 PM, Barnabás Pőcze wrote:
> > > > >
> > > > > > Hello all,
> > > > > > I am completely new to Linux kernel development. I have written a kernel module for my laptop that integrates the fan speeds available in the embedded controller memory into the hwmon subsystem.
> > > > > > My first question would be: can such a driver be merged into the mainline? I ask this because it is a device specific driver, and I am not sure if such drivers are wanted in the mainline.
> > > > >
> > > > > There are several device/platform specific drivers in drivers/hwmon;
> > > > > that is not a problem. Question is more how the EC is accessed, and
> > > >
> > > > It is accessed using the acpi/ec driver.
> > > >
> > > > > who is going to maintain the driver after the initial submission.
> > > > > This might be easier to evaluate if we had a patch or a pointer to,
> > > > > for example, an out-of-tree driver at a public repository site such
> > > > > as github.
> > > >
> > > > I uploaded it to github, I hope it helps: https://github.com/pobrn/xmg_fusion_15_fans
> > > > I apologize for stylistic inconsistencies and such in the code, this is more or less a work in progress (at least in terms of making it an "acceptable" kernel module).
> > >
> > > Way too noisy, way too too many empty lines, and you should drop the "nodetect"
> > > module option as it is way too risky. Otherwise I don't have major problems
> > > with it.
> > > Guenter
> >
> > Thank you for the feedback, I will definitely try to fix those problems if I submit it as a patch. What I gather from your response is that it is possible that such driver is included under drivers/hwmon, correct?
>
> Correct.
>
> > Furthermore, did it help answer the "who is going to maintain the driver after the initial submission" question of your previous email?
>
> A driver is not write-and-forget. It has to be maintained, preferably by someone
> with access to the hardware. Otherwise it is going to bit-rot. Do you plan to
> volunteer to do that ?
>

I have no clue what that entails, but I am assuming: fixing bugs, accepting, reviewing patches for that driver, then forwarding them upstream, maybe also updating the code base according to the best practices at the moment from time to time, correct?

I would certainly volunteer if it is needed.


Barnabás Pőcze


> Thanks,
> Guenter
>
> > > > > > Depending on the answer to my first question, my second question is: where should such a driver reside in the source tree? Initially, I thought of drivers/hwmon, but that seems to be occupied by drivers for external(?) devices (I am not sure, but that is the idea I get). So I am now thinking of drivers/platform/x86. However, I have failed to find any fan hwmon drivers there, so I am not sure about that one, either.
> > > > >
> > > > > hwmon drivers should in general reside in drivers/hwmon, unless hardware
> > > > > monitoring functionality is part of other functionality and would be
> > > > > difficult to extract from the main driver (example: various Ethernet
> > > > > or graphics controllers).
> > > > > Guenter
> > > >
> > > > Thanks for the reply.
> > > > Barnabás Pőcze
> >
> > Barnabás Pőcze