Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1214175
| From | Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: CONFIG_DEBUG_SHIRQ and PM |
| Date | 2015-08-26 22:40 +0200 |
| Message-ID | <q1PEe-89i-13@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <q1OI9-6NZ-13@gated-at.bofh.it> <q1P1v-7aJ-1@gated-at.bofh.it> <q1Pbc-7Bp-23@gated-at.bofh.it> <q1PkS-7My-17@gated-at.bofh.it> <q1Puy-7Y2-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 26 August 2015 at 17:24, Felipe Balbi <balbi@ti.com> wrote:
[..]
>>
>> static irqreturn_t tw68_irq(int irq, void *dev_id)
>> {
>> struct tw68_dev *dev = dev_id;
>> u32 status, orig;
>> int loop;
>>
>> status = orig = tw_readl(TW68_INTSTAT) & dev->pci_irqmask;
>
> Now try to read that register when your clock is gated. That's the
> problem I'm talking about. Everything about the handler is functioning
> correctly; however clocks are gated in ->remove() and free_irq() is
> only called *AFTER* ->remove() has returned.
>
Yeah, it's pretty clear you are talking about clocks here. That's
why I said "read won't stall" in the next paragraph.
>> [etc]
>> }
>>
>> The IRQ handler accesses the device struct and then
>> reads through PCI. So if you use devm_request_irq
>> you need to make sure the device struct is still allocated
>> after remove(), and the PCI read won't stall or crash.
>
> dude, that's not the problem I'm talking about. I still have my
> private_data around, what I don't have is:
>
> _ _
> __ _ ___| | ___ ___| | __
> / _` | / __| |/ _ \ / __| |/ /
> | (_| | | (__| | (_) | (__| <
> \__,_| \___|_|\___/ \___|_|\_\
>
>
Yes, *you* may have your private data around and have a clock gated,
others (the tw68 for instance) may have its region released and unmapped.
And yet others may have $whatever resource released in the
remove() and assume it's available in the IRQ handler.
I honestly can't think why using request_irq / free_irq to solve this
is a workaround.
>> Interestingly, tw68 uses devm_request_irq with IRQF_SHARED :-)
>>
>> Still, I don't think that's a good idea, since it relies on
>> the IRQ being freed *before* the device struct.
>
> that's not an issue at all. If you're using devm_request_irq() you're
> likely using devm_kzalloc() for the device struct anyway. Also, you
> called devm_kzalloc() before devm_request_irq() so IRQ *will* be freed
> before your private data; there's nothing wrong there.
>
--
Ezequiel GarcĂa, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
CONFIG_DEBUG_SHIRQ and PM Felipe Balbi <balbi@ti.com> - 2015-08-25 22:00 +0200
Re: CONFIG_DEBUG_SHIRQ and PM Felipe Balbi <balbi@ti.com> - 2015-08-26 21:40 +0200
Re: CONFIG_DEBUG_SHIRQ and PM Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> - 2015-08-26 22:00 +0200
Re: CONFIG_DEBUG_SHIRQ and PM Felipe Balbi <balbi@ti.com> - 2015-08-26 22:10 +0200
Re: CONFIG_DEBUG_SHIRQ and PM Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> - 2015-08-26 22:20 +0200
Re: CONFIG_DEBUG_SHIRQ and PM Felipe Balbi <balbi@ti.com> - 2015-08-26 22:30 +0200
Re: CONFIG_DEBUG_SHIRQ and PM Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> - 2015-08-26 22:40 +0200
Re: CONFIG_DEBUG_SHIRQ and PM Felipe Balbi <balbi@ti.com> - 2015-08-27 15:10 +0200
Re: CONFIG_DEBUG_SHIRQ and PM Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> - 2015-08-26 21:40 +0200
Re: CONFIG_DEBUG_SHIRQ and PM Thomas Gleixner <tglx@linutronix.de> - 2015-08-28 21:50 +0200
csiph-web