By default the retry timeout is 1 second.  Allow that to be modified,
primarily for slow operations, like firmware writes.

Also, the timeout was driven by a 1 second timer, so 1 second really
meant between 0 and 1 second.  Set the default to 2 seconds so it
means between 1 and 2 seconds.

Also allow the time the interface automatically stays in mainenance
mode to be modified from it's default 30 seconds.

Also consolidate some of the timeout and retry setup.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

more

In the effort to remove all VLAs from the kernel[1], it is desirable to
build with -Wvla.  However, this warning is overly pessimistic, in that
it is only happy with stack array sizes that are declared as constant
expressions, and not constant values.  One case of this is the
evaluation of the max() macro which, due to its construction, ends up
converting constant expression arguments into a constant value result.

All attempts to rewrite this macro with __builtin_constant_p() failed
with older compilers (e.g.  gcc 4.4)[2].  However, Martin Uecker,
constructed[3] a mind-shattering solution that works everywhere.
Cthulhu fhtagn!

This patch updates the min()/max() macros to evaluate to a constant
expression when called on constant expression arguments.  This removes
several false-positive stack VLA warnings from an x86 allmodconfig build
when -Wvla is added:

  $ diff -u before.txt after.txt | grep ^-
  -drivers/input/touchscreen/cyttsp4_core.c:871:2: warning: ISO C90 forbids variable length array ‘ids’ [-Wvla]
  -fs/btrfs/tree-checker.c:344:4: warning: ISO C90 forbids variable length array ‘namebuf’ [-Wvla]
  -lib/vsprintf.c:747:2: warning: ISO C90 forbids variable length array ‘sym’ [-Wvla]
  -net/ipv4/proc.c:403:2: warning: ISO C90 forbids variable length array ‘buff’ [-Wvla]
  -net/ipv6/proc.c:198:2: warning: ISO C90 forbids variable length array ‘buff’ [-Wvla]
  -net/ipv6/proc.c:218:2: warning: ISO C90 forbids variable length array ‘buff64’ [-Wvla]

This also updates two cases where different enums were being compared
and explicitly casts them to int (which matches the old side-effect of
the single-evaluation code): one in tpm/tpm_tis_core.h, and one in
drm/drm_color_mgmt.c.

 [1] https://lkml.org/lkml/2018/3/7/621
 [2] https://lkml.org/lkml/2018/3/10/170
 [3] https://lkml.org/lkml/2018/3/20/845Co-Developed-by: NLinus Torvalds <torvalds@linux-foundation.org>
Co-Developed-by: NMartin Uecker <Martin.Uecker@med.uni-goettingen.de>
Signed-off-by: NKees Cook <keescook@chromium.org>
Acked-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Successes in probe_kernel_read() would mask failures in copy_to_user()
during read_mem().
Reported-by: NBrad Spengler <spender@grsecurity.net>
Fixes: 22ec1a2a ("/dev/mem: Add bounce buffer for copy-out")
Cc: stable@vger.kernel.org
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch allows HP PA-RISC servers like rp3410/rp3440 and the HP C8000
workstation with an IPMI controller that predate IPMI 1.5 to use the standard
poweroff or powercycle commands.

These systems firmware don't set the chassis capability bit in the Get
Device ID, but they do implement the standard poweroff and powercycle
commands.
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The blackfin architecture is getting removed, so we don't
need this driver any more.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NAaron Wu <aaron.wu@analog.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The tile architecture is being removed, so we no longer need this driver.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The m32r architecture was the only user of the old-style
rtc driver for ds1302. The architecture is getting removed
now, and we have a modern driver for the same hardware in
drivers/rtc/rtc-ds1302.c, so this one won't be missed.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Keystone Security Accelerator module has a hardware random generator
sub-module. This commit adds the driver for this sub-module.
Signed-off-by: NVitaly Andrianov <vitalya@ti.com>
[t-kristo@ti.com: dropped one unnecessary dev_err message]
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

