* Question about nct6775 regarding MFD
@ 2025-06-16 10:34 Niedermayr, BENEDIKT
2025-06-16 12:14 ` Guenter Roeck
0 siblings, 1 reply; 3+ messages in thread
From: Niedermayr, BENEDIKT @ 2025-06-16 10:34 UTC (permalink / raw)
To: zev@bewilderbeest.net, jdelvare@suse.com, linux@roeck-us.net
Cc: Lopes Ivo, Diogo Miguel, Kiszka, Jan, linux-hwmon@vger.kernel.org,
linux-kernel@vger.kernel.org
Hi folks,
we are currently refactoring some parts of the
"drivers/platform/x86/siemens/*" which has references to some
Nuvoton Super-I/O chips. One of them is the nct6775.
The driver in question is not implemented as MFD, even though MFD would
have fit perfectly for it (or am I wrong?).
My question now:
Why wasn't the driver implemented as an MFD? Was MFD discussed during
your upstreaming-related conversations?
Kind regards,
Benedikt
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Question about nct6775 regarding MFD
2025-06-16 10:34 Question about nct6775 regarding MFD Niedermayr, BENEDIKT
@ 2025-06-16 12:14 ` Guenter Roeck
2025-06-16 14:48 ` Niedermayr, BENEDIKT
0 siblings, 1 reply; 3+ messages in thread
From: Guenter Roeck @ 2025-06-16 12:14 UTC (permalink / raw)
To: Niedermayr, BENEDIKT, zev@bewilderbeest.net, jdelvare@suse.com
Cc: Lopes Ivo, Diogo Miguel, Kiszka, Jan, linux-hwmon@vger.kernel.org,
linux-kernel@vger.kernel.org
On 6/16/25 03:34, Niedermayr, BENEDIKT wrote:
> Hi folks,
>
> we are currently refactoring some parts of the
> "drivers/platform/x86/siemens/*" which has references to some
>
> Nuvoton Super-I/O chips. One of them is the nct6775.
>
> The driver in question is not implemented as MFD, even though MFD would
> have fit perfectly for it (or am I wrong?).
>
>
> My question now:
>
> Why wasn't the driver implemented as an MFD? Was MFD discussed during
> your upstreaming-related conversations?
>
Super-IO chips have historically not been implemented as MFD since the functionality
is well separated except for configuration register access, and that is well handled
with the various superio_enter() functions which use a multiplexed memory region
to (temporarily) request chip access. Implementing those drivers as MFD would only
add complexity with no gain or benefit.
Guenter
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Question about nct6775 regarding MFD
2025-06-16 12:14 ` Guenter Roeck
@ 2025-06-16 14:48 ` Niedermayr, BENEDIKT
0 siblings, 0 replies; 3+ messages in thread
From: Niedermayr, BENEDIKT @ 2025-06-16 14:48 UTC (permalink / raw)
To: Guenter Roeck, zev@bewilderbeest.net, jdelvare@suse.com
Cc: Lopes Ivo, Diogo Miguel, Kiszka, Jan, linux-hwmon@vger.kernel.org,
linux-kernel@vger.kernel.org
On 16.06.25 14:14, Guenter Roeck wrote:
> On 6/16/25 03:34, Niedermayr, BENEDIKT wrote:
>> Hi folks,
>>
>> we are currently refactoring some parts of the
>> "drivers/platform/x86/siemens/*" which has references to some
>>
>> Nuvoton Super-I/O chips. One of them is the nct6775.
>>
>> The driver in question is not implemented as MFD, even though MFD would
>> have fit perfectly for it (or am I wrong?).
>>
>>
>> My question now:
>>
>> Why wasn't the driver implemented as an MFD? Was MFD discussed during
>> your upstreaming-related conversations?
>>
>
> Super-IO chips have historically not been implemented as MFD since the
> functionality
> is well separated except for configuration register access, and that is
> well handled
> with the various superio_enter() functions which use a multiplexed
> memory region
> to (temporarily) request chip access. Implementing those drivers as MFD
> would only
> add complexity with no gain or benefit.
>
> Guenter
>
Hi Guenter,
thanks for the quick response.
Made it clear to me!
Regards,
Benedikt
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-06-16 14:49 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-16 10:34 Question about nct6775 regarding MFD Niedermayr, BENEDIKT
2025-06-16 12:14 ` Guenter Roeck
2025-06-16 14:48 ` Niedermayr, BENEDIKT
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).