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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