linux-kernel - Re: [PATCH 7/8] rtc: rework rtc_register

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:   Wed, 18 Nov 2020 09:13:20 +0100
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>, linux-rtc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH 7/8] rtc: rework rtc_register_device() resource management

On Tue, Nov 17, 2020 at 10:35 PM Alexandre Belloni
<alexandre.belloni@...tlin.com> wrote:
>
> On 09/11/2020 17:34:08+0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bgolaszewski@...libre.com>
> >
> > rtc_register_device() is a managed interface but it doesn't use devres
> > by itself - instead it marks an rtc_device as "registered" and the devres
> > callback for devm_rtc_allocate_device() takes care of resource release.
> >
> > This doesn't correspond with the design behind devres where managed
> > structures should not be aware of being managed. The correct solution
> > here is to register a separate devres callback for unregistering the
> > device.
> >
> > While at it: rename rtc_register_device() to devm_rtc_register_device()
> > and add it to the list of managed interfaces in devres.rst. This way we
> > can avoid any potential confusion of driver developers who may expect
> > there to exist a corresponding unregister function.
> >
>
> I'm going to apply that but honestly, I don't like the fact that we now
> end up with both devm_rtc_device_register and devm_rtc_register_device.
> This was the main reason to not have the devm_ prefix there. I find that
> way more confusing than the current situation.
>

Yes, it's unfortunate that we have two similarly named functions but
devm_rtc_device_register() is deprecated and should go away right? In
that case it's just temporary. Additionally: since it's just a wrapper
around devm_rtc_allocate_device() and devm_rtc_register_device() now,
we should be able to just replace the code in the drivers with the
code from devm_rtc_device_register() and we may be able to get rid of
it soon?

Bartosz