linux-kernel - Re: [PATCH 5/7] regulator: qcom-labibb: Implement short-circuit and over-current IRQs

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: <20210111135745.GC4728@sirena.org.uk>
Date:   Mon, 11 Jan 2021 13:57:45 +0000
From:   Mark Brown <broonie@...nel.org>
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>
Cc:     linux-arm-msm@...r.kernel.org, agross@...nel.org,
        bjorn.andersson@...aro.org, lgirdwood@...il.com,
        robh+dt@...nel.org, sumit.semwal@...aro.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        phone-devel@...r.kernel.org, konrad.dybcio@...ainline.org,
        marijn.suijten@...ainline.org, martin.botka@...ainline.org
Subject: Re: [PATCH 5/7] regulator: qcom-labibb: Implement short-circuit and
 over-current IRQs

On Sat, Jan 09, 2021 at 02:29:19PM +0100, AngeloGioacchino Del Regno wrote:

> +	/* If the regulator is not enabled, this is a fake event */
> +	if (!ops->is_enabled(vreg->rdev))
> +		return 0;

Or handling the interrupt raced with a disable initiated from elsewhere.
Does the hardware actually have a problem with reporting spurious errors?

> +	return ret ? IRQ_NONE : IRQ_HANDLED;

Here and elsewhere please write normal conditional statements to improve
legibility.

> +	/* This function should be called only once, anyway. */
> +	if (unlikely(vreg->ocp_irq_requested))
> +		return 0;

If this is not a fast path it doesn't need an unlikely() annotation;
indeed it sounds more like there should be a warning printed if this
isn't supposed to be called multiple times.

> +	/* IRQ polarities - LAB: trigger-low, IBB: trigger-high */
> +	if (vreg->type == QCOM_LAB_TYPE) {
> +		irq_flags |= IRQF_TRIGGER_LOW;
> +		irq_trig_low = 1;
> +	} else {
> +		irq_flags |= IRQF_TRIGGER_HIGH;
> +		irq_trig_low = 0;
> +	}

This would be more clearly written as a switch statement.

> +	return devm_request_threaded_irq(vreg->dev, vreg->ocp_irq, NULL,
> +					 qcom_labibb_ocp_isr, irq_flags,
> +					 ocp_irq_name, vreg);

Are you *sure* that devm_ is appropriate here and the interrupt handler
won't attempt to use things that will be deallocated before devm gets
round to freeing the interrupt?

> +		if (!!(val & LABIBB_CONTROL_ENABLE)) {

The !! is redundant here and makes things less clear.

> @@ -166,8 +560,37 @@ static int qcom_labibb_of_parse_cb(struct device_node *np,
>  				   struct regulator_config *config)
>  {
>  	struct labibb_regulator *vreg = config->driver_data;
> +	char *sc_irq_name;

I really, really wouldn't expect to see interrupts being requested in
the DT parsing callback - apart from anything else the device is going
to have the physical interrupts with or without DT binding information.
These callbacks are for regulator specific properties, not basic probing.
Just request the interrupts in the main probe function, this also means
you can avoid using all the DT specific APIs which are generally a
warning sign.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)