Optimize hl_mmu_map and hl_mmu_unmap by not calling flush(ctx)
within per-page loop.
Signed-off-by: NPawel Piskorski <ppiskorski@habana.ai>
Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

The Cannon Lake device for itouch in HW spec is numbered 3, not 4.
Fix the internal numbering to match the HW spec.
Signed-off-by: NAlexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20200227112737.8383-1-tomas.winkler@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: NDimitri Sivanich <sivanich@hpe.com>
Link: https://lore.kernel.org/r/20200226222240.GA14474@embeddedorSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit.  Fix it by replacing with scnprintf().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200311074916.8783-1-tiwai@suse.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The TX/RX register should not be treated the same way to allow for better
support of tuning. Fix this by using a default initial value for TX.
Signed-off-by: NRicky Wu <ricky_wu@realtek.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200316025232.1167-1-ricky_wu@realtek.com
[Ulf: Updated changelog]
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The at24 driver attempts to read a byte from the device to validate that
it's actually present, and if not, disables the vcc regulator and
returns -ENODEV. However, between the read and the error handling path,
pm_runtime_idle() is called and invokes the driver's suspend callback,
which also disables the vcc regulator. This leads to an underflow of the
regulator enable count if the EEPROM is not present.

Move the pm_runtime_suspend() call to be after the error handling path
to resolve this.

Fixes: cd5676db ("misc: eeprom: at24: support pm_runtime control")
Signed-off-by: NMichael Auchter <michael.auchter@ni.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

altera_get_note is called from altera_init, where key is kzalloc(33).

When the allocation functions are annotated to allow the compiler to see
the sizes of objects, and with FORTIFY_SOURCE, we see:

In file included from drivers/misc/altera-stapl/altera.c:14:0:
In function ‘strlcpy’,
    inlined from ‘altera_init’ at drivers/misc/altera-stapl/altera.c:2189:5:
include/linux/string.h:378:4: error: call to ‘__write_overflow’ declared with attribute error: detected write beyond size of object passed as 1st parameter
    __write_overflow();
    ^~~~~~~~~~~~~~~~~~

That refers to this code in altera_get_note:

    if (key != NULL)
            strlcpy(key, &p[note_strings +
                            get_unaligned_be32(
                            &p[note_table + (8 * i)])],
                    length);

The error triggers because the length of 'key' is 33, but the copy
uses length supplied as the 'length' parameter, which is always
256. Split the size parameter into key_len and val_len, and use the
appropriate length depending on what is being copied.

Detected by compiler error, only compile-tested.

Cc: "Igor M. Liplianin" <liplianin@netup.ru>
Signed-off-by: NDaniel Axtens <dja@axtens.net>
Link: https://lore.kernel.org/r/20200120074344.504-2-dja@axtens.netSigned-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/202002251042.D898E67AC@keescookSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

During the development some of the module functions were factored
out of pci-mei.c and pci-txe.c files, but the includes
have remain there. We can remove them now.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20200223204419.2634-1-tomas.winkler@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use kzalloc instead of manually setting kmalloc
with flag GFP_ZERO since kzalloc sets allocated memory
to zero.
Signed-off-by: NHuang Zijiang <huang.zijiang@zte.com.cn>
Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
Link: https://lore.kernel.org/r/1581501247-5479-1-git-send-email-wang.yi59@zte.com.cnSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The MEI message header provides only 9 bits for storing
the message size, limiting to 511.
In theory the host buffer (hbuf) can contain up to 1020 bytes
(limited by byte =  255 * 4)
With the current hardware and hbuf size 512, this is not a real issue,
but as hardening approach we enforce the limit.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20200211160522.7562-1-tomas.winkler@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200211210822.GA31368@embeddedorSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200211211010.GA32239@embeddedorSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

During device memory memset, the driver allocates and use a CB (command
buffer). To reuse existing code, it keeps a pointer to the CB in two
variables, user_cb and patched_cb. Therefore, there is no need to "put"
both the user_cb and patched_cb, as it will cause an underflow of the
refcnt of the CB.
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

During hard reset we must not write to the device.
Hence avoid halting CoreSight during user context close if it is done
during hard reset.
In addition, we must not re-enable clock gating afterwards as it was
deliberately disabled in the beginning of the hard reset flow.
Signed-off-by: NOmer Shpigelman <oshpigelman@habana.ai>
Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

The driver must halt the engines before doing hard-reset, otherwise the
device can go into undefined state. There is a place where the driver
didn't do that and this patch fixes it.
Reviewed-by: NTomer Tayar <ttayar@habana.ai>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

Make the stack erasing test more verbose about the errors that it
can detect.
Signed-off-by: NAlexander Popov <alex.popov@linux.com>
Cc: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20200102234907.585508-1-alex.popov@linux.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The most notable change is DEFINE_SHOW_ATTRIBUTE macro split in
seq_file.h.

Conversion rule is:

	llseek		=> proc_lseek
	unlocked_ioctl	=> proc_ioctl

	xxx		=> proc_xxx

	delete ".owner = THIS_MODULE" line