My Nuvoton 6xx in a Dell XPS-13 has been intermittently failing to work
(necessitating a reboot). The problem seems to be that the TPM gets into a
state where the partial self-test doesn't return TPM_RC_SUCCESS (meaning
all tests have run to completion), but instead returns TPM_RC_TESTING
(meaning some tests are still running in the background).  There are
various theories that resending the self-test command actually causes the
tests to restart and thus triggers more TPM_RC_TESTING returns until the
timeout is exceeded.

There are several issues here: firstly being we shouldn't slow down the
boot sequence waiting for the self test to complete once the TPM
backgrounds them.  It will actually make available all functions that have
passed and if it gets a failure return TPM_RC_FAILURE to every subsequent
command.  So the fix is to kick off self tests once and if they return
TPM_RC_TESTING log that as a backgrounded self test and continue on.  In
order to prevent other tpm users from seeing any TPM_RC_TESTING returns
(which it might if they send a command that needs a TPM subsystem which is
still under test), we loop in tpm_transmit_cmd until either a timeout or we
don't get a TPM_RC_TESTING return.

Finally, there have been observations of strange returns from a partial
test. One Nuvoton is occasionally returning TPM_RC_COMMAND_CODE, so treat
any unexpected return from a partial self test as an indication we need to
run a full self test.

[jarkko.sakkinen@linux.intel.com: cleaned up some klog messages and
 dropped tpm_transmit_check() helper function from James' original
 commit.]

Fixes: 2482b1bb ("tpm: Trigger only missing TPM 2.0 self tests")
Cc: stable@vger.kernel.org
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>

TPM2 can return TPM2_RC_RETRY to any command and when it does we get
unexpected failures inside the kernel that surprise users (this is
mostly observed in the trusted key handling code).  The UEFI 2.6 spec
has advice on how to handle this:

    The firmware SHALL not return TPM2_RC_RETRY prior to the completion
    of the call to ExitBootServices().

    Implementer’s Note: the implementation of this function should check
    the return value in the TPM response and, if it is TPM2_RC_RETRY,
    resend the command. The implementation may abort if a sufficient
    number of retries has been done.

So we follow that advice in our tpm_transmit() code using
TPM2_DURATION_SHORT as the initial wait duration and
TPM2_DURATION_LONG as the maximum wait time.  This should fix all the
in-kernel use cases and also means that user space TSS implementations
don't have to have their own retry handling.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Cc: stable@vger.kernel.org
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

The Acer Acer Veriton X4110G has a TPM device detected as:
  tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71)

After the first S3 suspend, the following error appears during resume:
  tpm tpm0: A TPM error(38) occurred continue selftest

Any following S3 suspend attempts will now fail with this error:
  tpm tpm0: Error (38) sending savestate before suspend
  PM: Device 00:0b failed to suspend: error 38

Error 38 is TPM_ERR_INVALID_POSTINIT which means the TPM is
not in the correct state. This indicates that the platform BIOS
is not sending the usual TPM_Startup command during S3 resume.
>From this point onwards, all TPM commands will fail.

The same issue was previously reported on Foxconn 6150BK8MC and
Sony Vaio TX3.

The platform behaviour seems broken here, but we should not break
suspend/resume because of this.

When the unexpected TPM state is encountered, set a flag to skip the
affected TPM_SaveState command on later suspends.

Cc: stable@vger.kernel.org
Signed-off-by: NChris Chiu <chiu@endlessm.com>
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Link: http://lkml.kernel.org/r/CAB4CAwfSCvj1cudi+MWaB5g2Z67d9DwY1o475YOZD64ma23UiQ@mail.gmail.com
Link: https://lkml.org/lkml/2011/3/28/192
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591031Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

TPM2_CC_Create(0x153) and TPM2_CC_CreatePrimary (0x131) involve generation
of crypto keys which can be a computationally intensive task. The timeout
is set to 3min. Rather than increasing default timeout a new constant is
added, to not stall for too long on regular commands failures.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

use __le64 annotated variable for response buffer address as this is
read in little endian format form the register.

This suppresses sparse warning
drivers/char/tpm/tpm_crb.c:558:18: warning: cast to restricted __le64
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

1. The buffer cannot be const as it is used both for send and receive.
2. Drop useless casting to u8 *, as this is already a
type of 'buf' parameter, it has just masked the 'const' issue.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Fix tmp_ -> tpm_ typo and add reference to 'space' parameter
in kdoc for tpm_transmit and tpm_transmit_cmd functions.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

