* [PATCH] resource: Prevent irqresource_disabled() from erasing flags
@ 2021-03-29 19:52 Angela Czubak
2021-03-30 15:09 ` Rafael J. Wysocki
0 siblings, 1 reply; 7+ messages in thread
From: Angela Czubak @ 2021-03-29 19:52 UTC (permalink / raw)
To: rafael.j.wysocki
Cc: akpm, john.garry, linux-kernel, upstream, dtor, Angela Czubak
Do not overwrite flags as it leads to erasing triggering and polarity
information which might be useful in case of hard-coded interrupts.
This way the information can be read later on even though mapping to
APIC domain failed.
Signed-off-by: Angela Czubak <acz@semihalf.com>
---
Some Chromebooks use hard-coded interrupts in their ACPI tables.
This is an excerpt as dumped on Relm:
...
Name (_HID, "ELAN0001") // _HID: Hardware ID
Name (_DDN, "Elan Touchscreen ") // _DDN: DOS Device Name
Name (_UID, 0x05) // _UID: Unique ID
Name (ISTP, Zero)
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (BUF0, ResourceTemplate ()
{
I2cSerialBusV2 (0x0010, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive, ,, )
{
0x000000B8,
}
})
Return (BUF0) /* \_SB_.I2C1.ETSA._CRS.BUF0 */
}
...
This interrupt is hard-coded to 0xB8 = 184 which is too high to be mapped
to IO-APIC, so no triggering information is propagated as acpi_register_gsi()
fails and irqresource_disabled() is issued, which leads to erasing triggering
and polarity information.
If that function added its flags instead of overwriting them the correct IRQ
type would be set even for the hard-coded interrupts, which allows device driver
to retrieve it.
Please, let me know if this kind of modification is acceptable.
Best Regards,
Angela
include/linux/ioport.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 55de385c839cf..647744d8514e0 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -331,7 +331,7 @@ static inline void irqresource_disabled(struct resource *res, u32 irq)
{
res->start = irq;
res->end = irq;
- res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
+ res->flags |= IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
}
extern struct address_space *iomem_get_mapping(void);
--
2.17.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] resource: Prevent irqresource_disabled() from erasing flags
2021-03-29 19:52 [PATCH] resource: Prevent irqresource_disabled() from erasing flags Angela Czubak
@ 2021-03-30 15:09 ` Rafael J. Wysocki
2021-03-30 15:49 ` Mika Westerberg
0 siblings, 1 reply; 7+ messages in thread
From: Rafael J. Wysocki @ 2021-03-30 15:09 UTC (permalink / raw)
To: Angela Czubak, Mika Westerberg
Cc: akpm, john.garry, linux-kernel, upstream, dtor, linux-acpi, rafael
On 3/29/2021 9:52 PM, Angela Czubak wrote:
> Do not overwrite flags as it leads to erasing triggering and polarity
> information which might be useful in case of hard-coded interrupts.
> This way the information can be read later on even though mapping to
> APIC domain failed.
>
> Signed-off-by: Angela Czubak <acz@semihalf.com>
> ---
> Some Chromebooks use hard-coded interrupts in their ACPI tables.
> This is an excerpt as dumped on Relm:
>
> ...
> Name (_HID, "ELAN0001") // _HID: Hardware ID
> Name (_DDN, "Elan Touchscreen ") // _DDN: DOS Device Name
> Name (_UID, 0x05) // _UID: Unique ID
> Name (ISTP, Zero)
> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
> {
> Name (BUF0, ResourceTemplate ()
> {
> I2cSerialBusV2 (0x0010, ControllerInitiated, 0x00061A80,
> AddressingMode7Bit, "\\_SB.I2C1",
> 0x00, ResourceConsumer, , Exclusive,
> )
> Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive, ,, )
> {
> 0x000000B8,
> }
> })
> Return (BUF0) /* \_SB_.I2C1.ETSA._CRS.BUF0 */
> }
> ...
>
> This interrupt is hard-coded to 0xB8 = 184 which is too high to be mapped
> to IO-APIC, so no triggering information is propagated as acpi_register_gsi()
> fails and irqresource_disabled() is issued, which leads to erasing triggering
> and polarity information.
> If that function added its flags instead of overwriting them the correct IRQ
> type would be set even for the hard-coded interrupts, which allows device driver
> to retrieve it.
> Please, let me know if this kind of modification is acceptable.
From the quick look it should not be problematic, but it needs to be
checked more carefully.
Mika, what do you think?
> include/linux/ioport.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 55de385c839cf..647744d8514e0 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -331,7 +331,7 @@ static inline void irqresource_disabled(struct resource *res, u32 irq)
> {
> res->start = irq;
> res->end = irq;
> - res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> + res->flags |= IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> }
>
> extern struct address_space *iomem_get_mapping(void);
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] resource: Prevent irqresource_disabled() from erasing flags
2021-03-30 15:09 ` Rafael J. Wysocki
@ 2021-03-30 15:49 ` Mika Westerberg
2021-04-07 11:01 ` Angela Czubak
0 siblings, 1 reply; 7+ messages in thread
From: Mika Westerberg @ 2021-03-30 15:49 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Angela Czubak, akpm, john.garry, linux-kernel, upstream, dtor,
linux-acpi, rafael
Hi,
On Tue, Mar 30, 2021 at 05:09:42PM +0200, Rafael J. Wysocki wrote:
> On 3/29/2021 9:52 PM, Angela Czubak wrote:
> > Do not overwrite flags as it leads to erasing triggering and polarity
> > information which might be useful in case of hard-coded interrupts.
> > This way the information can be read later on even though mapping to
> > APIC domain failed.
> >
> > Signed-off-by: Angela Czubak <acz@semihalf.com>
> > ---
> > Some Chromebooks use hard-coded interrupts in their ACPI tables.
> > This is an excerpt as dumped on Relm:
> >
> > ...
> > Name (_HID, "ELAN0001") // _HID: Hardware ID
> > Name (_DDN, "Elan Touchscreen ") // _DDN: DOS Device Name
> > Name (_UID, 0x05) // _UID: Unique ID
> > Name (ISTP, Zero)
> > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
> > {
> > Name (BUF0, ResourceTemplate ()
> > {
> > I2cSerialBusV2 (0x0010, ControllerInitiated, 0x00061A80,
> > AddressingMode7Bit, "\\_SB.I2C1",
> > 0x00, ResourceConsumer, , Exclusive,
> > )
> > Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive, ,, )
> > {
> > 0x000000B8,
> > }
> > })
> > Return (BUF0) /* \_SB_.I2C1.ETSA._CRS.BUF0 */
> > }
> > ...
> >
> > This interrupt is hard-coded to 0xB8 = 184 which is too high to be mapped
> > to IO-APIC, so no triggering information is propagated as acpi_register_gsi()
> > fails and irqresource_disabled() is issued, which leads to erasing triggering
> > and polarity information.
> > If that function added its flags instead of overwriting them the correct IRQ
> > type would be set even for the hard-coded interrupts, which allows device driver
> > to retrieve it.
> > Please, let me know if this kind of modification is acceptable.
>
> From the quick look it should not be problematic, but it needs to be checked
> more carefully.
>
> Mika, what do you think?
I think it makes sense. We still set IORESOURCE_DISABLED unconditionally
so this should not cause issues. In theory at least :)
> > include/linux/ioport.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> > index 55de385c839cf..647744d8514e0 100644
> > --- a/include/linux/ioport.h
> > +++ b/include/linux/ioport.h
> > @@ -331,7 +331,7 @@ static inline void irqresource_disabled(struct resource *res, u32 irq)
> > {
> > res->start = irq;
> > res->end = irq;
> > - res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> > + res->flags |= IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> > }
> > extern struct address_space *iomem_get_mapping(void);
>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] resource: Prevent irqresource_disabled() from erasing flags
2021-03-30 15:49 ` Mika Westerberg
@ 2021-04-07 11:01 ` Angela Czubak
2021-04-07 12:53 ` Rafael J. Wysocki
0 siblings, 1 reply; 7+ messages in thread
From: Angela Czubak @ 2021-04-07 11:01 UTC (permalink / raw)
To: Mika Westerberg
Cc: Rafael J. Wysocki, akpm, john.garry, linux-kernel, upstream,
Dmitry Torokhov, linux-acpi, rafael
On Tue, Mar 30, 2021 at 5:50 PM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> Hi,
>
> On Tue, Mar 30, 2021 at 05:09:42PM +0200, Rafael J. Wysocki wrote:
> > On 3/29/2021 9:52 PM, Angela Czubak wrote:
> > > Do not overwrite flags as it leads to erasing triggering and polarity
> > > information which might be useful in case of hard-coded interrupts.
> > > This way the information can be read later on even though mapping to
> > > APIC domain failed.
> > >
> > > Signed-off-by: Angela Czubak <acz@semihalf.com>
> > > ---
> > > Some Chromebooks use hard-coded interrupts in their ACPI tables.
> > > This is an excerpt as dumped on Relm:
> > >
> > > ...
> > > Name (_HID, "ELAN0001") // _HID: Hardware ID
> > > Name (_DDN, "Elan Touchscreen ") // _DDN: DOS Device Name
> > > Name (_UID, 0x05) // _UID: Unique ID
> > > Name (ISTP, Zero)
> > > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
> > > {
> > > Name (BUF0, ResourceTemplate ()
> > > {
> > > I2cSerialBusV2 (0x0010, ControllerInitiated, 0x00061A80,
> > > AddressingMode7Bit, "\\_SB.I2C1",
> > > 0x00, ResourceConsumer, , Exclusive,
> > > )
> > > Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive, ,, )
> > > {
> > > 0x000000B8,
> > > }
> > > })
> > > Return (BUF0) /* \_SB_.I2C1.ETSA._CRS.BUF0 */
> > > }
> > > ...
> > >
> > > This interrupt is hard-coded to 0xB8 = 184 which is too high to be mapped
> > > to IO-APIC, so no triggering information is propagated as acpi_register_gsi()
> > > fails and irqresource_disabled() is issued, which leads to erasing triggering
> > > and polarity information.
> > > If that function added its flags instead of overwriting them the correct IRQ
> > > type would be set even for the hard-coded interrupts, which allows device driver
> > > to retrieve it.
> > > Please, let me know if this kind of modification is acceptable.
> >
> > From the quick look it should not be problematic, but it needs to be checked
> > more carefully.
> >
> > Mika, what do you think?
>
> I think it makes sense. We still set IORESOURCE_DISABLED unconditionally
> so this should not cause issues. In theory at least :)
>
Is there anything else you would need me to do regarding the patch?
I suppose there are more platforms that could benefit from not erasing
the flags, so if this patch is fit for upstream, can we continue the
process?
> > > include/linux/ioport.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> > > index 55de385c839cf..647744d8514e0 100644
> > > --- a/include/linux/ioport.h
> > > +++ b/include/linux/ioport.h
> > > @@ -331,7 +331,7 @@ static inline void irqresource_disabled(struct resource *res, u32 irq)
> > > {
> > > res->start = irq;
> > > res->end = irq;
> > > - res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> > > + res->flags |= IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> > > }
> > > extern struct address_space *iomem_get_mapping(void);
> >
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] resource: Prevent irqresource_disabled() from erasing flags
2021-04-07 11:01 ` Angela Czubak
@ 2021-04-07 12:53 ` Rafael J. Wysocki
0 siblings, 0 replies; 7+ messages in thread
From: Rafael J. Wysocki @ 2021-04-07 12:53 UTC (permalink / raw)
To: Angela Czubak
Cc: Mika Westerberg, Rafael J. Wysocki, Andrew Morton, John Garry,
Linux Kernel Mailing List, upstream, Dmitry Torokhov, linux-acpi
On Wed, Apr 7, 2021 at 1:01 PM Angela Czubak <acz@semihalf.com> wrote:
>
> On Tue, Mar 30, 2021 at 5:50 PM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > Hi,
> >
> > On Tue, Mar 30, 2021 at 05:09:42PM +0200, Rafael J. Wysocki wrote:
> > > On 3/29/2021 9:52 PM, Angela Czubak wrote:
> > > > Do not overwrite flags as it leads to erasing triggering and polarity
> > > > information which might be useful in case of hard-coded interrupts.
> > > > This way the information can be read later on even though mapping to
> > > > APIC domain failed.
> > > >
> > > > Signed-off-by: Angela Czubak <acz@semihalf.com>
> > > > ---
> > > > Some Chromebooks use hard-coded interrupts in their ACPI tables.
> > > > This is an excerpt as dumped on Relm:
> > > >
> > > > ...
> > > > Name (_HID, "ELAN0001") // _HID: Hardware ID
> > > > Name (_DDN, "Elan Touchscreen ") // _DDN: DOS Device Name
> > > > Name (_UID, 0x05) // _UID: Unique ID
> > > > Name (ISTP, Zero)
> > > > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
> > > > {
> > > > Name (BUF0, ResourceTemplate ()
> > > > {
> > > > I2cSerialBusV2 (0x0010, ControllerInitiated, 0x00061A80,
> > > > AddressingMode7Bit, "\\_SB.I2C1",
> > > > 0x00, ResourceConsumer, , Exclusive,
> > > > )
> > > > Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive, ,, )
> > > > {
> > > > 0x000000B8,
> > > > }
> > > > })
> > > > Return (BUF0) /* \_SB_.I2C1.ETSA._CRS.BUF0 */
> > > > }
> > > > ...
> > > >
> > > > This interrupt is hard-coded to 0xB8 = 184 which is too high to be mapped
> > > > to IO-APIC, so no triggering information is propagated as acpi_register_gsi()
> > > > fails and irqresource_disabled() is issued, which leads to erasing triggering
> > > > and polarity information.
> > > > If that function added its flags instead of overwriting them the correct IRQ
> > > > type would be set even for the hard-coded interrupts, which allows device driver
> > > > to retrieve it.
> > > > Please, let me know if this kind of modification is acceptable.
> > >
> > > From the quick look it should not be problematic, but it needs to be checked
> > > more carefully.
> > >
> > > Mika, what do you think?
> >
> > I think it makes sense. We still set IORESOURCE_DISABLED unconditionally
> > so this should not cause issues. In theory at least :)
> >
> Is there anything else you would need me to do regarding the patch?
Yes, please resend it with a CC to linux-acpi@vger.kernel.org for more
visibility.
> I suppose there are more platforms that could benefit from not erasing
> the flags, so if this patch is fit for upstream, can we continue the
> process?
>
> > > > include/linux/ioport.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> > > > index 55de385c839cf..647744d8514e0 100644
> > > > --- a/include/linux/ioport.h
> > > > +++ b/include/linux/ioport.h
> > > > @@ -331,7 +331,7 @@ static inline void irqresource_disabled(struct resource *res, u32 irq)
> > > > {
> > > > res->start = irq;
> > > > res->end = irq;
> > > > - res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> > > > + res->flags |= IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> > > > }
> > > > extern struct address_space *iomem_get_mapping(void);
> > >
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] resource: Prevent irqresource_disabled() from erasing flags
@ 2021-04-08 10:37 Angela Czubak
2021-04-08 18:03 ` Rafael J. Wysocki
0 siblings, 1 reply; 7+ messages in thread
From: Angela Czubak @ 2021-04-08 10:37 UTC (permalink / raw)
To: rafael.j.wysocki
Cc: akpm, mika.westerberg, john.garry, linux-acpi, upstream, dtor,
Angela Czubak
Do not overwrite flags as it leads to erasing triggering and polarity
information which might be useful in case of hard-coded interrupts.
This way the information can be read later on even though mapping to
APIC domain failed.
Signed-off-by: Angela Czubak <acz@semihalf.com>
---
Some Chromebooks use hard-coded interrupts in their ACPI tables.
This is an excerpt as dumped on Relm:
...
Name (_HID, "ELAN0001") // _HID: Hardware ID
Name (_DDN, "Elan Touchscreen ") // _DDN: DOS Device Name
Name (_UID, 0x05) // _UID: Unique ID
Name (ISTP, Zero)
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (BUF0, ResourceTemplate ()
{
I2cSerialBusV2 (0x0010, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive, ,, )
{
0x000000B8,
}
})
Return (BUF0) /* \_SB_.I2C1.ETSA._CRS.BUF0 */
}
...
This interrupt is hard-coded to 0xB8 = 184 which is too high to be mapped
to IO-APIC, so no triggering information is propagated as acpi_register_gsi()
fails and irqresource_disabled() is issued, which leads to erasing triggering
and polarity information.
If that function added its flags instead of overwriting them the correct IRQ
type would be set even for the hard-coded interrupts, which allows device driver
to retrieve it.
This patch was originaly sent to linux-kernel@vger.kernel.org.
I am resending it to linux-acpi@vger.kernel.org as per request of
Rafael J. Wysocki to gather more visibility.
Please let us know if you see possible issues with not erasing the flags or this
modification seems acceptable.
Best Regards,
Angela
include/linux/ioport.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 55de385c839cf..647744d8514e0 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -331,7 +331,7 @@ static inline void irqresource_disabled(struct resource *res, u32 irq)
{
res->start = irq;
res->end = irq;
- res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
+ res->flags |= IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
}
extern struct address_space *iomem_get_mapping(void);
--
2.17.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] resource: Prevent irqresource_disabled() from erasing flags
2021-04-08 10:37 Angela Czubak
@ 2021-04-08 18:03 ` Rafael J. Wysocki
0 siblings, 0 replies; 7+ messages in thread
From: Rafael J. Wysocki @ 2021-04-08 18:03 UTC (permalink / raw)
To: Angela Czubak
Cc: Rafael Wysocki, Andrew Morton, Mika Westerberg, John Garry,
ACPI Devel Maling List, upstream, Dmitry Torokhov
On Thu, Apr 8, 2021 at 12:38 PM Angela Czubak <acz@semihalf.com> wrote:
>
> Do not overwrite flags as it leads to erasing triggering and polarity
> information which might be useful in case of hard-coded interrupts.
> This way the information can be read later on even though mapping to
> APIC domain failed.
>
> Signed-off-by: Angela Czubak <acz@semihalf.com>
> ---
> Some Chromebooks use hard-coded interrupts in their ACPI tables.
> This is an excerpt as dumped on Relm:
>
> ...
> Name (_HID, "ELAN0001") // _HID: Hardware ID
> Name (_DDN, "Elan Touchscreen ") // _DDN: DOS Device Name
> Name (_UID, 0x05) // _UID: Unique ID
> Name (ISTP, Zero)
> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
> {
> Name (BUF0, ResourceTemplate ()
> {
> I2cSerialBusV2 (0x0010, ControllerInitiated, 0x00061A80,
> AddressingMode7Bit, "\\_SB.I2C1",
> 0x00, ResourceConsumer, , Exclusive,
> )
> Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive, ,, )
> {
> 0x000000B8,
> }
> })
> Return (BUF0) /* \_SB_.I2C1.ETSA._CRS.BUF0 */
> }
> ...
>
> This interrupt is hard-coded to 0xB8 = 184 which is too high to be mapped
> to IO-APIC, so no triggering information is propagated as acpi_register_gsi()
> fails and irqresource_disabled() is issued, which leads to erasing triggering
> and polarity information.
> If that function added its flags instead of overwriting them the correct IRQ
> type would be set even for the hard-coded interrupts, which allows device driver
> to retrieve it.
> This patch was originaly sent to linux-kernel@vger.kernel.org.
> I am resending it to linux-acpi@vger.kernel.org as per request of
> Rafael J. Wysocki to gather more visibility.
> Please let us know if you see possible issues with not erasing the flags or this
> modification seems acceptable.
I've applied the patch as 5.13 material, thanks!
> include/linux/ioport.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 55de385c839cf..647744d8514e0 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -331,7 +331,7 @@ static inline void irqresource_disabled(struct resource *res, u32 irq)
> {
> res->start = irq;
> res->end = irq;
> - res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> + res->flags |= IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> }
>
> extern struct address_space *iomem_get_mapping(void);
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-04-08 18:03 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-29 19:52 [PATCH] resource: Prevent irqresource_disabled() from erasing flags Angela Czubak
2021-03-30 15:09 ` Rafael J. Wysocki
2021-03-30 15:49 ` Mika Westerberg
2021-04-07 11:01 ` Angela Czubak
2021-04-07 12:53 ` Rafael J. Wysocki
2021-04-08 10:37 Angela Czubak
2021-04-08 18:03 ` Rafael J. Wysocki
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.