Searched hist:7495 (Results 1 - 25 of 25) sorted by relevance

/linux-master/tools/perf/arch/arm/
H A DMakefilediff 7495f374 Wed Sep 25 17:36:36 MDT 2013 Will Deacon <will@kernel.org> ARM: perf: wire up perf_regs and unwind support for ARM

This patch hooks in the perf_regs and libunwind code for ARM.

Cc: Jean Pihet <jean.pihet@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
/linux-master/Documentation/admin-guide/
H A Dbootconfig.rstdiff 7495e092 Tue Feb 04 05:33:53 MST 2020 Steven Rostedt (VMware) <rostedt@goodmis.org> bootconfig: Only load bootconfig if "bootconfig" is on the kernel cmdline

As the bootconfig is appended to the initrd it is not as easy to modify as
the kernel command line. If there's some issue with the kernel, and the
developer wants to boot a pristine kernel, it should not be needed to modify
the initrd to remove the bootconfig for a single boot.

As bootconfig is silently added (if the admin does not know where to look
they may not know it's being loaded). It should be explicitly added to the
kernel cmdline. The loading of the bootconfig is only done if "bootconfig"
is on the kernel command line. This will let admins know that the kernel
command line is extended.

Note, after adding printk()s for when the size is too great or the checksum
is wrong, exposed that the current method always looked for the boot config,
and if this size and checksum matched, it would parse it (as if either is
wrong a printk has been added to show this). It's better to only check this
if the boot config is asked to be looked for.

Link: https://lore.kernel.org/r/CAHk-=wjfjO+h6bQzrTf=YCZA53Y3EDyAs3Z4gEsT7icA3u_Psw@mail.gmail.com

Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
H A Dkernel-parameters.txtdiff 7495e092 Tue Feb 04 05:33:53 MST 2020 Steven Rostedt (VMware) <rostedt@goodmis.org> bootconfig: Only load bootconfig if "bootconfig" is on the kernel cmdline

As the bootconfig is appended to the initrd it is not as easy to modify as
the kernel command line. If there's some issue with the kernel, and the
developer wants to boot a pristine kernel, it should not be needed to modify
the initrd to remove the bootconfig for a single boot.

As bootconfig is silently added (if the admin does not know where to look
they may not know it's being loaded). It should be explicitly added to the
kernel cmdline. The loading of the bootconfig is only done if "bootconfig"
is on the kernel command line. This will let admins know that the kernel
command line is extended.

Note, after adding printk()s for when the size is too great or the checksum
is wrong, exposed that the current method always looked for the boot config,
and if this size and checksum matched, it would parse it (as if either is
wrong a printk has been added to show this). It's better to only check this
if the boot config is asked to be looked for.

Link: https://lore.kernel.org/r/CAHk-=wjfjO+h6bQzrTf=YCZA53Y3EDyAs3Z4gEsT7icA3u_Psw@mail.gmail.com

Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
/linux-master/arch/x86/include/asm/
H A Dgart.hdiff 260133ab Fri Sep 03 10:39:40 MDT 2010 Borislav Petkov <borislav.petkov@amd.com> x86, GART: Disable GART table walk probes

Current code tramples over bit F3x90[6] which can be used to
disable GART table walk probes. However, this bit should be set
for performance reasons (speed up GART table walks). We are
allowed to do that since we put GART tables in UC memory later
anyway. Make it so.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
LKML-Reference: <1283531981-7495-3-git-send-email-bp@amd64.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
diff 57ab43e3 Fri Sep 03 10:39:39 MDT 2010 Borislav Petkov <borislav.petkov@amd.com> x86, GART: Remove superfluous AMD64_GARTEN

There is a GARTEN so use that and drop the duplicate.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
LKML-Reference: <1283531981-7495-2-git-send-email-bp@amd64.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
/linux-master/Documentation/devicetree/bindings/dma/
H A Dqcom,gpi.yamldiff 7495a5bb Wed Apr 13 12:42:35 MDT 2022 Vinod Koul <vkoul@kernel.org> dt-bindings: dmaengine: qcom: gpi: Add minItems for interrupts

Add the minItems for interrupts property as well. In the absence of
this, we get warning if interrupts are less than 13

arch/arm64/boot/dts/qcom/qrb5165-rb5.dtb:
dma-controller@800000: interrupts: [[0, 588, 4], [0, 589, 4], [0, 590,
4], [0, 591, 4], [0, 592, 4], [0, 593, 4], [0, 594, 4], [0, 595, 4], [0,
596, 4], [0, 597, 4]] is too short

Signed-off-by: Vinod Koul <vkoul@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220414064235.1182195-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
/linux-master/drivers/char/agp/
H A Damd64-agp.cdiff 260133ab Fri Sep 03 10:39:40 MDT 2010 Borislav Petkov <borislav.petkov@amd.com> x86, GART: Disable GART table walk probes

Current code tramples over bit F3x90[6] which can be used to
disable GART table walk probes. However, this bit should be set
for performance reasons (speed up GART table walks). We are
allowed to do that since we put GART tables in UC memory later
anyway. Make it so.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
LKML-Reference: <1283531981-7495-3-git-send-email-bp@amd64.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
diff 57ab43e3 Fri Sep 03 10:39:39 MDT 2010 Borislav Petkov <borislav.petkov@amd.com> x86, GART: Remove superfluous AMD64_GARTEN

There is a GARTEN so use that and drop the duplicate.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
LKML-Reference: <1283531981-7495-2-git-send-email-bp@amd64.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
H A Dgeneric.cdiff 1b13fe6a Fri Sep 03 10:39:41 MDT 2010 Borislav Petkov <borislav.petkov@amd.com> AGP: Warn when GATT memory cannot be set to UC

This is one of those paranoid checks which should at least tell
us that something is about to go haywire after we've disabled
GART table walk probes which is done by default now on AMD.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
LKML-Reference: <1283531981-7495-4-git-send-email-bp@amd64.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
/linux-master/sound/firewire/
H A Damdtp-stream-trace.hdiff a9c4284b Tue May 10 16:33:27 MDT 2016 Takashi Sakamoto <o-takashi@sakamocchi.jp> ALSA: firewire-lib: add context information to tracepoints

In current implementation, packet processing is done in both of software
IRQ contexts of IR/IT contexts and process contexts.

This is usual interrupt handling of IR/IT context for 1394 OHCI.
(in hardware IRQ context)
irq_handler() (drivers/firewire/ohci.c)
->tasklet_schedule()
(in software IRQ context)
handle_it_packet() or handle_ir_packet_per_buffer() (drivers/firewire/ohci.c)
->flush_iso_completions()
->struct fw_iso_context.callback.sc()
= out_stream_callback() or in_stream_callback()

However, we have another chance for packet processing. It's done in PCM
frame handling via ALSA PCM interfaces.
(in process context)
ioctl(i.e. SNDRV_PCM_IOCTL_HWSYNC)
->snd_pcm_hwsync() (sound/core/pcm_native.c)
->snd_pcm_update_hw_ptr() (sound/core/pcm_lib.c)
->snd_pcm_update_hw_ptr0()
->struct snd_pcm_ops.pointer()
= amdtp_stream_pcm_pointer()
->fw_iso_context_flush_completions() (drivers/firewire/core-iso.c)
->struct fw_card_driver.flush_iso_completions()
= ohci_flush_iso_completions() (drivers/firewire/ohci.c)
->flush_iso_completions()
->struct fw_iso_context.callback.sc()
= out_stream_callback() or in_stream_callback()

This design is for a better granularity of PCM pointer. When ioctl(2) is
executed with some commands for ALSA PCM interface, queued packets are
handled at first. Then, the latest number of handled PCM frames is
reported. The number can represent PCM frames transferred in most near
isochronous cycle.

Current tracepoints include no information to distinguish running contexts.
When tracing the interval of software IRQ context, this is not good.

This commit adds more information for current context. Additionally, the
index of packet processed in one context is added in a case that packet
processing is executed in continuous context of the same kind,

As a result, the output includes 11 fields with additional two fields
to commit 0c95c1d6197f ("ALSA: firewire-lib: add tracepoints to dump a part
of isochronous packet data"):
17131.9186: out_packet: 07 7494 ffc0 ffc1 00 000700c0 9001a496 058 45 1 13
17131.9186: out_packet: 07 7495 ffc0 ffc1 00 000700c8 9001ba00 058 46 1 14
17131.9186: out_packet: 07 7496 ffc0 ffc1 00 000700d0 9001ffff 002 47 1 15
17131.9189: out_packet: 07 7497 ffc0 ffc1 00 000700d0 9001d36a 058 00 0 00
17131.9189: out_packet: 07 7498 ffc0 ffc1 00 000700d8 9001e8d4 058 01 0 01
17131.9189: out_packet: 07 7499 ffc0 ffc1 00 000700e0 9001023e 058 02 0 00
17131.9206: in_packet: 07 7447 ffc1 ffc0 01 3f070072 9001783d 058 32 1 00
17131.9206: in_packet: 07 7448 ffc1 ffc0 01 3f070072 90ffffff 002 33 1 01
17131.9206: in_packet: 07 7449 ffc1 ffc0 01 3f07007a 900191a8 058 34 1 02
(Here, some common fields are omitted so that a line is within 80
characters.)

The legend is:
- The second of cycle scheduled for the packet
- The count of cycle scheduled for the packet
- The ID of node as source (hex)
- The ID of node as destination (hex)
- The value of isochronous channel
- The first quadlet of CIP header (hex)
- The second quadlet of CIP header (hex)
- The number of included quadlets
- The index of packet in a buffer maintained by this module
- 0 in process context, 1 in IRQ context
- The index of packet processed in the context

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
H A Damdtp-stream.cdiff a9c4284b Tue May 10 16:33:27 MDT 2016 Takashi Sakamoto <o-takashi@sakamocchi.jp> ALSA: firewire-lib: add context information to tracepoints

In current implementation, packet processing is done in both of software
IRQ contexts of IR/IT contexts and process contexts.

This is usual interrupt handling of IR/IT context for 1394 OHCI.
(in hardware IRQ context)
irq_handler() (drivers/firewire/ohci.c)
->tasklet_schedule()
(in software IRQ context)
handle_it_packet() or handle_ir_packet_per_buffer() (drivers/firewire/ohci.c)
->flush_iso_completions()
->struct fw_iso_context.callback.sc()
= out_stream_callback() or in_stream_callback()

However, we have another chance for packet processing. It's done in PCM
frame handling via ALSA PCM interfaces.
(in process context)
ioctl(i.e. SNDRV_PCM_IOCTL_HWSYNC)
->snd_pcm_hwsync() (sound/core/pcm_native.c)
->snd_pcm_update_hw_ptr() (sound/core/pcm_lib.c)
->snd_pcm_update_hw_ptr0()
->struct snd_pcm_ops.pointer()
= amdtp_stream_pcm_pointer()
->fw_iso_context_flush_completions() (drivers/firewire/core-iso.c)
->struct fw_card_driver.flush_iso_completions()
= ohci_flush_iso_completions() (drivers/firewire/ohci.c)
->flush_iso_completions()
->struct fw_iso_context.callback.sc()
= out_stream_callback() or in_stream_callback()

This design is for a better granularity of PCM pointer. When ioctl(2) is
executed with some commands for ALSA PCM interface, queued packets are
handled at first. Then, the latest number of handled PCM frames is
reported. The number can represent PCM frames transferred in most near
isochronous cycle.

Current tracepoints include no information to distinguish running contexts.
When tracing the interval of software IRQ context, this is not good.

This commit adds more information for current context. Additionally, the
index of packet processed in one context is added in a case that packet
processing is executed in continuous context of the same kind,

As a result, the output includes 11 fields with additional two fields
to commit 0c95c1d6197f ("ALSA: firewire-lib: add tracepoints to dump a part
of isochronous packet data"):
17131.9186: out_packet: 07 7494 ffc0 ffc1 00 000700c0 9001a496 058 45 1 13
17131.9186: out_packet: 07 7495 ffc0 ffc1 00 000700c8 9001ba00 058 46 1 14
17131.9186: out_packet: 07 7496 ffc0 ffc1 00 000700d0 9001ffff 002 47 1 15
17131.9189: out_packet: 07 7497 ffc0 ffc1 00 000700d0 9001d36a 058 00 0 00
17131.9189: out_packet: 07 7498 ffc0 ffc1 00 000700d8 9001e8d4 058 01 0 01
17131.9189: out_packet: 07 7499 ffc0 ffc1 00 000700e0 9001023e 058 02 0 00
17131.9206: in_packet: 07 7447 ffc1 ffc0 01 3f070072 9001783d 058 32 1 00
17131.9206: in_packet: 07 7448 ffc1 ffc0 01 3f070072 90ffffff 002 33 1 01
17131.9206: in_packet: 07 7449 ffc1 ffc0 01 3f07007a 900191a8 058 34 1 02
(Here, some common fields are omitted so that a line is within 80
characters.)

The legend is:
- The second of cycle scheduled for the packet
- The count of cycle scheduled for the packet
- The ID of node as source (hex)
- The ID of node as destination (hex)
- The value of isochronous channel
- The first quadlet of CIP header (hex)
- The second quadlet of CIP header (hex)
- The number of included quadlets
- The index of packet in a buffer maintained by this module
- 0 in process context, 1 in IRQ context
- The index of packet processed in the context

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
/linux-master/drivers/hid/
H A Dhid-uclogic-core.cdiff 7495fb7e Mon Aug 15 08:29:56 MDT 2022 José Expósito <jose.exposito89@gmail.com> HID: uclogic: Add support for Parblo A610 PRO

The Parblo A610 PRO is a UGEE v2 device with a frame with 9 buttons
and a bitmap dial. Its pen has 2 buttons, supports tilt and pressure.

Add its ID in order to support the device.

Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
H A Dhid-uclogic-params.cdiff 7495fb7e Mon Aug 15 08:29:56 MDT 2022 José Expósito <jose.exposito89@gmail.com> HID: uclogic: Add support for Parblo A610 PRO

The Parblo A610 PRO is a UGEE v2 device with a frame with 9 buttons
and a bitmap dial. Its pen has 2 buttons, supports tilt and pressure.

Add its ID in order to support the device.

Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
H A Dhid-ids.hdiff 7495fb7e Mon Aug 15 08:29:56 MDT 2022 José Expósito <jose.exposito89@gmail.com> HID: uclogic: Add support for Parblo A610 PRO

The Parblo A610 PRO is a UGEE v2 device with a frame with 9 buttons
and a bitmap dial. Its pen has 2 buttons, supports tilt and pressure.

Add its ID in order to support the device.

Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
/linux-master/tools/perf/arch/arm/include/
H A Dperf_regs.h7495f374 Wed Sep 25 17:36:36 MDT 2013 Will Deacon <will@kernel.org> ARM: perf: wire up perf_regs and unwind support for ARM

This patch hooks in the perf_regs and libunwind code for ARM.

Cc: Jean Pihet <jean.pihet@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
/linux-master/drivers/usb/common/
H A Dulpi.cdiff 2e3dd4a6 Mon Jan 17 08:00:39 MST 2022 Jon Hunter <jonathanh@nvidia.com> usb: common: ulpi: Fix crash in ulpi_match()

Commit 7495af930835 ("ARM: multi_v7_defconfig: Enable drivers for
DragonBoard 410c") enables the CONFIG_PHY_QCOM_USB_HS for the ARM
multi_v7_defconfig. Enabling this Kconfig is causing the kernel to crash
on the Tegra20 Ventana platform in the ulpi_match() function.

The Qualcomm USB HS PHY driver that is enabled by CONFIG_PHY_QCOM_USB_HS,
registers a ulpi_driver but this driver does not provide an 'id_table',
so when ulpi_match() is called on the Tegra20 Ventana platform, it
crashes when attempting to deference the id_table pointer which is not
valid. The Qualcomm USB HS PHY driver uses device-tree for matching the
ULPI driver with the device and so fix this crash by using device-tree
for matching if the id_table is not valid.

Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20220117150039.44058-1-jonathanh@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
/linux-master/arch/x86/kernel/
H A Daperture_64.cdiff 260133ab Fri Sep 03 10:39:40 MDT 2010 Borislav Petkov <borislav.petkov@amd.com> x86, GART: Disable GART table walk probes

Current code tramples over bit F3x90[6] which can be used to
disable GART table walk probes. However, this bit should be set
for performance reasons (speed up GART table walks). We are
allowed to do that since we put GART tables in UC memory later
anyway. Make it so.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
LKML-Reference: <1283531981-7495-3-git-send-email-bp@amd64.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
diff 57ab43e3 Fri Sep 03 10:39:39 MDT 2010 Borislav Petkov <borislav.petkov@amd.com> x86, GART: Remove superfluous AMD64_GARTEN

There is a GARTEN so use that and drop the duplicate.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
LKML-Reference: <1283531981-7495-2-git-send-email-bp@amd64.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
/linux-master/arch/arm/mach-tegra/
H A DMakefilediff 7495b2eb Mon Mar 18 05:17:34 MDT 2013 Danny Huang <dahuang@nvidia.com> ARM: tegra: add speedo-based process id for Tegra114

Add speedo-based process identification for Tegra114.

Based on the work by: Alex Frid <afrid@nvidia.com>

Signed-off-by: Danny Huang <dahuang@nvidia.com>
[swarren: added include of bug.h]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
/linux-master/kernel/trace/
H A Dtrace_sched_wakeup.cdiff 7495a5be Thu Sep 23 06:00:53 MDT 2010 Jiri Olsa <jolsa@redhat.com> tracing: Graph support for wakeup tracer

Add function graph support for wakeup latency tracer.
The graph output is enabled by setting the 'display-graph'
trace option.

Signed-off-by: Jiri Olsa <jolsa@redhat.com>
LKML-Reference: <1285243253-7372-4-git-send-email-jolsa@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
/linux-master/net/bluetooth/
H A Dhci_sysfs.cdiff 448a496f Mon Sep 19 11:56:59 MDT 2022 Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times

device_add shall not be called multiple times as stated in its
documentation:

'Do not call this routine or device_register() more than once for
any device structure'

Syzkaller reports a bug as follows [1]:
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:33!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
[...]
Call Trace:
<TASK>
__list_add include/linux/list.h:69 [inline]
list_add_tail include/linux/list.h:102 [inline]
kobj_kset_join lib/kobject.c:164 [inline]
kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214
kobject_add_varg lib/kobject.c:358 [inline]
kobject_add+0x150/0x1c0 lib/kobject.c:410
device_add+0x368/0x1e90 drivers/base/core.c:3452
hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53
hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799
hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110
hci_event_func net/bluetooth/hci_event.c:7440 [inline]
hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495
hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007
process_one_work+0x991/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e4/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>

Link: https://syzkaller.appspot.com/bug?id=da3246e2d33afdb92d66bc166a0934c5b146404a
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Hawkins Jiawei <yin31149@gmail.com>
/linux-master/drivers/mmc/host/
H A Dsdhci-esdhc-imx.cdiff 45334ee1 Wed Aug 18 05:16:51 MDT 2021 Haibo Chen <haibo.chen@nxp.com> mmc: sdhci-esdhc-imx: Select the correct mode for auto tuning

USDHC hardware auto tuning circuit support check 1/4/8 data lines and cmd
line. Out of reset uSDHC, it default select check 4 data lines and do not
check cmd line. This is incorrect if we use 8 data lines. So need to config
the auto tuning mode according to current bus width.

Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Link: https://lore.kernel.org/r/1629285415-7495-2-git-send-email-haibo.chen@nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
diff a0dbbdc2 Wed Aug 18 05:16:50 MDT 2021 Haibo Chen <haibo.chen@nxp.com> mmc: sdhci-esdhc-imx: Remove redundant code for manual tuning

For manual tuning method, already call esdhc_prepare_tuning() config the
necessary registers, so remove the redundant code in esdhc_writew_le() for
SDHCI_HOST_CONTROL2.

Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Link: https://lore.kernel.org/r/1629285415-7495-1-git-send-email-haibo.chen@nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
/linux-master/drivers/vfio/pci/
H A Dvfio_pci.cdiff 50173329 Mon Jul 27 13:43:40 MDT 2020 Giovanni Cabiddu <giovanni.cabiddu@intel.com> vfio/pci: Add QAT devices to denylist

The current generation of Intel® QuickAssist Technology devices
are not designed to run in an untrusted environment because of the
following issues reported in the document "Intel® QuickAssist Technology
(Intel® QAT) Software for Linux" (document number 336211-014):

QATE-39220 - GEN - Intel® QAT API submissions with bad addresses that
trigger DMA to invalid or unmapped addresses can cause a
platform hang
QATE-7495 - GEN - An incorrectly formatted request to Intel® QAT can
hang the entire Intel® QAT Endpoint

The document is downloadable from https://01.org/intel-quickassist-technology
at the following link:
https://01.org/sites/default/files/downloads/336211-014-qatforlinux-releasenotes-hwv1.7_0.pdf

This patch adds the following QAT devices to the denylist: DH895XCC,
C3XXX and C62X.

Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
/linux-master/arch/arm/configs/
H A Dmulti_v7_defconfigdiff 7495af93 Sun Dec 12 16:32:50 MST 2021 Stephan Gerhold <stephan@gerhold.net> ARM: multi_v7_defconfig: Enable drivers for DragonBoard 410c

The DragonBoard 410c is mainly supported by the ARM64 architecture
and defconfig, but it can also run well on the ARM32 architecture.
Add the necessary options to the multi_v7_defconfig to simplify
building an ARM32 kernel for DragonBoard 410c.

This is also a possible opportunity to slightly increase CI coverage
for older Qualcomm-based ARM32 platforms that are currently not
represented well in automated CI setups. The APQ8016 SoC used in DB410c
is still quite similar to those. DB410c is already used in some CI systems
so the same hardware could be re-used to get some basic ARM32 boot testing.

When deciding between built-in (y) and module (m), I usually used the
same that is already being used (and functional) in the ARM64 defconfig.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211213113250.4249-2-stephan@gerhold.net
/linux-master/init/
H A Dmain.cdiff f61872bb Fri Feb 07 17:07:37 MST 2020 Steven Rostedt (VMware) <rostedt@goodmis.org> bootconfig: Use parse_args() to find bootconfig and '--'

The current implementation does a naive search of "bootconfig" on the kernel
command line. But this could find "bootconfig" that is part of another
option in quotes (although highly unlikely). But it also needs to find '--'
on the kernel command line to know if it should append a '--' or not when a
bootconfig in the initrd file has an "init" section. The check uses the
naive strstr() to find to see if it exists. But this can return a false
positive if it exists in an option and then the "init" section in the initrd
will not be appended properly.

Using parse_args() to find both of these will solve both of these problems.

Link: https://lore.kernel.org/r/202002070954.C18E7F58B@keescook

Fixes: 7495e0926fdf3 ("bootconfig: Only load bootconfig if "bootconfig" is on the kernel cmdline")
Fixes: 1319916209ce8 ("bootconfig: init: Allow admin to use bootconfig for init command line")
Reported-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
diff 7495e092 Tue Feb 04 05:33:53 MST 2020 Steven Rostedt (VMware) <rostedt@goodmis.org> bootconfig: Only load bootconfig if "bootconfig" is on the kernel cmdline

As the bootconfig is appended to the initrd it is not as easy to modify as
the kernel command line. If there's some issue with the kernel, and the
developer wants to boot a pristine kernel, it should not be needed to modify
the initrd to remove the bootconfig for a single boot.

As bootconfig is silently added (if the admin does not know where to look
they may not know it's being loaded). It should be explicitly added to the
kernel cmdline. The loading of the bootconfig is only done if "bootconfig"
is on the kernel command line. This will let admins know that the kernel
command line is extended.

Note, after adding printk()s for when the size is too great or the checksum
is wrong, exposed that the current method always looked for the boot config,
and if this size and checksum matched, it would parse it (as if either is
wrong a printk has been added to show this). It's better to only check this
if the boot config is asked to be looked for.

Link: https://lore.kernel.org/r/CAHk-=wjfjO+h6bQzrTf=YCZA53Y3EDyAs3Z4gEsT7icA3u_Psw@mail.gmail.com

Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
/linux-master/virt/kvm/
H A Dkvm_main.cdiff 1f03b2bc Fri Feb 07 09:34:10 MST 2020 Marc Zyngier <maz@kernel.org> KVM: Disable preemption in kvm_get_running_vcpu()

Accessing a per-cpu variable only makes sense when preemption is
disabled (and the kernel does check this when the right debug options
are switched on).

For kvm_get_running_vcpu(), it is fine to return the value after
re-enabling preemption, as the preempt notifiers will make sure that
this is kept consistent across task migration (the comment above the
function hints at it, but lacks the crucial preemption management).

While we're at it, move the comment from the ARM code, which explains
why the whole thing works.

Fixes: 7495e22bb165 ("KVM: Move running VCPU from ARM to common code").
Cc: Paolo Bonzini <pbonzini@redhat.com>
Reported-by: Zenghui Yu <yuzenghui@huawei.com>
Tested-by: Zenghui Yu <yuzenghui@huawei.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/318984f6-bc36-33a3-abc6-bf2295974b06@huawei.com
Message-id: <20200207163410.31276-1-maz@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
diff 7495e22b Thu Jan 09 07:57:19 MST 2020 Paolo Bonzini <pbonzini@redhat.com> KVM: Move running VCPU from ARM to common code

For ring-based dirty log tracking, it will be more efficient to account
writes during schedule-out or schedule-in to the currently running VCPU.
We would like to do it even if the write doesn't use the current VCPU's
address space, as is the case for cached writes (see commit 4e335d9e7ddb,
"Revert "KVM: Support vCPU-based gfn->hva cache"", 2017-05-02).

Therefore, add a mechanism to track the currently-loaded kvm_vcpu struct.
There is already something similar in KVM/ARM; one important difference
is that kvm_arch_vcpu_{load,put} have two callers in virt/kvm/kvm_main.c:
we have to update both the architecture-independent vcpu_{load,put} and
the preempt notifiers.

Another change made in the process is to allow using kvm_get_running_vcpu()
in preemptible code. This is allowed because preempt notifiers ensure
that the value does not change even after the VCPU thread is migrated.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
/linux-master/arch/arm64/include/asm/
H A Dkvm_host.hdiff 7495e22b Thu Jan 09 07:57:19 MST 2020 Paolo Bonzini <pbonzini@redhat.com> KVM: Move running VCPU from ARM to common code

For ring-based dirty log tracking, it will be more efficient to account
writes during schedule-out or schedule-in to the currently running VCPU.
We would like to do it even if the write doesn't use the current VCPU's
address space, as is the case for cached writes (see commit 4e335d9e7ddb,
"Revert "KVM: Support vCPU-based gfn->hva cache"", 2017-05-02).

Therefore, add a mechanism to track the currently-loaded kvm_vcpu struct.
There is already something similar in KVM/ARM; one important difference
is that kvm_arch_vcpu_{load,put} have two callers in virt/kvm/kvm_main.c:
we have to update both the architecture-independent vcpu_{load,put} and
the preempt notifiers.

Another change made in the process is to allow using kvm_get_running_vcpu()
in preemptible code. This is allowed because preempt notifiers ensure
that the value does not change even after the VCPU thread is migrated.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
/linux-master/include/linux/
H A Dkvm_host.hdiff 7495e22b Thu Jan 09 07:57:19 MST 2020 Paolo Bonzini <pbonzini@redhat.com> KVM: Move running VCPU from ARM to common code

For ring-based dirty log tracking, it will be more efficient to account
writes during schedule-out or schedule-in to the currently running VCPU.
We would like to do it even if the write doesn't use the current VCPU's
address space, as is the case for cached writes (see commit 4e335d9e7ddb,
"Revert "KVM: Support vCPU-based gfn->hva cache"", 2017-05-02).

Therefore, add a mechanism to track the currently-loaded kvm_vcpu struct.
There is already something similar in KVM/ARM; one important difference
is that kvm_arch_vcpu_{load,put} have two callers in virt/kvm/kvm_main.c:
we have to update both the architecture-independent vcpu_{load,put} and
the preempt notifiers.

Another change made in the process is to allow using kvm_get_running_vcpu()
in preemptible code. This is allowed because preempt notifiers ensure
that the value does not change even after the VCPU thread is migrated.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Completed in 1598 milliseconds