The correct sequence is to first request locality and only after
that perform cmd_ready handshake, otherwise the hardware will drop
the subsequent message as from the device point of view the cmd_ready
handshake wasn't performed. Symmetrically locality has to be relinquished
only after going idle handshake has completed, this requires that
go_idle has to poll for the completion and as well locality
relinquish has to poll for completion so it is not overridden
in back to back commands flow.

Two wrapper functions are added (request_locality relinquish_locality)
to simplify the error handling.

The issue is only visible on devices that support multiple localities.

Fixes: 877c57d0 ("tpm_crb: request and relinquish locality 0")
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>

Add the Altera PCI Vendor id to pci_ids.h and remove the private
definitions from xillybus_pcie.c and altera-cvp.c.
Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: NEli Billauer <eli.billauer@gmail.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Anatolij Gustschin <agust@denx.de>

The driver works well on i.MX31 powered boards with device description
taken from board device tree, the only change to add to the driver is
the missing OF device id, the affected list of included headers and
indentation in platform driver struct are beautified a little.
Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: NKim Phillips <kim.phillips@arm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

/dev/nvram was never meant to be used alongside the RTC CMOS driver from
drivers/rtc as it already expose the NVRAM through another interface..
Anyway, the last defconfig to enable it properly was removed in 2010 so
prevent ARM users from selecting it.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the Altera PCI Vendor id to pci_ids.h and remove the private
definitions from xillybus_pcie.c and altera-cvp.c.
Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Eli Billauer <eli.billauer@gmail.com>
Cc: Anatolij Gustschin <agust@denx.de>
Acked-by: NEli Billauer <eli.billauer@gmail.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This happens when BMC doesn't return any data and the code is trying
to print the value of data[2].

