[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <edff3ca7-b2f8-45fc-adf5-539d25e1de32@siemens.com>
Date: Mon, 16 Jun 2025 14:48:59 +0000
From: "Niedermayr, BENEDIKT" <benedikt.niedermayr@...mens.com>
To: Guenter Roeck <linux@...ck-us.net>, "zev@...ilderbeest.net"
<zev@...ilderbeest.net>, "jdelvare@...e.com" <jdelvare@...e.com>
CC: "Lopes Ivo, Diogo Miguel" <diogo.ivo@...mens.com>, "Kiszka, Jan"
<jan.kiszka@...mens.com>, "linux-hwmon@...r.kernel.org"
<linux-hwmon@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: Question about nct6775 regarding MFD
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
Powered by blists - more mailing lists