* GPIO Driver for Skylake-Y PCH @ 2019-06-14 17:58 Alexander Ivanov 2019-06-14 18:46 ` Valdis Klētnieks 0 siblings, 1 reply; 34+ messages in thread From: Alexander Ivanov @ 2019-06-14 17:58 UTC (permalink / raw) To: kernelnewbies Hi, I have a hardware platform with Skylake i7-6500 CPU and Skylake-Y PCH southbridge, running 4.8.5 kernel fc25. The platform has 12 GPIO pins, however, none are available. gpio-pch driver does not support D31:F2 device that manages GPIO. Am I missing something here? Cheers, --Alex _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-14 17:58 GPIO Driver for Skylake-Y PCH Alexander Ivanov @ 2019-06-14 18:46 ` Valdis Klētnieks 2019-06-14 19:01 ` Alexander Ivanov 2019-06-14 19:12 ` Bjørn Mork 0 siblings, 2 replies; 34+ messages in thread From: Valdis Klētnieks @ 2019-06-14 18:46 UTC (permalink / raw) To: Alexander Ivanov; +Cc: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 874 bytes --] On Fri, 14 Jun 2019 10:58:53 -0700, "Alexander Ivanov" said: > I have a hardware platform with Skylake i7-6500 CPU and Skylake-Y PCH > southbridge, running 4.8.5 kernel fc25. The platform has 12 GPIO pins, however, > none are available. gpio-pch driver does not support D31:F2 device that manages > GPIO. > Am I missing something here? Well.. my copy of drivers/gpio/gpio-pch.c has this near line 440: static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, { 0, } }; MODULE_DEVICE_TABLE(pci, pch_gpio_pcidev_id); Though I'm having a hard time aligning that with "D31:F2". Are you confusing a PCI address with a PCI ID, or is this on a non-PCI bus? [-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-14 18:46 ` Valdis Klētnieks @ 2019-06-14 19:01 ` Alexander Ivanov 2019-06-14 19:09 ` Valdis Klētnieks 2019-06-14 19:12 ` Bjørn Mork 1 sibling, 1 reply; 34+ messages in thread From: Alexander Ivanov @ 2019-06-14 19:01 UTC (permalink / raw) To: kernelnewbies, Valdis Klētnieks [-- Attachment #1.1: Type: text/plain, Size: 1281 bytes --] Valdis, Thanks for quick response! On Fri, 14 Jun 2019 11:46 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote: > On Fri, 14 Jun 2019 10:58:53 -0700, "Alexander Ivanov" said: > > > I have a hardware platform with Skylake i7-6500 CPU and Skylake-Y PCH > > southbridge, running 4.8.5 kernel fc25. The platform has 12 GPIO pins, however, > > none are available. gpio-pch driver does not support D31:F2 device that manages > > GPIO. > > > Am I missing something here? > > Well.. my copy of drivers/gpio/gpio-pch.c has this near line 440: > > static const struct pci_device_id pch_gpio_pcidev_id[] = { > { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, > { 0, } > }; > MODULE_DEVICE_TABLE(pci, pch_gpio_pcidev_id); > > Though I'm having a hard time aligning that with "D31:F2". Are you confusing > a PCI address with a PCI ID, or is this on a non-PCI bus? No, I believe I am not. This borrowed from Intel doc (https://lab.whitequark.org/files/gpioke/Intel-332690-004EN.pdf, see Ch 2) It is a PCI device with 8086/9d20 IDs. --Alex ps. I apologize, I mistyped "D31:F2" it's supposed to be D31:F1. [-- Attachment #1.2: Type: text/html, Size: 2211 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-14 19:01 ` Alexander Ivanov @ 2019-06-14 19:09 ` Valdis Klētnieks 2019-06-14 20:25 ` Alexander Ivanov 0 siblings, 1 reply; 34+ messages in thread From: Valdis Klētnieks @ 2019-06-14 19:09 UTC (permalink / raw) To: Alexander Ivanov; +Cc: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 1043 bytes --] On Fri, 14 Jun 2019 12:01:28 -0700, you said: > > static const struct pci_device_id pch_gpio_pcidev_id[] = { > > { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, > > { 0, } > > }; > > MODULE_DEVICE_TABLE(pci, pch_gpio_pcidev_id); > It is a PCI device with 8086/9d20 IDs. Give this patch a try, if it works I'll push it upstream for you... diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c index 1d99293096f2..19884b5b2a74 100644 --- a/drivers/gpio/gpio-pch.c +++ b/drivers/gpio/gpio-pch.c @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume); static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, [-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-14 19:09 ` Valdis Klētnieks @ 2019-06-14 20:25 ` Alexander Ivanov 2019-06-14 22:40 ` Alexander Ivanov 0 siblings, 1 reply; 34+ messages in thread From: Alexander Ivanov @ 2019-06-14 20:25 UTC (permalink / raw) To: Valdis Klētnieks, Bjørn Mork; +Cc: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 2646 bytes --] On Fri, 14 Jun 2019 12:09 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote: > On Fri, 14 Jun 2019 12:01:28 -0700, you said: > > > > static const struct pci_device_id pch_gpio_pcidev_id[] = { > > > { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, > > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, > > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, > > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, > > > { 0, } > > > }; > > > MODULE_DEVICE_TABLE(pci, pch_gpio_pcidev_id); > > > It is a PCI device with 8086/9d20 IDs. > > Give this patch a try, if it works I'll push it upstream for you... > > diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c > index 1d99293096f2..19884b5b2a74 100644 > --- a/drivers/gpio/gpio-pch.c > +++ b/drivers/gpio/gpio-pch.c > @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume); > > static const struct pci_device_id pch_gpio_pcidev_id[] = { > { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, > + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, > I did try this. It did not enumerate. There is one little detail. This device is hidden by default in motherboard FW. However, I manually un-hide it before trying to enumerate the device. gpio-pch driver's patched as you described, built out-of-tree and loaded. Then, I un-hide the device and rescan the bus: # echo 1 > /sys/bus/pcie/rescan On Fri, 14 Jun 2019 12:13 -07:00, Bjørn Mork <bjorn@mork.no> wrote: > "Valdis Klētnieks" <valdis.kletnieks@vt.edu> writes: > > > Though I'm having a hard time aligning that with "D31:F2". Are you confusing > > a PCI address with a PCI ID, or is this on a non-PCI bus? > > "D31:F2" is device 31, function 2. We're used to see this as "1f.2". > > The question is really: Is there such a device in the system? And if so: > What's the ID? That's easy to find out: > > lspci -vvvnns 0:1f.2 > Device is indeed there: lspci -vvvnns 1f.1 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M] ps. I misstyped device address in my original post, it is supposed to be function 1 not 2: d31:f1. [-- Attachment #1.2: Type: text/html, Size: 4118 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-14 20:25 ` Alexander Ivanov @ 2019-06-14 22:40 ` Alexander Ivanov 2019-06-15 8:53 ` Bjørn Mork 2019-06-15 19:30 ` Valdis Klētnieks 0 siblings, 2 replies; 34+ messages in thread From: Alexander Ivanov @ 2019-06-14 22:40 UTC (permalink / raw) To: Valdis Klētnieks, Bjørn Mork; +Cc: kernelnewbies On Fri, 14 Jun 2019 13:25 -07:00, Alexander Ivanov <amivanov@fastmail.com> wrote: > > > On Fri, 14 Jun 2019 12:09 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote: >> On Fri, 14 Jun 2019 12:01:28 -0700, you said: >> >> > > static const struct pci_device_id pch_gpio_pcidev_id[] = { >> > > { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, >> > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, >> > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, >> > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, >> > > { 0, } >> > > }; >> > > MODULE_DEVICE_TABLE(pci, pch_gpio_pcidev_id); >> >> > It is a PCI device with 8086/9d20 IDs. >> >> Give this patch a try, if it works I'll push it upstream for you... >> >> diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c >> index 1d99293096f2..19884b5b2a74 100644 >> --- a/drivers/gpio/gpio-pch.c >> +++ b/drivers/gpio/gpio-pch.c >> @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume); >> >> static const struct pci_device_id pch_gpio_pcidev_id[] = { >> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, >> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, >> { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, >> { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, >> { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, >> > > > I did try this. It did not enumerate. > There is one little detail. This device is hidden by default in motherboard FW. However, I manually un-hide it before trying to enumerate the device. > > gpio-pch driver's patched as you described, built out-of-tree and loaded. Then, I un-hide the device and rescan the bus: > > # echo 1 > /sys/bus/pcie/rescan > > > > > On Fri, 14 Jun 2019 12:13 -07:00, Bjørn Mork <bjorn@mork.no> wrote: > > "Valdis Klētnieks" <valdis.kletnieks@vt.edu> writes: > > > > > Though I'm having a hard time aligning that with "D31:F2". Are you confusing > > > a PCI address with a PCI ID, or is this on a non-PCI bus? > > > > "D31:F2" is device 31, function 2. We're used to see this as "1f.2". > > > > The question is really: Is there such a device in the system? And if so: > > What's the ID? That's easy to find out: > > > > lspci -vvvnns 0:1f.2 > > > > Device is indeed there: > lspci -vvvnns 1f.1 > 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) > Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0 > Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M] > > > ps. I misstyped device address in my original post, it is supposed to be function 1 not 2: d31:f1. gpio-pch depends on X86_32 || MIPS || COMPILE_TEST config GPIO_PCH tristate "Intel EG20T PCH/LAPIS Semiconductor IOH(ML7223/ML7831) GPIO" depends on X86_32 || MIPS || COMPILE_TEST select GENERIC_IRQ_CHIP the platform at hand, is not X86_32 nor MIPS. It means gpi-pch requires CONFIG_COMPILE_TEST (to compile drivers which wont load....). Sure enough, even when driver enumerates, it fails to map BAR: [ 105.965846] pci 0000:00:1f.1: [8086:9d20] type 00 class 0x058000 [ 105.965928] pci 0000:00:1f.1: reg 0x10: [mem 0xfd000000-0xfdffffff 64bit] [ 105.967084] pci 0000:00:1f.1: BAR 0: assigned [mem 0x7d000000-0x7dffffff 64bit] [ 105.978037] pch_gpio 0000:00:1f.1: pch_gpio_probe : pci_iomap FAILED [ 105.978194] pch_gpio 0000:00:1f.1: pch_gpio_probe Failed returns -12 [ 105.978317] pch_gpio: probe of 0000:00:1f.1 failed with error -12 Any suggestions on what driver (if any available) should be used instead? _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-14 22:40 ` Alexander Ivanov @ 2019-06-15 8:53 ` Bjørn Mork 2019-06-15 19:30 ` Valdis Klētnieks 1 sibling, 0 replies; 34+ messages in thread From: Bjørn Mork @ 2019-06-15 8:53 UTC (permalink / raw) To: Alexander Ivanov; +Cc: Valdis Klētnieks, kernelnewbies "Alexander Ivanov" <amivanov@fastmail.com> writes: > Device is indeed there: >> lspci -vvvnns 1f.1 >> 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) >> Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- >> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >> Latency: 0 >> Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M] >> >> >> ps. I misstyped device address in my original post, it is supposed to be function 1 not 2: d31:f1. > > gpio-pch depends on X86_32 || MIPS || COMPILE_TEST > > config GPIO_PCH > tristate "Intel EG20T PCH/LAPIS Semiconductor IOH(ML7223/ML7831) GPIO" > depends on X86_32 || MIPS || COMPILE_TEST > select GENERIC_IRQ_CHIP > > the platform at hand, is not X86_32 nor MIPS. It means gpi-pch requires CONFIG_COMPILE_TEST (to compile drivers which wont load....). Sure enough, even when driver enumerates, it fails to map BAR: > > [ 105.965846] pci 0000:00:1f.1: [8086:9d20] type 00 class 0x058000 > [ 105.965928] pci 0000:00:1f.1: reg 0x10: [mem 0xfd000000-0xfdffffff 64bit] > [ 105.967084] pci 0000:00:1f.1: BAR 0: assigned [mem 0x7d000000-0x7dffffff 64bit] > [ 105.978037] pch_gpio 0000:00:1f.1: pch_gpio_probe : pci_iomap FAILED > [ 105.978194] pch_gpio 0000:00:1f.1: pch_gpio_probe Failed returns -12 > [ 105.978317] pch_gpio: probe of 0000:00:1f.1 failed with error -12 This seems to be from an older kernel, but anyway: pch_gpio_probe() attempts to map BAR 1. Your device does not have any such resource. So it fails. > Any suggestions on what driver (if any available) should be used instead? I wouldn't know. But I believe your device looks too different to be compatible with whatever devices this driver was made for. Bjørn _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-14 22:40 ` Alexander Ivanov 2019-06-15 8:53 ` Bjørn Mork @ 2019-06-15 19:30 ` Valdis Klētnieks 2019-06-15 19:38 ` Alexander Ivanov 2019-06-17 8:06 ` Andy Shevchenko 1 sibling, 2 replies; 34+ messages in thread From: Valdis Klētnieks @ 2019-06-15 19:30 UTC (permalink / raw) To: Alexander Ivanov, Jean Delvare Cc: Linus Walleij, Andy Shevchenko, Bjørn Mork, kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 1946 bytes --] On Fri, 14 Jun 2019 15:40:59 -0700, "Alexander Ivanov" said: (Adding likely knowledgeable people to the recipients) Jean, Andy, Linus: The situation thus far: Alexander has a system with this GPIO on it: > lspci -vvvnns 1f.1 > 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) > Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0 > Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M] The obvious first thing to try was: diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c index 1d99293096f2..19884b5b2a74 100644 --- a/drivers/gpio/gpio-pch.c +++ b/drivers/gpio/gpio-pch.c @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume); static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, and that died thusly when attempted to load: [ 105.965846] pci 0000:00:1f.1: [8086:9d20] type 00 class 0x058000 [ 105.965928] pci 0000:00:1f.1: reg 0x10: [mem 0xfd000000-0xfdffffff 64bit] [ 105.967084] pci 0000:00:1f.1: BAR 0: assigned [mem 0x7d000000-0x7dffffff 64bit] [ 105.978037] pch_gpio 0000:00:1f.1: pch_gpio_probe : pci_iomap FAILED [ 105.978194] pch_gpio 0000:00:1f.1: pch_gpio_probe Failed returns -12 [ 105.978317] pch_gpio: probe of 0000:00:1f.1 failed with error -12 So obviously an older kernel. Not sure what release Alexander is on, but a 'git log' against this week's linux-next tree didn't show anything that was an obvious fix for a similar problem. Any ideas? [-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-15 19:30 ` Valdis Klētnieks @ 2019-06-15 19:38 ` Alexander Ivanov 2019-06-15 19:56 ` Greg KH 2019-06-16 1:50 ` Valdis Klētnieks 2019-06-17 8:06 ` Andy Shevchenko 1 sibling, 2 replies; 34+ messages in thread From: Alexander Ivanov @ 2019-06-15 19:38 UTC (permalink / raw) To: Valdis Klētnieks, Jean Delvare Cc: Linus Walleij, Andy Shevchenko, Bjørn Mork, kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 2387 bytes --] On Sat, 15 Jun 2019 12:31 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote: > On Fri, 14 Jun 2019 15:40:59 -0700, "Alexander Ivanov" said: > > (Adding likely knowledgeable people to the recipients) > > Jean, Andy, Linus: The situation thus far: Alexander has a system with this GPIO on it: > > > lspci -vvvnns 1f.1 > > 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) > > Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] > > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > > Latency: 0 > > Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M] > > The obvious first thing to try was: > > diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c > index 1d99293096f2..19884b5b2a74 100644 > --- a/drivers/gpio/gpio-pch.c > +++ b/drivers/gpio/gpio-pch.c > @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume); > > static const struct pci_device_id pch_gpio_pcidev_id[] = { > { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, > + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, > > and that died thusly when attempted to load: > > [ 105.965846] pci 0000:00:1f.1: [8086:9d20] type 00 class 0x058000 > [ 105.965928] pci 0000:00:1f.1: reg 0x10: [mem 0xfd000000-0xfdffffff 64bit] > [ 105.967084] pci 0000:00:1f.1: BAR 0: assigned [mem 0x7d000000-0x7dffffff 64bit] > [ 105.978037] pch_gpio 0000:00:1f.1: pch_gpio_probe : pci_iomap FAILED > [ 105.978194] pch_gpio 0000:00:1f.1: pch_gpio_probe Failed returns -12 > [ 105.978317] pch_gpio: probe of 0000:00:1f.1 failed with error -12 > > So obviously an older kernel. Not sure what release Alexander is on, but > a 'git log' against this week's linux-next tree didn't show anything that was > an obvious fix for a similar problem. This is fedora 25 running 4.8.6 kernel. > > Any ideas? > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > [-- Attachment #1.2: Type: text/html, Size: 3365 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-15 19:38 ` Alexander Ivanov @ 2019-06-15 19:56 ` Greg KH 2019-06-16 1:50 ` Valdis Klētnieks 1 sibling, 0 replies; 34+ messages in thread From: Greg KH @ 2019-06-15 19:56 UTC (permalink / raw) To: Alexander Ivanov Cc: Valdis Klētnieks, kernelnewbies, Linus Walleij, Jean Delvare, Andy Shevchenko, Bjørn Mork On Sat, Jun 15, 2019 at 12:38:34PM -0700, Alexander Ivanov wrote: > > > On Sat, 15 Jun 2019 12:31 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote: > > On Fri, 14 Jun 2019 15:40:59 -0700, "Alexander Ivanov" said: > > > > (Adding likely knowledgeable people to the recipients) > > > > Jean, Andy, Linus: The situation thus far: Alexander has a system with this GPIO on it: > > > > > lspci -vvvnns 1f.1 > > > 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) > > > Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] > > > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > > > Latency: 0 > > > Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M] > > > > The obvious first thing to try was: > > > > diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c > > index 1d99293096f2..19884b5b2a74 100644 > > --- a/drivers/gpio/gpio-pch.c > > +++ b/drivers/gpio/gpio-pch.c > > @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume); > > > > static const struct pci_device_id pch_gpio_pcidev_id[] = { > > { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, > > + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, > > { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, > > > > and that died thusly when attempted to load: > > > > [ 105.965846] pci 0000:00:1f.1: [8086:9d20] type 00 class 0x058000 > > [ 105.965928] pci 0000:00:1f.1: reg 0x10: [mem 0xfd000000-0xfdffffff 64bit] > > [ 105.967084] pci 0000:00:1f.1: BAR 0: assigned [mem 0x7d000000-0x7dffffff 64bit] > > [ 105.978037] pch_gpio 0000:00:1f.1: pch_gpio_probe : pci_iomap FAILED > > [ 105.978194] pch_gpio 0000:00:1f.1: pch_gpio_probe Failed returns -12 > > [ 105.978317] pch_gpio: probe of 0000:00:1f.1 failed with error -12 > > > > So obviously an older kernel. Not sure what release Alexander is on, but > > a 'git log' against this week's linux-next tree didn't show anything that was > > an obvious fix for a similar problem. > > This is fedora 25 running 4.8.6 kernel. That kernel was released in October of 2016. Quite old and obsolete and totally and completely insecure. Please update to the latest version of Fedora. thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-15 19:38 ` Alexander Ivanov 2019-06-15 19:56 ` Greg KH @ 2019-06-16 1:50 ` Valdis Klētnieks 2019-06-16 2:45 ` Alexander Ivanov 1 sibling, 1 reply; 34+ messages in thread From: Valdis Klētnieks @ 2019-06-16 1:50 UTC (permalink / raw) To: Alexander Ivanov Cc: Linus Walleij, Andy Shevchenko, Bjørn Mork, Jean Delvare, kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 289 bytes --] On Sat, 15 Jun 2019 12:38:34 -0700, "Alexander Ivanov" said: > This is fedora 25 running 4.8.6 kernel. It probably won't fix the problem, but you should upgrade if at all possible. You're not getting any security patches for 25. 30 is the current release, with 31 due out fairly soon. [-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-16 1:50 ` Valdis Klētnieks @ 2019-06-16 2:45 ` Alexander Ivanov 2019-06-16 8:54 ` Bjørn Mork 0 siblings, 1 reply; 34+ messages in thread From: Alexander Ivanov @ 2019-06-16 2:45 UTC (permalink / raw) To: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 771 bytes --] On Sat, 15 Jun 2019 18:50 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote: > On Sat, 15 Jun 2019 12:38:34 -0700, "Alexander Ivanov" said: > > > This is fedora 25 running 4.8.6 kernel. > > It probably won't fix the problem, but you should upgrade if at all possible. > You're not getting any security patches for 25. 30 is the current release, > with 31 due out fairly soon. > I know. However, it isn't up to me. We have hundreds such units and I heard about plans to upgrade to 30 'soon'. I'm going to give it a try with 30 on my development board, just out of curiosity. For the problem at hand though, I'd likely have to find an external GPIO board that can generate an interrupt on GPIO pin toggle. Anyway, thanks for trying to help. [-- Attachment #1.2: Type: text/html, Size: 1174 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-16 2:45 ` Alexander Ivanov @ 2019-06-16 8:54 ` Bjørn Mork 0 siblings, 0 replies; 34+ messages in thread From: Bjørn Mork @ 2019-06-16 8:54 UTC (permalink / raw) To: Alexander Ivanov; +Cc: kernelnewbies "Alexander Ivanov" <amivanov@fastmail.com> writes: > We have hundreds such units and I heard about plans to upgrade to 30 'soon'. Quite off-topic, but I just had to comment on such plans: Fedora is the wrong distro for you. You should be planning for RHEL instead. Or a similar stable distro. Fedora is a distro for those who don't need to plan the next upgrade, but just can (and will) do it whenever there is a new release. Bjørn _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-15 19:30 ` Valdis Klētnieks 2019-06-15 19:38 ` Alexander Ivanov @ 2019-06-17 8:06 ` Andy Shevchenko 2019-06-18 0:00 ` Alexander Ivanov 1 sibling, 1 reply; 34+ messages in thread From: Andy Shevchenko @ 2019-06-17 8:06 UTC (permalink / raw) To: Valdis Klētnieks Cc: Linus Walleij, Alexander Ivanov, Bjørn Mork, Jean Delvare, kernelnewbies On Sat, Jun 15, 2019 at 03:30:24PM -0400, Valdis Klētnieks wrote: > On Fri, 14 Jun 2019 15:40:59 -0700, "Alexander Ivanov" said: > > (Adding likely knowledgeable people to the recipients) > > Jean, Andy, Linus: The situation thus far: Alexander has a system with this GPIO on it: How come that this device is GPIO? I mean what makes you, guys, to come to this conclusion? > > lspci -vvvnns 1f.1 > > 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) > > Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] > > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > > Latency: 0 > > Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M] > The obvious first thing to try was: ...which is obviously wrong. See above. P.S. Agree with Greg that one must update kernel either to LTS or to latest supported one. -- With Best Regards, Andy Shevchenko _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-17 8:06 ` Andy Shevchenko @ 2019-06-18 0:00 ` Alexander Ivanov 2019-06-18 8:40 ` Andy Shevchenko 0 siblings, 1 reply; 34+ messages in thread From: Alexander Ivanov @ 2019-06-18 0:00 UTC (permalink / raw) To: Andy Shevchenko, Valdis Klētnieks Cc: Linus Walleij, Jean Delvare, Bjørn Mork, kernelnewbies On Mon, 17 Jun 2019 09:39 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > How come that this device is GPIO? > I mean what makes you, guys, to come to this conclusion? > Intel document 332996-002EN [1] chapter 28 says GPP_* groups are accessible through the PCH Sideband Interface, while 332690-004EN [2] defines P2SB at d31.f1 Obviously, I am wrong here. However, the question stands, is there linux kernel support for Intel PCH GPIO? [1] http://www.intel.cn/content/dam/www/public/us/en/documents/datasheets/6th-gen-core-pch-u-y-io-datasheet-vol-2.pdf [2] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/100-series-chipset-datasheet-vol-1.pdf _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-18 0:00 ` Alexander Ivanov @ 2019-06-18 8:40 ` Andy Shevchenko 2019-06-18 14:48 ` Valdis Klētnieks 2019-06-20 21:02 ` Alexander Ivanov 0 siblings, 2 replies; 34+ messages in thread From: Andy Shevchenko @ 2019-06-18 8:40 UTC (permalink / raw) To: Alexander Ivanov Cc: Linus Walleij, Valdis Klētnieks, Jean Delvare, Bjørn Mork, kernelnewbies On Mon, Jun 17, 2019 at 05:00:54PM -0700, Alexander Ivanov wrote: > On Mon, 17 Jun 2019 09:39 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > > How come that this device is GPIO? > > I mean what makes you, guys, to come to this conclusion? > > > > Intel document 332996-002EN [1] chapter 28 says GPP_* groups are accessible through the PCH Sideband Interface, while 332690-004EN [2] defines P2SB at d31.f1 > > Obviously, I am wrong here. However, the question stands, is there linux kernel support for Intel PCH GPIO? Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, the drivers for which are available under drivers/pinctrl/intel. What you are looking for is located under PINCTRL_SUNRISEPOINT configuration option. > [1] http://www.intel.cn/content/dam/www/public/us/en/documents/datasheets/6th-gen-core-pch-u-y-io-datasheet-vol-2.pdf > [2] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/100-series-chipset-datasheet-vol-1.pdf -- With Best Regards, Andy Shevchenko _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-18 8:40 ` Andy Shevchenko @ 2019-06-18 14:48 ` Valdis Klētnieks 2019-06-18 15:57 ` Andy Shevchenko 2019-06-20 21:02 ` Alexander Ivanov 1 sibling, 1 reply; 34+ messages in thread From: Valdis Klētnieks @ 2019-06-18 14:48 UTC (permalink / raw) To: Andy Shevchenko Cc: Linus Walleij, Alexander Ivanov, Jean Delvare, Bj?rn Mork, kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 513 bytes --] On Tue, 18 Jun 2019 11:40:34 +0300, Andy Shevchenko said: > Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, > the drivers for which are available under drivers/pinctrl/intel. What you are > looking for is located under PINCTRL_SUNRISEPOINT configuration option. Thanks for the info, it's often unclear where to look - when the hardware has a PCH and documentation that says it has GPIO, and there's an in-tree driver called gpio_pch, it's easy to fail to look in the right place :) [-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-18 14:48 ` Valdis Klētnieks @ 2019-06-18 15:57 ` Andy Shevchenko 2019-06-18 16:17 ` Alexander Ivanov 0 siblings, 1 reply; 34+ messages in thread From: Andy Shevchenko @ 2019-06-18 15:57 UTC (permalink / raw) To: Valdis Klētnieks Cc: Linus Walleij, Alexander Ivanov, Jean Delvare, Bj?rn Mork, kernelnewbies On Tue, Jun 18, 2019 at 10:48:45AM -0400, Valdis Klētnieks wrote: > On Tue, 18 Jun 2019 11:40:34 +0300, Andy Shevchenko said: > > > Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, > > the drivers for which are available under drivers/pinctrl/intel. What you are > > looking for is located under PINCTRL_SUNRISEPOINT configuration option. > > Thanks for the info, it's often unclear where to look - when the hardware has > a PCH and documentation that says it has GPIO, and there's an in-tree driver > called gpio_pch, it's easy to fail to look in the right place :) Citing in-kernel documentation: --- 8< --- 8< ---- 8< --- Electrical properties of the pin such as biasing and drive strength may be placed at some pin-specific register in all cases or as part of the GPIO register in case (B) especially. This doesn't mean that such properties necessarily pertain to what the Linux kernel calls "GPIO". -- With Best Regards, Andy Shevchenko _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-18 15:57 ` Andy Shevchenko @ 2019-06-18 16:17 ` Alexander Ivanov 0 siblings, 0 replies; 34+ messages in thread From: Alexander Ivanov @ 2019-06-18 16:17 UTC (permalink / raw) To: Andy Shevchenko, Valdis Klētnieks Cc: Linus Walleij, Bj?rn Mork, Jean Delvare, kernelnewbies On Tue, 18 Jun 2019 08:58 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Tue, Jun 18, 2019 at 10:48:45AM -0400, Valdis Klētnieks wrote: > > On Tue, 18 Jun 2019 11:40:34 +0300, Andy Shevchenko said: > > > > > Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, > > > the drivers for which are available under drivers/pinctrl/intel. What you are > > > looking for is located under PINCTRL_SUNRISEPOINT configuration option. > > > > Thanks for the info, it's often unclear where to look - when the hardware has > > a PCH and documentation that says it has GPIO, and there's an in-tree driver > > called gpio_pch, it's easy to fail to look in the right place :) > Thank you for the info, indeed. I'm going to give it a try. > Citing in-kernel documentation: > > --- 8< --- 8< ---- 8< --- > > Electrical properties of the pin such as biasing and drive strength > may be placed at some pin-specific register in all cases or as part > of the GPIO register in case (B) especially. This doesn't mean that such > properties necessarily pertain to what the Linux kernel calls "GPIO". > Given the amount of related (and not so much) documentation, it's hard to miss. That's what this newsgroup for :) Thank you for helping! _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-18 8:40 ` Andy Shevchenko 2019-06-18 14:48 ` Valdis Klētnieks @ 2019-06-20 21:02 ` Alexander Ivanov 2019-06-21 10:12 ` Andy Shevchenko 1 sibling, 1 reply; 34+ messages in thread From: Alexander Ivanov @ 2019-06-20 21:02 UTC (permalink / raw) To: Andy Shevchenko Cc: Linus Walleij, Valdis Klētnieks, Bjørn Mork, Jean Delvare, kernelnewbies On Tue, 18 Jun 2019 01:41 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > > Obviously, I am wrong here. However, the question stands, is there linux kernel support for Intel PCH GPIO? > > Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, > the drivers for which are available under drivers/pinctrl/intel. What you are > looking for is located under PINCTRL_SUNRISEPOINT configuration option. > My box is updated with current Fedora distro and now running 5.0.9-301.fc30.x86_64. It's also said that the box has Sunrisepoint chipset. For this chipset, 5.0.9 kernel support following devices: static const struct acpi_device_id spt_pinctrl_acpi_match[] = { { "INT344B", (kernel_ulong_t)&sptlp_soc_data }, { "INT345D", (kernel_ulong_t)&spth_soc_data }, { } }; [ https://elixir.bootlin.com/linux/v5.0.9/source/drivers/pinctrl/intel/pinctrl-sunrisepoint.c#L587 ] I believe the box has INT344B device attached to acpi bus proper: $ sudo ls -la /sys/bus/acpi/devices/INT344* ... lrwxrwxrwx. 1 root root 0 Jun 20 11:47 /sys/bus/acpi/devices/INT344B:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT344B:00 Drivers seem loaded: $ lsmod | grep pin pinctrl_sunrisepoint 28672 0 pinctrl_intel 28672 1 pinctrl_sunrisepoint However, I don't see any gpio devices. $ ls /dev/gpio* ls: cannot access '/dev/gpio*': No such file or directory $ ls /sys/bus/gpio/devices/ $ What am I still missing? _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-20 21:02 ` Alexander Ivanov @ 2019-06-21 10:12 ` Andy Shevchenko 2019-06-21 17:39 ` Alexander Ivanov 0 siblings, 1 reply; 34+ messages in thread From: Andy Shevchenko @ 2019-06-21 10:12 UTC (permalink / raw) To: Alexander Ivanov Cc: Linus Walleij, Valdis Klētnieks, Bjørn Mork, Jean Delvare, kernelnewbies On Thu, Jun 20, 2019 at 02:02:11PM -0700, Alexander Ivanov wrote: > On Tue, 18 Jun 2019 01:41 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > Obviously, I am wrong here. However, the question stands, is there linux kernel support for Intel PCH GPIO? > > > > Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, > > the drivers for which are available under drivers/pinctrl/intel. What you are > > looking for is located under PINCTRL_SUNRISEPOINT configuration option. > My box is updated with current Fedora distro and now running 5.0.9-301.fc30.x86_64. It's also said that the box has Sunrisepoint chipset. For this chipset, 5.0.9 kernel support following devices: > > static const struct acpi_device_id spt_pinctrl_acpi_match[] = { > { "INT344B", (kernel_ulong_t)&sptlp_soc_data }, > { "INT345D", (kernel_ulong_t)&spth_soc_data }, > { } > }; > > [ https://elixir.bootlin.com/linux/v5.0.9/source/drivers/pinctrl/intel/pinctrl-sunrisepoint.c#L587 ] > > I believe the box has INT344B device attached to acpi bus proper: > > $ sudo ls -la /sys/bus/acpi/devices/INT344* > ... > lrwxrwxrwx. 1 root root 0 Jun 20 11:47 /sys/bus/acpi/devices/INT344B:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT344B:00 Usually to check this is better to run grep -H 15 /sys/bus/acpi/devices/*/status which return you the list of *present and available* ACPI devices. > Drivers seem loaded: > > $ lsmod | grep pin > pinctrl_sunrisepoint 28672 0 > pinctrl_intel 28672 1 pinctrl_sunrisepoint > > However, I don't see any gpio devices. > > $ ls /dev/gpio* > ls: cannot access '/dev/gpio*': No such file or directory > $ ls /sys/bus/gpio/devices/ > $ > > What am I still missing? Two items: - CONFIG_GPIO_SYSFS (deprecated!) - that this is an old way to access to GPIO chips, the correct one is to use character device; libgpiod tools will help you with that -- With Best Regards, Andy Shevchenko _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-21 10:12 ` Andy Shevchenko @ 2019-06-21 17:39 ` Alexander Ivanov 2019-06-24 18:39 ` Alexander Ivanov 0 siblings, 1 reply; 34+ messages in thread From: Alexander Ivanov @ 2019-06-21 17:39 UTC (permalink / raw) To: Andy Shevchenko Cc: Linus Walleij, Valdis Klētnieks, Jean Delvare, Bjørn Mork, kernelnewbies On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > Usually to check this is better to run > grep -H 15 /sys/bus/acpi/devices/*/status > which return you the list of *present and available* ACPI devices. It looks like INT344B device is neither present nor available. This device isn't in the list returned by above grep. Its status actually returns 0. What could be reasons for that? > > to use character device; libgpiod tools will help you with that It's good to know there is C library for handling gpio. But this is user-land thing. I'm interested in kernel's means to handle gpios. And for experiments I'd rather use tools/gpio/. Anyway, I can figure out how to use kernel API. At the moment though I need to understand what's wrong with my platform and how can I fix/make it work. Thx! _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-21 17:39 ` Alexander Ivanov @ 2019-06-24 18:39 ` Alexander Ivanov 2019-06-25 11:08 ` Andy Shevchenko 0 siblings, 1 reply; 34+ messages in thread From: Alexander Ivanov @ 2019-06-24 18:39 UTC (permalink / raw) To: Andy Shevchenko Cc: Linus Walleij, Valdis Klētnieks, Bjørn Mork, Jean Delvare, kernelnewbies On Fri, 21 Jun 2019 10:39 -07:00, Alexander Ivanov <amivanov@fastmail.com> wrote: > > On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > Usually to check this is better to run > > grep -H 15 /sys/bus/acpi/devices/*/status > > which return you the list of *present and available* ACPI devices. > > > It looks like INT344B device is neither present nor available. This > device isn't in the list returned by above grep. > Its status actually returns 0. What could be reasons for that? > Any idea why would otherwise 'visible' [1] device appear unavailable and not present [2]? I cannot see anything obviously wrong in kernel traces either. [1] # tree /sys/bus/acpi/devices/INT344B\:00/ /sys/bus/acpi/devices/INT344B:00/ ├── hid ├── modalias ├── path ├── power │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_time │ ├── runtime_status │ └── runtime_suspended_time ├── status ├── subsystem -> ../../../../../bus/acpi └── uevent [2] # cat /sys/bus/acpi/devices/INT344B\:00/status 0 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-24 18:39 ` Alexander Ivanov @ 2019-06-25 11:08 ` Andy Shevchenko 2019-06-25 14:10 ` Linus Walleij 2019-08-28 21:04 ` Alexander Ivanov 0 siblings, 2 replies; 34+ messages in thread From: Andy Shevchenko @ 2019-06-25 11:08 UTC (permalink / raw) To: Alexander Ivanov Cc: Linus Walleij, Valdis Klētnieks, Bjørn Mork, Jean Delvare, kernelnewbies On Mon, Jun 24, 2019 at 11:39:42AM -0700, Alexander Ivanov wrote: > On Fri, 21 Jun 2019 10:39 -07:00, Alexander Ivanov <amivanov@fastmail.com> wrote: > > > > On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > Usually to check this is better to run > > > grep -H 15 /sys/bus/acpi/devices/*/status > > > which return you the list of *present and available* ACPI devices. > > > > > > It looks like INT344B device is neither present nor available. This > > device isn't in the list returned by above grep. > > Its status actually returns 0. What could be reasons for that? > > > > Any idea why would otherwise 'visible' [1] device appear unavailable and not present [2]? > I cannot see anything obviously wrong in kernel traces either. > > > [1] # tree /sys/bus/acpi/devices/INT344B\:00/ > /sys/bus/acpi/devices/INT344B:00/ > ├── hid > ├── modalias > ├── path > ├── power > │ ├── autosuspend_delay_ms > │ ├── control > │ ├── runtime_active_time > │ ├── runtime_status > │ └── runtime_suspended_time > ├── status > ├── subsystem -> ../../../../../bus/acpi > └── uevent > > [2] # cat /sys/bus/acpi/devices/INT344B\:00/status > 0 There is no issue with kernel. ACPI tables provided by firmware, so, vendor of your firmware decided to turn off this device. -- With Best Regards, Andy Shevchenko _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-25 11:08 ` Andy Shevchenko @ 2019-06-25 14:10 ` Linus Walleij 2019-07-10 16:04 ` Andy Shevchenko 2019-08-28 21:04 ` Alexander Ivanov 1 sibling, 1 reply; 34+ messages in thread From: Linus Walleij @ 2019-06-25 14:10 UTC (permalink / raw) To: Andy Shevchenko Cc: Valdis Klētnieks, Alexander Ivanov, Bjørn Mork, Jean Delvare, kernelnewbies On Tue, Jun 25, 2019 at 1:08 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Mon, Jun 24, 2019 at 11:39:42AM -0700, Alexander Ivanov wrote: > > On Fri, 21 Jun 2019 10:39 -07:00, Alexander Ivanov <amivanov@fastmail.com> wrote: > > > > > > On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > > Usually to check this is better to run > > > > grep -H 15 /sys/bus/acpi/devices/*/status > > > > which return you the list of *present and available* ACPI devices. > > > > > > > > > It looks like INT344B device is neither present nor available. This > > > device isn't in the list returned by above grep. > > > Its status actually returns 0. What could be reasons for that? > > > > > > > Any idea why would otherwise 'visible' [1] device appear unavailable and not present [2]? > > I cannot see anything obviously wrong in kernel traces either. > > > > > > [1] # tree /sys/bus/acpi/devices/INT344B\:00/ > > /sys/bus/acpi/devices/INT344B:00/ > > ├── hid > > ├── modalias > > ├── path > > ├── power > > │ ├── autosuspend_delay_ms > > │ ├── control > > │ ├── runtime_active_time > > │ ├── runtime_status > > │ └── runtime_suspended_time > > ├── status > > ├── subsystem -> ../../../../../bus/acpi > > └── uevent > > > > [2] # cat /sys/bus/acpi/devices/INT344B\:00/status > > 0 > > There is no issue with kernel. ACPI tables provided by firmware, so, > vendor of your firmware decided to turn off this device. In Linux we usually respect users and contributors more than vendors, so if there are users that need to access this device and the firmware doesn't let them, but there is a way for us to fix that, then we should provide the tools. But I guess that would happen in the ACPI core? Yours, Linus Walleij _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-25 14:10 ` Linus Walleij @ 2019-07-10 16:04 ` Andy Shevchenko 0 siblings, 0 replies; 34+ messages in thread From: Andy Shevchenko @ 2019-07-10 16:04 UTC (permalink / raw) To: Linus Walleij Cc: Valdis Klētnieks, Alexander Ivanov, Bjørn Mork, Jean Delvare, kernelnewbies On Tue, Jun 25, 2019 at 04:10:23PM +0200, Linus Walleij wrote: > On Tue, Jun 25, 2019 at 1:08 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Jun 24, 2019 at 11:39:42AM -0700, Alexander Ivanov wrote: > > > On Fri, 21 Jun 2019 10:39 -07:00, Alexander Ivanov <amivanov@fastmail.com> wrote: > > > > On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko > > > > <andriy.shevchenko@linux.intel.com> wrote: > > There is no issue with kernel. ACPI tables provided by firmware, so, > > vendor of your firmware decided to turn off this device. > > In Linux we usually respect users and contributors more than > vendors, so if there are users that need to access this device > and the firmware doesn't let them, but there is a way for us to > fix that, then we should provide the tools. > > But I guess that would happen in the ACPI core? Linus, there is another problem, if we even work around this (you should ask Rafael, indeed), the MMIO resources, provided by the table is solely generated by BIOS. The IP, AFAIK, has a possibility to be reallocated in the address space. The user will need BIOS to clarify that, it can't be done in OS (GPIO is exposed as not a PCI device). -- With Best Regards, Andy Shevchenko _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-25 11:08 ` Andy Shevchenko 2019-06-25 14:10 ` Linus Walleij @ 2019-08-28 21:04 ` Alexander Ivanov 2019-08-29 7:47 ` Valentin Vidić 1 sibling, 1 reply; 34+ messages in thread From: Alexander Ivanov @ 2019-08-28 21:04 UTC (permalink / raw) To: Andy Shevchenko, Linus Walleij, Valdis Klētnieks Cc: Bjørn Mork, Jean Delvare, kernelnewbies On Tue, 25 Jun 2019 04:08 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > There is no issue with kernel. ACPI tables provided by firmware, so, > vendor of your firmware decided to turn off this device. > It took me (or rather the vendor) to update the firmware and enable INT344B controller. After update, the system enumerates gpio controller [ 4.236944] sunrisepoint-pinctrl INT344B:00: intel_gpio_probe init done All is good! Thank you for helping! _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-08-28 21:04 ` Alexander Ivanov @ 2019-08-29 7:47 ` Valentin Vidić 2019-08-29 10:49 ` Andy Shevchenko 2019-08-29 15:59 ` Alexander Ivanov 0 siblings, 2 replies; 34+ messages in thread From: Valentin Vidić @ 2019-08-29 7:47 UTC (permalink / raw) To: Alexander Ivanov Cc: Valdis Klētnieks, kernelnewbies, Linus Walleij, Bjørn Mork, Andy Shevchenko, Jean Delvare On Wed, Aug 28, 2019 at 02:04:44PM -0700, Alexander Ivanov wrote: > It took me (or rather the vendor) to update the firmware and enable INT344B > controller. After update, the system enumerates gpio controller How did you get them to update the firmware? I have a similar problem with iTCO_wdt on Intel NUC not being enabled. -- Valentin _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-08-29 7:47 ` Valentin Vidić @ 2019-08-29 10:49 ` Andy Shevchenko 2019-08-29 11:49 ` Valentin Vidić 2019-08-29 15:59 ` Alexander Ivanov 1 sibling, 1 reply; 34+ messages in thread From: Andy Shevchenko @ 2019-08-29 10:49 UTC (permalink / raw) To: Valentin Vidić Cc: Valdis Klētnieks, kernelnewbies, Linus Walleij, Bjørn Mork, Alexander Ivanov, Jean Delvare On Thu, Aug 29, 2019 at 09:47:42AM +0200, Valentin Vidić wrote: > On Wed, Aug 28, 2019 at 02:04:44PM -0700, Alexander Ivanov wrote: > > It took me (or rather the vendor) to update the firmware and enable INT344B > > controller. After update, the system enumerates gpio controller > > How did you get them to update the firmware? I have a similar problem > with iTCO_wdt on Intel NUC not being enabled. This actually should be done other way around, i.e. enabling ACPI WDAT table will get you watchdog and this is *highly* recommended way. -- With Best Regards, Andy Shevchenko _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-08-29 10:49 ` Andy Shevchenko @ 2019-08-29 11:49 ` Valentin Vidić 2019-08-29 14:59 ` Andy Shevchenko 0 siblings, 1 reply; 34+ messages in thread From: Valentin Vidić @ 2019-08-29 11:49 UTC (permalink / raw) To: Andy Shevchenko Cc: Alexander Ivanov, kernelnewbies, Linus Walleij, Bjørn Mork, Valdis Klētnieks, Jean Delvare On Thu, Aug 29, 2019 at 01:49:31PM +0300, Andy Shevchenko wrote: > This actually should be done other way around, i.e. enabling ACPI WDAT table > will get you watchdog and this is *highly* recommended way. If I understand correctly you are suggesting to try the wdat_wdt driver instead? Discussion about iTCO_wdt problem with Intel NUC is here but no solution so far: https://www.spinics.net/lists/linux-watchdog/msg16232.html https://www.spinics.net/lists/linux-i2c/msg41504.html # modprobe i2c_i801 [40450.070587] i801_smbus 0000:00:1f.4: SPD Write Disable is set [40450.070652] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt [40450.072919] iTCO_vendor_support: vendor-support=0 [40450.073485] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [40450.073546] iTCO_wdt iTCO_wdt: can't request region for resource [mem 0x00c5fffc-0x00c5ffff] [40450.073578] iTCO_wdt: probe of iTCO_wdt failed with error -16 -- Valentin _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-08-29 11:49 ` Valentin Vidić @ 2019-08-29 14:59 ` Andy Shevchenko 2019-08-29 17:17 ` Valentin Vidić 0 siblings, 1 reply; 34+ messages in thread From: Andy Shevchenko @ 2019-08-29 14:59 UTC (permalink / raw) To: Valentin Vidić Cc: Alexander Ivanov, kernelnewbies, Linus Walleij, Bjørn Mork, Valdis Klētnieks, Jean Delvare On Thu, Aug 29, 2019 at 01:49:55PM +0200, Valentin Vidić wrote: > On Thu, Aug 29, 2019 at 01:49:31PM +0300, Andy Shevchenko wrote: > > This actually should be done other way around, i.e. enabling ACPI WDAT table > > will get you watchdog and this is *highly* recommended way. > > If I understand correctly you are suggesting to try the wdat_wdt driver instead? Yes. That driver should be in use assuming properly crafted firmware. > > Discussion about iTCO_wdt problem with Intel NUC is here but no solution so far: > > https://www.spinics.net/lists/linux-watchdog/msg16232.html > https://www.spinics.net/lists/linux-i2c/msg41504.html > > # modprobe i2c_i801 > [40450.070587] i801_smbus 0000:00:1f.4: SPD Write Disable is set > [40450.070652] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt > [40450.072919] iTCO_vendor_support: vendor-support=0 > [40450.073485] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 > [40450.073546] iTCO_wdt iTCO_wdt: can't request region for resource [mem 0x00c5fffc-0x00c5ffff] > [40450.073578] iTCO_wdt: probe of iTCO_wdt failed with error -16 -- With Best Regards, Andy Shevchenko _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-08-29 14:59 ` Andy Shevchenko @ 2019-08-29 17:17 ` Valentin Vidić 0 siblings, 0 replies; 34+ messages in thread From: Valentin Vidić @ 2019-08-29 17:17 UTC (permalink / raw) To: Andy Shevchenko Cc: Alexander Ivanov, kernelnewbies, Linus Walleij, Bjørn Mork, Valdis Klētnieks, Jean Delvare On Thu, Aug 29, 2019 at 05:59:26PM +0300, Andy Shevchenko wrote: > Yes. That driver should be in use assuming properly crafted firmware. I have the latest available firmware for this NUC but there is no such table and loading wdat_wdt module does not find anything. Seems I'm out of luck with this system :/ # ls -l /sys/firmware/acpi/tables/ total 0 -r-------- 1 root root 188 Aug 29 17:13 APIC -r-------- 1 root root 56 Aug 29 17:13 BGRT drwxr-xr-x 2 root root 0 Aug 29 17:13 data -r-------- 1 root root 84 Aug 29 17:13 DBG2 -r-------- 1 root root 52 Aug 29 17:13 DBGP -r-------- 1 root root 168 Aug 29 17:13 DMAR -r-------- 1 root root 273143 Aug 29 17:13 DSDT drwxr-xr-x 2 root root 0 Aug 29 17:13 dynamic -r-------- 1 root root 276 Aug 29 17:13 FACP -r-------- 1 root root 64 Aug 29 17:13 FACS -r-------- 1 root root 156 Aug 29 17:13 FIDT -r-------- 1 root root 68 Aug 29 17:12 FPDT -r-------- 1 root root 56 Aug 29 17:13 HPET -r-------- 1 root root 92 Aug 29 17:13 LPIT -r-------- 1 root root 60 Aug 29 17:13 MCFG -r-------- 1 root root 45 Aug 29 17:13 NHLT -r-------- 1 root root 6940 Aug 29 17:13 SSDT1 -r-------- 1 root root 12742 Aug 29 17:13 SSDT2 -r-------- 1 root root 4014 Aug 29 17:13 SSDT3 -r-------- 1 root root 12360 Aug 29 17:13 SSDT4 -r-------- 1 root root 10206 Aug 29 17:13 SSDT5 -r-------- 1 root root 2232 Aug 29 17:13 SSDT6 -r-------- 1 root root 324 Aug 29 17:13 SSDT7 -r-------- 1 root root 244 Aug 29 17:13 SSDT8 -r-------- 1 root root 52 Aug 29 17:13 TPM2 -r-------- 1 root root 66 Aug 29 17:13 UEFI -r-------- 1 root root 40 Aug 29 17:13 WSMT -- Valentin _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-08-29 7:47 ` Valentin Vidić 2019-08-29 10:49 ` Andy Shevchenko @ 2019-08-29 15:59 ` Alexander Ivanov 1 sibling, 0 replies; 34+ messages in thread From: Alexander Ivanov @ 2019-08-29 15:59 UTC (permalink / raw) To: Valentin Vidić Cc: Valdis Klētnieks, kernelnewbies, Linus Walleij, Bjørn Mork, Andy Shevchenko, Jean Delvare On Thu, 29 Aug 2019 00:47 -07:00, Valentin Vidić <vvidic@valentin-vidic.from.hr> wrote: > On Wed, Aug 28, 2019 at 02:04:44PM -0700, Alexander Ivanov wrote: > > It took me (or rather the vendor) to update the firmware and enable INT344B > > controller. After update, the system enumerates gpio controller > > How did you get them to update the firmware? I have a similar problem > with iTCO_wdt on Intel NUC not being enabled. > We have quite big account with them and paid support service, otherwise it would be virtually impossible :/ _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: GPIO Driver for Skylake-Y PCH 2019-06-14 18:46 ` Valdis Klētnieks 2019-06-14 19:01 ` Alexander Ivanov @ 2019-06-14 19:12 ` Bjørn Mork 1 sibling, 0 replies; 34+ messages in thread From: Bjørn Mork @ 2019-06-14 19:12 UTC (permalink / raw) To: Valdis Klētnieks; +Cc: Alexander Ivanov, kernelnewbies "Valdis Klētnieks" <valdis.kletnieks@vt.edu> writes: > Though I'm having a hard time aligning that with "D31:F2". Are you confusing > a PCI address with a PCI ID, or is this on a non-PCI bus? "D31:F2" is device 31, function 2. We're used to see this as "1f.2". The question is really: Is there such a device in the system? And if so: What's the ID? That's easy to find out: lspci -vvvnns 0:1f.2 Bjørn _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2019-09-02 1:02 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-14 17:58 GPIO Driver for Skylake-Y PCH Alexander Ivanov 2019-06-14 18:46 ` Valdis Klētnieks 2019-06-14 19:01 ` Alexander Ivanov 2019-06-14 19:09 ` Valdis Klētnieks 2019-06-14 20:25 ` Alexander Ivanov 2019-06-14 22:40 ` Alexander Ivanov 2019-06-15 8:53 ` Bjørn Mork 2019-06-15 19:30 ` Valdis Klētnieks 2019-06-15 19:38 ` Alexander Ivanov 2019-06-15 19:56 ` Greg KH 2019-06-16 1:50 ` Valdis Klētnieks 2019-06-16 2:45 ` Alexander Ivanov 2019-06-16 8:54 ` Bjørn Mork 2019-06-17 8:06 ` Andy Shevchenko 2019-06-18 0:00 ` Alexander Ivanov 2019-06-18 8:40 ` Andy Shevchenko 2019-06-18 14:48 ` Valdis Klētnieks 2019-06-18 15:57 ` Andy Shevchenko 2019-06-18 16:17 ` Alexander Ivanov 2019-06-20 21:02 ` Alexander Ivanov 2019-06-21 10:12 ` Andy Shevchenko 2019-06-21 17:39 ` Alexander Ivanov 2019-06-24 18:39 ` Alexander Ivanov 2019-06-25 11:08 ` Andy Shevchenko 2019-06-25 14:10 ` Linus Walleij 2019-07-10 16:04 ` Andy Shevchenko 2019-08-28 21:04 ` Alexander Ivanov 2019-08-29 7:47 ` Valentin Vidić 2019-08-29 10:49 ` Andy Shevchenko 2019-08-29 11:49 ` Valentin Vidić 2019-08-29 14:59 ` Andy Shevchenko 2019-08-29 17:17 ` Valentin Vidić 2019-08-29 15:59 ` Alexander Ivanov 2019-06-14 19:12 ` Bjørn Mork
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).