linux-kernel - Re: [PATCH 07/11] iio: adc: Add support for QCOM PMIC5 Gen3 ADC

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA8EJprb=804S=GfxPw_7AxoHRO1XzC+wGPCsvNGrRpJgj+y6A@mail.gmail.com>
Date:   Mon, 23 Oct 2023 11:03:46 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Jishnu Prakash <quic_jprakash@...cinc.com>
Cc:     Jonathan Cameron <jic23@...nel.org>, agross@...nel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linus.walleij@...aro.org, Jonathan.Cameron@...wei.com,
        sboyd@...nel.org, quic_subbaram@...cinc.com,
        quic_collinsd@...cinc.com, quic_kamalw@...cinc.com,
        marijn.suijten@...ainline.org, andriy.shevchenko@...ux.intel.com,
        krzysztof.kozlowski@...aro.org,
        Lars-Peter Clausen <lars@...afoo.de>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        Cosmin Tanislav <demonsingur@...il.com>,
        Mike Looijmans <mike.looijmans@...ic.nl>,
        Ramona Bolboaca <ramona.bolboaca@...log.com>,
        ChiYuan Huang <cy_huang@...htek.com>,
        Ibrahim Tilki <Ibrahim.Tilki@...log.com>,
        William Breathitt Gray <william.gray@...aro.org>,
        Lee Jones <lee@...nel.org>,
        Leonard Göhrs <l.goehrs@...gutronix.de>,
        Haibo Chen <haibo.chen@....com>, linux-iio@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-arm-msm-owner@...r.kernel.org
Subject: Re: [PATCH 07/11] iio: adc: Add support for QCOM PMIC5 Gen3 ADC

On Mon, 23 Oct 2023 at 09:15, Jishnu Prakash <quic_jprakash@...cinc.com> wrote:
>
> Hi Jonathan,
>
> On 7/8/2023 9:29 PM, Jonathan Cameron wrote:
> > On Sat, 8 Jul 2023 12:58:31 +0530
> > Jishnu Prakash <quic_jprakash@...cinc.com> wrote:

> >> +
> >> +    ret = adc5_get_fw_data(adc);
> >> +    if (ret < 0) {
> >> +            dev_err(adc->dev, "adc get dt data failed, ret=%d\n", ret);
> >> +            return ret;
> >> +    }
> >> +
> >> +    for (i = 0; i < adc->num_sdams; i++) {
> >> +            ret = devm_request_irq(dev, adc->base[i].irq, adc5_gen3_isr,
> >> +                                    0, adc->base[i].irq_name, adc);
> >> +            if (ret < 0) {
> >> +                    dev_err(adc->dev, "Getting IRQ %d failed, ret=%d\n", adc->base[i].irq, ret);
> >> +                    return ret;
> >> +            }
> >> +    }
> >> +
> >> +    ret = adc_tm_register_tzd(adc);
> >> +    if (ret < 0)
> >> +            return ret;
> >> +
> >> +    if (adc->n_tm_channels)
> >> +            INIT_WORK(&adc->tm_handler_work, tm_handler_work);
> >> +
> >> +    indio_dev->name = pdev->name;
> >> +    indio_dev->modes = INDIO_DIRECT_MODE;
> >> +    indio_dev->info = &adc5_gen3_info;
> >> +    indio_dev->channels = adc->iio_chans;
> >> +    indio_dev->num_channels = adc->nchannels;
> >> +
> >> +    return devm_iio_device_register(dev, indio_dev);
> >> +}
> >> +
> >> +static int adc5_gen3_exit(struct platform_device *pdev)
> >> +{
> > As you are mixing devm manged cleanup and the explicit sort the
> > result is that you remove the userspace interfaces 'after' you run
> > everything in here. I'm thinking disabling the channels at least
> > isn't a good idea in that case.
> >
> > If you want to use devm (which is good) then you need to work out how
> > to register additional callbacks during probe to tear down everything in
> > the right order (typically the reverse of what happens in probe)
> > devm_add_action_or_reset() is the way to add those extra callbacks.
> >
> > If not, just don't use devm for at least those bits that will end up
> > running out of order (such as iio_device_register()) and manually call their
> > cleanup routines instead.
>
>
> I checked some other examples in the iio/adc/ folder, I think I see what
> you mean here. It looks like drivers with a remove callback always use
> iio_device_register and iio_device_unregister instead of the devm_*
> variant, due to the issue with sysfs removal as you said.
>
> I'll update the probe and remove functions similarly, to do explicit
> cleanups as required, avoiding devm_ usage for places where it should be
> avoided.

I think you got the message all wrong. There is nothing bad with using
devm_. As a matter of fact it is a preferred form in most of the
cases. However you have to be careful to tear down your device in the
correct order. And as Jonathan pointed
out, you might add necessary hooks manually by calling
devm_add_action_or_reset().

[skipped the rest]



-- 
With best wishes
Dmitry