Getting following crash:
[  484.728410] Unable to handle kernel NULL pointer dereference at virtual address 00000002
[  484.736496] pgd = ffff0000094a2000
[  484.739885] [00000002] *pgd=00000047fcffe003, *pud=00000047fcffd003, *pmd=0000000000000000
[  484.748158] Internal error: Oops: 96000005 [#1] SMP
[...]
[  485.101451] Call trace:
[...]
[  485.188473] [<ffff000000a46e68>] msg_done_handler+0x668/0x700 [ipmi_ssif]
[  485.195249] [<ffff000000a456b8>] ipmi_ssif_thread+0x110/0x128 [ipmi_ssif]
[  485.202038] [<ffff0000080f1430>] kthread+0x108/0x138
[  485.206994] [<ffff0000080838e0>] ret_from_fork+0x10/0x30
[  485.212294] Code: aa1903e1 aa1803e0 b900227f 95fef6a5 (39400aa3)

Adding a check to validate the data len before printing data[2] to fix this issue.
Signed-off-by: NKamlakant Patel <kamlakant.patel@cavium.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Realtek has some sort of "Virtual" IPMI device on the PCI bus as a
KCS controller, but whatever it is, it's not one.  Ignore it if seen.
Reported-by: NChris Chiu <chiu@endlessm.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NDaniel Drake <drake@endlessm.com>

The IPMI spec states:

  The purpose of the SPMI Table is to provide a mechanism that can
  be used by the OSPM (an ACPI term for “OS Operating System-directed
  configuration and Power Management” essentially meaning an ACPI-aware
  OS or OS loader) very early in the boot process, e.g., before the
  ability to execute ACPI control methods in the OS is available.

When we are probing IPMI in Linux, ACPI control methods are available,
so we shouldn't be probing using SPMI.  It could cause some confusion
during the probing process.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The IPMI spec states:

  The purpose of the SPMI Table is to provide a mechanism that can
  be used by the OSPM (an ACPI term for “OS Operating System-directed
  configuration and Power Management” essentially meaning an ACPI-aware
  OS or OS loader) very early in the boot process, e.g., before the
  ability to execute ACPI control methods in the OS is available.

When we are probing IPMI in Linux, ACPI control methods are available,
so we shouldn't be probing using SPMI.  It could cause some confusion
during the probing process.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NJiandi An <anjiandi@codeaurora.org>

On Armada 7K/8K we need to explicitly enable the register clock. This
clock is optional because not all the SoCs using this IP need it but at
least for Armada 7K/8K it is actually mandatory.

The binding documentation is updating accordingly.
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

clk_disable_unprepare() already checks that the clock pointer is valid.
No need to test it before calling it.
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Functions cavium_rng_remove and cavium_rng_remove_vf are local to the
source and do not need to be in global scope, so make them static.

Cleans up sparse warnings:
drivers/char/hw_random/cavium-rng-vf.c:80:7: warning: symbol
'cavium_rng_remove_vf' was not declared. Should it be static?
drivers/char/hw_random/cavium-rng.c:65:7: warning: symbol
'cavium_rng_remove' was not declared. Should it be static?
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

If platform_device_alloc() then we should return -ENOMEM instead of
returning success.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Use the ARRAY_SIZE macro on a array poweroff_functions to determine
size of the array. Improvement suggested by Coccinelle.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The cleanup code for an init failure and for a device removal were
quite similar, consolidate all that into one function.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The data is allocated with kzalloc, no need to set things to NULL.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

device_remove_group() was called on any cleanup, even if the
device attrs had not been added yet.  That can occur in certain
error scenarios, so add a flag to know if it has been added.

Also make sure we remove the dev if we added it ourselves.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: stable@vger.kernel.org # 4.15
Cc: Laura Abbott <labbott@redhat.com>
Tested-by: NBill Perkins <wmp@grnwood.net>

Increase timeout delay to support longer timing linked
to rng initialization. Measurement is based on timer instead
of instructions per iteration which is not powerful on all
targets.
Signed-off-by: NLionel Debieve <lionel.debieve@st.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add a new property that allow to disable the clock error
detection which is required when the clock source selected
is out of specification (which is not mandatory).
Signed-off-by: NLionel Debieve <lionel.debieve@st.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Avoid issue when probing the RNG without
reset if bad status has been detected previously
Signed-off-by: NLionel Debieve <lionel.debieve@st.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Since commit 34ce71a9 ("ALSA: timer: remove legacy rtctimer"), the
rtc_register/rtc_control/rtc_unregister API is unused. As it is highly
unlikely to be needed again, remove it.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>

Ever since "random: kill dead extract_state struct" [1], the
dont_count_entropy member of struct timer_rand_state has been
effectively unused. Since it hasn't found a new use in 12 years, it's
probably safe to finally kill it.

[1] Pre-git, https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=c1c48e61c251f57e7a3f1bf11b3c462b2de9dcb5Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

add_interrupt_randomess always wakes up
code blocking on /dev/random. This wake up is done
unconditionally. Unfortunately this means all interrupts
take the wait queue spinlock, which can be rather expensive
on large systems processing lots of interrupts.

We saw 1% cpu time spinning on this on a large macro workload
running on a large system.

I believe it's a recent regression (?)

Always check if there is a waiter on the wait queue
before waking up. This check can be done without
taking a spinlock.

1.06%         10460  [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
         |
         ---native_queued_spin_lock_slowpath
            |
             --0.57%--_raw_spin_lock_irqsave
                       |
                        --0.56%--__wake_up_common_lock
                                  credit_entropy_bits
                                  add_interrupt_randomness
                                  handle_irq_event_percpu
                                  handle_irq_event
                                  handle_edge_irq
                                  handle_irq
                                  do_IRQ
                                  common_interrupt
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

This fixes a harmless UBSAN where root could potentially end up
causing an overflow while bumping the entropy_total field (which is
ignored once the entropy pool has been initialized, and this generally
is completed during the boot sequence).

This is marginal for the stable kernel series, but it's a really
trivial patch, and it fixes UBSAN warning that might cause security
folks to get overly excited for no reason.
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Reported-by: NChen Feng <puck.chen@hisilicon.com>
Cc: stable@vger.kernel.org

And get rid of the license text that is no longer necessary.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Alistair Popple <alistair@popple.id.au>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Joel Stanley <joel@jms.id.au>
Cc: Rocky Craig <rocky.craig@hp.com>