* Failed IRQ assignment for INT0002 on Braswell
@ 2017-11-21 22:35 Oleksandr Natalenko
2017-11-22 10:48 ` Hans de Goede
0 siblings, 1 reply; 9+ messages in thread
From: Oleksandr Natalenko @ 2017-11-21 22:35 UTC (permalink / raw)
To: Hans de Goede; +Cc: platform-driver-x86, linux-kernel
Hi, Hans.
v4.13 kernel introduced new fancy warning in the dmesg:
===
kernel: acpi INT0002:00: Device [GPED] is in always present list
kernel: genirq: Flags mismatch irq 9. 00010084 (INT0002) vs. 00002080 (acpi)
kernel: INT0002 Virtual GPIO INT0002:00: Error requesting IRQ 9: -16
kernel: INT0002 Virtual GPIO: probe of INT0002:00 failed with error -16
===
Looking at git log, I've found that this driver was indeed introduced in v4.13
by the following commit:
===
commit 63dada87f7ef7d4a536765c816fbbe7c4b9f3c85
Author: Hans de Goede <hdegoede@redhat.com>
Date: Mon Jun 12 22:55:46 2017 +0200
platform/x86: Add driver for ACPI INT0002 Virtual GPIO device
===
I've checked DSDT disassembly for this device, and here is relevant snippet
[1]. The only thing I currently understand there is that IRQ 9 is hard coded
(line 64), but I'm not sure where those flags come from.
The hardware in J3710 CPU on ASRock J3710-ITX motherboard.
Next, I've found that you also faced this warning and posted some RFC patch
[2], but unfortunately I do not see what that discussion ended up with.
It is not that I really need GPIO on this board, but it would be nice to get
rid of this warning. Could you please point me to a possible fix or a way for
further investigation?
Thanks.
Regards,
Oleksandr
[1] https://gist.github.com/2c69d6e4eb4b5c256601847a9c6aec45
[2] https://patchwork.kernel.org/patch/9671783/
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Failed IRQ assignment for INT0002 on Braswell 2017-11-21 22:35 Failed IRQ assignment for INT0002 on Braswell Oleksandr Natalenko @ 2017-11-22 10:48 ` Hans de Goede 2017-11-22 12:48 ` Oleksandr Natalenko 0 siblings, 1 reply; 9+ messages in thread From: Hans de Goede @ 2017-11-22 10:48 UTC (permalink / raw) To: Oleksandr Natalenko; +Cc: platform-driver-x86, linux-kernel Hi, On 21-11-17 23:35, Oleksandr Natalenko wrote: > Hi, Hans. > > v4.13 kernel introduced new fancy warning in the dmesg: > > === > kernel: acpi INT0002:00: Device [GPED] is in always present list > kernel: genirq: Flags mismatch irq 9. 00010084 (INT0002) vs. 00002080 (acpi) > kernel: INT0002 Virtual GPIO INT0002:00: Error requesting IRQ 9: -16 > kernel: INT0002 Virtual GPIO: probe of INT0002:00 failed with error -16 > === > > Looking at git log, I've found that this driver was indeed introduced in v4.13 > by the following commit: > > === > commit 63dada87f7ef7d4a536765c816fbbe7c4b9f3c85 > Author: Hans de Goede <hdegoede@redhat.com> > Date: Mon Jun 12 22:55:46 2017 +0200 > > platform/x86: Add driver for ACPI INT0002 Virtual GPIO device > === > > I've checked DSDT disassembly for this device, and here is relevant snippet > [1]. The only thing I currently understand there is that IRQ 9 is hard coded > (line 64), but I'm not sure where those flags come from. > > The hardware in J3710 CPU on ASRock J3710-ITX motherboard. > > Next, I've found that you also faced this warning and posted some RFC patch > [2], but unfortunately I do not see what that discussion ended up with. > > It is not that I really need GPIO on this board, but it would be nice to get > rid of this warning. Could you please point me to a possible fix or a way for > further investigation? This should be fixed by: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/irq?id=382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 Which is in 4.13, but the trigger-type does not seem to be the problem in your case, the problem likely is the ONESHOT flag: #define IRQF_ONESHOT 0x00002000 Which appears to be set in the flags for the acpi irq handler: > kernel: genirq: Flags mismatch irq 9. 00010084 (INT0002) vs. 00002080 (acpi) But that irq is requested here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/osl.c#n570 : if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) { printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq); ... And IRQF_ONESHOT is not passed, so I do not understand where the 00002000 in the acpi irq handler flags is coming from ... Regards, Hans ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Failed IRQ assignment for INT0002 on Braswell 2017-11-22 10:48 ` Hans de Goede @ 2017-11-22 12:48 ` Oleksandr Natalenko 2017-11-22 15:50 ` Hans de Goede 0 siblings, 1 reply; 9+ messages in thread From: Oleksandr Natalenko @ 2017-11-22 12:48 UTC (permalink / raw) To: Hans de Goede; +Cc: platform-driver-x86, linux-kernel Hi, Hans. On středa 22. listopadu 2017 11:48:50 CET Hans de Goede wrote: > /* snip */ > This should be fixed by: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ke > rnel/irq?id=382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 > > Which is in 4.13, but the trigger-type does not seem to be the problem in > your case, the problem likely is the ONESHOT flag: > > #define IRQF_ONESHOT 0x00002000 > > Which appears to be set in the flags for the acpi irq handler: > > kernel: genirq: Flags mismatch irq 9. 00010084 (INT0002) vs. 00002080 > > (acpi) > But that irq is requested here: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv > ers/acpi/osl.c#n570 > > > > if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) { > printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq); > ... > > And IRQF_ONESHOT is not passed, so I do not understand where the 00002000 in > the acpi irq handler flags is coming from ... Well, looks like I know where this flag comes from. I boot this machine with "threadirqs", and IRQF_ONESHOT description says: === 52 * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished. 53 * Used by threaded interrupts which need to keep the 54 * irq line disabled until the threaded handler has been run. === If I boot the machine without "threadirqs", looks like the device is set up okay. The only message I get in the kernel log is: === kernel: acpi INT0002:00: Device [GPED] is in always present list === Grepping for IRQ 9: === kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) kernel: ACPI: IRQ9 used by override. === and 9th interrupt shows this device: === 9: 0 0 0 0 IO-APIC 9-fasteoi acpi, INT0002 === Any idea why "threadirqs" makes this fail? Thanks. Regards, Oleksandr ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Failed IRQ assignment for INT0002 on Braswell 2017-11-22 12:48 ` Oleksandr Natalenko @ 2017-11-22 15:50 ` Hans de Goede 0 siblings, 0 replies; 9+ messages in thread From: Hans de Goede @ 2017-11-22 15:50 UTC (permalink / raw) To: Oleksandr Natalenko; +Cc: platform-driver-x86, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2236 bytes --] Hi, On 22-11-17 13:48, Oleksandr Natalenko wrote: > Hi, Hans. > > On středa 22. listopadu 2017 11:48:50 CET Hans de Goede wrote: >> /* snip */ >> This should be fixed by: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ke >> rnel/irq?id=382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 >> >> Which is in 4.13, but the trigger-type does not seem to be the problem in >> your case, the problem likely is the ONESHOT flag: >> >> #define IRQF_ONESHOT 0x00002000 >> >> Which appears to be set in the flags for the acpi irq handler: >> > kernel: genirq: Flags mismatch irq 9. 00010084 (INT0002) vs. 00002080 >> > (acpi) >> But that irq is requested here: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv >> ers/acpi/osl.c#n570 >> >> >> >> if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) { >> printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq); >> ... >> >> And IRQF_ONESHOT is not passed, so I do not understand where the 00002000 in >> the acpi irq handler flags is coming from ... > > Well, looks like I know where this flag comes from. I boot this machine with > "threadirqs", and IRQF_ONESHOT description says: > > === > 52 * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler > finished. > 53 * Used by threaded interrupts which need to keep the > 54 * irq line disabled until the threaded handler has been > run. > === > > If I boot the machine without "threadirqs", looks like the device is set up > okay. The only message I get in the kernel log is: > > === > kernel: acpi INT0002:00: Device [GPED] is in always present list > === > > Grepping for IRQ 9: > > === > kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > kernel: ACPI: IRQ9 used by override. > === > > and 9th interrupt shows this device: > > === > 9: 0 0 0 0 IO-APIC 9-fasteoi > acpi, INT0002 > === > > Any idea why "threadirqs" makes this fail? Yes, I think this is caused by the int0002 vgpio driver unnecessarily passing the IRQF_NO_THREAD flag, attached is a patch which should fix this, can you give this a try ? Regards, Hans [-- Attachment #2: 0001-platform-x86-intel_int0002_vgpio-Remove-IRQF_NO_THRE.patch --] [-- Type: text/x-patch, Size: 1297 bytes --] >From a68410ecefc73b538f8123c59bd6d2aade4600ba Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede@redhat.com> Date: Wed, 22 Nov 2017 16:36:05 +0100 Subject: [PATCH v2] platform/x86: intel_int0002_vgpio: Remove IRQF_NO_THREAD irq flag Remove the IRQF_NO_THREAD irq flag, there is no need for it and it breaks irq-sharing with the "acpi" irq when passing "threadirqs" on the kernel cmdline, as the acpi/osl.c code does not pass IRQF_NO_THREAD. Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/platform/x86/intel_int0002_vgpio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/intel_int0002_vgpio.c b/drivers/platform/x86/intel_int0002_vgpio.c index f7b67e898abc..a473dc51b18d 100644 --- a/drivers/platform/x86/intel_int0002_vgpio.c +++ b/drivers/platform/x86/intel_int0002_vgpio.c @@ -180,7 +180,7 @@ static int int0002_probe(struct platform_device *pdev) * to gpiochip_set_chained_irqchip, because the irq is shared. */ ret = devm_request_irq(dev, irq, int0002_irq, - IRQF_SHARED | IRQF_NO_THREAD, "INT0002", chip); + IRQF_SHARED, "INT0002", chip); if (ret) { dev_err(dev, "Error requesting IRQ %d: %d\n", irq, ret); return ret; -- 2.14.3 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: Failed IRQ assignment for INT0002 on Braswell @ 2017-11-22 15:50 ` Hans de Goede 0 siblings, 0 replies; 9+ messages in thread From: Hans de Goede @ 2017-11-22 15:50 UTC (permalink / raw) To: Oleksandr Natalenko; +Cc: platform-driver-x86, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2236 bytes --] Hi, On 22-11-17 13:48, Oleksandr Natalenko wrote: > Hi, Hans. > > On středa 22. listopadu 2017 11:48:50 CET Hans de Goede wrote: >> /* snip */ >> This should be fixed by: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ke >> rnel/irq?id=382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 >> >> Which is in 4.13, but the trigger-type does not seem to be the problem in >> your case, the problem likely is the ONESHOT flag: >> >> #define IRQF_ONESHOT 0x00002000 >> >> Which appears to be set in the flags for the acpi irq handler: >> > kernel: genirq: Flags mismatch irq 9. 00010084 (INT0002) vs. 00002080 >> > (acpi) >> But that irq is requested here: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv >> ers/acpi/osl.c#n570 >> >> >> >> if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) { >> printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq); >> ... >> >> And IRQF_ONESHOT is not passed, so I do not understand where the 00002000 in >> the acpi irq handler flags is coming from ... > > Well, looks like I know where this flag comes from. I boot this machine with > "threadirqs", and IRQF_ONESHOT description says: > > === > 52 * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler > finished. > 53 * Used by threaded interrupts which need to keep the > 54 * irq line disabled until the threaded handler has been > run. > === > > If I boot the machine without "threadirqs", looks like the device is set up > okay. The only message I get in the kernel log is: > > === > kernel: acpi INT0002:00: Device [GPED] is in always present list > === > > Grepping for IRQ 9: > > === > kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > kernel: ACPI: IRQ9 used by override. > === > > and 9th interrupt shows this device: > > === > 9: 0 0 0 0 IO-APIC 9-fasteoi > acpi, INT0002 > === > > Any idea why "threadirqs" makes this fail? Yes, I think this is caused by the int0002 vgpio driver unnecessarily passing the IRQF_NO_THREAD flag, attached is a patch which should fix this, can you give this a try ? Regards, Hans [-- Attachment #2: 0001-platform-x86-intel_int0002_vgpio-Remove-IRQF_NO_THRE.patch --] [-- Type: text/x-patch, Size: 1296 bytes --] From a68410ecefc73b538f8123c59bd6d2aade4600ba Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede@redhat.com> Date: Wed, 22 Nov 2017 16:36:05 +0100 Subject: [PATCH v2] platform/x86: intel_int0002_vgpio: Remove IRQF_NO_THREAD irq flag Remove the IRQF_NO_THREAD irq flag, there is no need for it and it breaks irq-sharing with the "acpi" irq when passing "threadirqs" on the kernel cmdline, as the acpi/osl.c code does not pass IRQF_NO_THREAD. Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/platform/x86/intel_int0002_vgpio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/intel_int0002_vgpio.c b/drivers/platform/x86/intel_int0002_vgpio.c index f7b67e898abc..a473dc51b18d 100644 --- a/drivers/platform/x86/intel_int0002_vgpio.c +++ b/drivers/platform/x86/intel_int0002_vgpio.c @@ -180,7 +180,7 @@ static int int0002_probe(struct platform_device *pdev) * to gpiochip_set_chained_irqchip, because the irq is shared. */ ret = devm_request_irq(dev, irq, int0002_irq, - IRQF_SHARED | IRQF_NO_THREAD, "INT0002", chip); + IRQF_SHARED, "INT0002", chip); if (ret) { dev_err(dev, "Error requesting IRQ %d: %d\n", irq, ret); return ret; -- 2.14.3 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: Failed IRQ assignment for INT0002 on Braswell 2017-11-22 15:50 ` Hans de Goede (?) @ 2017-11-22 18:13 ` Oleksandr Natalenko 2017-11-23 21:08 ` Andy Shevchenko -1 siblings, 1 reply; 9+ messages in thread From: Oleksandr Natalenko @ 2017-11-22 18:13 UTC (permalink / raw) To: Hans de Goede; +Cc: platform-driver-x86, linux-kernel Hi, Hans. With this patch applied the warning is not emitted anymore with threadirqs enabled, and relevant kthread (irq/9-INT0002) is created. Feel free to add Reported-by/Tested-by from me once you do a submission. Thanks. Regards, Oleksandr On středa 22. listopadu 2017 16:50:33 CET Hans de Goede wrote: > Hi, > > On 22-11-17 13:48, Oleksandr Natalenko wrote: > > Hi, Hans. > > > > On středa 22. listopadu 2017 11:48:50 CET Hans de Goede wrote: > >> /* snip */ > >> This should be fixed by: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit > >> /ke rnel/irq?id=382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 > >> > >> Which is in 4.13, but the trigger-type does not seem to be the problem in > >> your case, the problem likely is the ONESHOT flag: > >> > >> #define IRQF_ONESHOT 0x00002000 > >> > >> Which appears to be set in the flags for the acpi irq handler: > >> > kernel: genirq: Flags mismatch irq 9. 00010084 (INT0002) vs. 00002080 > >> > (acpi) > >> > >> But that irq is requested here: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/d > >> riv ers/acpi/osl.c#n570 > >> > >> if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) { > >> > >> printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq); > >> ... > >> > >> And IRQF_ONESHOT is not passed, so I do not understand where the 00002000 > >> in the acpi irq handler flags is coming from ... > > > > Well, looks like I know where this flag comes from. I boot this machine > > with "threadirqs", and IRQF_ONESHOT description says: > > > > === > > > > 52 * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq > > handler > > > > finished. > > > > 53 * Used by threaded interrupts which need to keep the > > 54 * irq line disabled until the threaded handler has > > been > > > > run. > > === > > > > If I boot the machine without "threadirqs", looks like the device is set > > up > > okay. The only message I get in the kernel log is: > > > > === > > kernel: acpi INT0002:00: Device [GPED] is in always present list > > === > > > > Grepping for IRQ 9: > > > > === > > kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > > kernel: ACPI: IRQ9 used by override. > > === > > > > and 9th interrupt shows this device: > > > > === > > > > 9: 0 0 0 0 IO-APIC 9-fasteoi > > > > acpi, INT0002 > > === > > > > Any idea why "threadirqs" makes this fail? > > Yes, I think this is caused by the int0002 vgpio driver unnecessarily > passing the IRQF_NO_THREAD flag, attached is a patch which should fix this, > can you give this a try ? > > Regards, > > Hans ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Failed IRQ assignment for INT0002 on Braswell 2017-11-22 18:13 ` Oleksandr Natalenko @ 2017-11-23 21:08 ` Andy Shevchenko 2017-11-23 21:15 ` Oleksandr Natalenko 0 siblings, 1 reply; 9+ messages in thread From: Andy Shevchenko @ 2017-11-23 21:08 UTC (permalink / raw) To: Oleksandr Natalenko; +Cc: Hans de Goede, Platform Driver, linux-kernel On Wed, Nov 22, 2017 at 8:13 PM, Oleksandr Natalenko <oleksandr@natalenko.name> wrote: > > Hi, Hans. > > With this patch applied the warning is not emitted anymore with threadirqs > enabled, and relevant kthread (irq/9-INT0002) is created. > > Feel free to add Reported-by/Tested-by from me once you do a submission. First of all, please stop top-posting. Second, we are using patchwork which can automatically add tags based on given in followup emails. So, if you wish to see your tag in the commit message at the end, please, send a reply with Reported-by: Tested-by: tags. Thanks. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Failed IRQ assignment for INT0002 on Braswell 2017-11-23 21:08 ` Andy Shevchenko @ 2017-11-23 21:15 ` Oleksandr Natalenko 2017-11-23 21:22 ` Andy Shevchenko 0 siblings, 1 reply; 9+ messages in thread From: Oleksandr Natalenko @ 2017-11-23 21:15 UTC (permalink / raw) To: Andy Shevchenko; +Cc: Hans de Goede, Platform Driver, linux-kernel On čtvrtek 23. listopadu 2017 22:08:29 CET Andy Shevchenko wrote: > On Wed, Nov 22, 2017 at 8:13 PM, Oleksandr Natalenko > > <oleksandr@natalenko.name> wrote: > > Hi, Hans. > > > > With this patch applied the warning is not emitted anymore with threadirqs > > enabled, and relevant kthread (irq/9-INT0002) is created. > > > > Feel free to add Reported-by/Tested-by from me once you do a submission. > > First of all, please stop top-posting. > > Second, we are using patchwork which can automatically add tags based > on given in followup emails. > So, if you wish to see your tag in the commit message at the end, > please, send a reply with > > Reported-by: > Tested-by: > > tags. > > Thanks. Right. Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Failed IRQ assignment for INT0002 on Braswell 2017-11-23 21:15 ` Oleksandr Natalenko @ 2017-11-23 21:22 ` Andy Shevchenko 0 siblings, 0 replies; 9+ messages in thread From: Andy Shevchenko @ 2017-11-23 21:22 UTC (permalink / raw) To: Oleksandr Natalenko; +Cc: Hans de Goede, Platform Driver, linux-kernel On Thu, Nov 23, 2017 at 11:15 PM, Oleksandr Natalenko <oleksandr@natalenko.name> wrote: > On čtvrtek 23. listopadu 2017 22:08:29 CET Andy Shevchenko wrote: >> On Wed, Nov 22, 2017 at 8:13 PM, Oleksandr Natalenko >> >> <oleksandr@natalenko.name> wrote: >> > Hi, Hans. >> > >> > With this patch applied the warning is not emitted anymore with threadirqs >> > enabled, and relevant kthread (irq/9-INT0002) is created. >> > >> > Feel free to add Reported-by/Tested-by from me once you do a submission. >> >> First of all, please stop top-posting. >> >> Second, we are using patchwork which can automatically add tags based >> on given in followup emails. >> So, if you wish to see your tag in the commit message at the end, >> please, send a reply with >> >> Reported-by: >> Tested-by: >> >> tags. >> >> Thanks. > > Right. > > Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name> > Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Pushed to my review and testing queue, thanks! -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-11-23 21:23 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-21 22:35 Failed IRQ assignment for INT0002 on Braswell Oleksandr Natalenko 2017-11-22 10:48 ` Hans de Goede 2017-11-22 12:48 ` Oleksandr Natalenko 2017-11-22 15:50 ` Hans de Goede 2017-11-22 15:50 ` Hans de Goede 2017-11-22 18:13 ` Oleksandr Natalenko 2017-11-23 21:08 ` Andy Shevchenko 2017-11-23 21:15 ` Oleksandr Natalenko 2017-11-23 21:22 ` Andy Shevchenko
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.