Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1381413 > unrolled thread

Re: [PATCH V4 4/6] slim: qcom: Add Qualcomm Slimbus controller driver

Started byMark Brown <broonie@kernel.org>
First post2016-04-18 11:30 +0200
Last post2016-04-19 00:50 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH V4 4/6] slim: qcom: Add Qualcomm Slimbus controller driver Mark Brown <broonie@kernel.org> - 2016-04-18 11:30 +0200
    Re: [PATCH V4 4/6] slim: qcom: Add Qualcomm Slimbus controller driver Sagar Dharia <sdharia@codeaurora.org> - 2016-04-19 00:50 +0200

#1381413 — Re: [PATCH V4 4/6] slim: qcom: Add Qualcomm Slimbus controller driver

FromMark Brown <broonie@kernel.org>
Date2016-04-18 11:30 +0200
SubjectRe: [PATCH V4 4/6] slim: qcom: Add Qualcomm Slimbus controller driver
Message-ID<rpdFi-32l-21@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 15, 2016 at 10:17:36AM -0600, Sagar Dharia wrote:

Please leave blank lines between paragraphs, it makes things much easier
to read than a wall of uninterrupted text.

> >>+	ret = devm_request_irq(&pdev->dev, dev->irq, msm_slim_interrupt,
> >>+				IRQF_TRIGGER_HIGH, "msm_slim_irq", dev);
> >>+	if (ret) {
> >>+		dev_err(&pdev->dev, "request IRQ failed\n");
> >>+		goto err_request_irq_failed;
> >>+	}

> >Are you sure this is safe and we don't deallocate things the interrupt
> >handler uses before we disable the interrupt?

> Since clock is not enabled before this step, we won't be getting any
> interrupts from HW at this stage.

No, that's not what I'm saying - I'm asking about the *disable* path on
remove.

[toc] | [next] | [standalone]


#1382092

FromSagar Dharia <sdharia@codeaurora.org>
Date2016-04-19 00:50 +0200
Message-ID<rpq9s-4YY-7@gated-at.bofh.it>
In reply to#1381413
On 4/18/2016 3:19 AM, Mark Brown wrote:
> On Fri, Apr 15, 2016 at 10:17:36AM -0600, Sagar Dharia wrote:
>
> Please leave blank lines between paragraphs, it makes things much easier
> to read than a wall of uninterrupted text.
>
>>>> +	ret = devm_request_irq(&pdev->dev, dev->irq, msm_slim_interrupt,
>>>> +				IRQF_TRIGGER_HIGH, "msm_slim_irq", dev);
>>>> +	if (ret) {
>>>> +		dev_err(&pdev->dev, "request IRQ failed\n");
>>>> +		goto err_request_irq_failed;
>>>> +	}
>>> Are you sure this is safe and we don't deallocate things the interrupt
>>> handler uses before we disable the interrupt?
>> Since clock is not enabled before this step, we won't be getting any
>> interrupts from HW at this stage.
> No, that's not what I'm saying - I'm asking about the *disable* path on
> remove.
Good point, I will change the del_controller as well to enter clock-pause,
and the controller's remove function to disable interrupt.

Thanks
Sagar

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web