Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi again, On Sat, 2019-01-12 at 10:52 +0100, Michael Niewöhner wrote: > Hi Mimi, > > On Fri, 2019-01-11 at 10:40 -0500, Mimi Zohar wrote: > > Hi Michael, > > > > On Sun, 2018-11-11 at 19:50 +0100, Michael Niewöhner wrote: > > > > > Well, there are at least two implementations I know of: > > > For my Lenovo X260 I can choose between Infineon TPM 1.2 or Intel PTT TPM > > > 2.0 > > > This here is my ThinkStation P320 which can choose between PTT 1.2, PTT > > > 2.0, > > > Nuvoton 1.2 and 2.0. When switchting between 1.2 and 2.0 the Nuvoton gets > > > reflashed with the appropriate firmware. > > > > With IBM's LTC help, we finally found a Lenovo with the Nuvoton > > NCPT650. It's a System x3550 M5[1], not a ThinkStation P320, running > > Fedora (vmlinuz-4.16.14-300.fc28.x86_64). I replaced the 4.16 kernel > > with the latest stable 4.19.y kernel. Both the TPM and IMA seem to be > > working properly. Not sure if this helps... > > > > From dmesg: > > # dmesg | grep -i tpm > > [0.00] Linux version 4.19.14 (m...@x86tpm2server.rtp.stglabs.i > > bm.com) (gcc version 8.1.1 20180502 (Red Hat 8.1.1-1) (GCC)) #6 SMP > > Thu Jan 10 22:32:54 EST 2019 > > [0.00] efi: ACPI=0x7b786000 ACPI 2.0=0x7b786014 > > SMBIOS=0x793fe000 TPMEventLog=0x426fa018 > > [0.014413] ACPI: SSDT 0x7B784000 0003A7 (v02 INTEL > > Tpm2Tabl 1000 INTL 20130328) > > [0.014416] ACPI: TPM2 0x7B783000 34 (v03 INTEL EDK2 > > 0002 INTL 0113) > > [2.667052] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2 > > > > # cat /sys/kernel/security/ima/ascii_runtime_measurements | head -2 > > 10 5425744ce804c8cae89a08d53b41ab20ff1b3ea6 ima-sig > > sha1:7996f7339c3ce64e63f1232ef1aa6033247af784 boot_aggregate > > > > I installed the ibmtpm2tss[2], built (eg. autoreconf -i; configure -- > > enable-hwtpm) and installed it. > > > > # export LD_LIBRARY_PATH=/usr/local/lib/ > > # cd /usr/local/bin > > # ./tsspcrread -ha 10 -halg sha256 -ns > > f73ff9109b06d4f7a7cbe7eac32b20d2ca662e55cb4c81e152beea261989ad4b > > > > Mimi > > > > [1] https://lenovopress.com/lp0599.pdf > > [2] https://git.code.sf.net/p/ibmtpm20tss/tss > > > > what UEFI version is installed on that machine? > Is the TPM connected via LPC or I2C? > > Best regards > Michael > > I had a short look to an extracted x3550 UEFI firmware (tbe132l-2.52). This seems to be a very different implementation, probably due to the fact that this is a server firmware but not a desktop/workstation firmware. I do not know how much UEFI has influence on the communication with the TPM but I assume we can not really compare x3550 with P320 :-( Best regards Michael
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi Mimi, On Fri, 2019-01-11 at 10:40 -0500, Mimi Zohar wrote: > Hi Michael, > > On Sun, 2018-11-11 at 19:50 +0100, Michael Niewöhner wrote: > > > Well, there are at least two implementations I know of: > > For my Lenovo X260 I can choose between Infineon TPM 1.2 or Intel PTT TPM > > 2.0 > > This here is my ThinkStation P320 which can choose between PTT 1.2, PTT 2.0, > > Nuvoton 1.2 and 2.0. When switchting between 1.2 and 2.0 the Nuvoton gets > > reflashed with the appropriate firmware. > > With IBM's LTC help, we finally found a Lenovo with the Nuvoton > NCPT650. It's a System x3550 M5[1], not a ThinkStation P320, running > Fedora (vmlinuz-4.16.14-300.fc28.x86_64). I replaced the 4.16 kernel > with the latest stable 4.19.y kernel. Both the TPM and IMA seem to be > working properly. Not sure if this helps... > > From dmesg: > # dmesg | grep -i tpm > [0.00] Linux version 4.19.14 (m...@x86tpm2server.rtp.stglabs.i > bm.com) (gcc version 8.1.1 20180502 (Red Hat 8.1.1-1) (GCC)) #6 SMP > Thu Jan 10 22:32:54 EST 2019 > [0.00] efi: ACPI=0x7b786000 ACPI 2.0=0x7b786014 > SMBIOS=0x793fe000 TPMEventLog=0x426fa018 > [0.014413] ACPI: SSDT 0x7B784000 0003A7 (v02 INTEL > Tpm2Tabl 1000 INTL 20130328) > [0.014416] ACPI: TPM2 0x7B783000 34 (v03 INTEL EDK2 > 0002 INTL 0113) > [2.667052] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2 > > # cat /sys/kernel/security/ima/ascii_runtime_measurements | head -2 > 10 5425744ce804c8cae89a08d53b41ab20ff1b3ea6 ima-sig > sha1:7996f7339c3ce64e63f1232ef1aa6033247af784 boot_aggregate > > I installed the ibmtpm2tss[2], built (eg. autoreconf -i; configure -- > enable-hwtpm) and installed it. > > # export LD_LIBRARY_PATH=/usr/local/lib/ > # cd /usr/local/bin > # ./tsspcrread -ha 10 -halg sha256 -ns > f73ff9109b06d4f7a7cbe7eac32b20d2ca662e55cb4c81e152beea261989ad4b > > Mimi > > [1] https://lenovopress.com/lp0599.pdf > [2] https://git.code.sf.net/p/ibmtpm20tss/tss > what UEFI version is installed on that machine? Is the TPM connected via LPC or I2C? Best regards Michael
Re: tpm_tis TPM2.0 not detected on cold boot
On Thu, 2019-01-10 at 19:28 +0200, Jarkko Sakkinen wrote:
> On Fri, Jan 04, 2019 at 04:28:24PM +0100, Michael Niewöhner wrote:
> > root@debian:~# tpm2_pcrlist
> > ERROR:tcti:src/util/io.c:102:write_all() failed to write to fd 3: Operation
> > not
> > permitted
> > ERROR:tcti:src/tss2-tcti/tcti-device.c:86:tcti_device_transmit() wrong
> > number of
> > bytes written. Expected 22, wrote 0.
> > ERROR: GetCapability: Get PCR allocation status Error. TPM
> > Error:0xa000a..
> > ERROR: Unable to run tpm2_pcrlist
> > root@debian:~# tpm2_pcrlist; tpm2_pcrlist
> > sha1 :
> > 0 : 1ebb2be3b7103a09b5caeeb5827c1242cd6632ec
> > 1 : 425e833da73cb511150d6ffcf6fac64e9a6feb58
> > 2 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
> > 3 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
> > 4 : d13c141b174afbb568773adf1f39940a2df47c7d
> > 5 : 756a3647403ab141ec2c1ac7325854f4a93f6efd
> > ..
>
> So the sympton is that it from time to time works and time to time
> fails.
Not exactly. It only works on the second of two directly consecutive calls.
>
> Can't recall whether you had interrupts enabled or disabled for the
> TPM chip (depending on whether you use IRQs or polling you'd have
> to tweak the code from a different place), but you could tweak
> directly the TPM2_DURATION_* constants in drivers/char/tpm/tpm.h:
>
> enum tpm2_timeouts {
> TPM2_TIMEOUT_A =750,
> TPM2_TIMEOUT_B = 2000,
> TPM2_TIMEOUT_C =200,
> TPM2_TIMEOUT_D = 30,
> TPM2_DURATION_SHORT = 20,
> TPM2_DURATION_MEDIUM=750,
> TPM2_DURATION_LONG = 2000,
> TPM2_DURATION_LONG_LONG = 30,
> TPM2_DURATION_DEFAULT = 12,
> };
>
> Set SHORT, LONG and MEDIUM to lets say 3000 and lets see if that
> makes a difference or not.
> /Jarkko
I have already tried this but there was not any difference.
Michael
Re: tpm_tis TPM2.0 not detected on cold boot
On Thu, 2019-01-10 at 19:19 +0200, Jarkko Sakkinen wrote: > On Thu, Jan 03, 2019 at 04:47:31PM +0100, Michael Niewöhner wrote: > > On Thu, 2019-01-03 at 17:04 +0200, Jarkko Sakkinen wrote: > > > On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote: > > > > On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote: > > > > > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote: > > > > > > There is another issue but I don't know if both are related. Maybe > > > > > > that's > > > > > > just a > > > > > > timing issue... > > > > > > > > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 > > > > > > dd: error reading '/dev/hwrng': Operation not permitted > > > > > > 0+0 records in > > > > > > 0+0 records out > > > > > > 0 bytes copied, 0.755958 s, 0.0 kB/s > > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng > > > > > > bs=1 > > > > > > count=1 | xxd > > > > > > dd: error reading '/dev/hwrng': Operation not permitted > > > > > > 0+0 records in > > > > > > 0+0 records out > > > > > > 0 bytes copied, 0.755697 s, 0.0 kB/s > > > > > > 1+0 records in > > > > > > 1+0 records out > > > > > > : 52 R > > > > > > 1 byte copied, 0.0106268 s, 0.1 kB/s > > > > > > > > > > > > > > > > > > Michael > > > > > > > > > > What does /sys/devices/virtual/misc/hw_random/rng_current show? > > > > > > > > > > Did run commands as a sanity check on my laptop and seem to work. > > > > > > > > > > /Jarkko > > > > > > > > rng_current says "tpm-rng-0", which should be correct > > > > > > Is /dev/tpm0 accessible and usable? > > > > > > /Jarkko > > > > No, it does not seem to work: > > > > root@debian:~# tpm_version > > Tspi_Context_Connect failed: 0x3011 - layer=tsp, code=0011 (17), > > Communication failure > > root@debian:~# tcsd -f > > TCSD TDDL ioctl: (25) Inappropriate ioctl for device > > TCSD TDDL Falling back to Read/Write device support. > > TCSD TDDL ERROR: write to device /dev/tpm0 failed: Operation not permitted > > TCSD TCS ERROR: TCS GetCapability failed with result = 0x1087 > > root@debian:~# stat /dev/tpm0 > > File: /dev/tpm0 > > Size: 0 Blocks: 0 IO Block: 4096 character special > > file > > Device: 6h/6d Inode: 1114Links: 1 Device type: a,e0 > > Access: (0600/crw---) Uid: ( 104/ tss) Gid: ( 112/ tss) > > Access: 2019-01-03 16:39:20.627635333 +0100 > > Modify: 2019-01-03 16:39:20.627635333 +0100 > > Change: 2019-01-03 16:39:20.627635333 +0100 > > Birth: - > > But those tools should not work because TrouSerS is for TPM 1.2. > > /Jarkko Right. I realized that too late... Have a look at my email from Fri, 04 Jan 2019 19:26:10 +0100 Michael
Re: tpm_tis TPM2.0 not detected on cold boot
On Fri, 2019-01-04 at 16:28 +0100, Michael Niewöhner wrote: > On Fri, 2019-01-04 at 12:58 +0100, Michael Niewöhner wrote: > > On Thu, 2019-01-03 at 16:47 +0100, Michael Niewöhner wrote: > > > On Thu, 2019-01-03 at 17:04 +0200, Jarkko Sakkinen wrote: > > > > On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote: > > > > > On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote: > > > > > > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote: > > > > > > > There is another issue but I don't know if both are related. Maybe > > > > > > > that's > > > > > > > just a > > > > > > > timing issue... > > > > > > > > > > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 > > > > > > > dd: error reading '/dev/hwrng': Operation not permitted > > > > > > > 0+0 records in > > > > > > > 0+0 records out > > > > > > > 0 bytes copied, 0.755958 s, 0.0 kB/s > > > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd > > > > > > > if=/dev/hwrng > > > > > > > bs=1 > > > > > > > count=1 | xxd > > > > > > > dd: error reading '/dev/hwrng': Operation not permitted > > > > > > > 0+0 records in > > > > > > > 0+0 records out > > > > > > > 0 bytes copied, 0.755697 s, 0.0 kB/s > > > > > > > 1+0 records in > > > > > > > 1+0 records out > > > > > > > : 52 R > > > > > > > 1 byte copied, 0.0106268 s, 0.1 kB/s > > > > > > > > > > > > > > > > > > > > > Michael > > > > > > > > > > > > What does /sys/devices/virtual/misc/hw_random/rng_current show? > > > > > > > > > > > > Did run commands as a sanity check on my laptop and seem to work. > > > > > > > > > > > > /Jarkko > > > > > > > > > > rng_current says "tpm-rng-0", which should be correct > > > > > > > > Is /dev/tpm0 accessible and usable? > > > > > > > > /Jarkko > > > > > > No, it does not seem to work: > > > > > > root@debian:~# tpm_version > > > Tspi_Context_Connect failed: 0x3011 - layer=tsp, code=0011 (17), > > > Communication failure > > > root@debian:~# tcsd -f > > > TCSD TDDL ioctl: (25) Inappropriate ioctl for device > > > TCSD TDDL Falling back to Read/Write device support. > > > TCSD TDDL ERROR: write to device /dev/tpm0 failed: Operation not permitted > > > TCSD TCS ERROR: TCS GetCapability failed with result = 0x1087 > > > root@debian:~# stat /dev/tpm0 > > > File: /dev/tpm0 > > > Size: 0 Blocks: 0 IO Block: 4096 character > > > special > > > file > > > Device: 6h/6d Inode: 1114Links: 1 Device type: a,e0 > > > Access: (0600/crw---) Uid: ( 104/ tss) Gid: ( 112/ tss) > > > Access: 2019-01-03 16:39:20.627635333 +0100 > > > Modify: 2019-01-03 16:39:20.627635333 +0100 > > > Change: 2019-01-03 16:39:20.627635333 +0100 > > > Birth: - > > > > > > Michael > > > > I have done some more tests with tpm2-tests from > > https://github.com/jethrogb/tpm2-utils. > > These are my results: > > > > > > (initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type > > Error on write(fd,(char*)_cmd,sizeof(tpm_cmd)): Operation not permitted > > > > (initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type; ./tpm2-test /dev/tpm0 > > vendor_ > > tpm_type > > Error on write(fd,(char*)_cmd,sizeof(tpm_cmd)): Operation not permitted > > � > > nitramfs) > > > > -> Same symptom like with dd if=/dev/tpm > > > > > > Trying to read the firmware version: > > > > (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 > > firmwa > > re_version_1;) 2>/dev/null | hexdump -C > > 80 01 00 00 00 1b 00 00 00 00 01 00 00 00 06 > > 00 || > > 0010 00 00 01 00 00 01 0b 00 01 00 03 |...| > > 001b > > > > (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 > > fi
Re: tpm_tis TPM2.0 not detected on cold boot
On Fri, 2019-01-04 at 12:58 +0100, Michael Niewöhner wrote: > On Thu, 2019-01-03 at 16:47 +0100, Michael Niewöhner wrote: > > On Thu, 2019-01-03 at 17:04 +0200, Jarkko Sakkinen wrote: > > > On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote: > > > > On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote: > > > > > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote: > > > > > > There is another issue but I don't know if both are related. Maybe > > > > > > that's > > > > > > just a > > > > > > timing issue... > > > > > > > > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 > > > > > > dd: error reading '/dev/hwrng': Operation not permitted > > > > > > 0+0 records in > > > > > > 0+0 records out > > > > > > 0 bytes copied, 0.755958 s, 0.0 kB/s > > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng > > > > > > bs=1 > > > > > > count=1 | xxd > > > > > > dd: error reading '/dev/hwrng': Operation not permitted > > > > > > 0+0 records in > > > > > > 0+0 records out > > > > > > 0 bytes copied, 0.755697 s, 0.0 kB/s > > > > > > 1+0 records in > > > > > > 1+0 records out > > > > > > : 52 R > > > > > > 1 byte copied, 0.0106268 s, 0.1 kB/s > > > > > > > > > > > > > > > > > > Michael > > > > > > > > > > What does /sys/devices/virtual/misc/hw_random/rng_current show? > > > > > > > > > > Did run commands as a sanity check on my laptop and seem to work. > > > > > > > > > > /Jarkko > > > > > > > > rng_current says "tpm-rng-0", which should be correct > > > > > > Is /dev/tpm0 accessible and usable? > > > > > > /Jarkko > > > > No, it does not seem to work: > > > > root@debian:~# tpm_version > > Tspi_Context_Connect failed: 0x3011 - layer=tsp, code=0011 (17), > > Communication failure > > root@debian:~# tcsd -f > > TCSD TDDL ioctl: (25) Inappropriate ioctl for device > > TCSD TDDL Falling back to Read/Write device support. > > TCSD TDDL ERROR: write to device /dev/tpm0 failed: Operation not permitted > > TCSD TCS ERROR: TCS GetCapability failed with result = 0x1087 > > root@debian:~# stat /dev/tpm0 > > File: /dev/tpm0 > > Size: 0 Blocks: 0 IO Block: 4096 character special > > file > > Device: 6h/6d Inode: 1114Links: 1 Device type: a,e0 > > Access: (0600/crw---) Uid: ( 104/ tss) Gid: ( 112/ tss) > > Access: 2019-01-03 16:39:20.627635333 +0100 > > Modify: 2019-01-03 16:39:20.627635333 +0100 > > Change: 2019-01-03 16:39:20.627635333 +0100 > > Birth: - > > > > Michael > > I have done some more tests with tpm2-tests from > https://github.com/jethrogb/tpm2-utils. > These are my results: > > > (initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type > Error on write(fd,(char*)_cmd,sizeof(tpm_cmd)): Operation not permitted > > (initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type; ./tpm2-test /dev/tpm0 > vendor_ > tpm_type > Error on write(fd,(char*)_cmd,sizeof(tpm_cmd)): Operation not permitted > � > nitramfs) > > -> Same symptom like with dd if=/dev/tpm > > > Trying to read the firmware version: > > (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 > firmwa > re_version_1;) 2>/dev/null | hexdump -C > 80 01 00 00 00 1b 00 00 00 00 01 00 00 00 06 00 || > 0010 00 00 01 00 00 01 0b 00 01 00 03 |...| > 001b > > (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 > firmwa > re_version_2;) 2>/dev/null | hexdump -C > 80 01 00 00 00 1b 00 00 00 00 01 00 00 00 06 00 || > 0010 00 00 01 00 00 01 0c 00 02 00 08 |...| > 001b > > -> This version numbers are correct, 1.3.2.8 indeed is the current flashed > firmware. > > > Get the vendor strings: > > (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 > vendor > _string_1;) 2>/dev/null | xxd > : 8001 001b 0100 0600 > 001
Re: tpm_tis TPM2.0 not detected on cold boot
On Thu, 2019-01-03 at 16:47 +0100, Michael Niewöhner wrote: > On Thu, 2019-01-03 at 17:04 +0200, Jarkko Sakkinen wrote: > > On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote: > > > On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote: > > > > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote: > > > > > There is another issue but I don't know if both are related. Maybe > > > > > that's > > > > > just a > > > > > timing issue... > > > > > > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 > > > > > dd: error reading '/dev/hwrng': Operation not permitted > > > > > 0+0 records in > > > > > 0+0 records out > > > > > 0 bytes copied, 0.755958 s, 0.0 kB/s > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng > > > > > bs=1 > > > > > count=1 | xxd > > > > > dd: error reading '/dev/hwrng': Operation not permitted > > > > > 0+0 records in > > > > > 0+0 records out > > > > > 0 bytes copied, 0.755697 s, 0.0 kB/s > > > > > 1+0 records in > > > > > 1+0 records out > > > > > : 52 R > > > > > 1 byte copied, 0.0106268 s, 0.1 kB/s > > > > > > > > > > > > > > > Michael > > > > > > > > What does /sys/devices/virtual/misc/hw_random/rng_current show? > > > > > > > > Did run commands as a sanity check on my laptop and seem to work. > > > > > > > > /Jarkko > > > > > > rng_current says "tpm-rng-0", which should be correct > > > > Is /dev/tpm0 accessible and usable? > > > > /Jarkko > > No, it does not seem to work: > > root@debian:~# tpm_version > Tspi_Context_Connect failed: 0x3011 - layer=tsp, code=0011 (17), > Communication failure > root@debian:~# tcsd -f > TCSD TDDL ioctl: (25) Inappropriate ioctl for device > TCSD TDDL Falling back to Read/Write device support. > TCSD TDDL ERROR: write to device /dev/tpm0 failed: Operation not permitted > TCSD TCS ERROR: TCS GetCapability failed with result = 0x1087 > root@debian:~# stat /dev/tpm0 > File: /dev/tpm0 > Size: 0 Blocks: 0 IO Block: 4096 character special > file > Device: 6h/6d Inode: 1114Links: 1 Device type: a,e0 > Access: (0600/crw---) Uid: ( 104/ tss) Gid: ( 112/ tss) > Access: 2019-01-03 16:39:20.627635333 +0100 > Modify: 2019-01-03 16:39:20.627635333 +0100 > Change: 2019-01-03 16:39:20.627635333 +0100 > Birth: - > > Michael I have done some more tests with tpm2-tests from https://github.com/jethrogb/tpm2-utils. These are my results: (initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type Error on write(fd,(char*)_cmd,sizeof(tpm_cmd)): Operation not permitted (initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type; ./tpm2-test /dev/tpm0 vendor_ tpm_type Error on write(fd,(char*)_cmd,sizeof(tpm_cmd)): Operation not permitted � nitramfs) -> Same symptom like with dd if=/dev/tpm Trying to read the firmware version: (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 firmwa re_version_1;) 2>/dev/null | hexdump -C 80 01 00 00 00 1b 00 00 00 00 01 00 00 00 06 00 || 0010 00 00 01 00 00 01 0b 00 01 00 03 |...| 001b (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 firmwa re_version_2;) 2>/dev/null | hexdump -C 80 01 00 00 00 1b 00 00 00 00 01 00 00 00 06 00 || 0010 00 00 01 00 00 01 0c 00 02 00 08 |...| 001b -> This version numbers are correct, 1.3.2.8 indeed is the current flashed firmware. Get the vendor strings: (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 vendor _string_1;) 2>/dev/null | xxd : 8001 001b 0100 0600 0010: 0100 0001 0672 6c73 00 ...rls. (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 vendor _string_2;) 2>/dev/null | xxd : 8001 001b 0100 0600 0010: 0100 0001 074e 5043 54 ...NPCT (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 vendor _string_3;) 2>/dev/null | xxd : 8001 001b 0100 0600 0010: 0100 0001 0820 00 ... ... (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 vendor _string_4;) 2>/dev/null | xxd : 8001 001b 0100 0600 0010: 0100 0001 0920 00 ... ... Well, NPCT is correct... Michael
Re: tpm_tis TPM2.0 not detected on cold boot
On Thu, 2019-01-03 at 17:04 +0200, Jarkko Sakkinen wrote: > On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote: > > On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote: > > > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote: > > > > There is another issue but I don't know if both are related. Maybe > > > > that's > > > > just a > > > > timing issue... > > > > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 > > > > dd: error reading '/dev/hwrng': Operation not permitted > > > > 0+0 records in > > > > 0+0 records out > > > > 0 bytes copied, 0.755958 s, 0.0 kB/s > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng > > > > bs=1 > > > > count=1 | xxd > > > > dd: error reading '/dev/hwrng': Operation not permitted > > > > 0+0 records in > > > > 0+0 records out > > > > 0 bytes copied, 0.755697 s, 0.0 kB/s > > > > 1+0 records in > > > > 1+0 records out > > > > : 52 R > > > > 1 byte copied, 0.0106268 s, 0.1 kB/s > > > > > > > > > > > > Michael > > > > > > What does /sys/devices/virtual/misc/hw_random/rng_current show? > > > > > > Did run commands as a sanity check on my laptop and seem to work. > > > > > > /Jarkko > > > > rng_current says "tpm-rng-0", which should be correct > > Is /dev/tpm0 accessible and usable? > > /Jarkko No, it does not seem to work: root@debian:~# tpm_version Tspi_Context_Connect failed: 0x3011 - layer=tsp, code=0011 (17), Communication failure root@debian:~# tcsd -f TCSD TDDL ioctl: (25) Inappropriate ioctl for device TCSD TDDL Falling back to Read/Write device support. TCSD TDDL ERROR: write to device /dev/tpm0 failed: Operation not permitted TCSD TCS ERROR: TCS GetCapability failed with result = 0x1087 root@debian:~# stat /dev/tpm0 File: /dev/tpm0 Size: 0 Blocks: 0 IO Block: 4096 character special file Device: 6h/6d Inode: 1114Links: 1 Device type: a,e0 Access: (0600/crw---) Uid: ( 104/ tss) Gid: ( 112/ tss) Access: 2019-01-03 16:39:20.627635333 +0100 Modify: 2019-01-03 16:39:20.627635333 +0100 Change: 2019-01-03 16:39:20.627635333 +0100 Birth: - Michael
Re: tpm_tis TPM2.0 not detected on cold boot
On Thu, 2019-01-03 at 15:41 +0200, Jarkko Sakkinen wrote: > On Sun, Dec 16, 2018 at 02:32:38PM +0100, Michael Niewöhner wrote: > > > dmesg cold boot with tpm_tis.interrupts=0 tpm_tis.force=1: > > -- > > > dmesg | grep -i tpm > > [0.00] Command line: initrd=\initrd-test console=ttyS0,115200n8 > > break=premount tpm_tis.interrupts=0 tpm_tis.force=1 > > [0.00] efi: ACPI > > 2.0=0x9e07e000 ACPI=0x9e07e000 SMBIOS=0x9ebeb000 SMBIOS > > 3.0=0x9ebea000 MEMATTR=0x98fb2018 TPMEventLog=0x972bb018 > > [0.003531] ACPI: TPM2 0x9E0B7F70 34 (v03 LENOVO TC- > > S06 1260 AMI ) > > [0.162005] Kernel command line: initrd=\initrd-test > > console=ttyS0,115200n8 > > break=premount tpm_tis.interrupts=0 tpm_tis.force=1 > > [3.616806] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > [3.683117] tpm_tis tpm_tis: can't request region for resource [mem > > 0xfed4-0xfed44fff] > > [3.691378] tpm_tis: probe of tpm_tis failed with error -16 > > [4.572539] ima: Error Communicating to TPM chip > > Wonder why this happens. What does /proc/iomem show? > > /Jarkko root@debian:~# cat /proc/iomem -0fff : Reserved 1000-00057fff : System RAM 00058000-00058fff : Reserved 00059000-0009dfff : System RAM 0009e000-000f : Reserved 000a-000b : PCI Bus :00 000c-000c3fff : PCI Bus :00 000c4000-000c7fff : PCI Bus :00 000c8000-000cbfff : PCI Bus :00 000cc000-000c : PCI Bus :00 000d-000d3fff : PCI Bus :00 000d4000-000d7fff : PCI Bus :00 000d8000-000dbfff : PCI Bus :00 000dc000-000d : PCI Bus :00 000e-000e3fff : PCI Bus :00 000e4000-000e7fff : PCI Bus :00 000e8000-000ebfff : PCI Bus :00 000ec000-000e : PCI Bus :00 000f-000f : System ROM 0010-942eb017 : System RAM 942eb018-942fb457 : System RAM 942fb458-976bbfff : System RAM 976bc000-976bcfff : ACPI Non-volatile Storage 976bd000-976bdfff : Reserved 976be000-9d7fafff : System RAM 9d7fb000-9ea61fff : Reserved 9dde3018-9dde3019 : APEI ERST 9dde301c-9dde3021 : APEI ERST 9dde3028-9dde3039 : APEI ERST 9dde3040-9dde304c : APEI ERST 9dde3050-9dde504f : APEI ERST 9ea62000-9eaedfff : ACPI Tables 9eaee000-9f2c7fff : ACPI Non-volatile Storage 9f2c8000-9f743fff : Reserved 9f744000-9f7f : System RAM 9f80-9fff : Reserved a000-dfff : PCI Bus :00 dfb0-dfdf : PCI Bus :03 dfb0-dfb7 : :03:00.3 dfb0-dfb7 : igb dfb8-dfbf : :03:00.2 dfb8-dfbf : igb dfc0-dfc7 : :03:00.1 dfc0-dfc7 : igb dfc8-dfcf : :03:00.0 dfc8-dfcf : igb dfd0-dfd03fff : :03:00.3 dfd0-dfd03fff : igb dfd04000-dfd07fff : :03:00.2 dfd04000-dfd07fff : igb dfd08000-dfd0bfff : :03:00.1 dfd08000-dfd0bfff : igb dfd0c000-dfd0 : :03:00.0 dfd0c000-dfd0 : igb dfe0-dfef : PCI Bus :02 dfe0-dfe03fff : :02:00.0 dfe0-dfe03fff : rtl_pci dff0-dff1 : :00:1f.6 dff0-dff1 : e1000e dff2-dff23fff : :00:1f.2 dff24000-dff25fff : :00:17.0 dff24000-dff25fff : ahci dff26000-dff267ff : :00:17.0 dff26000-dff267ff : ahci dff27000-dff270ff : :00:17.0 dff27000-dff270ff : ahci dffe-dfff : pnp 00:06 e000-efff : PCI MMCONFIG [bus 00-ff] e000-efff : Reserved e000-efff : pnp 00:06 fd00-fe7f : PCI Bus :00 fd00-fdab : pnp 00:07 fdac-fdac : pnp 00:09 fdad-fdad : pnp 00:07 fdae-fdae : pnp 00:09 fdaf-fdaf : pnp 00:09 fdb0-fdff : pnp 00:07 fdc6000c-fdc6000f : iTCO_wdt fdc6000c-fdc6000f : iTCO_wdt fe00-fe010fff : Reserved fe036000-fe03bfff : pnp 00:07 fe03d000-fe3f : pnp 00:07 fe41-fe7f : pnp 00:07 fec0-fec00fff : Reserved fec0-fec003ff : IOAPIC 0 fed0-fed00fff : Reserved fed0-fed003ff : HPET 0 fed0-fed003ff : PNP0103:00 fed1-fed17fff : pnp 00:06 fed18000-fed18fff : pnp 00:06 fed19000-fed19fff : pnp 00:06 fed2-fed3 : pnp 00:06 fed4-fed44fff : MSFT0101:00 fed4-fed44fff : MSFT0101:00 fed45000-fed8 : pnp 00:06 fed9-fed90fff : dmar0 fee0-fee00fff : Local APIC fee0-fee00fff : Reserved ff00- : Reserved ff00- : INT0800:00 ff00- : pnp 00:06 1-85fff : System RAM 2afc0-2b06031d0 : Kernel code 2b06031d1-2b0d120ff : Kernel data 2b1119000-2b11f : Kernel bss 20-2f : PCI Bus :00 20-20 : :00:14.0 20-20 : xhci-hcd 21-2100ff : :00:1f.4 211000-211fff : :00:14.2 211000-211fff : Intel PCH thermal driver
Re: tpm_tis TPM2.0 not detected on cold boot
On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote: > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote: > > There is another issue but I don't know if both are related. Maybe that's > > just a > > timing issue... > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 > > dd: error reading '/dev/hwrng': Operation not permitted > > 0+0 records in > > 0+0 records out > > 0 bytes copied, 0.755958 s, 0.0 kB/s > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng bs=1 > > count=1 | xxd > > dd: error reading '/dev/hwrng': Operation not permitted > > 0+0 records in > > 0+0 records out > > 0 bytes copied, 0.755697 s, 0.0 kB/s > > 1+0 records in > > 1+0 records out > > : 52 R > > 1 byte copied, 0.0106268 s, 0.1 kB/s > > > > > > Michael > > What does /sys/devices/virtual/misc/hw_random/rng_current show? > > Did run commands as a sanity check on my laptop and seem to work. > > /Jarkko rng_current says "tpm-rng-0", which should be correct Michael
Re: tpm_tis TPM2.0 not detected on cold boot
On Tue, 2019-01-01 at 11:38 -0500, Mimi Zohar wrote: > On Tue, 2019-01-01 at 17:15 +0100, Michael Niewöhner wrote: > > On Mon, 2018-12-31 at 16:17 -0500, Mimi Zohar wrote: > > > On Sun, 2018-12-30 at 14:22 +0100, Michael Niewöhner wrote: > > > > > > > > difference is that on a cold boot, the TPM takes longer to initialize. > > > > > > > > Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot > > > > manager > > > > does > > > > not solve the problem. So the problem is NOT that the TPM takes longer > > > > to > > > > initialize. Even adding a delay of 20 seconds before TPM init does not > > > > solve > > > > that while that should be more than enough time. > > > > > > The purpose of commenting out the TPM2 selftest was to minimize the > > > TPM initialization delay, so that the TPM is ready before IMA. After > > > James' patch that wasn't needed anymore. > > > > > > Looking back at this thread, I see you're using systemd-boot, not > > > grub2. When you commented out the systemd-boot timeout, IMA found the > > > TPM. The question is why isn't the TPM ready with the timeout before > > > IMA (like above)? Has systemd-boot done the selftest? > > > > I am not sure wether systemd-boot touches TPM at all but I get the same > > behaviour with syslinux-efi. > > From looking at the source code, it depends on whether systemd was > compiled with ENABLE_TPM enabled(eg. src/boot/efi/boot.c, > src/boot/efi/measure.c, src/boot/efi/stub.c). Debian build it with TPM enabled. I just checked syslinux-efi which does not do anything TPM-related. > > Mimi >
Re: tpm_tis TPM2.0 not detected on cold boot
On Mon, 2018-12-31 at 16:17 -0500, Mimi Zohar wrote: > On Sun, 2018-12-30 at 14:22 +0100, Michael Niewöhner wrote: > > > > difference is that on a cold boot, the TPM takes longer to initialize. > > > > Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot manager > > does > > not solve the problem. So the problem is NOT that the TPM takes longer to > > initialize. Even adding a delay of 20 seconds before TPM init does not solve > > that while that should be more than enough time. > > The purpose of commenting out the TPM2 selftest was to minimize the > TPM initialization delay, so that the TPM is ready before IMA. After > James' patch that wasn't needed anymore. > > Looking back at this thread, I see you're using systemd-boot, not > grub2. When you commented out the systemd-boot timeout, IMA found the > TPM. The question is why isn't the TPM ready with the timeout before > IMA (like above)? Has systemd-boot done the selftest? I am not sure wether systemd-boot touches TPM at all but I get the same behaviour with syslinux-efi. > > Mimi >
Re: tpm_tis TPM2.0 not detected on cold boot
On Sat, 2018-12-29 at 22:33 -0500, Mimi Zohar wrote: > On Tue, 2018-12-25 at 14:55 +0100, Michael Niewöhner wrote: > > On Sun, 2018-12-23 at 12:55 +0100, Michael Niewöhner wrote: > > > Hi Mimi, > > > > > > On Sat, 2018-12-22 at 17:53 -0500, Mimi Zohar wrote: > > > > On Sat, 2018-12-22 at 14:47 +0100, Michael Niewöhner wrote: > > > > > > > > > When I remove the timeout and boot directly to the linux kernel, I get > > > > > that > > > > > "2314 TPM-self test error" since it has not finished, yet. The TPM is > > > > > detected > > > > > by IMA and works fine then. > > > > > > > > > > Some more tests showed that any delay before booting the kernel causes > > > > > the > > > > > TPM > > > > > to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in > > > > > some > > > > > very > > > > > rare cases the TPM got detected. > > > > > > > > > > I wanted to know if the TPM is in an well initialized state at the > > > > > time of > > > > > that > > > > > error. Since I was not able to get some test/debug kernel patches > > > > > working > > > > > I > > > > > decided to try kexec. It turned out that the TPM is indeed correctly > > > > > working > > > > > and > > > > > will be detected just fine by linux after kexec! > > > > > > > > No surprise here. kexec would be the equivalent of a soft reboot. > > > > > > Well, I am not that deep in kexec internals but isn't a soft reboot much > > > more > > > than a kexec? I thought kexec would "just" load the new kernel to memory > > > and > > > executes it while a soft reboot goes at least through some UEFI > > > initialization. > > > For example, my pwm fans - in fact the EC - get resetted on a soft reboot, > > > while > > > a kexec does not touch them. > > > > > Similarly, the PCRs are not reset on kexec. > > > > That is why I wanted to test if there is a different behaviour on kexec > > > compared > > > to a "real" soft reboot. If there was such difference I would have assumed > > > a > > > UEFI bug that does not initialize the TPM correctly. > > > Kexec AFAIK does not invoke any UEFI initialization, so the TPM should be > > > in > > > the > > > same state as before kexec and since there is no difference between sr and > > > kexec > > > I have the feeling there is something wrong in the kernel. > > > > > > Correct me if I am wrong here, please. > > But the problem you've described is on a cold boot, not a soft reboot. > Both the soft reboot and kexec are working properly. It seems the Exactly, soft reboot / warm boot works. What I don't understand is WHY it works. If it was a hardware problem I would expect it not to work after it previously failed after a cold boot but that is not the case. The warm reboot / kexec does reinitialize anything. That means maybe it would be sufficient to reinitialize that - whatever it is - to get the TPM working instead of needing a full warm reboot. > difference is that on a cold boot, the TPM takes longer to initialize. Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot manager does not solve the problem. So the problem is NOT that the TPM takes longer to initialize. Even adding a delay of 20 seconds before TPM init does not solve that while that should be more than enough time. > > > > My current workaround is to do a machine_emergency_reboot() when TPM isn't > > > detected correctly. That is a pretty hard workaround but it seems to work > > > for > > > now... > > This is a again soft reboot. > > > > > > > > Is there anyone having an idea what could be wrong here? I am willing > > > > > to > > > > > debug > > > > > this but I have really no idea where to start :-( > > > > > > > > A while ago, I was "playing" with a pi. Commenting out > > > > tpm2_do_selftest() seemed to resolve a similar problem, but that was > > > > before James' patches. I don't know if that would make a difference > > > > now. > > > > > > Hm, I will try that.. > > > > > > > Unfortunately this did not change anything > > Not much I can do now. After vacation, I'll set up the pi to see if > it is working properly with a recent kernel. > > Mimi >
Re: tpm_tis TPM2.0 not detected on cold boot
On Sun, 2018-12-23 at 12:55 +0100, Michael Niewöhner wrote: > Hi Mimi, > > On Sat, 2018-12-22 at 17:53 -0500, Mimi Zohar wrote: > > On Sat, 2018-12-22 at 14:47 +0100, Michael Niewöhner wrote: > > > > > When I remove the timeout and boot directly to the linux kernel, I get > > > that > > > "2314 TPM-self test error" since it has not finished, yet. The TPM is > > > detected > > > by IMA and works fine then. > > > > > > Some more tests showed that any delay before booting the kernel causes the > > > TPM > > > to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in some > > > very > > > rare cases the TPM got detected. > > > > > > I wanted to know if the TPM is in an well initialized state at the time of > > > that > > > error. Since I was not able to get some test/debug kernel patches working > > > I > > > decided to try kexec. It turned out that the TPM is indeed correctly > > > working > > > and > > > will be detected just fine by linux after kexec! > > > > No surprise here. kexec would be the equivalent of a soft reboot. > > Well, I am not that deep in kexec internals but isn't a soft reboot much more > than a kexec? I thought kexec would "just" load the new kernel to memory and > executes it while a soft reboot goes at least through some UEFI > initialization. > For example, my pwm fans - in fact the EC - get resetted on a soft reboot, > while > a kexec does not touch them. > > That is why I wanted to test if there is a different behaviour on kexec > compared > to a "real" soft reboot. If there was such difference I would have assumed a > UEFI bug that does not initialize the TPM correctly. > Kexec AFAIK does not invoke any UEFI initialization, so the TPM should be in > the > same state as before kexec and since there is no difference between sr and > kexec > I have the feeling there is something wrong in the kernel. > > Correct me if I am wrong here, please. > > My current workaround is to do a machine_emergency_reboot() when TPM isn't > detected correctly. That is a pretty hard workaround but it seems to work for > now... > > > > > > > > > Is there anyone having an idea what could be wrong here? I am willing to > > > debug > > > this but I have really no idea where to start :-( > > > > A while ago, I was "playing" with a pi. Commenting out > > tpm2_do_selftest() seemed to resolve a similar problem, but that was > > before James' patches. I don't know if that would make a difference > > now. > > Hm, I will try that.. > Unfortunately this did not change anything > > > Mimi > > > > There is another issue but I don't know if both are related. Maybe that's just > a > timing issue... > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 > dd: error reading '/dev/hwrng': Operation not permitted > 0+0 records in > 0+0 records out > 0 bytes copied, 0.755958 s, 0.0 kB/s > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng bs=1 > count=1 | xxd > dd: error reading '/dev/hwrng': Operation not permitted > 0+0 records in > 0+0 records out > 0 bytes copied, 0.755697 s, 0.0 kB/s > 1+0 records in > 1+0 records out > : 52 R > 1 byte copied, 0.0106268 s, 0.1 kB/s > > > Michael
Re: tpm_tis TPM2.0 not detected on cold boot
Hi Mimi, On Sat, 2018-12-22 at 17:53 -0500, Mimi Zohar wrote: > On Sat, 2018-12-22 at 14:47 +0100, Michael Niewöhner wrote: > > > When I remove the timeout and boot directly to the linux kernel, I get that > > "2314 TPM-self test error" since it has not finished, yet. The TPM is > > detected > > by IMA and works fine then. > > > > Some more tests showed that any delay before booting the kernel causes the > > TPM > > to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in some > > very > > rare cases the TPM got detected. > > > > I wanted to know if the TPM is in an well initialized state at the time of > > that > > error. Since I was not able to get some test/debug kernel patches working I > > decided to try kexec. It turned out that the TPM is indeed correctly working > > and > > will be detected just fine by linux after kexec! > > No surprise here. kexec would be the equivalent of a soft reboot. Well, I am not that deep in kexec internals but isn't a soft reboot much more than a kexec? I thought kexec would "just" load the new kernel to memory and executes it while a soft reboot goes at least through some UEFI initialization. For example, my pwm fans - in fact the EC - get resetted on a soft reboot, while a kexec does not touch them. That is why I wanted to test if there is a different behaviour on kexec compared to a "real" soft reboot. If there was such difference I would have assumed a UEFI bug that does not initialize the TPM correctly. Kexec AFAIK does not invoke any UEFI initialization, so the TPM should be in the same state as before kexec and since there is no difference between sr and kexec I have the feeling there is something wrong in the kernel. Correct me if I am wrong here, please. My current workaround is to do a machine_emergency_reboot() when TPM isn't detected correctly. That is a pretty hard workaround but it seems to work for now... > > > > > Is there anyone having an idea what could be wrong here? I am willing to > > debug > > this but I have really no idea where to start :-( > > A while ago, I was "playing" with a pi. Commenting out > tpm2_do_selftest() seemed to resolve a similar problem, but that was > before James' patches. I don't know if that would make a difference > now. Hm, I will try that.. > Mimi > There is another issue but I don't know if both are related. Maybe that's just a timing issue... root@debian:~# dd if=/dev/hwrng bs=1 count=1 dd: error reading '/dev/hwrng': Operation not permitted 0+0 records in 0+0 records out 0 bytes copied, 0.755958 s, 0.0 kB/s root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng bs=1 count=1 | xxd dd: error reading '/dev/hwrng': Operation not permitted 0+0 records in 0+0 records out 0 bytes copied, 0.755697 s, 0.0 kB/s 1+0 records in 1+0 records out : 52 R 1 byte copied, 0.0106268 s, 0.1 kB/s Michael
Re: tpm_tis TPM2.0 not detected on cold boot
Hi all, On Sun, 2018-12-16 at 14:32 +0100, Michael Niewöhner wrote: > Hi again, > > after my UEFI firmware mod/hack to flash the newest available Nuvoton firmware > to the NCPT650 the selftest error went away. Since then the TPM worked without > any further problems, at least after warm reboots. > > What I didn't notice before is that it does NOT work after a cold (re)boot. > There is no difference between Intel Firmware TPM and the Nuvoton TPM. > I can reproduce the error for both. I did not test TPM1.2 again. > > dmesg warm (re)boot: > > > dmesg | grep -i tpm > > [0.00] efi: ACPI > 2.0=0x9e07e000 ACPI=0x9e07e000 SMBIOS=0x9ebeb000 SMBIOS > 3.0=0x9ebea000 MEMATTR=0x98fb2018 TPMEventLog=0x972bc018 > [0.003368] ACPI: TPM2 0x9E0B7F70 34 (v03 LENOVO TC- > S06 1260 AMI ) > [3.610138] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > dmesg cold boot with tpm_tis.interrupts=0 tpm_tis.force=1: > -- > > dmesg | grep -i tpm > > [0.00] Command line: initrd=\initrd-test console=ttyS0,115200n8 > break=premount tpm_tis.interrupts=0 tpm_tis.force=1 > [0.00] efi: ACPI > 2.0=0x9e07e000 ACPI=0x9e07e000 SMBIOS=0x9ebeb000 SMBIOS > 3.0=0x9ebea000 MEMATTR=0x98fb2018 TPMEventLog=0x972bb018 > [0.003531] ACPI: TPM2 0x9E0B7F70 34 (v03 LENOVO TC- > S06 1260 AMI ) > [0.162005] Kernel command line: initrd=\initrd-test console=ttyS0,115200n8 > break=premount tpm_tis.interrupts=0 tpm_tis.force=1 > [3.616806] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > [3.683117] tpm_tis tpm_tis: can't request region for resource [mem > 0xfed4-0xfed44fff] > [3.691378] tpm_tis: probe of tpm_tis failed with error -16 > [4.572539] ima: Error Communicating to TPM chip > > > dmesg cold boot: > > > dmesg | grep -i tpm > > [0.00] Command line: initrd=\initrd-test console=ttyS0,115200n8 > break=premount > [0.00] efi: ACPI > 2.0=0x9e07e000 ACPI=0x9e07e000 SMBIOS=0x9ebeb000 SMBIOS > 3.0=0x9ebea000 MEMATTR=0x98fb2298 TPMEventLog=0x972bb018 > [0.003559] ACPI: TPM2 0x9E0B7F70 34 (v03 LENOVO TC- > S06 1260 AMI ) > [0.161958] Kernel command line: initrd=\initrd-test console=ttyS0,115200n8 > break=premount > [5.245801] ima: No TPM chip found, activating TPM-bypass! > > > Any ideas how to debug this? > > Thanks > Michael I have been doing some more debugging - as far as I were able to. These are my results: Doing a cold boot I was getting "No TPM chip found" in most cases. I found out that the TPM will not be found if the bootloader (systemd-boot in my case) has a timeout value of 10 seconds. This was set for some other tests... When I remove the timeout and boot directly to the linux kernel, I get that "2314 TPM-self test error" since it has not finished, yet. The TPM is detected by IMA and works fine then. Some more tests showed that any delay before booting the kernel causes the TPM to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in some very rare cases the TPM got detected. I wanted to know if the TPM is in an well initialized state at the time of that error. Since I was not able to get some test/debug kernel patches working I decided to try kexec. It turned out that the TPM is indeed correctly working and will be detected just fine by linux after kexec! Is there anyone having an idea what could be wrong here? I am willing to debug this but I have really no idea where to start :-( Best regards Michael kexec test output: <...> (initramfs) dmesg | grep -i tpm [0.00] Command line: initrd=\initrd console=ttyS0,115200n8 root=zfs:rpool/ROOT tpm.override_rng_quality=1024 quiet break=top [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 SMBIOS 3.0=0x9f5ea000 MPS=0xfca00 ESRT=0x9c07b118 MEMATTR=0x9982d018 TPMEventLog=0x 98ace018 [0.001310] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC- S06 1260 AMI ) [0.159568] Kernel command line: initrd=\initrd console=ttyS0,115200n8 root=zfs:rpool/ROOT quiet break=top [1.376200] ima: No TPM chip found, activating TPM-bypass! / # kexec -f --initrd=/initrd.img-4.19.9\+ --reuse-cmdline /vmlinuz-4.19.9\+ [ 890.632541] kexec_core: Starting new kernel <...> (initramfs) dmesg | grep -i tpm [0.00] Command line: initrd=\initrd console=ttyS0,115200n8 root=zfs:rpool/ROOT tpm.override_rng_quality=1024 quiet break=top [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 SMBIOS 3.0=0x9f5ea000 MPS=0xfca00 ESRT=0x9c07b118 MEMATTR=0x9982d018 TPMEventLog=0x 98ace018 [
tpm_tis TPM2.0 not detected on cold boot
Hi again, after my UEFI firmware mod/hack to flash the newest available Nuvoton firmware to the NCPT650 the selftest error went away. Since then the TPM worked without any further problems, at least after warm reboots. What I didn't notice before is that it does NOT work after a cold (re)boot. There is no difference between Intel Firmware TPM and the Nuvoton TPM. I can reproduce the error for both. I did not test TPM1.2 again. dmesg warm (re)boot: > dmesg | grep -i tpm [0.00] efi: ACPI 2.0=0x9e07e000 ACPI=0x9e07e000 SMBIOS=0x9ebeb000 SMBIOS 3.0=0x9ebea000 MEMATTR=0x98fb2018 TPMEventLog=0x972bc018 [0.003368] ACPI: TPM2 0x9E0B7F70 34 (v03 LENOVO TC- S06 1260 AMI ) [3.610138] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) dmesg cold boot with tpm_tis.interrupts=0 tpm_tis.force=1: -- > dmesg | grep -i tpm [0.00] Command line: initrd=\initrd-test console=ttyS0,115200n8 break=premount tpm_tis.interrupts=0 tpm_tis.force=1 [0.00] efi: ACPI 2.0=0x9e07e000 ACPI=0x9e07e000 SMBIOS=0x9ebeb000 SMBIOS 3.0=0x9ebea000 MEMATTR=0x98fb2018 TPMEventLog=0x972bb018 [0.003531] ACPI: TPM2 0x9E0B7F70 34 (v03 LENOVO TC- S06 1260 AMI ) [0.162005] Kernel command line: initrd=\initrd-test console=ttyS0,115200n8 break=premount tpm_tis.interrupts=0 tpm_tis.force=1 [3.616806] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) [3.683117] tpm_tis tpm_tis: can't request region for resource [mem 0xfed4-0xfed44fff] [3.691378] tpm_tis: probe of tpm_tis failed with error -16 [4.572539] ima: Error Communicating to TPM chip dmesg cold boot: > dmesg | grep -i tpm [0.00] Command line: initrd=\initrd-test console=ttyS0,115200n8 break=premount [0.00] efi: ACPI 2.0=0x9e07e000 ACPI=0x9e07e000 SMBIOS=0x9ebeb000 SMBIOS 3.0=0x9ebea000 MEMATTR=0x98fb2298 TPMEventLog=0x972bb018 [0.003559] ACPI: TPM2 0x9E0B7F70 34 (v03 LENOVO TC- S06 1260 AMI ) [0.161958] Kernel command line: initrd=\initrd-test console=ttyS0,115200n8 break=premount [5.245801] ima: No TPM chip found, activating TPM-bypass! Any ideas how to debug this? Thanks Michael
Re: [PATCH] Allow hwrng to initialize crng.
On Sat, 2018-12-15 at 18:11 +0100, Michael Niewöhner wrote:
> On Thu, 2018-12-13 at 12:50 +0800, Louis Collard wrote:
> > On Sun, Nov 18, 2018 at 4:15 AM Michael Niewöhner
> > wrote:
> > >
> > > Hi Louis,
> > >
> > > On Wed, 2018-09-26 at 11:24 +0800, Louis Collard wrote:
> > > > Some systems, for example embedded systems, do not generate
> > > > enough entropy on boot through interrupts, and boot may be blocked for
> > > > several minutes waiting for a call to getrandom to complete.
> > > >
> > > > Currently, random data is read from a hwrng when it is registered,
> > > > and is loaded into primary_crng. This data is treated in the same
> > > > way as data that is device-specific but otherwise unchanging, and
> > > > so primary_crng cannot become initialized with the data from the
> > > > hwrng.
> > > >
> > > > This change causes the data initially read from the hwrng to be
> > > > treated the same as subsequent data that is read from the hwrng if
> > > > it's quality score is non-zero.
> > > >
> > > > The implications of this are:
> > > >
> > > > The data read from hwrng can cause primary_crng to become
> > > > initialized, therefore avoiding problems of getrandom blocking
> > > > on boot.
> > > >
> > > > Calls to getrandom (with GRND_RANDOM) may be using entropy
> > > > exclusively (or in practise, almost exclusively) from the hwrng.
> > > >
> > > > Regarding the latter point; this behavior is the same as if a
> > > > user specified a quality score of 1 (bit of entropy per 1024 bits)
> > > > so hopefully this is not too scary a change to make.
> > > >
> > > > This change is the result of the discussion here:
> > > > https://patchwork.kernel.org/patch/10453893/
> > > >
> > > > Signed-off-by: Louis Collard
> > > > Acked-by: Jarkko Sakkinen
> > > > ---
> > > > drivers/char/hw_random/core.c | 9 +++--
> > > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/char/hw_random/core.c
> > > > b/drivers/char/hw_random/core.c
> > > > index aaf9e5afaad4..47f358aa0c3d 100644
> > > > --- a/drivers/char/hw_random/core.c
> > > > +++ b/drivers/char/hw_random/core.c
> > > > @@ -24,6 +24,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #define RNG_MODULE_NAME "hw_random"
> > > >
> > > > @@ -64,13 +65,17 @@ static size_t rng_buffer_size(void)
> > > > static void add_early_randomness(struct hwrng *rng)
> > > > {
> > > > int bytes_read;
> > > > - size_t size = min_t(size_t, 16, rng_buffer_size());
> > > > + /* Read enough to initialize crng. */
> > > > + size_t size = 2*CHACHA20_KEY_SIZE;
> > > >
> > > > mutex_lock(_mutex);
> > > > bytes_read = rng_get_data(rng, rng_buffer, size, 1);
> > > > mutex_unlock(_mutex);
> > > > if (bytes_read > 0)
> > > > - add_device_randomness(rng_buffer, bytes_read);
> > > > + /* Allow crng to become initialized, but do not add
> > > > + * entropy to the pool.
> > > > + */
> > > > + add_hwgenerator_randomness(rng_buffer, bytes_read, 0);
> > > > }
> > > >
> > > > static inline void cleanup_rng(struct kref *kref)
> > >
> > > I found your patch by chance, searching for a solution for crng init delay
> > > on my
> > > headless machine. Unfortunately it hardly makes any difference for me.
> > > With
> > > the
> > > patch the system hangs for about 80s instead of 120s until the "crng init
> > > done"
> > > message.In contrast, doing a `cat /dev/hwrng >/dev/random` or running rngd
> > > initializes the crng instantly.
> > >
> > > Isn't that delay the problem this patch tries to fix? Any idea what is
> > > wrong
> > > here?
> > >
> > > Thanks!
> > >
> > > Best regards
> > > Michael
> > >
> > >
> >
> > Yes that is the problem this is trying to address. My guess would be
>
Re: [PATCH] Allow hwrng to initialize crng.
On Thu, 2018-12-13 at 12:50 +0800, Louis Collard wrote:
> On Sun, Nov 18, 2018 at 4:15 AM Michael Niewöhner
> wrote:
> >
> > Hi Louis,
> >
> > On Wed, 2018-09-26 at 11:24 +0800, Louis Collard wrote:
> > > Some systems, for example embedded systems, do not generate
> > > enough entropy on boot through interrupts, and boot may be blocked for
> > > several minutes waiting for a call to getrandom to complete.
> > >
> > > Currently, random data is read from a hwrng when it is registered,
> > > and is loaded into primary_crng. This data is treated in the same
> > > way as data that is device-specific but otherwise unchanging, and
> > > so primary_crng cannot become initialized with the data from the
> > > hwrng.
> > >
> > > This change causes the data initially read from the hwrng to be
> > > treated the same as subsequent data that is read from the hwrng if
> > > it's quality score is non-zero.
> > >
> > > The implications of this are:
> > >
> > > The data read from hwrng can cause primary_crng to become
> > > initialized, therefore avoiding problems of getrandom blocking
> > > on boot.
> > >
> > > Calls to getrandom (with GRND_RANDOM) may be using entropy
> > > exclusively (or in practise, almost exclusively) from the hwrng.
> > >
> > > Regarding the latter point; this behavior is the same as if a
> > > user specified a quality score of 1 (bit of entropy per 1024 bits)
> > > so hopefully this is not too scary a change to make.
> > >
> > > This change is the result of the discussion here:
> > > https://patchwork.kernel.org/patch/10453893/
> > >
> > > Signed-off-by: Louis Collard
> > > Acked-by: Jarkko Sakkinen
> > > ---
> > > drivers/char/hw_random/core.c | 9 +++--
> > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> > > index aaf9e5afaad4..47f358aa0c3d 100644
> > > --- a/drivers/char/hw_random/core.c
> > > +++ b/drivers/char/hw_random/core.c
> > > @@ -24,6 +24,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #define RNG_MODULE_NAME "hw_random"
> > >
> > > @@ -64,13 +65,17 @@ static size_t rng_buffer_size(void)
> > > static void add_early_randomness(struct hwrng *rng)
> > > {
> > > int bytes_read;
> > > - size_t size = min_t(size_t, 16, rng_buffer_size());
> > > + /* Read enough to initialize crng. */
> > > + size_t size = 2*CHACHA20_KEY_SIZE;
> > >
> > > mutex_lock(_mutex);
> > > bytes_read = rng_get_data(rng, rng_buffer, size, 1);
> > > mutex_unlock(_mutex);
> > > if (bytes_read > 0)
> > > - add_device_randomness(rng_buffer, bytes_read);
> > > + /* Allow crng to become initialized, but do not add
> > > + * entropy to the pool.
> > > + */
> > > + add_hwgenerator_randomness(rng_buffer, bytes_read, 0);
> > > }
> > >
> > > static inline void cleanup_rng(struct kref *kref)
> >
> > I found your patch by chance, searching for a solution for crng init delay
> > on my
> > headless machine. Unfortunately it hardly makes any difference for me. With
> > the
> > patch the system hangs for about 80s instead of 120s until the "crng init
> > done"
> > message.In contrast, doing a `cat /dev/hwrng >/dev/random` or running rngd
> > initializes the crng instantly.
> >
> > Isn't that delay the problem this patch tries to fix? Any idea what is wrong
> > here?
> >
> > Thanks!
> >
> > Best regards
> > Michael
> >
> >
>
> Yes that is the problem this is trying to address. My guess would be
> rng_get_data() is not returning as much data as requested, so the
> delay is reduced but not eliminated. Looking at implementation of
> rng_get_data() it appears this could be caused by device support for
> read() vs data_read(). I don't have a good feel for whether looping to
> retrieve more data here would be acceptable, it is certainly a bigger
> change than currently proposed.
>
> Thanks,
> Louis
Hi Louis,
that is what I thought first, too, but I was able to verify that 64 bytes are
read as expected.
It seems this is exactly what David noticed in your discussion
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi again, after some experiments I finally found a solution... There seems to be a bug in TPM2.0 firmware version (1.3.1.0) included in Lenovos UEFI image but they do not provide an update. I have extracted the firmware version 1.3.2.8 from Dell's XPS15 TPM2.0 firmware update and used this to replace the firmware in my Lenovo UEFI image. After flashing this version via UEFI Setup the TPM2.0 gets detected and now is fully working. WTF. For anyone having the same problem: binwalk, uefi-firmware-parser, uefipatch and flashrom are your friends ;-) Best regards Michael
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi again, after some experiments I finally found a solution... There seems to be a bug in TPM2.0 firmware version (1.3.1.0) included in Lenovos UEFI image but they do not provide an update. I have extracted the firmware version 1.3.2.8 from Dell's XPS15 TPM2.0 firmware update and used this to replace the firmware in my Lenovo UEFI image. After flashing this version via UEFI Setup the TPM2.0 gets detected and now is fully working. WTF. For anyone having the same problem: binwalk, uefi-firmware-parser, uefipatch and flashrom are your friends ;-) Best regards Michael
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi, On Mon, 2018-11-19 at 15:49 +0200, Jarkko Sakkinen wrote: > On Sun, Nov 18, 2018 at 03:10:06PM +0100, Michael Niewöhner wrote: > > On Sun, 2018-11-18 at 10:18 +0200, Jarkko Sakkinen wrote: > > > On Fri, Nov 16, 2018 at 10:06:28PM +0100, Michael Niewöhner wrote: > > > > On Wed, 2018-11-14 at 21:46 +0100, Michael Niewöhner wrote: > > > > > Hi all, > > > > > > > > > > I tried that patch mentioned by Mimi but it does not change anything > > > > > for > > > > > me. > > > > > > > > > > Then I did some more tests with different kernel configs and finally > > > > > got > > > > > TPM > > > > > working by > > > > > a) compiling TPM as modules and rmmod tpm* and re-modprobe tpm_tis. > > > > > > > > > > (initramfs) dmesg | grep -i tpm > > > > > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 > > > > > SMBIOS=0x9f5eb000 > > > > > SMBIOS 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 > > > > > TPMEventLog=0x97cbb018 > > > > > [0.003793] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC- > > > > > S06 1260 AMI ) > > > > > (initramfs) rmmod tpm_crb tpm_tis tpm_tis_core tpm > > > > > (initramfs) modprobe tpm_tis > > > > > [ 44.956905] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > > > > > > > > b) compiling TPM-support in-kernel and manually bind the ACPI device > > > > > > > > > > (initramfs) dmesg | grep -i tpm > > > > > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 > > > > > SMBIOS=0x9f5eb000 > > > > > SMBIOS > > > > > 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 > > > > > TPMEventLog=0x97cbb018 > > > > > [0.003546] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC-S06 > > > > > 1260 > > > > > AMI ) > > > > > (initramfs) echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind > > > > > [ 233.076079] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > > > > > > > > > > > > > It seems to me, the kernel tries to enable the TPM to early... > > > > > > > > > > > > > > > Michael > > > > > > > > Looks like the manual driver bind works more or less but e.g reading > > > > hwrng > > > > does > > > > not work... > > > > > > > > # echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind > > > > [ 148.293302] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > > # cat /sys/devices/virtual/misc/hw_random/rng_current > > > > tpm-rng-0 > > > > # cat /dev/hwrng >/dev/null > > > > cat: /dev/hwrng: Operation not permitted > > > > > > Can you check with trace-cmd start -p function -l 'tpm*'? > > > > > > /Jarkko > > > > > > Hi Jarko, > > > > what output do you need exactly? > > TPM gets added with tpm_add_hwrng() and the callback that is called by > hwrng subsystem is tpm_hwrng_read(). > > Obviously the former gets called (can be seen from the sysfs file). Just > wondering if it ever reaches tpm_hwrng_read(). > > /Jarkko I wanted to be sure that there is no hardware failure so I tested the TPM in UEFI Shell using the tpm tools from github.com/fpmurphy/UEFI-Utilities-2016 I can confirm that it is working there in both modes 1.2 and 2.0. FS0:\> ShowTPM2.efi Signature : TPM2 Length : 52 Revision : 3 Checksum : 167 Oem ID : LENOVO Oem Table ID : TC-S06 Oem Revision : 4704 Creator ID : AMI Creator Revision : 0 Platform Class : 0 Control Area Address : 0 Start Method : 6 (Memory mapped I/O) Platform S.P. Size : 0 FS0:\> ShowTCM20.efi Structure Version: 1.1 Protocol Version: 1.1 Supported Hash Algorithms: SHA1 SHA256 Supported Event Log Formats: TCG_1.2 TCG_2 TPM Present Flag: True Maximum Command Size: 2048 Maximum Response Size: 2048 Manufactuer ID: NTC Number of PCR Banks: 2 FS0:\> ShowPCR20.efi Bank (Algorithm): TPM_ALG_SHA1 (0x0004) [00] 1E BB 2B E3 B7 10 3A 09 B5 CA EE B5 82 7C 12 42 CD 66 32 EC [01] 80 4E 8E 47 19 9D C7 31 4E B4 3C 4D C9 58 EF 6F 0B 6B 49 62 [02] B2 A8 3B 0E BF 2F 83 74 29 9A 5B 2B DF C3 1E A9 55 AD 72 36 [03] B2 A8 3B 0E BF 2F 83 74 29 9A 5B 2B DF C3 1E A9 55 AD 72 36 .. Michael
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi, On Mon, 2018-11-19 at 15:49 +0200, Jarkko Sakkinen wrote: > On Sun, Nov 18, 2018 at 03:10:06PM +0100, Michael Niewöhner wrote: > > On Sun, 2018-11-18 at 10:18 +0200, Jarkko Sakkinen wrote: > > > On Fri, Nov 16, 2018 at 10:06:28PM +0100, Michael Niewöhner wrote: > > > > On Wed, 2018-11-14 at 21:46 +0100, Michael Niewöhner wrote: > > > > > Hi all, > > > > > > > > > > I tried that patch mentioned by Mimi but it does not change anything > > > > > for > > > > > me. > > > > > > > > > > Then I did some more tests with different kernel configs and finally > > > > > got > > > > > TPM > > > > > working by > > > > > a) compiling TPM as modules and rmmod tpm* and re-modprobe tpm_tis. > > > > > > > > > > (initramfs) dmesg | grep -i tpm > > > > > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 > > > > > SMBIOS=0x9f5eb000 > > > > > SMBIOS 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 > > > > > TPMEventLog=0x97cbb018 > > > > > [0.003793] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC- > > > > > S06 1260 AMI ) > > > > > (initramfs) rmmod tpm_crb tpm_tis tpm_tis_core tpm > > > > > (initramfs) modprobe tpm_tis > > > > > [ 44.956905] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > > > > > > > > b) compiling TPM-support in-kernel and manually bind the ACPI device > > > > > > > > > > (initramfs) dmesg | grep -i tpm > > > > > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 > > > > > SMBIOS=0x9f5eb000 > > > > > SMBIOS > > > > > 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 > > > > > TPMEventLog=0x97cbb018 > > > > > [0.003546] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC-S06 > > > > > 1260 > > > > > AMI ) > > > > > (initramfs) echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind > > > > > [ 233.076079] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > > > > > > > > > > > > > It seems to me, the kernel tries to enable the TPM to early... > > > > > > > > > > > > > > > Michael > > > > > > > > Looks like the manual driver bind works more or less but e.g reading > > > > hwrng > > > > does > > > > not work... > > > > > > > > # echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind > > > > [ 148.293302] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > > # cat /sys/devices/virtual/misc/hw_random/rng_current > > > > tpm-rng-0 > > > > # cat /dev/hwrng >/dev/null > > > > cat: /dev/hwrng: Operation not permitted > > > > > > Can you check with trace-cmd start -p function -l 'tpm*'? > > > > > > /Jarkko > > > > > > Hi Jarko, > > > > what output do you need exactly? > > TPM gets added with tpm_add_hwrng() and the callback that is called by > hwrng subsystem is tpm_hwrng_read(). > > Obviously the former gets called (can be seen from the sysfs file). Just > wondering if it ever reaches tpm_hwrng_read(). > > /Jarkko I wanted to be sure that there is no hardware failure so I tested the TPM in UEFI Shell using the tpm tools from github.com/fpmurphy/UEFI-Utilities-2016 I can confirm that it is working there in both modes 1.2 and 2.0. FS0:\> ShowTPM2.efi Signature : TPM2 Length : 52 Revision : 3 Checksum : 167 Oem ID : LENOVO Oem Table ID : TC-S06 Oem Revision : 4704 Creator ID : AMI Creator Revision : 0 Platform Class : 0 Control Area Address : 0 Start Method : 6 (Memory mapped I/O) Platform S.P. Size : 0 FS0:\> ShowTCM20.efi Structure Version: 1.1 Protocol Version: 1.1 Supported Hash Algorithms: SHA1 SHA256 Supported Event Log Formats: TCG_1.2 TCG_2 TPM Present Flag: True Maximum Command Size: 2048 Maximum Response Size: 2048 Manufactuer ID: NTC Number of PCR Banks: 2 FS0:\> ShowPCR20.efi Bank (Algorithm): TPM_ALG_SHA1 (0x0004) [00] 1E BB 2B E3 B7 10 3A 09 B5 CA EE B5 82 7C 12 42 CD 66 32 EC [01] 80 4E 8E 47 19 9D C7 31 4E B4 3C 4D C9 58 EF 6F 0B 6B 49 62 [02] B2 A8 3B 0E BF 2F 83 74 29 9A 5B 2B DF C3 1E A9 55 AD 72 36 [03] B2 A8 3B 0E BF 2F 83 74 29 9A 5B 2B DF C3 1E A9 55 AD 72 36 .. Michael
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
On Sun, 2018-11-18 at 10:18 +0200, Jarkko Sakkinen wrote: > On Fri, Nov 16, 2018 at 10:06:28PM +0100, Michael Niewöhner wrote: > > On Wed, 2018-11-14 at 21:46 +0100, Michael Niewöhner wrote: > > > Hi all, > > > > > > I tried that patch mentioned by Mimi but it does not change anything for > > > me. > > > > > > Then I did some more tests with different kernel configs and finally got > > > TPM > > > working by > > > a) compiling TPM as modules and rmmod tpm* and re-modprobe tpm_tis. > > > > > > (initramfs) dmesg | grep -i tpm > > > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 > > > SMBIOS 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 > > > TPMEventLog=0x97cbb018 > > > [0.003793] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC- > > > S06 1260 AMI ) > > > (initramfs) rmmod tpm_crb tpm_tis tpm_tis_core tpm > > > (initramfs) modprobe tpm_tis > > > [ 44.956905] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > > > > b) compiling TPM-support in-kernel and manually bind the ACPI device > > > > > > (initramfs) dmesg | grep -i tpm > > > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 > > > SMBIOS > > > 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 TPMEventLog=0x97cbb018 > > > [0.003546] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC-S06 > > > 1260 > > > AMI ) > > > (initramfs) echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind > > > [ 233.076079] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > > > > > > > It seems to me, the kernel tries to enable the TPM to early... > > > > > > > > > Michael > > > > Looks like the manual driver bind works more or less but e.g reading hwrng > > does > > not work... > > > > # echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind > > [ 148.293302] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > # cat /sys/devices/virtual/misc/hw_random/rng_current > > tpm-rng-0 > > # cat /dev/hwrng >/dev/null > > cat: /dev/hwrng: Operation not permitted > > Can you check with trace-cmd start -p function -l 'tpm*'? > > /Jarkko Hi Jarko, what output do you need exactly? root@debian:~# trace-cmd record -p function -l 'tpm*' plugin 'function' Hit Ctrl^C to stop recording ^CCPU0 data recorded at offset=0x464000 0 bytes in size CPU1 data recorded at offset=0x464000 0 bytes in size CPU2 data recorded at offset=0x464000 0 bytes in size CPU3 data recorded at offset=0x464000 4096 bytes in size CPU4 data recorded at offset=0x465000 4096 bytes in size CPU5 data recorded at offset=0x466000 0 bytes in size CPU6 data recorded at offset=0x466000 0 bytes in size CPU7 data recorded at offset=0x466000 0 bytes in size root@debian:~# trace-cmd report CPU 0 is empty CPU 1 is empty CPU 2 is empty CPU 5 is empty CPU 6 is empty CPU 7 is empty cpus=8 cat-3324 [003] 265.547715: function: tpm_hwrng_read cat-3324 [003] 265.547721: function: tpm_get_random cat-3324 [003] 265.547721: function:tpm_find_get_ops cat-3324 [003] 265.547721: function: tpm_try_get_ops cat-3324 [003] 265.547721: function:tpm2_get_random cat-3324 [003] 265.547722: function: tpm_transmit_cmd cat-3324 [003] 265.547722: function: tpm_transmit cat-3324 [003] 265.547722: function: tpm_tis_clkrun_enable cat-3324 [003] 265.547723: function: tpm_tcg_read_bytes < snip ... many times the same lines: cat-3324 ... function: tpm_tcg_read_bytes > cat-3324 [004] 266.291087: function: tpm_tcg_read_bytes cat-3324 [004] 266.296347: function: tpm_tis_clkrun_enable cat-3324 [004] 266.296349: function: tpm_put_ops Michael
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
On Sun, 2018-11-18 at 10:18 +0200, Jarkko Sakkinen wrote: > On Fri, Nov 16, 2018 at 10:06:28PM +0100, Michael Niewöhner wrote: > > On Wed, 2018-11-14 at 21:46 +0100, Michael Niewöhner wrote: > > > Hi all, > > > > > > I tried that patch mentioned by Mimi but it does not change anything for > > > me. > > > > > > Then I did some more tests with different kernel configs and finally got > > > TPM > > > working by > > > a) compiling TPM as modules and rmmod tpm* and re-modprobe tpm_tis. > > > > > > (initramfs) dmesg | grep -i tpm > > > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 > > > SMBIOS 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 > > > TPMEventLog=0x97cbb018 > > > [0.003793] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC- > > > S06 1260 AMI ) > > > (initramfs) rmmod tpm_crb tpm_tis tpm_tis_core tpm > > > (initramfs) modprobe tpm_tis > > > [ 44.956905] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > > > > b) compiling TPM-support in-kernel and manually bind the ACPI device > > > > > > (initramfs) dmesg | grep -i tpm > > > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 > > > SMBIOS > > > 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 TPMEventLog=0x97cbb018 > > > [0.003546] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC-S06 > > > 1260 > > > AMI ) > > > (initramfs) echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind > > > [ 233.076079] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > > > > > > > It seems to me, the kernel tries to enable the TPM to early... > > > > > > > > > Michael > > > > Looks like the manual driver bind works more or less but e.g reading hwrng > > does > > not work... > > > > # echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind > > [ 148.293302] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > # cat /sys/devices/virtual/misc/hw_random/rng_current > > tpm-rng-0 > > # cat /dev/hwrng >/dev/null > > cat: /dev/hwrng: Operation not permitted > > Can you check with trace-cmd start -p function -l 'tpm*'? > > /Jarkko Hi Jarko, what output do you need exactly? root@debian:~# trace-cmd record -p function -l 'tpm*' plugin 'function' Hit Ctrl^C to stop recording ^CCPU0 data recorded at offset=0x464000 0 bytes in size CPU1 data recorded at offset=0x464000 0 bytes in size CPU2 data recorded at offset=0x464000 0 bytes in size CPU3 data recorded at offset=0x464000 4096 bytes in size CPU4 data recorded at offset=0x465000 4096 bytes in size CPU5 data recorded at offset=0x466000 0 bytes in size CPU6 data recorded at offset=0x466000 0 bytes in size CPU7 data recorded at offset=0x466000 0 bytes in size root@debian:~# trace-cmd report CPU 0 is empty CPU 1 is empty CPU 2 is empty CPU 5 is empty CPU 6 is empty CPU 7 is empty cpus=8 cat-3324 [003] 265.547715: function: tpm_hwrng_read cat-3324 [003] 265.547721: function: tpm_get_random cat-3324 [003] 265.547721: function:tpm_find_get_ops cat-3324 [003] 265.547721: function: tpm_try_get_ops cat-3324 [003] 265.547721: function:tpm2_get_random cat-3324 [003] 265.547722: function: tpm_transmit_cmd cat-3324 [003] 265.547722: function: tpm_transmit cat-3324 [003] 265.547722: function: tpm_tis_clkrun_enable cat-3324 [003] 265.547723: function: tpm_tcg_read_bytes < snip ... many times the same lines: cat-3324 ... function: tpm_tcg_read_bytes > cat-3324 [004] 266.291087: function: tpm_tcg_read_bytes cat-3324 [004] 266.296347: function: tpm_tis_clkrun_enable cat-3324 [004] 266.296349: function: tpm_put_ops Michael
Re: [PATCH] Allow hwrng to initialize crng.
Hi Louis,
On Wed, 2018-09-26 at 11:24 +0800, Louis Collard wrote:
> Some systems, for example embedded systems, do not generate
> enough entropy on boot through interrupts, and boot may be blocked for
> several minutes waiting for a call to getrandom to complete.
>
> Currently, random data is read from a hwrng when it is registered,
> and is loaded into primary_crng. This data is treated in the same
> way as data that is device-specific but otherwise unchanging, and
> so primary_crng cannot become initialized with the data from the
> hwrng.
>
> This change causes the data initially read from the hwrng to be
> treated the same as subsequent data that is read from the hwrng if
> it's quality score is non-zero.
>
> The implications of this are:
>
> The data read from hwrng can cause primary_crng to become
> initialized, therefore avoiding problems of getrandom blocking
> on boot.
>
> Calls to getrandom (with GRND_RANDOM) may be using entropy
> exclusively (or in practise, almost exclusively) from the hwrng.
>
> Regarding the latter point; this behavior is the same as if a
> user specified a quality score of 1 (bit of entropy per 1024 bits)
> so hopefully this is not too scary a change to make.
>
> This change is the result of the discussion here:
> https://patchwork.kernel.org/patch/10453893/
>
> Signed-off-by: Louis Collard
> Acked-by: Jarkko Sakkinen
> ---
> drivers/char/hw_random/core.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index aaf9e5afaad4..47f358aa0c3d 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #define RNG_MODULE_NAME "hw_random"
>
> @@ -64,13 +65,17 @@ static size_t rng_buffer_size(void)
> static void add_early_randomness(struct hwrng *rng)
> {
> int bytes_read;
> - size_t size = min_t(size_t, 16, rng_buffer_size());
> + /* Read enough to initialize crng. */
> + size_t size = 2*CHACHA20_KEY_SIZE;
>
> mutex_lock(_mutex);
> bytes_read = rng_get_data(rng, rng_buffer, size, 1);
> mutex_unlock(_mutex);
> if (bytes_read > 0)
> - add_device_randomness(rng_buffer, bytes_read);
> + /* Allow crng to become initialized, but do not add
> + * entropy to the pool.
> + */
> + add_hwgenerator_randomness(rng_buffer, bytes_read, 0);
> }
>
> static inline void cleanup_rng(struct kref *kref)
I found your patch by chance, searching for a solution for crng init delay on my
headless machine. Unfortunately it hardly makes any difference for me. With the
patch the system hangs for about 80s instead of 120s until the "crng init done"
message.In contrast, doing a `cat /dev/hwrng >/dev/random` or running rngd
initializes the crng instantly.
Isn't that delay the problem this patch tries to fix? Any idea what is wrong
here?
Thanks!
Best regards
Michael
Re: [PATCH] Allow hwrng to initialize crng.
Hi Louis,
On Wed, 2018-09-26 at 11:24 +0800, Louis Collard wrote:
> Some systems, for example embedded systems, do not generate
> enough entropy on boot through interrupts, and boot may be blocked for
> several minutes waiting for a call to getrandom to complete.
>
> Currently, random data is read from a hwrng when it is registered,
> and is loaded into primary_crng. This data is treated in the same
> way as data that is device-specific but otherwise unchanging, and
> so primary_crng cannot become initialized with the data from the
> hwrng.
>
> This change causes the data initially read from the hwrng to be
> treated the same as subsequent data that is read from the hwrng if
> it's quality score is non-zero.
>
> The implications of this are:
>
> The data read from hwrng can cause primary_crng to become
> initialized, therefore avoiding problems of getrandom blocking
> on boot.
>
> Calls to getrandom (with GRND_RANDOM) may be using entropy
> exclusively (or in practise, almost exclusively) from the hwrng.
>
> Regarding the latter point; this behavior is the same as if a
> user specified a quality score of 1 (bit of entropy per 1024 bits)
> so hopefully this is not too scary a change to make.
>
> This change is the result of the discussion here:
> https://patchwork.kernel.org/patch/10453893/
>
> Signed-off-by: Louis Collard
> Acked-by: Jarkko Sakkinen
> ---
> drivers/char/hw_random/core.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index aaf9e5afaad4..47f358aa0c3d 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #define RNG_MODULE_NAME "hw_random"
>
> @@ -64,13 +65,17 @@ static size_t rng_buffer_size(void)
> static void add_early_randomness(struct hwrng *rng)
> {
> int bytes_read;
> - size_t size = min_t(size_t, 16, rng_buffer_size());
> + /* Read enough to initialize crng. */
> + size_t size = 2*CHACHA20_KEY_SIZE;
>
> mutex_lock(_mutex);
> bytes_read = rng_get_data(rng, rng_buffer, size, 1);
> mutex_unlock(_mutex);
> if (bytes_read > 0)
> - add_device_randomness(rng_buffer, bytes_read);
> + /* Allow crng to become initialized, but do not add
> + * entropy to the pool.
> + */
> + add_hwgenerator_randomness(rng_buffer, bytes_read, 0);
> }
>
> static inline void cleanup_rng(struct kref *kref)
I found your patch by chance, searching for a solution for crng init delay on my
headless machine. Unfortunately it hardly makes any difference for me. With the
patch the system hangs for about 80s instead of 120s until the "crng init done"
message.In contrast, doing a `cat /dev/hwrng >/dev/random` or running rngd
initializes the crng instantly.
Isn't that delay the problem this patch tries to fix? Any idea what is wrong
here?
Thanks!
Best regards
Michael
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
On Wed, 2018-11-14 at 21:46 +0100, Michael Niewöhner wrote: > Hi all, > > I tried that patch mentioned by Mimi but it does not change anything for me. > > Then I did some more tests with different kernel configs and finally got TPM > working by > a) compiling TPM as modules and rmmod tpm* and re-modprobe tpm_tis. > > (initramfs) dmesg | grep -i tpm > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 > SMBIOS 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 > TPMEventLog=0x97cbb018 > [0.003793] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC- > S06 1260 AMI ) > (initramfs) rmmod tpm_crb tpm_tis tpm_tis_core tpm > (initramfs) modprobe tpm_tis > [ 44.956905] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > b) compiling TPM-support in-kernel and manually bind the ACPI device > > (initramfs) dmesg | grep -i tpm > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 > SMBIOS > 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 TPMEventLog=0x97cbb018 > [0.003546] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC-S06 > 1260 > AMI ) > (initramfs) echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind > [ 233.076079] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > It seems to me, the kernel tries to enable the TPM to early... > > > Michael Looks like the manual driver bind works more or less but e.g reading hwrng does not work... # echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind [ 148.293302] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) # cat /sys/devices/virtual/misc/hw_random/rng_current tpm-rng-0 # cat /dev/hwrng >/dev/null cat: /dev/hwrng: Operation not permitted
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
On Wed, 2018-11-14 at 21:46 +0100, Michael Niewöhner wrote: > Hi all, > > I tried that patch mentioned by Mimi but it does not change anything for me. > > Then I did some more tests with different kernel configs and finally got TPM > working by > a) compiling TPM as modules and rmmod tpm* and re-modprobe tpm_tis. > > (initramfs) dmesg | grep -i tpm > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 > SMBIOS 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 > TPMEventLog=0x97cbb018 > [0.003793] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC- > S06 1260 AMI ) > (initramfs) rmmod tpm_crb tpm_tis tpm_tis_core tpm > (initramfs) modprobe tpm_tis > [ 44.956905] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > b) compiling TPM-support in-kernel and manually bind the ACPI device > > (initramfs) dmesg | grep -i tpm > [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 > SMBIOS > 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 TPMEventLog=0x97cbb018 > [0.003546] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC-S06 > 1260 > AMI ) > (initramfs) echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind > [ 233.076079] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > > It seems to me, the kernel tries to enable the TPM to early... > > > Michael Looks like the manual driver bind works more or less but e.g reading hwrng does not work... # echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind [ 148.293302] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) # cat /sys/devices/virtual/misc/hw_random/rng_current tpm-rng-0 # cat /dev/hwrng >/dev/null cat: /dev/hwrng: Operation not permitted
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi all, I tried that patch mentioned by Mimi but it does not change anything for me. Then I did some more tests with different kernel configs and finally got TPM working by a) compiling TPM as modules and rmmod tpm* and re-modprobe tpm_tis. (initramfs) dmesg | grep -i tpm [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 SMBIOS 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 TPMEventLog=0x97cbb018 [0.003793] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC- S06 1260 AMI ) (initramfs) rmmod tpm_crb tpm_tis tpm_tis_core tpm (initramfs) modprobe tpm_tis [ 44.956905] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) b) compiling TPM-support in-kernel and manually bind the ACPI device (initramfs) dmesg | grep -i tpm [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 SMBIOS 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 TPMEventLog=0x97cbb018 [0.003546] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC-S06 1260 AMI ) (initramfs) echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind [ 233.076079] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) It seems to me, the kernel tries to enable the TPM to early... Michael
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi all, I tried that patch mentioned by Mimi but it does not change anything for me. Then I did some more tests with different kernel configs and finally got TPM working by a) compiling TPM as modules and rmmod tpm* and re-modprobe tpm_tis. (initramfs) dmesg | grep -i tpm [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 SMBIOS 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 TPMEventLog=0x97cbb018 [0.003793] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC- S06 1260 AMI ) (initramfs) rmmod tpm_crb tpm_tis tpm_tis_core tpm (initramfs) modprobe tpm_tis [ 44.956905] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) b) compiling TPM-support in-kernel and manually bind the ACPI device (initramfs) dmesg | grep -i tpm [0.00] efi: ACPI 2.0=0x9ea7e000 ACPI=0x9ea7e000 SMBIOS=0x9f5eb000 SMBIOS 3.0=0x9f5ea000 ESRT=0x9c07d918 MEMATTR=0x9bea3018 TPMEventLog=0x97cbb018 [0.003546] ACPI: TPM2 0x9EAB7F70 34 (v03 LENOVO TC-S06 1260 AMI ) (initramfs) echo MSFT0101:00 >/sys/bus/platform/drivers/tpm_tis/bind [ 233.076079] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) It seems to me, the kernel tries to enable the TPM to early... Michael
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
On Sun, 2018-11-11 at 21:34 +0100, Michael Niewöhner wrote: > On Sun, 2018-11-11 at 12:29 -0800, James Bottomley wrote: > > On Sun, 2018-11-11 at 21:09 +0100, Michael Niewöhner wrote: > > > On Sun, 2018-11-11 at 10:57 -0800, James Bottomley wrote: > > > > [...] > > > > Well, I still think the ACPI setup is incorrect. What's in > > > > /sys/class/platform (should be directories of ACPI devices)? The > > > > TPM is supposed to show up as MSFT0101. If it doesn't is there any > > > > other device string in there that might be a TPM? > > > > > > Nope. I'm not sure if it should show up in ACPI... isn't TPM 2.0 I2C? > > > > Your ACPI parser identifies it here: > > > > > [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO TC- > > > S06 1300 AMI ) > > > > So it has to be a device in the platform directory. What is in this > > directory? To find the TPM it probably has something TPM like in the > > firmware_node description: > > > > /sys/devices/platform//firmware_node/description > > > > Mine says > > > > jejb@jarvis:~/git/linux/drivers> cat > > /sys/devices/platform/MSFT0101\:00/firmware_node/description > > TPM 2.0 Device > > > > Ah, yep. There is indeed a MSFT0101: > (initramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/description > TPM 2.0 Device > (initramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/hid > MSFT0101 > (in > itramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/path > \_SB_.TPM_ > (in > itramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/status > 15 > (initramf > s) cat /sys/devices/platform/MSFT0101\:00/firmware_node/uid > 1 > > > James Very strange... When I pull the power cord, then replug and boot, I get these dmesg messages: [0.00] efi: ACPI 2.0=0x9ea78000 ACPI=0x9ea78000 SMBIOS=0x9f5e5000 SMBIOS 3.0=0x9f5e4000 MPS=0xfca00 ESRT=0x9c06e918 MEMATTR=0x99cb9018 TPMEventLog=0x 98d0c018 [0.001794] ACPI: TPM2 0x9EAB1F70 34 (v03 LENOVO TC- S06 1260 AMI ) [3.096587] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) [3.105684] tpm tpm0: A TPM error (2314) occurred attempting the self test After a reboot I get those "ima: ..." message again. Pulling the plug seems to reset anything (the TPM). The PTT TPM 2.0 shows exactly the same behaviour.
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
On Sun, 2018-11-11 at 21:34 +0100, Michael Niewöhner wrote: > On Sun, 2018-11-11 at 12:29 -0800, James Bottomley wrote: > > On Sun, 2018-11-11 at 21:09 +0100, Michael Niewöhner wrote: > > > On Sun, 2018-11-11 at 10:57 -0800, James Bottomley wrote: > > > > [...] > > > > Well, I still think the ACPI setup is incorrect. What's in > > > > /sys/class/platform (should be directories of ACPI devices)? The > > > > TPM is supposed to show up as MSFT0101. If it doesn't is there any > > > > other device string in there that might be a TPM? > > > > > > Nope. I'm not sure if it should show up in ACPI... isn't TPM 2.0 I2C? > > > > Your ACPI parser identifies it here: > > > > > [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO TC- > > > S06 1300 AMI ) > > > > So it has to be a device in the platform directory. What is in this > > directory? To find the TPM it probably has something TPM like in the > > firmware_node description: > > > > /sys/devices/platform//firmware_node/description > > > > Mine says > > > > jejb@jarvis:~/git/linux/drivers> cat > > /sys/devices/platform/MSFT0101\:00/firmware_node/description > > TPM 2.0 Device > > > > Ah, yep. There is indeed a MSFT0101: > (initramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/description > TPM 2.0 Device > (initramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/hid > MSFT0101 > (in > itramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/path > \_SB_.TPM_ > (in > itramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/status > 15 > (initramf > s) cat /sys/devices/platform/MSFT0101\:00/firmware_node/uid > 1 > > > James Very strange... When I pull the power cord, then replug and boot, I get these dmesg messages: [0.00] efi: ACPI 2.0=0x9ea78000 ACPI=0x9ea78000 SMBIOS=0x9f5e5000 SMBIOS 3.0=0x9f5e4000 MPS=0xfca00 ESRT=0x9c06e918 MEMATTR=0x99cb9018 TPMEventLog=0x 98d0c018 [0.001794] ACPI: TPM2 0x9EAB1F70 34 (v03 LENOVO TC- S06 1260 AMI ) [3.096587] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) [3.105684] tpm tpm0: A TPM error (2314) occurred attempting the self test After a reboot I get those "ima: ..." message again. Pulling the plug seems to reset anything (the TPM). The PTT TPM 2.0 shows exactly the same behaviour.
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
On Sun, 2018-11-11 at 12:29 -0800, James Bottomley wrote: > On Sun, 2018-11-11 at 21:09 +0100, Michael Niewöhner wrote: > > On Sun, 2018-11-11 at 10:57 -0800, James Bottomley wrote: > > [...] > > > Well, I still think the ACPI setup is incorrect. What's in > > > /sys/class/platform (should be directories of ACPI devices)? The > > > TPM is supposed to show up as MSFT0101. If it doesn't is there any > > > other device string in there that might be a TPM? > > > > Nope. I'm not sure if it should show up in ACPI... isn't TPM 2.0 I2C? > > Your ACPI parser identifies it here: > > > [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO TC- > > S06 1300 AMI ) > > So it has to be a device in the platform directory. What is in this > directory? To find the TPM it probably has something TPM like in the > firmware_node description: > > /sys/devices/platform//firmware_node/description > > Mine says > > jejb@jarvis:~/git/linux/drivers> cat > /sys/devices/platform/MSFT0101\:00/firmware_node/description > TPM 2.0 Device > Ah, yep. There is indeed a MSFT0101: (initramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/description TPM 2.0 Device (initramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/hid MSFT0101 (in itramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/path \_SB_.TPM_ (in itramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/status 15 (initramf s) cat /sys/devices/platform/MSFT0101\:00/firmware_node/uid 1 > James
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
On Sun, 2018-11-11 at 12:29 -0800, James Bottomley wrote: > On Sun, 2018-11-11 at 21:09 +0100, Michael Niewöhner wrote: > > On Sun, 2018-11-11 at 10:57 -0800, James Bottomley wrote: > > [...] > > > Well, I still think the ACPI setup is incorrect. What's in > > > /sys/class/platform (should be directories of ACPI devices)? The > > > TPM is supposed to show up as MSFT0101. If it doesn't is there any > > > other device string in there that might be a TPM? > > > > Nope. I'm not sure if it should show up in ACPI... isn't TPM 2.0 I2C? > > Your ACPI parser identifies it here: > > > [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO TC- > > S06 1300 AMI ) > > So it has to be a device in the platform directory. What is in this > directory? To find the TPM it probably has something TPM like in the > firmware_node description: > > /sys/devices/platform//firmware_node/description > > Mine says > > jejb@jarvis:~/git/linux/drivers> cat > /sys/devices/platform/MSFT0101\:00/firmware_node/description > TPM 2.0 Device > Ah, yep. There is indeed a MSFT0101: (initramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/description TPM 2.0 Device (initramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/hid MSFT0101 (in itramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/path \_SB_.TPM_ (in itramfs) cat /sys/devices/platform/MSFT0101\:00/firmware_node/status 15 (initramf s) cat /sys/devices/platform/MSFT0101\:00/firmware_node/uid 1 > James
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
On Sun, 2018-11-11 at 10:57 -0800, James Bottomley wrote: > On Sun, 2018-11-11 at 19:50 +0100, Michael Niewöhner wrote: > [...] > > > However, this makes me wonder about yours: > > > > > > > [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO > > > > TC- > > > > S06 1300 AMI ) > > > > > > I thought the Lenovo "upgrade to 2.0" in fact disabled the external > > > TPM in favour of the Intel PTT (software TPM in the management > > > engine). Since you apparently have the tpm_crb driver that should > > > find the PTT TPM, this might be one of the attachment bugs in the > > > CRB driver ... from your ACPI output it looks to be not specifying > > > the Tpm2Tabl. > > > > Well, there are at least two implementations I know of: > > For my Lenovo X260 I can choose between Infineon TPM 1.2 or Intel PTT > > TPM 2.0 This here is my ThinkStation P320 which can choose between > > PTT 1.2, PTT 2.0, > > Nuvoton 1.2 and 2.0. When switchting between 1.2 and 2.0 the Nuvoton > > gets > > reflashed with the appropriate firmware. > > Well, I still think the ACPI setup is incorrect. What's in > /sys/class/platform (should be directories of ACPI devices)? The TPM > is supposed to show up as MSFT0101. If it doesn't is there any other > device string in there that might be a TPM? Nope. I'm not sure if it should show up in ACPI... isn't TPM 2.0 I2C? $ find /sys | grep -i tpm /sys/class/tpmrm /sys/class/tpm /sys/bus/platform/drivers/tpm_tis /sys/bus/platform/drivers/tpm_tis/uevent /sys/bus/platform/drivers/tpm_tis/bind /sys/bus/platform/drivers/tpm_tis/unbind /sys/bus/pnp/drivers/tpm_tis /sys/bus/pnp/drivers/tpm_tis/uevent /sys/bus/pnp/drivers/tpm_tis/bind /sys/bus/pnp/drivers/tpm_tis/unbind /sys/bus/acpi/drivers/tpm_crb /sys/bus/acpi/drivers/tpm_crb/uevent /sys/bus/acpi/drivers/tpm_crb/bind /sys/bus/acpi/drivers/tpm_crb/unbind /sys/bus/i2c/drivers/tpm_i2c_nuvoton /sys/bus/i2c/drivers/tpm_i2c_nuvoton/uevent /sys/bus/i2c/drivers/tpm_i2c_nuvoton/bind /sys/bus/i2c/drivers/tpm_i2c_nuvoton/unbind > > James >
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
On Sun, 2018-11-11 at 10:57 -0800, James Bottomley wrote: > On Sun, 2018-11-11 at 19:50 +0100, Michael Niewöhner wrote: > [...] > > > However, this makes me wonder about yours: > > > > > > > [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO > > > > TC- > > > > S06 1300 AMI ) > > > > > > I thought the Lenovo "upgrade to 2.0" in fact disabled the external > > > TPM in favour of the Intel PTT (software TPM in the management > > > engine). Since you apparently have the tpm_crb driver that should > > > find the PTT TPM, this might be one of the attachment bugs in the > > > CRB driver ... from your ACPI output it looks to be not specifying > > > the Tpm2Tabl. > > > > Well, there are at least two implementations I know of: > > For my Lenovo X260 I can choose between Infineon TPM 1.2 or Intel PTT > > TPM 2.0 This here is my ThinkStation P320 which can choose between > > PTT 1.2, PTT 2.0, > > Nuvoton 1.2 and 2.0. When switchting between 1.2 and 2.0 the Nuvoton > > gets > > reflashed with the appropriate firmware. > > Well, I still think the ACPI setup is incorrect. What's in > /sys/class/platform (should be directories of ACPI devices)? The TPM > is supposed to show up as MSFT0101. If it doesn't is there any other > device string in there that might be a TPM? Nope. I'm not sure if it should show up in ACPI... isn't TPM 2.0 I2C? $ find /sys | grep -i tpm /sys/class/tpmrm /sys/class/tpm /sys/bus/platform/drivers/tpm_tis /sys/bus/platform/drivers/tpm_tis/uevent /sys/bus/platform/drivers/tpm_tis/bind /sys/bus/platform/drivers/tpm_tis/unbind /sys/bus/pnp/drivers/tpm_tis /sys/bus/pnp/drivers/tpm_tis/uevent /sys/bus/pnp/drivers/tpm_tis/bind /sys/bus/pnp/drivers/tpm_tis/unbind /sys/bus/acpi/drivers/tpm_crb /sys/bus/acpi/drivers/tpm_crb/uevent /sys/bus/acpi/drivers/tpm_crb/bind /sys/bus/acpi/drivers/tpm_crb/unbind /sys/bus/i2c/drivers/tpm_i2c_nuvoton /sys/bus/i2c/drivers/tpm_i2c_nuvoton/uevent /sys/bus/i2c/drivers/tpm_i2c_nuvoton/bind /sys/bus/i2c/drivers/tpm_i2c_nuvoton/unbind > > James >
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi Mimi, On Sun, 2018-11-11 at 13:33 -0500, Mimi Zohar wrote: > On Sun, 2018-11-11 at 18:55 +0100, Michael Niewöhner wrote: > > Hi all, > > > > Nuvoton NCPT650 does not work in TPM 2.0 mode with tpm_tis / tpm_i2c_nuvoton > > while it works in TPM 1.2 mode (I can reflash it via UEFI setup). > > Kernel version is 4.19.1 > > > > Kernel config: > > > > $ cat .config | egrep 'TCG|TPM|CRB|_TIS' > > CONFIG_TCG_TPM=y > > CONFIG_HW_RANDOM_TPM=y > > CONFIG_TCG_TIS_CORE=y > > CONFIG_TCG_TIS=y > > CONFIG_TCG_TIS_SPI=y > > # CONFIG_TCG_TIS_I2C_ATMEL is not set > > # CONFIG_TCG_TIS_I2C_INFINEON is not set > > CONFIG_TCG_TIS_I2C_NUVOTON=y > > # CONFIG_TCG_NSC is not set > > # CONFIG_TCG_ATMEL is not set > > # CONFIG_TCG_INFINEON is not set > > CONFIG_TCG_CRB=y > > # CONFIG_TCG_VTPM_PROXY is not set > > # CONFIG_TCG_TIS_ST33ZP24_I2C is not set > > # CONFIG_TCG_TIS_ST33ZP24_SPI is not set > > > > > > TPM 1.2 mode dmesg: > > > > $ dmesg | egrep -i tis\|tpm\|crb > > [3.210040] tpm_tis 00:0a: 1.2 TPM (device-id 0xFE, rev-id 2) > > > > > > TPM 2.0 mode dmesg: > > > > $ dmesg | egrep -i tis\|tpm\|crb > > [0.00] efi: ACPI > > 2.0=0x9e457000 ACPI=0x9e457000 SMBIOS=0x9ec44000 SMBIOS > > 3.0=0x9ec43000 TPMEventLog=0x9711f018 > > [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO TC- > > S06 1300 AMI ) > > [4.071550] ima: No TPM chip found, activating TPM-bypass! > > It's possible that eventually the TPM is initialized, but not in time > for IMA. Could you you check to see if the TPM is responding to > userspace commands after boot? No it isn't even detected. There is no /dev/tpm0 and /sys/class/tpm is empty. > > Mimi >
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi Mimi, On Sun, 2018-11-11 at 13:33 -0500, Mimi Zohar wrote: > On Sun, 2018-11-11 at 18:55 +0100, Michael Niewöhner wrote: > > Hi all, > > > > Nuvoton NCPT650 does not work in TPM 2.0 mode with tpm_tis / tpm_i2c_nuvoton > > while it works in TPM 1.2 mode (I can reflash it via UEFI setup). > > Kernel version is 4.19.1 > > > > Kernel config: > > > > $ cat .config | egrep 'TCG|TPM|CRB|_TIS' > > CONFIG_TCG_TPM=y > > CONFIG_HW_RANDOM_TPM=y > > CONFIG_TCG_TIS_CORE=y > > CONFIG_TCG_TIS=y > > CONFIG_TCG_TIS_SPI=y > > # CONFIG_TCG_TIS_I2C_ATMEL is not set > > # CONFIG_TCG_TIS_I2C_INFINEON is not set > > CONFIG_TCG_TIS_I2C_NUVOTON=y > > # CONFIG_TCG_NSC is not set > > # CONFIG_TCG_ATMEL is not set > > # CONFIG_TCG_INFINEON is not set > > CONFIG_TCG_CRB=y > > # CONFIG_TCG_VTPM_PROXY is not set > > # CONFIG_TCG_TIS_ST33ZP24_I2C is not set > > # CONFIG_TCG_TIS_ST33ZP24_SPI is not set > > > > > > TPM 1.2 mode dmesg: > > > > $ dmesg | egrep -i tis\|tpm\|crb > > [3.210040] tpm_tis 00:0a: 1.2 TPM (device-id 0xFE, rev-id 2) > > > > > > TPM 2.0 mode dmesg: > > > > $ dmesg | egrep -i tis\|tpm\|crb > > [0.00] efi: ACPI > > 2.0=0x9e457000 ACPI=0x9e457000 SMBIOS=0x9ec44000 SMBIOS > > 3.0=0x9ec43000 TPMEventLog=0x9711f018 > > [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO TC- > > S06 1300 AMI ) > > [4.071550] ima: No TPM chip found, activating TPM-bypass! > > It's possible that eventually the TPM is initialized, but not in time > for IMA. Could you you check to see if the TPM is responding to > userspace commands after boot? No it isn't even detected. There is no /dev/tpm0 and /sys/class/tpm is empty. > > Mimi >
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi James, On Sun, 2018-11-11 at 10:24 -0800, James Bottomley wrote: > On Sun, 2018-11-11 at 18:55 +0100, Michael Niewöhner wrote: > > Hi all, > > > > Nuvoton NCPT650 does not work in TPM 2.0 mode with tpm_tis / > > tpm_i2c_nuvoton while it works in TPM 1.2 mode (I can reflash it via > > UEFI setup). Kernel version is 4.19.1 > > Not that this helps you, but mine definitely works. I've got an older > Dell XPS-13 with a Nuvoton 650 which is software switchable between 1.2 > and 2.0. This is what mine says > > jejb@jarvis:~> dmesg|egrep -i tis\|tpm\|crb > [0.00] efi: ACPI=0x79419000 ACPI > 2.0=0x79419000 SMBIOS=0xf TPMEventLog=0x69db3018 > [0.012797] ACPI: TPM2 0x79446CC0 34 (v03Tpm2Tabl > 0001 AMI ) > [2.035242] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > However, this makes me wonder about yours: > > > [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO TC- > > S06 1300 AMI ) > > I thought the Lenovo "upgrade to 2.0" in fact disabled the external TPM > in favour of the Intel PTT (software TPM in the management engine). > Since you apparently have the tpm_crb driver that should find the PTT > TPM, this might be one of the attachment bugs in the CRB driver ... > from your ACPI output it looks to be not specifying the Tpm2Tabl. Well, there are at least two implementations I know of: For my Lenovo X260 I can choose between Infineon TPM 1.2 or Intel PTT TPM 2.0 This here is my ThinkStation P320 which can choose between PTT 1.2, PTT 2.0, Nuvoton 1.2 and 2.0. When switchting between 1.2 and 2.0 the Nuvoton gets reflashed with the appropriate firmware. > > James >
Re: [BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi James, On Sun, 2018-11-11 at 10:24 -0800, James Bottomley wrote: > On Sun, 2018-11-11 at 18:55 +0100, Michael Niewöhner wrote: > > Hi all, > > > > Nuvoton NCPT650 does not work in TPM 2.0 mode with tpm_tis / > > tpm_i2c_nuvoton while it works in TPM 1.2 mode (I can reflash it via > > UEFI setup). Kernel version is 4.19.1 > > Not that this helps you, but mine definitely works. I've got an older > Dell XPS-13 with a Nuvoton 650 which is software switchable between 1.2 > and 2.0. This is what mine says > > jejb@jarvis:~> dmesg|egrep -i tis\|tpm\|crb > [0.00] efi: ACPI=0x79419000 ACPI > 2.0=0x79419000 SMBIOS=0xf TPMEventLog=0x69db3018 > [0.012797] ACPI: TPM2 0x79446CC0 34 (v03Tpm2Tabl > 0001 AMI ) > [2.035242] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2) > > However, this makes me wonder about yours: > > > [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO TC- > > S06 1300 AMI ) > > I thought the Lenovo "upgrade to 2.0" in fact disabled the external TPM > in favour of the Intel PTT (software TPM in the management engine). > Since you apparently have the tpm_crb driver that should find the PTT > TPM, this might be one of the attachment bugs in the CRB driver ... > from your ACPI output it looks to be not specifying the Tpm2Tabl. Well, there are at least two implementations I know of: For my Lenovo X260 I can choose between Infineon TPM 1.2 or Intel PTT TPM 2.0 This here is my ThinkStation P320 which can choose between PTT 1.2, PTT 2.0, Nuvoton 1.2 and 2.0. When switchting between 1.2 and 2.0 the Nuvoton gets reflashed with the appropriate firmware. > > James >
[BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi all, Nuvoton NCPT650 does not work in TPM 2.0 mode with tpm_tis / tpm_i2c_nuvoton while it works in TPM 1.2 mode (I can reflash it via UEFI setup). Kernel version is 4.19.1 Kernel config: $ cat .config | egrep 'TCG|TPM|CRB|_TIS' CONFIG_TCG_TPM=y CONFIG_HW_RANDOM_TPM=y CONFIG_TCG_TIS_CORE=y CONFIG_TCG_TIS=y CONFIG_TCG_TIS_SPI=y # CONFIG_TCG_TIS_I2C_ATMEL is not set # CONFIG_TCG_TIS_I2C_INFINEON is not set CONFIG_TCG_TIS_I2C_NUVOTON=y # CONFIG_TCG_NSC is not set # CONFIG_TCG_ATMEL is not set # CONFIG_TCG_INFINEON is not set CONFIG_TCG_CRB=y # CONFIG_TCG_VTPM_PROXY is not set # CONFIG_TCG_TIS_ST33ZP24_I2C is not set # CONFIG_TCG_TIS_ST33ZP24_SPI is not set TPM 1.2 mode dmesg: $ dmesg | egrep -i tis\|tpm\|crb [3.210040] tpm_tis 00:0a: 1.2 TPM (device-id 0xFE, rev-id 2) TPM 2.0 mode dmesg: $ dmesg | egrep -i tis\|tpm\|crb [0.00] efi: ACPI 2.0=0x9e457000 ACPI=0x9e457000 SMBIOS=0x9ec44000 SMBIOS 3.0=0x9ec43000 TPMEventLog=0x9711f018 [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO TC- S06 1300 AMI ) [4.071550] ima: No TPM chip found, activating TPM-bypass! Any ideas? Best regards Michael
[BUG] Nuvoton NCPT650 TPM 2.0 mode not working
Hi all, Nuvoton NCPT650 does not work in TPM 2.0 mode with tpm_tis / tpm_i2c_nuvoton while it works in TPM 1.2 mode (I can reflash it via UEFI setup). Kernel version is 4.19.1 Kernel config: $ cat .config | egrep 'TCG|TPM|CRB|_TIS' CONFIG_TCG_TPM=y CONFIG_HW_RANDOM_TPM=y CONFIG_TCG_TIS_CORE=y CONFIG_TCG_TIS=y CONFIG_TCG_TIS_SPI=y # CONFIG_TCG_TIS_I2C_ATMEL is not set # CONFIG_TCG_TIS_I2C_INFINEON is not set CONFIG_TCG_TIS_I2C_NUVOTON=y # CONFIG_TCG_NSC is not set # CONFIG_TCG_ATMEL is not set # CONFIG_TCG_INFINEON is not set CONFIG_TCG_CRB=y # CONFIG_TCG_VTPM_PROXY is not set # CONFIG_TCG_TIS_ST33ZP24_I2C is not set # CONFIG_TCG_TIS_ST33ZP24_SPI is not set TPM 1.2 mode dmesg: $ dmesg | egrep -i tis\|tpm\|crb [3.210040] tpm_tis 00:0a: 1.2 TPM (device-id 0xFE, rev-id 2) TPM 2.0 mode dmesg: $ dmesg | egrep -i tis\|tpm\|crb [0.00] efi: ACPI 2.0=0x9e457000 ACPI=0x9e457000 SMBIOS=0x9ec44000 SMBIOS 3.0=0x9ec43000 TPMEventLog=0x9711f018 [0.003517] ACPI: TPM2 0x9E490ED8 34 (v03 LENOVO TC- S06 1300 AMI ) [4.071550] ima: No TPM chip found, activating TPM-bypass! Any ideas? Best regards Michael
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi, On Mon, 2016-10-17 at 15:21 +0530, Vivek Gautam wrote: > > On 10/17/2016 01:38 PM, Felipe Balbi wrote: > > Hi, > > > > Michael Niewöhner <li...@mniewoehner.de> writes: > > > Hi Felipe, > > > On Fri, 2016-10-07 at 22:26 +0200, Michael Niewöhner wrote: > > > > Hi Felipe, > > > > > > > > On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote: > > > > > Hi, > > > > > > > > > > Michael Niewöhner <li...@mniewoehner.de> writes: > > > > > > > The clocks are same across working/non-working. > > > > > > > Is it possible to bisect the commit that's causing hang for 4.8x ? > > > > > > > > > > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: > > > > > > re-factor init and exit paths > > > > > > This patch causes both the hang on reboot and the lsusb hang. > > > > > > > > > > How to reproduce? Why don't we see this on x86 and TI boards? I'm > > > > > guessing this is failed bisection, as I can't see anything in that > > > > > commit that would cause reboot hang. Also, that code path is *NOT* > > > > > executed when you run lsusb. > > > > > > > > > > > > > I've tested this procedure multiple times to be sure: > > > > > > > > - checkout c499ff71, compile, boot the odroid > > > > - run lsusb -v => lsusb hangs, can't terminate with ctrl-c > > > > - hard reset, after boot run poweroff or reboot => board does not > > > > completely power off / reboot (see log below) > > > > - revert c499ff71, mrproper, compile, boot the odroid > > > > - run lsusb -v => shows full output, not hanging > > > > - run reboot or poweroff => board powers off / reboots just fine > > > > > > > > > > > > dmesg poweroff not working: > > > > ... > > > > [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid > > > > 144 > > > > [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining > > > > processes... > > > > [ 120.769212] systemd-shutdown[1]: Unmounting file systems. > > > > [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. > > > > [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. > > > > [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. > > > > [ 121.106523] systemd-shutdown[1]: Deactivating swaps. > > > > [ 121.111585] systemd-shutdown[1]: All swaps deactivated. > > > > [ 121.116661] systemd-shutdown[1]: Detaching loop devices. > > > > [ 121.126395] systemd-shutdown[1]: All loop devices detached. > > > > [ 121.130525] systemd-shutdown[1]: Detaching DM devices. > > > > [ 121.135824] systemd-shutdown[1]: All DM devices detached. > > > > [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown > > > > succeeded. > > > > [ 121.171739] systemd-shutdown[1]: Powering off. > > > > > > > > => at this point removing the sd card would show a message > > > > "removed mmc0" (not sure what the real message was...) so the board is > > > > not completely off. > > > > > > > > > > > > dmesg poweroff working: > > > > ... > > > > [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid > > > > 144 > > > > [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining > > > > processes... > > > > [ 120.769212] systemd-shutdown[1]: Unmounting file systems. > > > > [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. > > > > [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. > > > > [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. > > > > [ 121.106523] systemd-shutdown[1]: Deactivating swaps. > > > > [ 121.111585] systemd-shutdown[1]: All swaps deactivated. > > > > [ 121.116661]
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi, On Mon, 2016-10-17 at 15:21 +0530, Vivek Gautam wrote: > > On 10/17/2016 01:38 PM, Felipe Balbi wrote: > > Hi, > > > > Michael Niewöhner writes: > > > Hi Felipe, > > > On Fri, 2016-10-07 at 22:26 +0200, Michael Niewöhner wrote: > > > > Hi Felipe, > > > > > > > > On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote: > > > > > Hi, > > > > > > > > > > Michael Niewöhner writes: > > > > > > > The clocks are same across working/non-working. > > > > > > > Is it possible to bisect the commit that's causing hang for 4.8x ? > > > > > > > > > > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: > > > > > > re-factor init and exit paths > > > > > > This patch causes both the hang on reboot and the lsusb hang. > > > > > > > > > > How to reproduce? Why don't we see this on x86 and TI boards? I'm > > > > > guessing this is failed bisection, as I can't see anything in that > > > > > commit that would cause reboot hang. Also, that code path is *NOT* > > > > > executed when you run lsusb. > > > > > > > > > > > > > I've tested this procedure multiple times to be sure: > > > > > > > > - checkout c499ff71, compile, boot the odroid > > > > - run lsusb -v => lsusb hangs, can't terminate with ctrl-c > > > > - hard reset, after boot run poweroff or reboot => board does not > > > > completely power off / reboot (see log below) > > > > - revert c499ff71, mrproper, compile, boot the odroid > > > > - run lsusb -v => shows full output, not hanging > > > > - run reboot or poweroff => board powers off / reboots just fine > > > > > > > > > > > > dmesg poweroff not working: > > > > ... > > > > [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid > > > > 144 > > > > [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining > > > > processes... > > > > [ 120.769212] systemd-shutdown[1]: Unmounting file systems. > > > > [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. > > > > [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. > > > > [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. > > > > [ 121.106523] systemd-shutdown[1]: Deactivating swaps. > > > > [ 121.111585] systemd-shutdown[1]: All swaps deactivated. > > > > [ 121.116661] systemd-shutdown[1]: Detaching loop devices. > > > > [ 121.126395] systemd-shutdown[1]: All loop devices detached. > > > > [ 121.130525] systemd-shutdown[1]: Detaching DM devices. > > > > [ 121.135824] systemd-shutdown[1]: All DM devices detached. > > > > [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown > > > > succeeded. > > > > [ 121.171739] systemd-shutdown[1]: Powering off. > > > > > > > > => at this point removing the sd card would show a message > > > > "removed mmc0" (not sure what the real message was...) so the board is > > > > not completely off. > > > > > > > > > > > > dmesg poweroff working: > > > > ... > > > > [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid > > > > 144 > > > > [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining > > > > processes... > > > > [ 120.769212] systemd-shutdown[1]: Unmounting file systems. > > > > [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. > > > > [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. > > > > [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > > > [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. > > > > [ 121.106523] systemd-shutdown[1]: Deactivating swaps. > > > > [ 121.111585] systemd-shutdown[1]: All swaps deactivated. > > > > [ 121.116661] systemd-shutdown[1]: Detaching loop devices. > > &g
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Felipe, On Fri, 2016-10-07 at 22:26 +0200, Michael Niewöhner wrote: > Hi Felipe, > > On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote: > > Hi, > > > > Michael Niewöhner <li...@mniewoehner.de> writes: > > > > > > > > > > > The clocks are same across working/non-working. > > > > Is it possible to bisect the commit that's causing hang for 4.8x ? > > > > > > > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor > > > init and exit paths > > > This patch causes both the hang on reboot and the lsusb hang. > > > > How to reproduce? Why don't we see this on x86 and TI boards? I'm > > guessing this is failed bisection, as I can't see anything in that > > commit that would cause reboot hang. Also, that code path is *NOT* > > executed when you run lsusb. > > > > I've tested this procedure multiple times to be sure: > > - checkout c499ff71, compile, boot the odroid > - run lsusb -v => lsusb hangs, can't terminate with ctrl-c > - hard reset, after boot run poweroff or reboot => board does not completely > power off / reboot (see log below) > - revert c499ff71, mrproper, compile, boot the odroid > - run lsusb -v => shows full output, not hanging > - run reboot or poweroff => board powers off / reboots just fine > > > dmesg poweroff not working: > ... > [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 > > [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... > > [ 120.769212] systemd-shutdown[1]: Unmounting file systems. > > [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. > > [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. > > [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. > > [ 121.106523] systemd-shutdown[1]: Deactivating swaps. > > [ 121.111585] systemd-shutdown[1]: All swaps deactivated. > > [ 121.116661] systemd-shutdown[1]: Detaching loop devices. > > [ 121.126395] systemd-shutdown[1]: All loop devices detached. > > [ 121.130525] systemd-shutdown[1]: Detaching DM devices. > > [ 121.135824] systemd-shutdown[1]: All DM devices detached. > > [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. > > [ 121.171739] systemd-shutdown[1]: Powering off. > > => at this point removing the sd card would show a message > "removed mmc0" (not sure what the real message was...) so the board is not > completely off. > > > dmesg poweroff working: > ... > [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 > > [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... > > [ 120.769212] systemd-shutdown[1]: Unmounting file systems. > > [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. > > [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. > > [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. > > [ 121.106523] systemd-shutdown[1]: Deactivating swaps. > > [ 121.111585] systemd-shutdown[1]: All swaps deactivated. > > [ 121.116661] systemd-shutdown[1]: Detaching loop devices. > > [ 121.126395] systemd-shutdown[1]: All loop devices detached. > > [ 121.130525] systemd-shutdown[1]: Detaching DM devices. > > [ 121.135824] systemd-shutdown[1]: All DM devices detached. > > [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. > > [ 121.171739] systemd-shutdown[1]: Powering off. > [ 121.182331] rebo� > > > > Best regards > Michael Niewöhner I did some more tests with next-20161016. Reverting / commenting out one part of your patch "solves&quo
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Felipe, On Fri, 2016-10-07 at 22:26 +0200, Michael Niewöhner wrote: > Hi Felipe, > > On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote: > > Hi, > > > > Michael Niewöhner writes: > > > > > > > > > > > The clocks are same across working/non-working. > > > > Is it possible to bisect the commit that's causing hang for 4.8x ? > > > > > > > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor > > > init and exit paths > > > This patch causes both the hang on reboot and the lsusb hang. > > > > How to reproduce? Why don't we see this on x86 and TI boards? I'm > > guessing this is failed bisection, as I can't see anything in that > > commit that would cause reboot hang. Also, that code path is *NOT* > > executed when you run lsusb. > > > > I've tested this procedure multiple times to be sure: > > - checkout c499ff71, compile, boot the odroid > - run lsusb -v => lsusb hangs, can't terminate with ctrl-c > - hard reset, after boot run poweroff or reboot => board does not completely > power off / reboot (see log below) > - revert c499ff71, mrproper, compile, boot the odroid > - run lsusb -v => shows full output, not hanging > - run reboot or poweroff => board powers off / reboots just fine > > > dmesg poweroff not working: > ... > [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 > > [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... > > [ 120.769212] systemd-shutdown[1]: Unmounting file systems. > > [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. > > [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. > > [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. > > [ 121.106523] systemd-shutdown[1]: Deactivating swaps. > > [ 121.111585] systemd-shutdown[1]: All swaps deactivated. > > [ 121.116661] systemd-shutdown[1]: Detaching loop devices. > > [ 121.126395] systemd-shutdown[1]: All loop devices detached. > > [ 121.130525] systemd-shutdown[1]: Detaching DM devices. > > [ 121.135824] systemd-shutdown[1]: All DM devices detached. > > [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. > > [ 121.171739] systemd-shutdown[1]: Powering off. > > => at this point removing the sd card would show a message > "removed mmc0" (not sure what the real message was...) so the board is not > completely off. > > > dmesg poweroff working: > ... > [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 > > [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... > > [ 120.769212] systemd-shutdown[1]: Unmounting file systems. > > [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. > > [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. > > [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > > [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. > > [ 121.106523] systemd-shutdown[1]: Deactivating swaps. > > [ 121.111585] systemd-shutdown[1]: All swaps deactivated. > > [ 121.116661] systemd-shutdown[1]: Detaching loop devices. > > [ 121.126395] systemd-shutdown[1]: All loop devices detached. > > [ 121.130525] systemd-shutdown[1]: Detaching DM devices. > > [ 121.135824] systemd-shutdown[1]: All DM devices detached. > > [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. > > [ 121.171739] systemd-shutdown[1]: Powering off. > [ 121.182331] rebo� > > > > Best regards > Michael Niewöhner I did some more tests with next-20161016. Reverting / commenting out one part of your patch "solves" the lsusb hang, the rebo
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Felipe, On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote: > Hi, > > Michael Niewöhner <li...@mniewoehner.de> writes: > > > > > > > > The clocks are same across working/non-working. > > > Is it possible to bisect the commit that's causing hang for 4.8x ? > > > > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init > > and exit paths > > This patch causes both the hang on reboot and the lsusb hang. > > How to reproduce? Why don't we see this on x86 and TI boards? I'm > guessing this is failed bisection, as I can't see anything in that > commit that would cause reboot hang. Also, that code path is *NOT* > executed when you run lsusb. > I've tested this procedure multiple times to be sure: - checkout c499ff71, compile, boot the odroid - run lsusb -v => lsusb hangs, can't terminate with ctrl-c - hard reset, after boot run poweroff or reboot => board does not completely power off / reboot (see log below) - revert c499ff71, mrproper, compile, boot the odroid - run lsusb -v => shows full output, not hanging - run reboot or poweroff => board powers off / reboots just fine dmesg poweroff not working: ... [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 120.769212] systemd-shutdown[1]: Unmounting file systems. [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. [ 121.106523] systemd-shutdown[1]: Deactivating swaps. [ 121.111585] systemd-shutdown[1]: All swaps deactivated. [ 121.116661] systemd-shutdown[1]: Detaching loop devices. [ 121.126395] systemd-shutdown[1]: All loop devices detached. [ 121.130525] systemd-shutdown[1]: Detaching DM devices. [ 121.135824] systemd-shutdown[1]: All DM devices detached. [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. [ 121.171739] systemd-shutdown[1]: Powering off. => at this point removing the sd card would show a message "removed mmc0" (not sure what the real message was...) so the board is not completely off. dmesg poweroff working: ... [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 120.769212] systemd-shutdown[1]: Unmounting file systems. [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. [ 121.106523] systemd-shutdown[1]: Deactivating swaps. [ 121.111585] systemd-shutdown[1]: All swaps deactivated. [ 121.116661] systemd-shutdown[1]: Detaching loop devices. [ 121.126395] systemd-shutdown[1]: All loop devices detached. [ 121.130525] systemd-shutdown[1]: Detaching DM devices. [ 121.135824] systemd-shutdown[1]: All DM devices detached. [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. [ 121.171739] systemd-shutdown[1]: Powering off. [ 121.182331] rebo� Best regards Michael
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Felipe, On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote: > Hi, > > Michael Niewöhner writes: > > > > > > > > The clocks are same across working/non-working. > > > Is it possible to bisect the commit that's causing hang for 4.8x ? > > > > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init > > and exit paths > > This patch causes both the hang on reboot and the lsusb hang. > > How to reproduce? Why don't we see this on x86 and TI boards? I'm > guessing this is failed bisection, as I can't see anything in that > commit that would cause reboot hang. Also, that code path is *NOT* > executed when you run lsusb. > I've tested this procedure multiple times to be sure: - checkout c499ff71, compile, boot the odroid - run lsusb -v => lsusb hangs, can't terminate with ctrl-c - hard reset, after boot run poweroff or reboot => board does not completely power off / reboot (see log below) - revert c499ff71, mrproper, compile, boot the odroid - run lsusb -v => shows full output, not hanging - run reboot or poweroff => board powers off / reboots just fine dmesg poweroff not working: ... [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 120.769212] systemd-shutdown[1]: Unmounting file systems. [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. [ 121.106523] systemd-shutdown[1]: Deactivating swaps. [ 121.111585] systemd-shutdown[1]: All swaps deactivated. [ 121.116661] systemd-shutdown[1]: Detaching loop devices. [ 121.126395] systemd-shutdown[1]: All loop devices detached. [ 121.130525] systemd-shutdown[1]: Detaching DM devices. [ 121.135824] systemd-shutdown[1]: All DM devices detached. [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. [ 121.171739] systemd-shutdown[1]: Powering off. => at this point removing the sd card would show a message "removed mmc0" (not sure what the real message was...) so the board is not completely off. dmesg poweroff working: ... [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 120.769212] systemd-shutdown[1]: Unmounting file systems. [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. [ 121.106523] systemd-shutdown[1]: Deactivating swaps. [ 121.111585] systemd-shutdown[1]: All swaps deactivated. [ 121.116661] systemd-shutdown[1]: Detaching loop devices. [ 121.126395] systemd-shutdown[1]: All loop devices detached. [ 121.130525] systemd-shutdown[1]: Detaching DM devices. [ 121.135824] systemd-shutdown[1]: All DM devices detached. [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. [ 121.171739] systemd-shutdown[1]: Powering off. [ 121.182331] rebo� Best regards Michael
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Vivek, On Di, 2016-10-04 at 17:32 +0530, Vivek Gautam wrote: > Hi Michael, > > > On Tue, Oct 4, 2016 at 4:28 PM, Michael Niewöhner <li...@mniewoehner.de> > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1.] One line summary of the problem: > > > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 > > > > > > > > > > > > > > [2.] Full description of the problem/report: > > > > > > > No usb 3.0 devices are being detected when attached while USB 2.0 > > > > > > > devices work on the same port. > > > > > > > USB 3.0 works after applying patches [9.1] and [9.2], but seems > > > > > > > to be > > > > > > > buggy. The usb hub is redetected every time an usb device is > > > > > > > attached. > > [snip] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [9.] Other notes, patches, fixes, workarounds: > > > > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234 > > > > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259 > > > > > > These patches are required to get USB super-speed working on > > > Exynos5420/5800. > > > But they did not make to upstream. There was resistance on adding new > > > phy_calibrate() > > > callback. > > > > > > Without these patches the Exynos5420/5800 will enumerate all > > > super-speed capable devices > > > as high-speed devices. > > > Last time we checked with exynos542x smdk boards and peach-* boards, > > > we could get the > > > Super - speed devices working. I have not tested odroid anytime so > > > don't have much idea about the > > > its intricacies. > > > I guess Anand was able to use these patches to get his kernel working in > > > past. > > > > > > The patches don't work anymore with 4.8-rc* / 4.8. They worked - but very > > unstable - with 4.7. > > > > One more problem appeared since one of the 4.8-RCs: reboot hangs when the > > dwc3 > > module is loaded. If I unload it before reboot / shutdown everything is > > fine. > > > > > > > > > > > > > When you have a downstream on-board usb hub, ideally it should be able > > > to detect the devices > > > and not reset everytime you connect a new device (like you mentioned > > > earlier). > > > There can be two possible reasons why the hub keeps getting reset ever > > > after applying the above > > > mentioned patches: > > > 1) the clock rates are not proper. > > > 2) the regulator load setting is not enough to drive the hub. > > > > > > Anand, can you please point Michael to an older kernel with which you > > > could test usb on odroid successfully ? > > > You can compare the clocks with an older version and see if there'a > > > any difference. > > > > > > Any possibility of any other framework (such as, bus-freq) trimming > > > down the clock - rates ? > > > > > > > > # v4.7.5 > > > > > > $ cat /sys/kernel/debug/clk/clk_summary | grep usb > > sclk_usbh20_scan_clk 00 48000 > > 0 > > sclk_usbh20 0048000 > > 000 0 > > mout_usbd300 112400 > > 0 > > dout_usbd300 002400 > > 0 > > sclk_usbd300 > > 002400 0 > > dout_usbphy300 112400 > > 0 > > sclk_usbphy300 4424000 > > 000 0 > > mout_usbd301 112400 > > 0 > > dout_usbd301 002400 > > 0 > > sclk_usbd301 > > 002400 0 > > dout_usbphy301 112400 > > 0 > &
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Vivek, On Di, 2016-10-04 at 17:32 +0530, Vivek Gautam wrote: > Hi Michael, > > > On Tue, Oct 4, 2016 at 4:28 PM, Michael Niewöhner > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1.] One line summary of the problem: > > > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 > > > > > > > > > > > > > > [2.] Full description of the problem/report: > > > > > > > No usb 3.0 devices are being detected when attached while USB 2.0 > > > > > > > devices work on the same port. > > > > > > > USB 3.0 works after applying patches [9.1] and [9.2], but seems > > > > > > > to be > > > > > > > buggy. The usb hub is redetected every time an usb device is > > > > > > > attached. > > [snip] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [9.] Other notes, patches, fixes, workarounds: > > > > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234 > > > > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259 > > > > > > These patches are required to get USB super-speed working on > > > Exynos5420/5800. > > > But they did not make to upstream. There was resistance on adding new > > > phy_calibrate() > > > callback. > > > > > > Without these patches the Exynos5420/5800 will enumerate all > > > super-speed capable devices > > > as high-speed devices. > > > Last time we checked with exynos542x smdk boards and peach-* boards, > > > we could get the > > > Super - speed devices working. I have not tested odroid anytime so > > > don't have much idea about the > > > its intricacies. > > > I guess Anand was able to use these patches to get his kernel working in > > > past. > > > > > > The patches don't work anymore with 4.8-rc* / 4.8. They worked - but very > > unstable - with 4.7. > > > > One more problem appeared since one of the 4.8-RCs: reboot hangs when the > > dwc3 > > module is loaded. If I unload it before reboot / shutdown everything is > > fine. > > > > > > > > > > > > > When you have a downstream on-board usb hub, ideally it should be able > > > to detect the devices > > > and not reset everytime you connect a new device (like you mentioned > > > earlier). > > > There can be two possible reasons why the hub keeps getting reset ever > > > after applying the above > > > mentioned patches: > > > 1) the clock rates are not proper. > > > 2) the regulator load setting is not enough to drive the hub. > > > > > > Anand, can you please point Michael to an older kernel with which you > > > could test usb on odroid successfully ? > > > You can compare the clocks with an older version and see if there'a > > > any difference. > > > > > > Any possibility of any other framework (such as, bus-freq) trimming > > > down the clock - rates ? > > > > > > > > # v4.7.5 > > > > > > $ cat /sys/kernel/debug/clk/clk_summary | grep usb > > sclk_usbh20_scan_clk 00 48000 > > 0 > > sclk_usbh20 0048000 > > 000 0 > > mout_usbd300 112400 > > 0 > > dout_usbd300 002400 > > 0 > > sclk_usbd300 > > 002400 0 > > dout_usbphy300 112400 > > 0 > > sclk_usbphy300 4424000 > > 000 0 > > mout_usbd301 112400 > > 0 > > dout_usbd301 002400 > > 0 > > sclk_usbd301 > > 002400 0 > > dout_usbphy301 112400 > > 0 > > sclk_usbphy30
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi, On Di, 2016-09-20 at 23:12 +0200, Michael Niewöhner wrote: > > > Hi guys, > > > > > > > > > > > > > Hi All > > > > > > Adding Vivek Gautam. > > > > > > On 29 August 2016 at 16:35, Michael Niewöhner > > <li...@mniewoehner.de> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Mathias, > > > > > On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 29.08.2016 10:28, Felipe Balbi wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Michael Niewöhner <li...@mniewoehner.de> writes: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1.] One line summary of the problem: > > > > > > > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with > > > > > > Exynos 5422 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [2.] Full description of the problem/report: > > > > > > > > > > > No usb 3.0 devices are being detected when > > > > > > attached while USB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.0 > > > > > > > > > > > devices work on the same port. > > > > > > > > > > > USB 3.0 works after applying patches [9.1] and > > > > > > [9.2], but > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > seems > > > > > > > > > > > to be > > > > > > > > > > > buggy. The usb hub is redetected every time an > > > > > > usb device is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > attached. > > > > > > > > > > > > > > > > > > dwc3 is host, which means it's actually XHCI :-) > > > > > > > > > > > > > > > > > > Adding Mathias > > > > > > >
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi, On Di, 2016-09-20 at 23:12 +0200, Michael Niewöhner wrote: > > > Hi guys, > > > > > > > > > > > > > Hi All > > > > > > Adding Vivek Gautam. > > > > > > On 29 August 2016 at 16:35, Michael Niewöhner > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Mathias, > > > > > On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 29.08.2016 10:28, Felipe Balbi wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Michael Niewöhner writes: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1.] One line summary of the problem: > > > > > > > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with > > > > > > Exynos 5422 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [2.] Full description of the problem/report: > > > > > > > > > > > No usb 3.0 devices are being detected when > > > > > > attached while USB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.0 > > > > > > > > > > > devices work on the same port. > > > > > > > > > > > USB 3.0 works after applying patches [9.1] and > > > > > > [9.2], but > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > seems > > > > > > > > > > > to be > > > > > > > > > > > buggy. The usb hub is redetected every time an > > > > > > usb device is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > attached. > > > > > > > > > > > > > > > > > > dwc3 is host, which means it's actually XHCI :-) > > > > > > > > > > > > > > > > > > Adding Mathias > > > > > > > > > > > > > > > > > > &
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi guys, On Di, 2016-08-30 at 10:32 +0530, Anand Moon wrote: > Hi All > > Adding Vivek Gautam. > > On 29 August 2016 at 16:35, Michael Niewöhner <li...@mniewoehner.de> > wrote: > > > > Hi Mathias, > > On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: > > > > > > On 29.08.2016 10:28, Felipe Balbi wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > Michael Niewöhner <li...@mniewoehner.de> writes: > > > > > > > > > > > > > > > [1.] One line summary of the problem: > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 > > > > > > > > > > [2.] Full description of the problem/report: > > > > > No usb 3.0 devices are being detected when attached while USB > > > > > 2.0 > > > > > devices work on the same port. > > > > > USB 3.0 works after applying patches [9.1] and [9.2], but > > > > > seems > > > > > to be > > > > > buggy. The usb hub is redetected every time an usb device is > > > > > attached. > > > > > > > > dwc3 is host, which means it's actually XHCI :-) > > > > > > > > Adding Mathias > > > > > > > > > > > > > > > > > > > dmesg: > > > > > [ 192.287080] usb 3-1.2: USB disconnect, device number 7 > > > > > [ 210.370699] hub 3-1:1.0: hub_ext_port_status failed (err = > > > > > -71) > > > > > > Looks like the hub GetPortStatus request fails with protocol > > > error. > > > > > > Reading xhci root hub port status is mostly just register reads > > > and > > > writes. It > > > shouldn't include any actual transfers that could return -EPROTO > > > > > > So this is not the root hub? but a external or integrated on your > > > board, right? > > > > > > The protocol error -71 is returned at transfer errors or if > > > device > > > stalled. > > > > > > Adding more xhci debugging options could show something: > > > echo -n 'module xhci_hcd =p' > > > > /sys/kernel/debug/dynamic_debug/control > > > > > > > > > > > > > > > > > > > > > > > > > > [9.] Other notes, patches, fixes, workarounds: > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234 > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259 > > > > > > The additional patches that makes things somehow work involve > > > tuning > > > the PHY, > > > this is an area I'm not familiar with > > > > > > -Mathias > > > > > > > > > I'm sorry, I should have said that this is the dmesg output with > > the > > patches applied. Without them there is no output at all when I > > attach > > an usb 3.0 device. > > > > Michael > > There are two dwc3 ports in the SoC : one for Gbit Ethernet another > one for on-board GL3521 USB 3.0 hub controller. > > 3.10.x kernel > odroid@odroid:~$ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, > Driver=r8152, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=s5p-ehci/3p, 480M > > 4.x kernel > odroid@odroid:~$ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, > Driver=r8152, 480M > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M > |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb- > storage, 5000M > |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb- > storage, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exyno
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi guys, On Di, 2016-08-30 at 10:32 +0530, Anand Moon wrote: > Hi All > > Adding Vivek Gautam. > > On 29 August 2016 at 16:35, Michael Niewöhner > wrote: > > > > Hi Mathias, > > On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: > > > > > > On 29.08.2016 10:28, Felipe Balbi wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > Michael Niewöhner writes: > > > > > > > > > > > > > > > [1.] One line summary of the problem: > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 > > > > > > > > > > [2.] Full description of the problem/report: > > > > > No usb 3.0 devices are being detected when attached while USB > > > > > 2.0 > > > > > devices work on the same port. > > > > > USB 3.0 works after applying patches [9.1] and [9.2], but > > > > > seems > > > > > to be > > > > > buggy. The usb hub is redetected every time an usb device is > > > > > attached. > > > > > > > > dwc3 is host, which means it's actually XHCI :-) > > > > > > > > Adding Mathias > > > > > > > > > > > > > > > > > > > dmesg: > > > > > [ 192.287080] usb 3-1.2: USB disconnect, device number 7 > > > > > [ 210.370699] hub 3-1:1.0: hub_ext_port_status failed (err = > > > > > -71) > > > > > > Looks like the hub GetPortStatus request fails with protocol > > > error. > > > > > > Reading xhci root hub port status is mostly just register reads > > > and > > > writes. It > > > shouldn't include any actual transfers that could return -EPROTO > > > > > > So this is not the root hub? but a external or integrated on your > > > board, right? > > > > > > The protocol error -71 is returned at transfer errors or if > > > device > > > stalled. > > > > > > Adding more xhci debugging options could show something: > > > echo -n 'module xhci_hcd =p' > > > > /sys/kernel/debug/dynamic_debug/control > > > > > > > > > > > > > > > > > > > > > > > > > > [9.] Other notes, patches, fixes, workarounds: > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234 > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259 > > > > > > The additional patches that makes things somehow work involve > > > tuning > > > the PHY, > > > this is an area I'm not familiar with > > > > > > -Mathias > > > > > > > > > I'm sorry, I should have said that this is the dmesg output with > > the > > patches applied. Without them there is no output at all when I > > attach > > an usb 3.0 device. > > > > Michael > > There are two dwc3 ports in the SoC : one for Gbit Ethernet another > one for on-board GL3521 USB 3.0 hub controller. > > 3.10.x kernel > odroid@odroid:~$ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, > Driver=r8152, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=s5p-ehci/3p, 480M > > 4.x kernel > odroid@odroid:~$ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, > Driver=r8152, 480M > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M > |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb- > storage, 5000M > |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb- > storage, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Mathias, On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: > On 29.08.2016 10:28, Felipe Balbi wrote: > > > > > > Hi, > > > > Michael Niewöhner <li...@mniewoehner.de> writes: > > > > > > [1.] One line summary of the problem: > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 > > > > > > [2.] Full description of the problem/report: > > > No usb 3.0 devices are being detected when attached while USB 2.0 > > > devices work on the same port. > > > USB 3.0 works after applying patches [9.1] and [9.2], but seems > > > to be > > > buggy. The usb hub is redetected every time an usb device is > > > attached. > > > > dwc3 is host, which means it's actually XHCI :-) > > > > Adding Mathias > > > > > > > > dmesg: > > > [ 192.287080] usb 3-1.2: USB disconnect, device number 7 > > > [ 210.370699] hub 3-1:1.0: hub_ext_port_status failed (err = > > > -71) > > Looks like the hub GetPortStatus request fails with protocol error. > > Reading xhci root hub port status is mostly just register reads and > writes. It > shouldn't include any actual transfers that could return -EPROTO > > So this is not the root hub? but a external or integrated on your > board, right? > > The protocol error -71 is returned at transfer errors or if device > stalled. > > Adding more xhci debugging options could show something: > echo -n 'module xhci_hcd =p' > > /sys/kernel/debug/dynamic_debug/control > > > > > > > > > [9.] Other notes, patches, fixes, workarounds: > > > [9.1] https://lkml.org/lkml/2014/4/28/234 > > > [9.2] https://lkml.org/lkml/2015/2/2/259 > > The additional patches that makes things somehow work involve tuning > the PHY, > this is an area I'm not familiar with > > -Mathias > I'm sorry, I should have said that this is the dmesg output with the patches applied. Without them there is no output at all when I attach an usb 3.0 device. Michael signature.asc Description: This is a digitally signed message part
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Mathias, On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: > On 29.08.2016 10:28, Felipe Balbi wrote: > > > > > > Hi, > > > > Michael Niewöhner writes: > > > > > > [1.] One line summary of the problem: > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 > > > > > > [2.] Full description of the problem/report: > > > No usb 3.0 devices are being detected when attached while USB 2.0 > > > devices work on the same port. > > > USB 3.0 works after applying patches [9.1] and [9.2], but seems > > > to be > > > buggy. The usb hub is redetected every time an usb device is > > > attached. > > > > dwc3 is host, which means it's actually XHCI :-) > > > > Adding Mathias > > > > > > > > dmesg: > > > [ 192.287080] usb 3-1.2: USB disconnect, device number 7 > > > [ 210.370699] hub 3-1:1.0: hub_ext_port_status failed (err = > > > -71) > > Looks like the hub GetPortStatus request fails with protocol error. > > Reading xhci root hub port status is mostly just register reads and > writes. It > shouldn't include any actual transfers that could return -EPROTO > > So this is not the root hub? but a external or integrated on your > board, right? > > The protocol error -71 is returned at transfer errors or if device > stalled. > > Adding more xhci debugging options could show something: > echo -n 'module xhci_hcd =p' > > /sys/kernel/debug/dynamic_debug/control > > > > > > > > > [9.] Other notes, patches, fixes, workarounds: > > > [9.1] https://lkml.org/lkml/2014/4/28/234 > > > [9.2] https://lkml.org/lkml/2015/2/2/259 > > The additional patches that makes things somehow work involve tuning > the PHY, > this is an area I'm not familiar with > > -Mathias > I'm sorry, I should have said that this is the dmesg output with the patches applied. Without them there is no output at all when I attach an usb 3.0 device. Michael signature.asc Description: This is a digitally signed message part
PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
[1.] One line summary of the problem: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 [2.] Full description of the problem/report: No usb 3.0 devices are being detected when attached while USB 2.0 devices work on the same port. USB 3.0 works after applying patches [9.1] and [9.2], but seems to be buggy. The usb hub is redetected every time an usb device is attached. dmesg: [ 192.287080] usb 3-1.2: USB disconnect, device number 7 [ 210.370699] hub 3-1:1.0: hub_ext_port_status failed (err = -71) [ 210.375159] usb 3-1-port2: connect-debounce failed [ 210.380126] usb 3-1: USB disconnect, device number 5 [ 210.488917] usb 4-1: USB disconnect, device number 3 [ 210.708861] usb 3-1: new high-speed USB device number 9 using xhci- hcd [ 210.851308] usb 3-1: New USB device found, idVendor=05e3, idProduct=0610 [ 210.856530] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 210.863696] usb 3-1: Product: USB2.0 Hub [ 210.867721] usb 3-1: Manufacturer: GenesysLogic [ 210.877800] hub 3-1:1.0: USB hub found [ 210.880600] hub 3-1:1.0: 2 ports detected [ 210.913438] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node [ 211.468970] usb 3-1.2: new high-speed USB device number 10 using xhci-hcd [ 211.579279] usb 3-1.2: New USB device found, idVendor=0951, idProduct=1666 [ 211.584667] usb 3-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 211.592002] usb 3-1.2: Product: DataTraveler 3.0 [ 211.596720] usb 3-1.2: Manufacturer: Kingston [ 211.601075] usb 3-1.2: SerialNumber: 00190F0C0295BE711962B008 [ 211.607557] usb-storage 3-1.2:1.0: USB Mass Storage device detected [ 211.613640] scsi host0: usb-storage 3-1.2:1.0 [ 211.620179] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node [ 212.677008] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6 [ 212.685208] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 212.687323] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node [ 214.209074] usb 4-1: new SuperSpeed USB device number 4 using xhci- hcd [ 214.231660] usb 4-1: New USB device found, idVendor=05e3, idProduct=0616 [ 214.236882] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 214.244057] usb 4-1: Product: USB3.0 Hub [ 214.248060] usb 4-1: Manufacturer: GenesysLogic [ 214.254181] hub 4-1:1.0: USB hub found [ 214.256754] hub 4-1:1.0: 2 ports detected [ 214.264279] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node [ 214.634773] sd 0:0:0:0: [sda] 61457664 512-byte logical blocks: (31.5 GB/29.3 GiB) [ 214.641164] sd 0:0:0:0: [sda] Write Protect is off [ 214.645631] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00 [ 214.645900] sd 0:0:0:0: [sda] No Caching mode page found [ 214.650978] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 214.682552] sda: sda1 [ 214.685165] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 234.526936] usb 3-1.2: USB disconnect, device number 10 [3.] Keywords (i.e., modules, networking, kernel): usb 3.0, dwc3, exynos, odroid [4.] Kernel information 4.6.x, 4.7.x [4.1.] Kernel version (from /proc/version): Linux version 4.7.2+ (c0d3@z3r0) (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #1 SMP Sun Aug 28 18:52:25 CEST 2016 [4.2.] Kernel .config file: #cat .config | grep -E "(USB|DWC|DRD).*=(m|y)" CONFIG_CAN_EMS_USB=m CONFIG_CAN_ESD_USB2=m CONFIG_CAN_GS_USB=m CONFIG_CAN_KVASER_USB=m CONFIG_CAN_PEAK_USB=m CONFIG_CAN_8DEV_USB=m CONFIG_BT_HCIBTUSB=m CONFIG_BT_HCIBTUSB_BCM=y CONFIG_BT_HCIBTUSB_RTL=y CONFIG_USB_NET_DRIVERS=y CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_RTL8152=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_AX88179_178A=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_CDC_EEM=m CONFIG_USB_NET_CDC_NCM=m CONFIG_USB_NET_HUAWEI_CDC_NCM=m CONFIG_USB_NET_CDC_MBIM=m CONFIG_USB_NET_DM9601=m CONFIG_USB_NET_SR9700=m CONFIG_USB_NET_SR9800=m CONFIG_USB_NET_SMSC75XX=m CONFIG_USB_NET_SMSC95XX=m CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET_ENABLE=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=m CONFIG_USB_NET_CX82310_ETH=m CONFIG_USB_NET_KALMIA=m CONFIG_USB_NET_QMI_WWAN=m CONFIG_USB_HSO=m CONFIG_USB_NET_INT51X1=m CONFIG_USB_CDC_PHONET=m CONFIG_USB_IPHETH=m CONFIG_USB_SIERRA_NET=m CONFIG_USB_VL600=m CONFIG_ATH6KL_USB=m CONFIG_AT76C50X_USB=m CONFIG_BRCMFMAC_USB=y CONFIG_P54_USB=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_THINFIRM_USB=m CONFIG_RT2500USB=m CONFIG_RT73USB=m CONFIG_RT2800USB=m CONFIG_RT2800USB_RT33XX=y CONFIG_RT2800USB_RT35XX=y CONFIG_RT2800USB_RT3573=y CONFIG_RT2800USB_RT53XX=y CONFIG_RT2800USB_RT55XX=y CONFIG_RT2X00_LIB_USB=m CONFIG_RTLWIFI_USB=m CONFIG_RSI_USB=m CONFIG_USB_NET_RNDIS_WLAN=m CONFIG_WIMAX_I2400M_USB=m
PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
[1.] One line summary of the problem: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 [2.] Full description of the problem/report: No usb 3.0 devices are being detected when attached while USB 2.0 devices work on the same port. USB 3.0 works after applying patches [9.1] and [9.2], but seems to be buggy. The usb hub is redetected every time an usb device is attached. dmesg: [ 192.287080] usb 3-1.2: USB disconnect, device number 7 [ 210.370699] hub 3-1:1.0: hub_ext_port_status failed (err = -71) [ 210.375159] usb 3-1-port2: connect-debounce failed [ 210.380126] usb 3-1: USB disconnect, device number 5 [ 210.488917] usb 4-1: USB disconnect, device number 3 [ 210.708861] usb 3-1: new high-speed USB device number 9 using xhci- hcd [ 210.851308] usb 3-1: New USB device found, idVendor=05e3, idProduct=0610 [ 210.856530] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 210.863696] usb 3-1: Product: USB2.0 Hub [ 210.867721] usb 3-1: Manufacturer: GenesysLogic [ 210.877800] hub 3-1:1.0: USB hub found [ 210.880600] hub 3-1:1.0: 2 ports detected [ 210.913438] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node [ 211.468970] usb 3-1.2: new high-speed USB device number 10 using xhci-hcd [ 211.579279] usb 3-1.2: New USB device found, idVendor=0951, idProduct=1666 [ 211.584667] usb 3-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 211.592002] usb 3-1.2: Product: DataTraveler 3.0 [ 211.596720] usb 3-1.2: Manufacturer: Kingston [ 211.601075] usb 3-1.2: SerialNumber: 00190F0C0295BE711962B008 [ 211.607557] usb-storage 3-1.2:1.0: USB Mass Storage device detected [ 211.613640] scsi host0: usb-storage 3-1.2:1.0 [ 211.620179] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node [ 212.677008] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6 [ 212.685208] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 212.687323] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node [ 214.209074] usb 4-1: new SuperSpeed USB device number 4 using xhci- hcd [ 214.231660] usb 4-1: New USB device found, idVendor=05e3, idProduct=0616 [ 214.236882] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 214.244057] usb 4-1: Product: USB3.0 Hub [ 214.248060] usb 4-1: Manufacturer: GenesysLogic [ 214.254181] hub 4-1:1.0: USB hub found [ 214.256754] hub 4-1:1.0: 2 ports detected [ 214.264279] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node [ 214.634773] sd 0:0:0:0: [sda] 61457664 512-byte logical blocks: (31.5 GB/29.3 GiB) [ 214.641164] sd 0:0:0:0: [sda] Write Protect is off [ 214.645631] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00 [ 214.645900] sd 0:0:0:0: [sda] No Caching mode page found [ 214.650978] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 214.682552] sda: sda1 [ 214.685165] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 234.526936] usb 3-1.2: USB disconnect, device number 10 [3.] Keywords (i.e., modules, networking, kernel): usb 3.0, dwc3, exynos, odroid [4.] Kernel information 4.6.x, 4.7.x [4.1.] Kernel version (from /proc/version): Linux version 4.7.2+ (c0d3@z3r0) (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #1 SMP Sun Aug 28 18:52:25 CEST 2016 [4.2.] Kernel .config file: #cat .config | grep -E "(USB|DWC|DRD).*=(m|y)" CONFIG_CAN_EMS_USB=m CONFIG_CAN_ESD_USB2=m CONFIG_CAN_GS_USB=m CONFIG_CAN_KVASER_USB=m CONFIG_CAN_PEAK_USB=m CONFIG_CAN_8DEV_USB=m CONFIG_BT_HCIBTUSB=m CONFIG_BT_HCIBTUSB_BCM=y CONFIG_BT_HCIBTUSB_RTL=y CONFIG_USB_NET_DRIVERS=y CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_RTL8152=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_AX88179_178A=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_CDC_EEM=m CONFIG_USB_NET_CDC_NCM=m CONFIG_USB_NET_HUAWEI_CDC_NCM=m CONFIG_USB_NET_CDC_MBIM=m CONFIG_USB_NET_DM9601=m CONFIG_USB_NET_SR9700=m CONFIG_USB_NET_SR9800=m CONFIG_USB_NET_SMSC75XX=m CONFIG_USB_NET_SMSC95XX=m CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET_ENABLE=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=m CONFIG_USB_NET_CX82310_ETH=m CONFIG_USB_NET_KALMIA=m CONFIG_USB_NET_QMI_WWAN=m CONFIG_USB_HSO=m CONFIG_USB_NET_INT51X1=m CONFIG_USB_CDC_PHONET=m CONFIG_USB_IPHETH=m CONFIG_USB_SIERRA_NET=m CONFIG_USB_VL600=m CONFIG_ATH6KL_USB=m CONFIG_AT76C50X_USB=m CONFIG_BRCMFMAC_USB=y CONFIG_P54_USB=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_THINFIRM_USB=m CONFIG_RT2500USB=m CONFIG_RT73USB=m CONFIG_RT2800USB=m CONFIG_RT2800USB_RT33XX=y CONFIG_RT2800USB_RT35XX=y CONFIG_RT2800USB_RT3573=y CONFIG_RT2800USB_RT53XX=y CONFIG_RT2800USB_RT55XX=y CONFIG_RT2X00_LIB_USB=m CONFIG_RTLWIFI_USB=m CONFIG_RSI_USB=m CONFIG_USB_NET_RNDIS_WLAN=m CONFIG_WIMAX_I2400M_USB=m
Re: [PATCH 1/2] regulator: act8865: add restart handler for act8846
I reworked the patch and here it is ;-)
The act8846 provides means to reset the system when used as main pmic.
This patch adds a restart handler for power cycling the regulator thus resetting
the board / soc when system-power-controller in dts is set.
This can be useful for example if there is no other means of reset.
Signed-off-by: Michael Niewoehner
---
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index 2ff73d7..836d10b 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
/*
* ACT8600 Global Register Map.
@@ -133,6 +134,8 @@
#defineACT8865_VOLTAGE_NUM 64
#define ACT8600_SUDCDC_VOLTAGE_NUM 255
+#define ACT8846_SIPC_MASK 0x01
+
struct act8865 {
struct regmap *regmap;
int off_reg;
@@ -402,6 +405,22 @@ static void act8865_power_off(void)
while (1);
}
+static int act8846_power_cycle(struct notifier_block *this,
+ unsigned long code, void *unused)
+{
+ struct act8865 *act8846;
+
+ act8846 = i2c_get_clientdata(act8865_i2c_client);
+ regmap_write(act8846->regmap, ACT8846_GLB_OFF_CTRL, ACT8846_SIPC_MASK);
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block act8846_restart_handler = {
+ .notifier_call = act8846_power_cycle,
+ .priority = 129,
+};
+
static int act8865_pmic_probe(struct i2c_client *client,
const struct i2c_device_id *i2c_id)
{
@@ -484,6 +503,8 @@ static int act8865_pmic_probe(struct i2c_client *client,
}
if (of_device_is_system_power_controller(dev->of_node)) {
+ int ret;
+
if (!pm_power_off && (off_reg > 0)) {
act8865_i2c_client = client;
act8865->off_reg = off_reg;
@@ -492,6 +513,14 @@ static int act8865_pmic_probe(struct i2c_client *client,
} else {
dev_err(dev, "Failed to set poweroff capability,
already defined\n");
}
+
+ if (type == ACT8846) {
+ act8865_i2c_client = client;
+ ret =
register_restart_handler(_restart_handler);
+ if (ret)
+ pr_err("%s: cannot register restart handler,
%d\n",
+ __func__, ret);
+ }
}
/* Finally register devices */--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] regulator: act8865: add restart handler for act8846
I reworked the patch and here it is ;-)
The act8846 provides means to reset the system when used as main pmic.
This patch adds a restart handler for power cycling the regulator thus resetting
the board / soc when system-power-controller in dts is set.
This can be useful for example if there is no other means of reset.
Signed-off-by: Michael Niewoehner mniew...@stud.hs-offenburg.de
---
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index 2ff73d7..836d10b 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -27,6 +27,7 @@
#include linux/of_device.h
#include linux/regulator/of_regulator.h
#include linux/regmap.h
+#include linux/reboot.h
/*
* ACT8600 Global Register Map.
@@ -133,6 +134,8 @@
#defineACT8865_VOLTAGE_NUM 64
#define ACT8600_SUDCDC_VOLTAGE_NUM 255
+#define ACT8846_SIPC_MASK 0x01
+
struct act8865 {
struct regmap *regmap;
int off_reg;
@@ -402,6 +405,22 @@ static void act8865_power_off(void)
while (1);
}
+static int act8846_power_cycle(struct notifier_block *this,
+ unsigned long code, void *unused)
+{
+ struct act8865 *act8846;
+
+ act8846 = i2c_get_clientdata(act8865_i2c_client);
+ regmap_write(act8846-regmap, ACT8846_GLB_OFF_CTRL, ACT8846_SIPC_MASK);
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block act8846_restart_handler = {
+ .notifier_call = act8846_power_cycle,
+ .priority = 129,
+};
+
static int act8865_pmic_probe(struct i2c_client *client,
const struct i2c_device_id *i2c_id)
{
@@ -484,6 +503,8 @@ static int act8865_pmic_probe(struct i2c_client *client,
}
if (of_device_is_system_power_controller(dev-of_node)) {
+ int ret;
+
if (!pm_power_off (off_reg 0)) {
act8865_i2c_client = client;
act8865-off_reg = off_reg;
@@ -492,6 +513,14 @@ static int act8865_pmic_probe(struct i2c_client *client,
} else {
dev_err(dev, Failed to set poweroff capability,
already defined\n);
}
+
+ if (type == ACT8846) {
+ act8865_i2c_client = client;
+ ret =
register_restart_handler(act8846_restart_handler);
+ if (ret)
+ pr_err(%s: cannot register restart handler,
%d\n,
+ __func__, ret);
+ }
}
/* Finally register devices */--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] regulator: act8865: add restart handler for act8846
Hi Heiko,
thanks, I’ll rework the patch and the description on Thursday ;-)
Am 12.05.2015 um 22:22 schrieb Heiko Stuebner :
> Hi Michael,
>
> Am Montag, 11. Mai 2015, 22:54:11 schrieb Michael Niewöhner:
>> Rebooting radxa rock which uses act8846 results in kernel panic because the
>> bootloader doesn't readjust frequency or voltage for cpu correctly. This
>> workaround power cycles the act8846 at restart to reset the board.
>
> Hmm, it might be nice to reword this, as this being a "workaround" for the
> radxarock is a bit "short sighted".
>
> The act8846 simply provides means to reset the system when used as main pmic
> [hence the reliance on the system-power-controller] and other socs/boards
> using it as pmic might also profit from exposing this function - for example
> if
> there is no other means of reset.
>
>
>> Signed-off-by: Michael Niewoehner
>> ---
>> drivers/regulator/act8865-regulator.c | 43
>> +++ 1 file changed, 43 insertions(+)
>>
>> diff --git a/drivers/regulator/act8865-regulator.c
>> b/drivers/regulator/act8865-regulator.c index 2ff73d7..f8cdff3 100644
>> --- a/drivers/regulator/act8865-regulator.c
>> +++ b/drivers/regulator/act8865-regulator.c
>> @@ -27,6 +27,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /*
>> * ACT8600 Global Register Map.
>> @@ -133,10 +134,14 @@
>> #define ACT8865_VOLTAGE_NUM 64
>> #define ACT8600_SUDCDC_VOLTAGE_NUM 255
>>
>> +#define ACT8846_SIPC_MASK 0x01
>> +
>> struct act8865 {
>> struct regmap *regmap;
>> int off_reg;
>> int off_mask;
>> +int sipc_reg;
>> +int sipc_mask;
>> };
>>
>> static const struct regmap_config act8865_regmap_config = {
>> @@ -402,6 +407,17 @@ static void act8865_power_off(void)
>> while (1);
>> }
>>
>> +static int act8846_power_cycle(struct notifier_block *this,
>> +unsigned long code, void *unused)
>> +{
>> +struct act8865 *act8846;
>> +
>> +act8846 = i2c_get_clientdata(act8865_i2c_client);
>> +regmap_write(act8846->regmap, act8846->sipc_reg, act8846->sipc_mask);
>
> The act8846 is currently the only one of the three types providing such
> functionality, so until the second chip variant surfaces that provides a
> reset
> capability, it might be less intrusive to simply do
>
> regmap_write(act8846->regmap, ACT8846_GLB_OFF_CTRL, ACT8846_SIPC_MASK);
>
> here and skip all the infrastructure like sipc_reg and sipc_mask assignment
> and handling? But I guess that is Mark's call what he likes better.
>
>
>> +
>> +return NOTIFY_DONE;
>> +}
>> +
>
> structs like the restart_handler normally live near the function they
> reference and not as static part of some function. And as the restart
> functionality is not rockchip-specific, it should also not be named
> rockchip_foo as below ;-)
>
> static struct notifier_block act8846_restart_handler = {
> .notifier_call = act8846_power_cycle,
> .priority = 129,
> };
>
>
>
>> static int act8865_pmic_probe(struct i2c_client *client,
>>const struct i2c_device_id *i2c_id)
>> {
>> @@ -413,6 +429,7 @@ static int act8865_pmic_probe(struct i2c_client *client,
>> struct act8865 *act8865;
>> unsigned long type;
>> int off_reg, off_mask;
>> +int sipc_reg, sipc_mask;
>>
>> pdata = dev_get_platdata(dev);
>>
>> @@ -434,18 +451,24 @@ static int act8865_pmic_probe(struct i2c_client
>> *client, num_regulators = ARRAY_SIZE(act8600_regulators);
>> off_reg = -1;
>> off_mask = -1;
>> +sipc_reg = -1;
>> +sipc_mask = -1;
>> break;
>> case ACT8846:
>> regulators = act8846_regulators;
>> num_regulators = ARRAY_SIZE(act8846_regulators);
>> off_reg = ACT8846_GLB_OFF_CTRL;
>> off_mask = ACT8846_OFF_SYSMASK;
>> +sipc_reg = ACT8846_GLB_OFF_CTRL;
>> +sipc_mask = ACT8846_SIPC_MASK;
>> break;
>> case ACT8865:
>> regulators = act8865_regulators;
>> num_regulators = ARRAY_SIZE(act8865_regulators);
>> off_reg = ACT8865_SYS_CTRL;
>> off_mask = ACT8865_MSTROFF;
>> +sipc_reg = -1;
>> +sipc_mask = -1;
>> break;
>> default:
>>
Re: [PATCH 2/2] ARM: dts: rockchip: add system-power-controller toact8846
I agree on relicensing to gpl2/x11. Michael > Am 11.05.2015 um 23:58 schrieb Heiko Stuebner : > > Am Montag, 11. Mai 2015, 22:57:21 schrieb Michael Niewöhner: >> Add system-power-controller to act8846 in rk3188-radxarock.dts in addition >> to the act8846 patch fixing the reboot kernel panic >> >> Signed-off-by: Michael Niewoehner > > I have to ask, are you ok with the pending dts relicensing to a gpl2/x11 dual > license [0]? > > Otherwise this looks fine and the act8846 is the power-controller of the > radxarock in any case, so I'll take this one in any case. > > > Heiko > > [0] http://lists.infradead.org/pipermail/linux-rockchip/2015-March/002644.html > > >> --- >> arch/arm/boot/dts/rk3188-radxarock.dts | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts >> b/arch/arm/boot/dts/rk3188-radxarock.dts index bdf8570..225a0eb 100644 >> --- a/arch/arm/boot/dts/rk3188-radxarock.dts >> +++ b/arch/arm/boot/dts/rk3188-radxarock.dts >> @@ -152,6 +152,7 @@ >>compatible = "active-semi,act8846"; >>reg = <0x5a>; >>status = "okay"; >> +system-power-controller; >> >>pinctrl-names = "default"; >>pinctrl-0 = <_dvs0_ctl>; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ARM: dts: rockchip: add system-power-controller toact8846
I agree on relicensing to gpl2/x11. Michael Am 11.05.2015 um 23:58 schrieb Heiko Stuebner he...@sntech.de: Am Montag, 11. Mai 2015, 22:57:21 schrieb Michael Niewöhner: Add system-power-controller to act8846 in rk3188-radxarock.dts in addition to the act8846 patch fixing the reboot kernel panic Signed-off-by: Michael Niewoehner mniew...@stud.hs-offenburg.de I have to ask, are you ok with the pending dts relicensing to a gpl2/x11 dual license [0]? Otherwise this looks fine and the act8846 is the power-controller of the radxarock in any case, so I'll take this one in any case. Heiko [0] http://lists.infradead.org/pipermail/linux-rockchip/2015-March/002644.html --- arch/arm/boot/dts/rk3188-radxarock.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts b/arch/arm/boot/dts/rk3188-radxarock.dts index bdf8570..225a0eb 100644 --- a/arch/arm/boot/dts/rk3188-radxarock.dts +++ b/arch/arm/boot/dts/rk3188-radxarock.dts @@ -152,6 +152,7 @@ compatible = active-semi,act8846; reg = 0x5a; status = okay; +system-power-controller; pinctrl-names = default; pinctrl-0 = act8846_dvs0_ctl; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] regulator: act8865: add restart handler for act8846
Hi Heiko,
thanks, I’ll rework the patch and the description on Thursday ;-)
Am 12.05.2015 um 22:22 schrieb Heiko Stuebner he...@sntech.de:
Hi Michael,
Am Montag, 11. Mai 2015, 22:54:11 schrieb Michael Niewöhner:
Rebooting radxa rock which uses act8846 results in kernel panic because the
bootloader doesn't readjust frequency or voltage for cpu correctly. This
workaround power cycles the act8846 at restart to reset the board.
Hmm, it might be nice to reword this, as this being a workaround for the
radxarock is a bit short sighted.
The act8846 simply provides means to reset the system when used as main pmic
[hence the reliance on the system-power-controller] and other socs/boards
using it as pmic might also profit from exposing this function - for example
if
there is no other means of reset.
Signed-off-by: Michael Niewoehner mniew...@stud.hs-offenburg.de
---
drivers/regulator/act8865-regulator.c | 43
+++ 1 file changed, 43 insertions(+)
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c index 2ff73d7..f8cdff3 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -27,6 +27,7 @@
#include linux/of_device.h
#include linux/regulator/of_regulator.h
#include linux/regmap.h
+#include linux/reboot.h
/*
* ACT8600 Global Register Map.
@@ -133,10 +134,14 @@
#define ACT8865_VOLTAGE_NUM 64
#define ACT8600_SUDCDC_VOLTAGE_NUM 255
+#define ACT8846_SIPC_MASK 0x01
+
struct act8865 {
struct regmap *regmap;
int off_reg;
int off_mask;
+int sipc_reg;
+int sipc_mask;
};
static const struct regmap_config act8865_regmap_config = {
@@ -402,6 +407,17 @@ static void act8865_power_off(void)
while (1);
}
+static int act8846_power_cycle(struct notifier_block *this,
+unsigned long code, void *unused)
+{
+struct act8865 *act8846;
+
+act8846 = i2c_get_clientdata(act8865_i2c_client);
+regmap_write(act8846-regmap, act8846-sipc_reg, act8846-sipc_mask);
The act8846 is currently the only one of the three types providing such
functionality, so until the second chip variant surfaces that provides a
reset
capability, it might be less intrusive to simply do
regmap_write(act8846-regmap, ACT8846_GLB_OFF_CTRL, ACT8846_SIPC_MASK);
here and skip all the infrastructure like sipc_reg and sipc_mask assignment
and handling? But I guess that is Mark's call what he likes better.
+
+return NOTIFY_DONE;
+}
+
structs like the restart_handler normally live near the function they
reference and not as static part of some function. And as the restart
functionality is not rockchip-specific, it should also not be named
rockchip_foo as below ;-)
static struct notifier_block act8846_restart_handler = {
.notifier_call = act8846_power_cycle,
.priority = 129,
};
static int act8865_pmic_probe(struct i2c_client *client,
const struct i2c_device_id *i2c_id)
{
@@ -413,6 +429,7 @@ static int act8865_pmic_probe(struct i2c_client *client,
struct act8865 *act8865;
unsigned long type;
int off_reg, off_mask;
+int sipc_reg, sipc_mask;
pdata = dev_get_platdata(dev);
@@ -434,18 +451,24 @@ static int act8865_pmic_probe(struct i2c_client
*client, num_regulators = ARRAY_SIZE(act8600_regulators);
off_reg = -1;
off_mask = -1;
+sipc_reg = -1;
+sipc_mask = -1;
break;
case ACT8846:
regulators = act8846_regulators;
num_regulators = ARRAY_SIZE(act8846_regulators);
off_reg = ACT8846_GLB_OFF_CTRL;
off_mask = ACT8846_OFF_SYSMASK;
+sipc_reg = ACT8846_GLB_OFF_CTRL;
+sipc_mask = ACT8846_SIPC_MASK;
break;
case ACT8865:
regulators = act8865_regulators;
num_regulators = ARRAY_SIZE(act8865_regulators);
off_reg = ACT8865_SYS_CTRL;
off_mask = ACT8865_MSTROFF;
+sipc_reg = -1;
+sipc_mask = -1;
break;
default:
dev_err(dev, invalid device id %lu\n, type);
@@ -494,6 +517,26 @@ static int act8865_pmic_probe(struct i2c_client
*client, }
}
no need to add a second check for of_device_is_system_power_controller() as
we
already have a check for this property directly above, simply extend it with
something like the following.
if (of_device_is_system_power_controller(dev-of_node)) {
int ret;
/* already existing code to set poweroff handler */
if (type == ACT8846) {
ret = register_restart_handler(act8846_restart_handler);
if (ret)
pr_err(%s: cannot register restart handler, %d\n,
__func__, ret);
}
}
+/* Register restart handler
[PATCH 2/2] ARM: dts: rockchip: add system-power-controller to act8846
Add system-power-controller to act8846 in rk3188-radxarock.dts in addition to the act8846 patch fixing the reboot kernel panic Signed-off-by: Michael Niewoehner --- arch/arm/boot/dts/rk3188-radxarock.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts b/arch/arm/boot/dts/rk3188-radxarock.dts index bdf8570..225a0eb 100644 --- a/arch/arm/boot/dts/rk3188-radxarock.dts +++ b/arch/arm/boot/dts/rk3188-radxarock.dts @@ -152,6 +152,7 @@ compatible = "active-semi,act8846"; reg = <0x5a>; status = "okay"; + system-power-controller; pinctrl-names = "default"; pinctrl-0 = <_dvs0_ctl>; -- 2.3.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] regulator: act8865: add restart handler for act8846
Rebooting radxa rock which uses act8846 results in kernel panic because the
bootloader doesn't readjust frequency or voltage for cpu correctly. This
workaround power cycles the act8846 at restart to reset the board.
Signed-off-by: Michael Niewoehner
---
drivers/regulator/act8865-regulator.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index 2ff73d7..f8cdff3 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
/*
* ACT8600 Global Register Map.
@@ -133,10 +134,14 @@
#defineACT8865_VOLTAGE_NUM 64
#define ACT8600_SUDCDC_VOLTAGE_NUM 255
+#define ACT8846_SIPC_MASK 0x01
+
struct act8865 {
struct regmap *regmap;
int off_reg;
int off_mask;
+ int sipc_reg;
+ int sipc_mask;
};
static const struct regmap_config act8865_regmap_config = {
@@ -402,6 +407,17 @@ static void act8865_power_off(void)
while (1);
}
+static int act8846_power_cycle(struct notifier_block *this,
+ unsigned long code, void *unused)
+{
+ struct act8865 *act8846;
+
+ act8846 = i2c_get_clientdata(act8865_i2c_client);
+ regmap_write(act8846->regmap, act8846->sipc_reg, act8846->sipc_mask);
+
+ return NOTIFY_DONE;
+}
+
static int act8865_pmic_probe(struct i2c_client *client,
const struct i2c_device_id *i2c_id)
{
@@ -413,6 +429,7 @@ static int act8865_pmic_probe(struct i2c_client *client,
struct act8865 *act8865;
unsigned long type;
int off_reg, off_mask;
+ int sipc_reg, sipc_mask;
pdata = dev_get_platdata(dev);
@@ -434,18 +451,24 @@ static int act8865_pmic_probe(struct i2c_client *client,
num_regulators = ARRAY_SIZE(act8600_regulators);
off_reg = -1;
off_mask = -1;
+ sipc_reg = -1;
+ sipc_mask = -1;
break;
case ACT8846:
regulators = act8846_regulators;
num_regulators = ARRAY_SIZE(act8846_regulators);
off_reg = ACT8846_GLB_OFF_CTRL;
off_mask = ACT8846_OFF_SYSMASK;
+ sipc_reg = ACT8846_GLB_OFF_CTRL;
+ sipc_mask = ACT8846_SIPC_MASK;
break;
case ACT8865:
regulators = act8865_regulators;
num_regulators = ARRAY_SIZE(act8865_regulators);
off_reg = ACT8865_SYS_CTRL;
off_mask = ACT8865_MSTROFF;
+ sipc_reg = -1;
+ sipc_mask = -1;
break;
default:
dev_err(dev, "invalid device id %lu\n", type);
@@ -494,6 +517,26 @@ static int act8865_pmic_probe(struct i2c_client *client,
}
}
+ /* Register restart handler */
+ if (of_device_is_system_power_controller(dev->of_node)
+ && sipc_reg > 0) {
+ static struct notifier_block rockchip_restart_handler = {
+ .notifier_call = act8846_power_cycle,
+ .priority = 129,
+ };
+
+ int ret;
+
+ act8865_i2c_client = client;
+ act8865->sipc_reg = sipc_reg;
+ act8865->sipc_mask = sipc_mask;
+
+ ret = register_restart_handler(_restart_handler);
+ if (ret)
+ pr_err("%s: cannot register restart handler, %d\n",
+ __func__, ret);
+ }
+
/* Finally register devices */
for (i = 0; i < num_regulators; i++) {
const struct regulator_desc *desc = [i];
--
2.3.5--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] regulator: act8865: add restart handler for act8846
Rebooting radxa rock which uses act8846 results in kernel panic because the
bootloader doesn't readjust frequency or voltage for cpu correctly. This
workaround power cycles the act8846 at restart to reset the board.
Signed-off-by: Michael Niewoehner mniew...@stud.hs-offenburg.de
---
drivers/regulator/act8865-regulator.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index 2ff73d7..f8cdff3 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -27,6 +27,7 @@
#include linux/of_device.h
#include linux/regulator/of_regulator.h
#include linux/regmap.h
+#include linux/reboot.h
/*
* ACT8600 Global Register Map.
@@ -133,10 +134,14 @@
#defineACT8865_VOLTAGE_NUM 64
#define ACT8600_SUDCDC_VOLTAGE_NUM 255
+#define ACT8846_SIPC_MASK 0x01
+
struct act8865 {
struct regmap *regmap;
int off_reg;
int off_mask;
+ int sipc_reg;
+ int sipc_mask;
};
static const struct regmap_config act8865_regmap_config = {
@@ -402,6 +407,17 @@ static void act8865_power_off(void)
while (1);
}
+static int act8846_power_cycle(struct notifier_block *this,
+ unsigned long code, void *unused)
+{
+ struct act8865 *act8846;
+
+ act8846 = i2c_get_clientdata(act8865_i2c_client);
+ regmap_write(act8846-regmap, act8846-sipc_reg, act8846-sipc_mask);
+
+ return NOTIFY_DONE;
+}
+
static int act8865_pmic_probe(struct i2c_client *client,
const struct i2c_device_id *i2c_id)
{
@@ -413,6 +429,7 @@ static int act8865_pmic_probe(struct i2c_client *client,
struct act8865 *act8865;
unsigned long type;
int off_reg, off_mask;
+ int sipc_reg, sipc_mask;
pdata = dev_get_platdata(dev);
@@ -434,18 +451,24 @@ static int act8865_pmic_probe(struct i2c_client *client,
num_regulators = ARRAY_SIZE(act8600_regulators);
off_reg = -1;
off_mask = -1;
+ sipc_reg = -1;
+ sipc_mask = -1;
break;
case ACT8846:
regulators = act8846_regulators;
num_regulators = ARRAY_SIZE(act8846_regulators);
off_reg = ACT8846_GLB_OFF_CTRL;
off_mask = ACT8846_OFF_SYSMASK;
+ sipc_reg = ACT8846_GLB_OFF_CTRL;
+ sipc_mask = ACT8846_SIPC_MASK;
break;
case ACT8865:
regulators = act8865_regulators;
num_regulators = ARRAY_SIZE(act8865_regulators);
off_reg = ACT8865_SYS_CTRL;
off_mask = ACT8865_MSTROFF;
+ sipc_reg = -1;
+ sipc_mask = -1;
break;
default:
dev_err(dev, invalid device id %lu\n, type);
@@ -494,6 +517,26 @@ static int act8865_pmic_probe(struct i2c_client *client,
}
}
+ /* Register restart handler */
+ if (of_device_is_system_power_controller(dev-of_node)
+sipc_reg 0) {
+ static struct notifier_block rockchip_restart_handler = {
+ .notifier_call = act8846_power_cycle,
+ .priority = 129,
+ };
+
+ int ret;
+
+ act8865_i2c_client = client;
+ act8865-sipc_reg = sipc_reg;
+ act8865-sipc_mask = sipc_mask;
+
+ ret = register_restart_handler(rockchip_restart_handler);
+ if (ret)
+ pr_err(%s: cannot register restart handler, %d\n,
+ __func__, ret);
+ }
+
/* Finally register devices */
for (i = 0; i num_regulators; i++) {
const struct regulator_desc *desc = regulators[i];
--
2.3.5--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: dts: rockchip: add system-power-controller to act8846
Add system-power-controller to act8846 in rk3188-radxarock.dts in addition to the act8846 patch fixing the reboot kernel panic Signed-off-by: Michael Niewoehner mniew...@stud.hs-offenburg.de --- arch/arm/boot/dts/rk3188-radxarock.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts b/arch/arm/boot/dts/rk3188-radxarock.dts index bdf8570..225a0eb 100644 --- a/arch/arm/boot/dts/rk3188-radxarock.dts +++ b/arch/arm/boot/dts/rk3188-radxarock.dts @@ -152,6 +152,7 @@ compatible = active-semi,act8846; reg = 0x5a; status = okay; + system-power-controller; pinctrl-names = default; pinctrl-0 = act8846_dvs0_ctl; -- 2.3.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
