[QUESTION] fan rpm hwmon driver

[QUESTION] fan rpm hwmon driver

[Barnabás Pőcze]

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.

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.

I send my mail to the hwmon mailing list, because after all, it is about a hwmon module, but if it is not the correct place, please point me in the right direction.

I would greatly appreciate if anyone could help me. Thank you for your time.


Barnabás Pőcze

Re: [QUESTION] fan rpm hwmon driver

[Guenter Roeck]

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
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.

> 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

Re: [QUESTION] fan rpm hwmon driver

[Barnabás Pőcze]

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).


> > 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

Re: [QUESTION] fan rpm hwmon driver

[Guenter Roeck]

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

> 
>>> 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
> 

Re: [QUESTION] fan rpm hwmon driver

[Barnabás Pőcze]

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?

Furthermore, did it help answer the "who is going to maintain the driver after the initial submission" question of your previous email?


> > > > 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

Re: [QUESTION] fan rpm hwmon driver

[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 ?

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
> 

Re: [QUESTION] fan rpm hwmon driver

[Barnabás Pőcze]

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

Re: [QUESTION] fan rpm hwmon driver

[Guenter Roeck]

On 7/5/20 4:34 AM, Barnabás Pőcze wrote:
[ ... ]

>>
>>> 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?
> 
You would not have to forward patches upstream (I see them anyway), but
correct for the rest.

> I would certainly volunteer if it is needed.
> 
That would be great.

Something else that came to my mind: Did you examine the DSDT ?
If the board vendor did the right thing, it should include an abstract
means to read the fan data through ACPI. That would be much better than
having to read it from the EC directly.

Thanks,
Guenter

Re: [QUESTION] fan rpm hwmon driver

[Barnabás Pőcze]

2020. július 5., vasárnap 15:23 keltezéssel, Guenter Roeck írta:
> On 7/5/20 4:34 AM, Barnabás Pőcze wrote:
> [ ... ]
>
> > > > 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?
>
> You would not have to forward patches upstream (I see them anyway), but
> correct for the rest.
>

I see, thank you for the clarification.


> > I would certainly volunteer if it is needed.
>
> That would be great.
>
> Something else that came to my mind: Did you examine the DSDT ?
> If the board vendor did the right thing, it should include an abstract
> means to read the fan data through ACPI. That would be much better than
> having to read it from the EC directly.
>
> Thanks,
> Guenter


I agree that it would be better, I tried this approach because the Control Center software provided for Microsoft Windows uses direct port i/o, so I didn't really put much thought into the possible existence of an ACPI method to get the data, I am not familiar with ACPI either.

I did, at least I tried to examine the DSDT, but I could not really find anything fan related. Now I looked again, same results. Maybe it's that I don't know what exactly I should be looking for. And I feel like the acpi/fan driver should have picked it up, no? I could identify the EC, however. But I don't see anything relevant there, either. That's not to say there isn't, I just couldn't find it.


Barnabás Pőcze

Re: [QUESTION] fan rpm hwmon driver

[Guenter Roeck]

On Sun, Jul 05, 2020 at 02:43:46PM +0000, Barnabás Pőcze wrote:
> 2020. július 5., vasárnap 15:23 keltezéssel, Guenter Roeck írta:
> > On 7/5/20 4:34 AM, Barnabás Pőcze wrote:
> > [ ... ]
> >
> > > > > 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?
> >
> > You would not have to forward patches upstream (I see them anyway), but
> > correct for the rest.
> >
> 
> I see, thank you for the clarification.
> 
> 
> > > I would certainly volunteer if it is needed.
> >
> > That would be great.
> >
> > Something else that came to my mind: Did you examine the DSDT ?
> > If the board vendor did the right thing, it should include an abstract
> > means to read the fan data through ACPI. That would be much better than
> > having to read it from the EC directly.
> >
> > Thanks,
> > Guenter
> 
> 
> I agree that it would be better, I tried this approach because the Control Center software provided for Microsoft Windows uses direct port i/o, so I didn't really put much thought into the possible existence of an ACPI method to get the data, I am not familiar with ACPI either.
> 
> I did, at least I tried to examine the DSDT, but I could not really find anything fan related. Now I looked again, same results. Maybe it's that I don't know what exactly I should be looking for. And I feel like the acpi/fan driver should have picked it up, no? I could identify the EC, however. But I don't see anything relevant there, either. That's not to say there isn't, I just couldn't find it.
> 

No worries; at least you tried. Interesting that Windows doesn't use ACPI;
that is exactly what it is supposed to be used for, and Microsoft was
involved in writing its specification. Oh well, it is what it is.

Thanks,
Guenter