On Mon, Nov 16, 2020 at 12:38 PM Steven Rostedt wrote:
>
> On Mon, 16 Nov 2020 12:10:10 -0800
> Sami Tolvanen wrote:
>
> > On Mon, Nov 16, 2020 at 8:39 AM Steven Rostedt wrote:
> > >
> > > On Fri, 13 Nov 2020 10:34:14 -0800
> > > Sami Tolvanen wrote:
> > >
> > > > my_tramp[12]? are declared as
On 11/14/20 8:01 PM, Hillf Danton wrote:
> On Fri, 13 Nov 2020 00:01:22 +0200 Jarkko Sakkinen wrote:
> +
> +static unsigned long sgx_get_unmapped_area(struct file *file,
> +unsigned long addr,
> +unsigned long len,
> +
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 23d67a54857a768acdb0804cdd6037c324a50ecd
Gitweb:
https://git.kernel.org/tip/23d67a54857a768acdb0804cdd6037c324a50ecd
Author:Gabriel Krisman Bertazi
AuthorDate:Mon, 16 Nov 2020 12:42:00
James
Thanks for taking the time to review this and the pointers.
On 11/11/20 10:11 AM, James Morse wrote:
Hi Henry,
On 06/11/2020 23:25, Henry Willard wrote:
machine_shutdown() is called by kernel_kexec() to shutdown
the non-boot CPUs prior to starting the new kernel. The
implementation of
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 3136b93c3fb2b7c19e853e049203ff8f2b9dd2cd
Gitweb:
https://git.kernel.org/tip/3136b93c3fb2b7c19e853e049203ff8f2b9dd2cd
Author:Gabriel Krisman Bertazi
AuthorDate:Mon, 16 Nov 2020 12:41:58
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 524666cb5de7c38a1925e7401a6e59d68682dd8c
Gitweb:
https://git.kernel.org/tip/524666cb5de7c38a1925e7401a6e59d68682dd8c
Author:Gabriel Krisman Bertazi
AuthorDate:Mon, 16 Nov 2020 12:42:01
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 64eb35f701f04b30706e21d1b02636b5d31a37d2
Gitweb:
https://git.kernel.org/tip/64eb35f701f04b30706e21d1b02636b5d31a37d2
Author:Gabriel Krisman Bertazi
AuthorDate:Mon, 16 Nov 2020 12:42:03
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 51af3f23063946344330a77a7d1dece6fc6bb5d8
Gitweb:
https://git.kernel.org/tip/51af3f23063946344330a77a7d1dece6fc6bb5d8
Author:Gabriel Krisman Bertazi
AuthorDate:Mon, 16 Nov 2020 12:42:06
On Nov 16 2020, Nick Desaulniers wrote:
> A lot of VDSO's reset KBUILD_CFLAGS or use a new variable for their
> compiler flags. As such, they're missing `-include` command line flag
> that injects include/linux/compiler_types.h,
It's not missing here.
Andreas.
--
Andreas Schwab,
On Mon, 16 Nov 2020 12:55:29 -0800
Peiyong Lin wrote:
> Hi there,
>
> May I ask whether the merge window has passed? If so is it possible to
> ask for a review?
This is up to the maintainers of power management to accept this.
Rafael?
-- Steve
On Mon, 16 Nov 2020 16:02:18 -0500
Steven Rostedt wrote:
> + if (new) {
> + for (i = 0; old[i].func; i++)
> + if (old[i].func != tp_func->func
> + || old[i].data != tp_func->data)
> +
Write buffers use a kmalloc()'ed buffer, they can leak
up to seven bytes of kernel memory to flash if writes are not
aligned.
So use ubifs_pad() to fill these gaps with padding bytes.
This was never a problem while scanning because the scanner logic
manually aligns node lengths and skips over
On Wed, Nov 11, 2020 at 02:36:07PM +0100, Linus Walleij wrote:
> On Wed, Nov 11, 2020 at 1:33 PM Mark Brown wrote:
> > On Wed, Nov 11, 2020 at 02:05:19AM +0100, Linus Walleij wrote:
> > This is not clear to me, most of these settings are things that are
> > constant for the device so it's not
From: Mike Rapoport
Signed-off-by: Mike Rapoport
Cowritten-by: Alejandro Colomar
Acked-by: Alejandro Colomar
Signed-off-by: Alejandro Colomar
---
Hi Mike,
I added that note about not having a wrapper,
fixed a few minor formatting and wording issues,
and sorted ERRORS alphabetically.
On Mon, Nov 16, 2020 at 07:37:52PM +0100, Florian Lehner wrote:
> bpf handlers for perf events other than tracepoints, kprobes or uprobes
> are attached to the overflow_handler of the perf event.
>
> Perf events of type software/dummy are placeholder events. So when
> attaching a bpf handle to an
On Mon, 16 Nov 2020 15:44:37 -0500
Steven Rostedt wrote:
> If you use a stub function, it shouldn't affect anything. And the worse
> that would happen is that you have a slight overhead of calling the stub
> until you can properly remove the callback.
Something like this:
(haven't compiled it
On Mon, 2020-11-16 at 13:23 -0600, Bjorn Helgaas wrote:
> On Mon, Nov 16, 2020 at 06:53:09PM +0100, Rafael J. Wysocki wrote:
> > On Wed, Oct 7, 2020 at 7:10 PM Bjorn Helgaas
> > wrote:
> > > On Wed, Oct 07, 2020 at 06:53:16PM +0200, Rafael J. Wysocki
> > > wrote:
> > > > On Wed, Oct 7, 2020 at
On Sun, Nov 15, 2020 at 01:43:04PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Changelog:
> v1:
> * Added patch for raw QP
> * Fixed commit messages
> v0: https://lore.kernel.org/lkml/20201026132635.1337663-1-l...@kernel.org
>
> -
> >From Jason:
>
> Move
Hi Mani,
On 2020-11-16 04:43, Manivannan Sadhasivam wrote:
On Wed, Nov 11, 2020 at 11:21:10AM -0800, Bhaumik Bhatt wrote:
Some MHI client drivers may want to request a pause or halt of
data transfer activity on their channels. Support for this does
not exist and must be introduced, wherein the
On Thu, Oct 22, 2020 at 10:34 AM Peiyong Lin wrote:
>
> Historically there is no common trace event for GPU frequency, in
> downstream Android each different hardware vendor implements their own
> way to expose GPU frequency, for example as a debugfs node. This patch
> standardize it as a common
On Mon, Nov 16, 2020 at 02:27:12PM -0600, Scott Wood wrote:
> On Fri, 2020-11-13 at 18:50 -0600, Segher Boessenkool wrote:
> > All the others work fine (and are needed afaics), it is only -me200 that
> > doesn't exist (in mainline binutils). Perhaps -me5500 will work for it
> > instead.
>
>
Huh-could have sworn I had reviewed this one already.
Reviewed-by: Lyude Paul
On Mon, 2020-11-16 at 17:40 +, Lee Jones wrote:
> The stack is too full.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c: In function
>
On Mon, Nov 16, 2020 at 12:41 PM Lee Jones wrote:
>
> Also removing the call to
> amdgpu_atombios_encoder_get_backlight_level_from_reg()
> since, according to Alex Deucher, "We call it again below indirectly".
>
> Fixes the following W=1 kernel build warning(s):
>
>
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_prime.c:43:24: warning: no previous prototype
> for ‘radeon_gem_prime_import_sg_table’ [-Wmissing-prototypes]
> 43 | struct drm_gem_object
On 11/15/20 9:17 AM, Greg Kroah-Hartman wrote:
> On Sun, Nov 15, 2020 at 03:53:16PM +0100, Emmanouil Perselis wrote:
>> This patch fixes the warning "static const char * array should
>> probably be static const char * const" in
>> drivers/staging/greybus/audio_manager_module.c
>> I think Greg's
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/r600_hdmi.c:177:6: warning: no previous prototype for
> ‘r600_hdmi_update_acr’ [-Wmissing-prototypes]
> 177 | void r600_hdmi_update_acr(struct drm_encoder *encoder,
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/r600_cs.c:2343:5: warning: no previous prototype for
> ‘r600_dma_cs_next_reloc’ [-Wmissing-prototypes]
> 2343 | int r600_dma_cs_next_reloc(struct radeon_cs_parser
Forward the following PSCI SMCs issued by host to EL3 as they do not
require the hypervisor's intervention. This assumes that EL3 correctly
implements the PSCI specification.
Only function IDs implemented in Linux are included.
Where both 32-bit and 64-bit variants exist, it is assumed that the
Small refactor so that nVHE's handle_trap uses a switch on the Exception
Class value of ESR_EL2 in preparation for adding a handler of SMC32/64.
Signed-off-by: David Brazdil
---
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git
On Mon, 16 Nov 2020 15:37:27 -0500 (EST)
Mathieu Desnoyers wrote:
> >
> > Mathieu,
> >
> > Can't we do something that would still allow to unregister a probe even if
> > a new probe array fails to allocate? We could kick off a irq work to try to
> > clean up the probe at a later time, but
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/vce_v2_0.c:111:6: warning: no previous prototype for
> ‘vce_v2_0_enable_mgcg’ [-Wmissing-prototypes]
> 111 | void vce_v2_0_enable_mgcg(struct radeon_device *rdev,
On Sun, Nov 15, 2020 at 12:43 AM Tony Lindgren wrote:
>
> * Tim Harvey [201113 22:07]:
> > 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack registers")
> > appears to not only add the new clear_ack case it also attempts to
> > resolve the long standing ack_invert issue with this change:
> >
On Mon, 2020-11-16 at 14:52 +0530, Srinivasan Raju wrote:
> This introduces the pureLiFi LiFi driver for LiFi-X, LiFi-XC
> and LiFi-XL USB devices.
>
> This driver implementation has been based on the zd1211rw driver.
>
> Driver is based on 802.11 softMAC Architecture and uses
> native 802.11
In preparation for adding a CPU entry point in nVHE hyp code, extract
most of __do_hyp_init hypervisor initialization code into a common
helper function. This will be invoked by the entry point to install KVM
on the newly booted CPU.
Signed-off-by: David Brazdil
---
KVM by default keeps the stub vector installed and installs the nVHE
vector only briefly for init and later on demand. Change this policy
to install the vector at init and then never uninstall it if the kernel
was given the protected KVM command line parameter.
Signed-off-by: David Brazdil
---
CPU index should never be negative. Change the signature of
(set_)cpu_logical_map to take an unsigned int.
Signed-off-by: David Brazdil
---
arch/arm64/include/asm/smp.h | 4 ++--
arch/arm64/kernel/setup.c| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
When the a CPU is booted in EL2, the kernel checks for VHE support and
initializes the CPU core accordingly. For nVHE it also installs the stub
vectors and drops down to EL1.
Once KVM gains the ability to boot cores without going through the
kernel entry point, it will need to initialize the CPU
On Mon, 2020-11-16 at 23:09 +1100, Michael Ellerman wrote:
> Currently a build with CONFIG_E200=y will fail with:
>
> Error: invalid switch -me200
> Error: unrecognized option -me200
>
> Upstream binutils has never supported an -me200 option. Presumably it
> was supported at some point by
With protected nVHE hyp code interception host's PSCI CPU_ON/SUSPEND
SMCs, the host starts seeing new CPUs boot in EL1 instead of EL2. The
kernel logic that keeps track of the boot mode needs to be adjusted.
Add a static key enabled if KVM protected nVHE initialization is
successful.
When the
KVM currently initializes MAIR_EL2 to the value of MAIR_EL1. In
preparation for initializing MAIR_EL2 before MAIR_EL1, move the constant
into a shared header file. Since it is used for EL1 and EL2, rename to
MAIR_ELx_SET.
Signed-off-by: David Brazdil
---
arch/arm64/include/asm/memory.h | 29
When nVHE hyp starts interception host's PSCI CPU_ON SMCs, it will need
to install KVM on the newly booted CPU before returning to the host. Add
an entry point which expects the same kvm_nvhe_init_params struct as the
__kvm_hyp_init HVC in the CPU_ON context argument (x0).
The entry point
Once we start initializing KVM on newly booted cores before the rest of
the kernel, parameters to __do_hyp_init will need to be provided by EL2
rather than EL1. At that point it will not be possible to pass its four
arguments directly because PSCI_CPU_ON only supports one context
argument.
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/vce_v1_0.c:102:6: warning: no previous prototype for
> ‘vce_v1_0_enable_mgcg’ [-Wmissing-prototypes]
> 102 | void vce_v1_0_enable_mgcg(struct radeon_device *rdev,
All nVHE hyp code is currently executed as handlers of host's HVCs. This
will change as nVHE starts intercepting host's PSCI CPU_ON SMCs. The
newly booted CPU will need to initialize EL2 state and then enter the
host. Add __host_enter function that branches into the existing
host state-restoring
Add handler of host SMCs in KVM nVHE trap handler. Forward all SMCs to
EL3 and propagate the result back to EL1. This is done in preparation
for validating host SMCs in KVM nVHE protected mode.
The implementation assumes that firmware uses SMCCC v1.2 or older. That
means x0-x17 can be used both
Add a handler of PSCI SMCs in nVHE hyp code. The handler is initialized
with the version used by the host's PSCI driver and the function IDs it
was configured with. If the SMC function ID matches one of the
configured PSCI calls (for v0.1) or falls into the PSCI function ID
range (for v0.2+), the
While protected nVHE KVM is installed, start trapping all host SMCs.
By default, these are simply forwarded to EL3, but PSCI SMCs are
validated first.
Create new constant HCR_HOST_NVHE_PROTECTED_FLAGS with the new set of HCR
flags to use while the nVHE vector is installed when the kernel was
Add an early parameter that allows users to opt into protected KVM mode
when using the nVHE hypervisor. In this mode, guest state will be kept
private from the host. This will primarily involve enabling stage-2
address translation for the host, restricting DMA to host memory, and
filtering host
On Mon, Nov 16, 2020 at 10:59 AM Mark Brown wrote:
>
> On Fri, Nov 13, 2020 at 02:06:29PM -0800, Tim Harvey wrote:
>
> > asserted? I'm also wondering if my issue is that I currently have the
> > interrupt registered as such:
>
> > ret = devm_regmap_add_irq_chip(dev, gsc->regmap, client->irq,
> >
As we progress towards being able to keep guest state private to the
host running nVHE hypervisor, this series allows the hypervisor to
install itself on newly booted CPUs before the host is allowed to run
on them.
All functionality described below is opt-in, guarded by an early param
Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
Expose the array holding the information with a read-only accessor.
Signed-off-by: David Brazdil
---
drivers/firmware/psci/psci.c | 14 ++
Add a handler of CPU_SUSPEND host PSCI SMCs. The SMC can either enter
a sleep state indistinguishable from a WFI or a deeper sleep state that
behaves like a CPU_OFF+CPU_ON.
The handler saves r0,pc of the host and makes the same call to EL3 with
the hyp CPU entry point. It either returns back to
MAIR_EL2 is currently initialized to the value of MAIR_EL1, which itself
is set to a constant MAIR_ELx_SET.
Initialize MAIR_EL2 to MAIR_ELx_SET directly in preparation of allowing
KVM to start CPU cores itself and not initializing itself before ERETing
to EL1. In that case, MAIR_EL2 will be
KVM's host PSCI SMC filter needs to be aware of the PSCI version of the
system but currently it is impossible to distinguish between v0.1 and
PSCI disabled because both have get_version == NULL.
Populate get_version for v0.1 with a function that returns a constant.
psci_opt.get_version is
On Fri, 2020-11-13 at 18:50 -0600, Segher Boessenkool wrote:
> On Fri, Nov 13, 2020 at 04:37:38PM -0800, Fāng-ruì Sòng wrote:
> > On Fri, Nov 13, 2020 at 4:23 PM Segher Boessenkool
> > wrote:
> > > On Fri, Nov 13, 2020 at 12:14:18PM -0800, Nick Desaulniers wrote:
> > > > > > > Error: invalid
Add a handler of the CPU_ON PSCI call from host. When invoked, it looks
up the logical CPU ID corresponding to the provided MPIDR and populates
the state struct of the target CPU with the provided x0, pc. It then
calls CPU_ON itself, with an entry point in hyp that initializes EL2
state before
Add a host-initialized constant to KVM nVHE hyp code for converting
between EL2 linear map virtual addresses and physical addresses.
Also add `__hyp_pa` macro that performs the conversion.
Signed-off-by: David Brazdil
---
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 3 +++
arch/arm64/kvm/va_layout.c
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/cik_sdma.c:331:6: warning: no previous prototype for
> ‘cik_sdma_enable’ [-Wmissing-prototypes]
> 331 | void cik_sdma_enable(struct radeon_device *rdev, bool
When KVM starts validating host's PSCI requests, it will need to map
MPIDR back to the CPU ID. To this end, copy cpu_logical_map into nVHE
hyp memory when KVM is initialized.
Only copy the information for CPUs that are online at the point of KVM
initialization so that KVM rejects CPUs whose
When compiling with __KVM_NVHE_HYPERVISOR__ redefine per_cpu_offset() to
__hyp_per_cpu_offset() which looks up the base of the nVHE per-CPU
region of the given cpu and computes its offset from the
.hyp.data..percpu section.
This enables use of per_cpu_ptr() helpers in nVHE hyp code. Until now
Add rules for renaming the .data..ro_after_init ELF section in KVM nVHE
object files to .hyp.data..ro_after_init, linking it into the kernel
and mapping it in hyp at runtime.
The section is RW to the host, then mapped RO in hyp. The expectation is
that the host populates the variables in the
On Mon, 2020-11-16 at 21:33 +0100, Samuel Thibault wrote:
> Ben Hutchings, le lun. 16 nov. 2020 19:51:23 +, a ecrit:
> > On Mon, 2020-11-16 at 20:01 +0100, Samuel Thibault wrote:
> > > Perhaps we should rather use
> > >
> > > depends on ISA || (X86 && COMPILE_TEST)
> > >
> > > ?
> > > so
[REQUEST]
Thanks Rob for reviewing the dt patches.
Would it be possible for the maintainers and reviewers to review the code as
well?
[COVER LETTER]
Add support to enable VBUS detection in the pm8941 extcon driver.
Changes from v5:
- Gathered Rob H's Acked-by for the dt-bindings patch.
On Mon, 16 Nov 2020 12:10:10 -0800
Sami Tolvanen wrote:
> On Mon, Nov 16, 2020 at 8:39 AM Steven Rostedt wrote:
> >
> > On Fri, 13 Nov 2020 10:34:14 -0800
> > Sami Tolvanen wrote:
> >
> > > my_tramp[12]? are declared as global functions in C, but they are not
> > > marked global in the
Add interrupt support for reporting VBUS detection status that can be
detected via a dedicated PMIC pin.
Signed-off-by: Anirudh Ghayal
Signed-off-by: Guru Das Srinagesh
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml | 5 -
1 file changed, 4
Convert bindings from txt to YAML.
Signed-off-by: Guru Das Srinagesh
Reviewed-by: Rob Herring
---
.../bindings/extcon/qcom,pm8941-misc.txt | 41 ---
.../bindings/extcon/qcom,pm8941-misc.yaml | 59 ++
2 files changed, 59 insertions(+), 41
From: Anirudh Ghayal
VBUS can be detected via a dedicated PMIC pin. Add support
for reporting the VBUS status.
Signed-off-by: Anirudh Ghayal
Signed-off-by: Kavya Nunna
Signed-off-by: Guru Das Srinagesh
---
drivers/extcon/extcon-qcom-spmi-misc.c | 99 +++---
1
On Mon, Nov 16 2020 at 14:02, Jason Gunthorpe wrote:
> On Mon, Nov 16, 2020 at 06:56:33PM +0100, Thomas Gleixner wrote:
>> On Mon, Nov 16 2020 at 11:46, Jason Gunthorpe wrote:
>>
>> > On Mon, Nov 16, 2020 at 07:31:49AM +, Tian, Kevin wrote:
>> >
>> >> > The subdevices require PASID & IOMMU in
On Mon, 16 Nov 2020 13:29:29 -0700
Jonathan Corbet wrote:
> > Would something like the below work? I think I fixed the other places with
> > issues and for consistency, replaced the ".. code-block:: c" with just "::"
> > usage throughout the file.
>
> That will work. It will also have the
Ira,
On Mon, Nov 16 2020 at 10:49, Ira Weiny wrote:
> On Sun, Nov 15, 2020 at 07:58:52PM +0100, Thomas Gleixner wrote:
>> > Currently struct irqentry_state_t only contains a single bool value
>> > which makes passing it by value is reasonable. However, future patches
>> > propose to add
- On Nov 16, 2020, at 12:19 PM, rostedt rost...@goodmis.org wrote:
> On Sat, 14 Nov 2020 21:52:55 -0800
> Matt Mullins wrote:
>
>> bpf_link_free is always called in process context, including from a
>> workqueue and from __fput. Neither of these have the ability to
>> propagate an -ENOMEM
Am 16.11.20 um 18:41 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_tt.c:45: warning: Function parameter or member 'bo'
not described in 'ttm_tt_create'
drivers/gpu/drm/ttm/ttm_tt.c:45: warning: Function parameter or member
'zero_alloc' not
Am 16.11.20 um 18:41 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_range_manager.c:46: warning: cannot understand
function prototype: 'struct ttm_range_manager '
Cc: Christian Koenig
Cc: Huang Rui
Cc: David Airlie
Cc: Daniel Vetter
Cc:
Ben Hutchings, le lun. 16 nov. 2020 19:51:23 +, a ecrit:
> On Mon, 2020-11-16 at 20:01 +0100, Samuel Thibault wrote:
> > Perhaps we should rather use
> >
> > depends on ISA || (X86 && COMPILE_TEST)
> >
> > ?
> > so that we have compile testing on x86 only (where the inb/outb macros
> >
Am 16.11.20 um 18:41 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_bo.c:51: warning: Function parameter or member
'ttm_global_mutex' not described in 'DEFINE_MUTEX'
drivers/gpu/drm/ttm/ttm_bo.c:286: warning: Function parameter or member 'bo'
First of all, thanks everybody for the great insights/discussion! This
thread ended-up being a great learning for (at least) me.
Given the big amount of replies and intermixed comments, I wouldn't be
able to respond inline to all, so I'll try another approach below.
>From Bjorn:
"I think [0]
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/si_dpm.c:3802:4: warning: no previous prototype for
> ‘si_get_ddr3_mclk_frequency_ratio’ [-Wmissing-prototypes]
> 3802 | u8 si_get_ddr3_mclk_frequency_ratio(u32
On Mon, Nov 16, 2020 at 11:55 AM Allan, Bruce W wrote:
>
> > -Original Message-
> > From: Song Liu
> > Sent: Tuesday, November 10, 2020 5:05 PM
> > To: Andrii Nakryiko
> > Cc: bpf ; Networking ;
> > Starovoitov, Alexei ; Daniel Borkmann ;
> > Kernel Team ; open list >
On Mon, Nov 16, 2020 at 12:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/si.c:5678:5: warning: no previous prototype for
> ‘si_get_csb_size’ [-Wmissing-prototypes]
> 5678 | u32 si_get_csb_size(struct radeon_device *rdev)
> |
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/cik.c:4845:5: warning: no previous prototype for
> ‘cik_gpu_check_soft_reset’ [-Wmissing-prototypes]
> 4845 | u32 cik_gpu_check_soft_reset(struct radeon_device
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/cik.c:6413:6: warning: no previous prototype for
> ‘cik_init_cp_pg_table’ [-Wmissing-prototypes]
> 6413 | void cik_init_cp_pg_table(struct radeon_device *rdev)
> |
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/si.c:4186:6: warning: no previous prototype for
> ‘si_vram_gtt_location’ [-Wmissing-prototypes]
> 4186 | void si_vram_gtt_location(struct radeon_device *rdev,
> |
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/rv770_dpm.c:62:30: warning: no previous prototype for
> ‘evergreen_get_pi’ [-Wmissing-prototypes]
> 62 | struct evergreen_power_info *evergreen_get_pi(struct
On Mon, 16 Nov 2020 15:25:52 -0500
Steven Rostedt wrote:
> On Mon, 16 Nov 2020 12:24:32 -0700
> Jonathan Corbet wrote:
>
> > The problem is those literal blocks. The easiest fix will be to just use
> > the double-colon notation to indicate a literal block, so the paragraph
> > above would end
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/dce6_afmt.c:32:5: warning: no previous prototype for
> ‘dce6_endpoint_rreg’ [-Wmissing-prototypes]
> 32 | u32 dce6_endpoint_rreg(struct radeon_device *rdev,
> |
On Mon, 2020-11-16 at 20:01 +0100, Samuel Thibault wrote:
> Hello Ben,
>
> A long time ago you added a dependency for speakup drivers on
> CONFIG_ISA, and you also added || COMPILE_TEST as an alternative.
>
> It seems that some platform portability tests then think they should
> be able to build
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/si.c:3768:5: warning: no previous prototype for
> ‘si_gpu_check_soft_reset’ [-Wmissing-prototypes]
> 3768 | u32 si_gpu_check_soft_reset(struct radeon_device *rdev)
On Mon, 16 Nov 2020 12:24:32 -0700
Jonathan Corbet wrote:
> The problem is those literal blocks. The easiest fix will be to just use
> the double-colon notation to indicate a literal block, so the paragraph
> above would end with "...start your code with::". Note that there's a few
> of them
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 1eb0616c2df5b78c301eaa7bd2ee859f43915001
Gitweb:
https://git.kernel.org/tip/1eb0616c2df5b78c301eaa7bd2ee859f43915001
Author:Thomas Gleixner
AuthorDate:Mon, 16 Nov 2020 11:32:53 -08:00
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/cik.c:1868:5: warning: no previous prototype for
> ‘ci_mc_load_microcode’ [-Wmissing-prototypes]
> 1868 | int ci_mc_load_microcode(struct radeon_device *rdev)
> |
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/si.c:1570:5: warning: no previous prototype for
> ‘si_mc_load_microcode’ [-Wmissing-prototypes]
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: David Airlie
>
On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote:
> Deferring CR3 switch to C code means that we need to run more of the
> kernel entry code with the user page-table. To do so, we need to:
>
> - map more syscall, interrupt and exception entry code into the user
>page-table
On Mon, Nov 16, 2020 at 12:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/atombios_encoders.c:186:6: warning: no previous
> prototype for ‘radeon_atom_backlight_init’ [-Wmissing-prototypes]
> 186 | void radeon_atom_backlight_init(struct
On 11/16/20 8:48 PM, Andy Lutomirski wrote:
On Mon, Nov 16, 2020 at 6:49 AM Alexandre Chartre
wrote:
Extend PTI user mappings so that more kernel entry code can be executed
with the user page-table. To do so, we need to map syscall and interrupt
entry code, per cpu offsets
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/evergreen.c:4380:5: warning: no previous prototype
> for ‘evergreen_rlc_resume’ [-Wmissing-prototypes]
> 4380 | int evergreen_rlc_resume(struct radeon_device *rdev)
On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote:
> This RFC proposes to defer the PTI CR3 switch until we reach C code.
> The benefit is that this simplifies the assembly entry code, and make
> the PTI CR3 switch code easier to understand. This also paves the way
> for further
On Mon, Nov 16, 2020 at 12:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/atombios_encoders.c:2721:1: warning: no previous
> prototype for ‘radeon_add_atom_encoder’ [-Wmissing-prototypes]
> 2721 | radeon_add_atom_encoder(struct drm_device
On Mon, Nov 16, 2020 at 12:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/ni.c:1733:5: warning: no previous prototype for
> ‘cayman_gpu_check_soft_reset’ [-Wmissing-prototypes]
> 1733 | u32 cayman_gpu_check_soft_reset(struct radeon_device
On Mon, Nov 16 2020 at 11:32, Max Filippov wrote:
> From: Thomas Gleixner
>
> The conversion to the generic kmap_atomic() implementation missed the fact
> that xtensa's fixmap works bottom up while all other implementations work
> top down. There is no real reason why xtensa needs to work that
On Mon, Nov 16, 2020 at 6:01 AM Martin Schiller wrote:
>
> This makes it possible to handle carrier loss and detection.
> In case of Carrier Loss, layer 2 is terminated
> In case of Carrier Detection, we start timer t1 on a DCE interface,
> and on a DTE interface we change to state LAPB_STATE_1
501 - 600 of 1780 matches
Mail list logo
