linux-kernel - Re: [PATCH] Watchdog: sp5100_tco: Replace watchdog cd6h/cd7h port I/O accesses with MMIO accesses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <YTYEDvTTrE5JXlk4@rric.localdomain>
Date:   Mon, 6 Sep 2021 14:05:34 +0200
From:   Robert Richter <rrichter@....com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Terry Bowman <Terry.Bowman@....com>,
        linux-watchdog@...r.kernel.org, wim@...ux-watchdog.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Watchdog: sp5100_tco: Replace watchdog cd6h/cd7h port
 I/O accesses with MMIO accesses

Guenter,

On 13.08.21 15:37:30, Guenter Roeck wrote:
> I am sorry, I don't understand why the new code can not use devm functions,

devm was not chosen here as the iomem is only used during
initialization. The resource is released at the end of it. Using devm
would keep it open and carry it around including its data until the
device is released which we wanted to avoid. This would also add
unnecessary data to struct sp5100_tco and/or the device's data.

> why the new data structure is necessary in the first place,

Instead we used struct efch_cfg to carry all that temporary data
required during initialization. This is destroyed at the end of
sp5100_tco_setupdevice().

> and why it is
> not possible to improve alignment with the existing code.

The driver serves 3 to 4 platforms now. To refactor it a core driver
is needed plus sub-drivers for each platform. We decided not to change
existing code here for older platforms and keep it as it is for them.

Moreover, the efch driver only needs changes to its initialization
code (using mmio instead of ioports), everything else remains the
same.

> This will require
> a substantial amount of time to review to ensure that the changes are not
> excessive (at first glance it for sure looks like that to me).

This patch implements mostly helper functions and adds alternative
code paths for the mmio case. For an easier review we could split the
patch in about 3-4 patches, would that help?

Thanks,

-Robert