[akpm@linux-foundation.org: fix drivers/isdn/capi/kcapi_proc.c]
[sfr@canb.auug.org.au: fix kernel/sched/psi.c]
  Link: http://lkml.kernel.org/r/20200122180545.36222f50@canb.auug.org.au
Link: http://lkml.kernel.org/r/20191225172546.GB13378@avx2Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add Jasper Point (Jasper Lake) device id for MEI
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200124001455.24176-1-tomas.winkler@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Although in the most platforms, the power of eeprom are alway
on, some platforms disable the eeprom power in order to meet
low power request. This patch add the pm_runtime ops to control
power to support all platforms.
Signed-off-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
[Bartosz: rebased on top of current at24/for-next]
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

The PCI hotplug framework is used to update the devices when a new
image is written to the FPGA.
Reviewed-by: NAlastair D'Silva <alastair@d-silva.org>
Reviewed-by: NAndrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: NFrederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20191121134918.7155-12-fbarrat@linux.ibm.com

Add Comet Point device IDs for Comet Lake H platforms.

Cc: <stable@vger.kernel.org>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20200119094229.20116-1-tomas.winkler@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Mmgrab was introduced in commit f1f10076 ("mm: add new mmgrab()
helper") and most of the kernel was updated to use it. Update a
remaining file.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

<smpl>
@@ expression e; @@
- atomic_inc(&e->mm_count);
+ mmgrab(e);
</smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@inria.fr>
Acked-by: NAndrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1577634178-22530-2-git-send-email-Julia.Lawall@inria.fr

When building ARCH=um with CONFIG_UML_X86=y and CONFIG_64BIT=y we get
the build errors:

drivers/misc/lkdtm/bugs.c: In function ‘lkdtm_UNSET_SMEP’:
drivers/misc/lkdtm/bugs.c:288:8: error: implicit declaration of function ‘native_read_cr4’ [-Werror=implicit-function-declaration]
  cr4 = native_read_cr4();
        ^~~~~~~~~~~~~~~
drivers/misc/lkdtm/bugs.c:290:13: error: ‘X86_CR4_SMEP’ undeclared (first use in this function); did you mean ‘X86_FEATURE_SMEP’?
  if ((cr4 & X86_CR4_SMEP) != X86_CR4_SMEP) {
             ^~~~~~~~~~~~
             X86_FEATURE_SMEP
drivers/misc/lkdtm/bugs.c:290:13: note: each undeclared identifier is reported only once for each function it appears in
drivers/misc/lkdtm/bugs.c:297:2: error: implicit declaration of function ‘native_write_cr4’; did you mean ‘direct_write_cr4’? [-Werror=implicit-function-declaration]
  native_write_cr4(cr4);
  ^~~~~~~~~~~~~~~~
  direct_write_cr4

So specify that this block of code should only build when
CONFIG_X86_64=y *AND* CONFIG_UML is unset.
Signed-off-by: NBrendan Higgins <brendanhiggins@google.com>
Acked-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20191213003522.66450-1-brendanhiggins@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Adjust the DOUBLE_FAULT test to always be available (so test harnesses
don't have to make exceptions more missing tests), and for the
arch-specific tests to "XFAIL" so that test harnesses can reason about
expected vs unexpected failures.

Fixes: b09511c2 ("lkdtm: Add a DOUBLE_FAULT crash type on x86")
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/202001021226.751D3F869D@keescookSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

debugfs_remove_recursive will do NULL check, so remove
the redundant null check.
Signed-off-by: NXu Wang <vulab@iscas.ac.cn>
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Link: https://lore.kernel.org/r/1578391235-603-1-git-send-email-vulab@iscas.ac.cnSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

xsdfec_poll() is defined as returning 'unsigned int' but the
.poll method is declared as returning '__poll_t', a bitwise type.

Fix this by using the proper return type and using the EPOLL
constants instead of the POLL ones, as required for __poll_t.

CC: Derek Kiernan <derek.kiernan@xilinx.com>
CC: Dragan Cvetic <dragan.cvetic@xilinx.com>
Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: NDragan Cvetic <dragan.cvetic@xilinx.com>
Link: https://lore.kernel.org/r/20191209213655.57985-1-luc.vanoostenryck@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The second arg of xsdfec_set_order() is a 'void __user *'
and this pointer is then used in get_user() which expect
a __user pointer.

But get_user() can't be used with a void pointer, it a
pointer to the effective type. This is done here by casting
the argument to a pointer to the effective type but the
__user is missing in the cast.

Fix this by adding the missing __user in the cast.

CC: Derek Kiernan <derek.kiernan@xilinx.com>
CC: Dragan Cvetic <dragan.cvetic@xilinx.com>
Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: NDragan Cvetic <dragan.cvetic@xilinx.com>
Link: https://lore.kernel.org/r/20191209213719.58037-1-luc.vanoostenryck@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The variables i and flags are being initialized with values that are
never read.  The initializations are redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200113123149.187555-1-colin.king@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The variable r is being initialized with a value that is never
read and it is being updated later with a new value. Remove
the redundant initialization and move the declaration into a
deeper code block.

Addresses-Coverity: ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200107175234.121298-1-colin.king@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The variable retval is assigned with a value that is never read and
it is re-assigned a new value later on.  The assignment is redundant
and can be removed.  Clean up multiple occurrances of this pattern.

Addresses-Coverity: ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20191222222224.732340-1-colin.king@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

I have added the AU6625 PCI_ID to the list of supported IDs:
alcor_pci.c
// Added au6625s ID to the array of supported devices
alcor_pci.h
// Added entry to define the PCI ID

Made it fit in with the already submitted code:
alcor_pci.c
// Added config entry to that matches the one for au6601

>From general usage there seems to be no problems.
Signed-off-by: NRhys Perry <rhysperry111@gmail.com>
Link: https://lore.kernel.org/r/20191229171824.10308-1-rhysperry111@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Mmgrab was introduced in commit f1f10076 ("mm: add new mmgrab()
helper") and most of the kernel was updated to use it. Update a
remaining file.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

<smpl>
@@ expression e; @@
- atomic_inc(&e->mm_count);
+ mmgrab(e);
</smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@inria.fr>
Acked-by: NAndrew Donnellan <ajd@linux.ibm.com>
Link: https://lore.kernel.org/r/1577634178-22530-2-git-send-email-Julia.Lawall@inria.frSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some users prefer kdump tools to generate guest kernel dumpfile,
at the same time, need a out-of-band kernel panic event.

Currently if booting guest kernel with 'crash_kexec_post_notifiers',
QEMU will receive PVPANIC_PANICKED event and stop VM. If booting
guest kernel without 'crash_kexec_post_notifiers', guest will not
call notifier chain.

Add PVPANIC_CRASH_LOADED bit for pvpanic event, it means that guest
kernel actually hit a kernel panic, but the guest kernel wants to
handle by itself.
Signed-off-by: Nzhenwei pi <pizhenwei@bytedance.com>
Link: https://lore.kernel.org/r/20200102023513.318836-3-pizhenwei@bytedance.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some processes outside of the kernel(Ex, QEMU) should know what the
value really is for, so move the bit definition to a uapi file.
Suggested-by: NGreg KH <gregkh@linuxfoundation.org>
Signed-off-by: Nzhenwei pi <pizhenwei@bytedance.com>
Link: https://lore.kernel.org/r/20200102023513.318836-2-pizhenwei@bytedance.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A u8 can only go up to 255, condition n > 396 is
impossible, so change u8 to u16.
Signed-off-by: NRui Feng <rui_feng@realsil.com.cn>
Link: https://lore.kernel.org/r/1574214006-13540-1-git-send-email-rui_feng@realsil.com.cnSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver forgets to call pm_runtime_disable in remove.
Add the missed call to fix it.
Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/20191118080931.30749-1-hslester96@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Using the following command will get compile warnings:
make W=1 drivers/misc/genwqe/card_ddcb.o ARCH=x86_64

drivers/misc/genwqe/card_ddcb.c: In function setup_ddcb_queue:
drivers/misc/genwqe/card_ddcb.c:1024:6: warning: variable rc set but not
used [-Wunused-but-set-variable]
drivers/misc/genwqe/card_ddcb.c: In function genwqe_card_thread:
drivers/misc/genwqe/card_ddcb.c:1190:23: warning: variable rc set but
not used [-Wunused-but-set-variable]
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NHongbo Yao <yaohongbo@huawei.com>
Link: https://lore.kernel.org/r/20191205111655.170382-1-yaohongbo@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Right now several architectures allow their set_memory_*() family of
functions to fail, but callers may not be checking the return values.
If set_memory_*() returns with an error, call-site assumptions may be
infact wrong to assume that it would either succeed or not succeed at
all. Ideally, the failure of set_memory_*() should be passed up the call
stack, and callers should examine the failure and deal with it.

Need to fix the callers and add the __must_check attribute. They also
may not provide any level of atomicity, in the sense that the memory
protections may be left incomplete on failure. This issue likely has a
few steps on effects architectures:
  1) Have all callers of set_memory_*() helpers check the return value.
  2) Add __must_check to all set_memory_*() helpers so that new uses do
     not ignore the return value.
  3) Add atomicity to the calls so that the memory protections aren't
     left in a partial state.

This series is part of step 1. Make sram driver check the return value
of set_memory_*().
Signed-off-by: NTianlin Li <tli@digitalocean.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20191217194528.16461-1-tli@digitalocean.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The mei device and i915 must reside on the same
PCH in order for HDCP to work. Make the component
matching function enforce this requirement.

                   hdcp
                    |
   i915            mei
    |               |
    +----= PCH =----+

Cc: <stable@vger.kernel.org> v5.0+
Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Reviewed-by: NAlexander Usyskin <alexander.usyskin@intel.com>
Link: https://lore.kernel.org/r/20191212084103.2893-1-tomas.winkler@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Replace scnprintf with simple sprintf for sysfs files.
it is implicitly known that the buffer is big enough
for the variables to fit in.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20191126123002.4835-1-tomas.winkler@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>