From: Yazen Ghannam
Some systems may report spurious MCA errors. In general, spurious MCA
errors may be disabled by clearing a particular bit in MCA_CTL. However,
clearing a bit in MCA_CTL may not be recommended for some errors, so the
only option is to ignore them.
An MCA error is printed and
From: Yazen Ghannam
There are two groups of "ifdef CONFIG_X86_MCE_AMD" function prototypes
in .
Merge these two groups.
No functional change.
Signed-off-by: Yazen Ghannam
---
v2->v3
* This patch is new and unrelated to the other two. I just happened to
notice this issue when making other
Hi Andy,
> > > - It will make it quite unpleasant to call into an enclave in a
> > > coroutine depending on how the host untrusted runtime implements
> > > coroutines.
> >
> > I'm not sure what you are referring to by "coroutine". But this vDSO
> API will be (expected to be) the only routine
From: Yazen Ghannam
AMD Family 17h Models 10h-2Fh may report a high number of L1 BTB MCA
errors under certain conditions. The errors are benign and can safely be
ignored. However, the high error rate may cause the MCA threshold
counter to overflow causing a high rate of thresholding interrupts.
From: Yazen Ghannam
The show_cppc_data macro implicity uses define_one_cppc_ro. This will
prevent the creation of an attribute with read and write permissions.
Create a separate macro that defines a show attribute and creates
a read-only sysfs entry. This is in preparation for adding a macro
to
From: Yazen Ghannam
The cppc_set_perf() currently only works for DESIRED_PERF. To make it
generic, pass in the index of the register being accessed.
Also, rename cppc_set_perf() to cppc_set_reg(). This is in preparation
for it to be used for more than just the DESIRED_PERF register.
From: Yazen Ghannam
Newer AMD processors support a subset of the optional CPPC registers.
Create show, store and helper routines for supported CPPC registers.
Signed-off-by: Yazen Ghannam
[ carved out into a patch, cleaned up, productized ]
Signed-off-by: Janakarajan Natarajan
---
CPPC (Collaborative Processor Performance Control) offers optional
registers which can be used to tune the system based on energy and/or
performance requirements.
Newer AMD processors add support for a subset of these optional CPPC
registers, based on ACPI v6.1.
The following are the supported
From: Yazen Ghannam
To enable CPPC on a processor, the OS should write a value "1" to the
CPPC Enable register. Add support for this register.
Signed-off-by: Yazen Ghannam
[ carved out into a patch, cleaned up, productized ]
Signed-off-by: Janakarajan Natarajan
---
drivers/acpi/cppc_acpi.c |
From: Yazen Ghannam
Some CPPC registers can be used to configure the platform. To enable this,
create macros to define the show, store routines and create sysfs entries
with R/W permission.
Signed-off-by: Yazen Ghannam
[ carved into a patch, cleaned up, productized ]
Signed-off-by: Janakarajan
Add attributes for registers that are supported by the platform. This prevents
unsupported optional registers from having sysfs entries created.
Signed-off-by: Janakarajan Natarajan
---
drivers/acpi/cppc_acpi.c | 70
1 file changed, 56 insertions(+), 14
stable-rc/linux-3.18.y boot: 26 boots: 1 failed, 24 passed with 1
untried/unknown (v3.18.136-135-g0ec48545fd19)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.18.136-135-g0ec48545fd19/
Full Build Summary:
On Fri, Mar 22, 2019 at 10:14 AM Arnd Bergmann wrote:
> clang correctly points out a code path that would lead
> to an uninitialized variable use:
>
> security/selinux/netlabel.c:310:6: error: variable 'addr' is used
> uninitialized whenever 'if' condition is false
>
kobj_type currently uses a list of individual attributes to store
default attributes. Attribute groups are more flexible than a list of
attributes because groups provide support for attribute visibility. So,
add support for default attribute groups to kobj_type.
In future patches, the existing
On 2/12/19 2:42 PM, Mathieu Desnoyers wrote:
When available, use the cpu_id field from __rseq_abi on Linux to
implement sched_getcpu(). Fall-back on the vgetcpu vDSO if unavailable.
Benchmarks:
x86-64: Intel E5-2630 v3@2.40GHz, 16-core, hyperthreading
This patch looks good to me for master,
On Fri, 22 Mar 2019 16:03:07 + Chris Down wrote:
> This patch is an incremental improvement on the existing
> memory.{low,min} relative reclaim work to base its scan pressure
> calculations on how much protection is available compared to the current
> usage, rather than how much the current
On 2/12/19 2:42 PM, Mathieu Desnoyers wrote:
Register rseq(2) TLS for each thread (including main), and unregister
for each thread (excluding main). "rseq" stands for Restartable
Sequences.
Thanks, the implementation is looking good, before this goes in it needs
some procedural cleanup and the
> So apparently the hang happens while we're running the "final" PCI
> fixups. This happens after all the rest of PCI is initialized.
>
> Can you boot v5.0 vanilla with "initcall_debug"? Maybe we can narrow
> it down to a specific quirk.
yup, added the "initcall_debug" output to the ticket:
On Fri, Mar 22, 2019 at 1:46 PM Ondrej Mosnacek wrote:
> On Fri, Mar 22, 2019 at 3:04 PM Yue Haibing wrote:
> > From: YueHaibing
> >
> > Fix sparse warning:
> >
> > security/selinux/hooks.c:3389:5: warning:
> > symbol 'selinux_kernfs_init_security' was not declared. Should it be
> > static?
>
On Fri, Mar 22, 2019 at 07:39:31PM +, Christopher Lameter wrote:
> On Fri, 22 Mar 2019, Waiman Long wrote:
>
> > >
> > >> I am looking forward to it.
> > > There is also alrady rcu being used in these paths. kfree_rcu() would not
> > > be enough? It is an estalished mechanism that is mature
On Fri, Mar 22, 2019 at 6:55 PM Luck, Tony wrote:
>
> On Fri, Mar 22, 2019 at 03:00:25PM +0100, Arnd Bergmann wrote:
> > Sorry, this was my mistake, my email was garbled. The patch was
> > correct though: the idea here is not to change the Kconfig symbols
> > but to change the Makefile to do the
As far as I can tell/remember rev10 was originally created to support
making a SKU of jerry that had a different LCD. rev11-rev15 were
added to give some wiggle room for future builds. Downstream has a
separate device tree for rev10-rev15 (compared to rev3-rev7) with the
expectation that
As far as I can tell/remember rev10 was originally created to support
making a SKU of jerry that had a different LCD. rev11-rev15 were
added to give some wiggle room for future builds. Downstream has a
separate device tree for rev10-rev15 (compared to rev3-rev7) with the
expectation that
On Fri, Mar 22, 2019 at 04:44:37PM +0100, Thomas Gleixner wrote:
> > +EXPORT_SYMBOL(acrn_remove_intr_irq);
>
> Where is the code which uses these exports? We are not adding exports just
> because or for consumption by out of tree modules.
Right, if anything, all new exports should be _GPL.
--
Hi Enrico,
On 21/3/19 22:03, egran...@chromium.org wrote:
> From: Enrico Granata
>
> Add a layer of sanity checking to cros_ec_register against attempting to
> register IRQ values that are not strictly greater than 0.
>
> Signed-off-by: Enrico Granata
> ---
> drivers/mfd/cros_ec.c | 2 +-
>
Mighty is basically the same Chromebook as Jaq but it has a full-sized
SD slot and some different (slightly more rugged) plastics around it.
Like Jaq, Mighty may show up with various different brandings but all
of them have the same board inside.
In the downstream kernel Mighty and Jaq share a
Mighty is basically the same Chromebook as Jaq but it has a full-sized
SD slot and some different (slightly more rugged) plastics around it.
Like Jaq, Mighty may show up with various different brandings but all
of them have the same board inside.
Signed-off-by: Douglas Anderson
---
On Fri, 22 Mar 2019, Waiman Long wrote:
> >
> >> I am looking forward to it.
> > There is also alrady rcu being used in these paths. kfree_rcu() would not
> > be enough? It is an estalished mechanism that is mature and well
> > understood.
> >
> In this case, the memory objects are from kmem
On 3/22/19 10:53 AM, Bartosz Golaszewski wrote:
pt., 22 mar 2019 o 10:21 Pavel Machek napisał(a):
On Mon 2019-03-18 18:42:26, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
This adds basic support for LEDs for the max77650 PMIC. The device has
three current sinks for driving LEDs.
Hi Ingo,
I was looking through at urgent patches that need to go upstream (as
I'm working on a couple of patches now), and saw this series. It
doesn't look like it was applied yet.
Do you want to take this, or would you want me to? It touches arch/x86,
so I'll take it if one of the x86
On Fri, Mar 22, 2019 at 07:24:01PM +, Ghannam, Yazen wrote:
> Generally, the model groups share the same hardware design and so the
> same quirks. So I'm thinking that it'd be more efficient to have a
> filter function that targets a specific group of models rather than
> one that checks all
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, March 22, 2019 2:32 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org; ra...@milecki.pl;
>
On 3/22/2019 12:34 PM, Borislav Petkov wrote:
> On Thu, Mar 21, 2019 at 08:25:18PM +, Ghannam, Yazen wrote:
>> From: Yazen Ghannam
>>
>> AMD Family 17h Models 10h-2Fh may report a high number of L1 BTB MCA
>> errors under certain conditions. The errors are benign and can safely be
>> ignored.
On Thu, 21 Mar 2019 23:58:20 -0700
frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Fix compile warning in create_dyn_event(): 'ret' may be used uninitialized
> in this function [-Wuninitialized].
>
> Fixes: 5448d44c3855 ("tracing: Add unified dynamic event framework")
>
>
The pull request you sent on Fri, 22 Mar 2019 11:15:36 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/599beede718182cd85d5e1dc2d4e523c05d5014c
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Fri, 22 Mar 2019 11:25:39 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-5.1-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b44290a022dcffb5ca3b75300e571fad06214bc7
Thank you!
--
Deet-doot-dot, I am a
Hi Gareth, Phil,
Thanks for your patch!
On Fri, Mar 22, 2019 at 5:11 PM Gareth Williams
wrote:
> From: Phil Edworthy
>
> All SoC devices that use this driver have a module stop clock associated
> with it that we must ensure is enabled. All SoCs enabled this clock
> by default, so I guess no
The pull request you sent on Fri, 22 Mar 2019 11:28:08 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> devprop-5.1-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e42091739f649b3caf43ddffa53f0416dc396fdd
Thank you!
--
Deet-doot-dot,
The pull request you sent on Fri, 22 Mar 2019 11:26:55 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-5.1-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2c1ada4f052d6d5e5c0bf7901617479b2146139e
Thank you!
--
Deet-doot-dot, I am
On Thu, Mar 14, 2019 at 09:29:32PM +0900, William Breathitt Gray wrote:
> Changes in v10:
> - Fix off-by-one error in bitmap initialization in the
> test_for_each_set_clump8 function
> - Fix typos in clump_exp array definition in test_bitmap.c ("0x28"
> should have been "0x38")
> -
On Fri, Mar 22, 2019 at 07:32:28PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 21.03.19 10:23, Andy Shevchenko wrote:
>
> > ...and on top of that GPIO sysfs interface is deprecated.
>
> I don't like the idea of deprecating this. It might not be enough for
> all usecases, but for a lot
The other patchsets posted today are complete - thanks -
but this 3.18.137-rc1 tree still wants
29b00e609960 ("tmpfs: fix uninitialized return value in shmem_link")
to be added to fix this one - thanks.
Hugh
On Fri, 22 Mar 2019, Greg Kroah-Hartman wrote:
> 3.18-stable review patch. If anyone
From: Steven Rostedt (VMware)
Running the ftrace selftests on the latest kernel caused the
kprobe_eventname test to fail. It was due to the test that searches for
a function with at "dot" in the name and adding a probe to that.
Unfortunately, for this test, it picked:
On 3/22/2019 12:24 PM, Borislav Petkov wrote:
> On Thu, Mar 21, 2019 at 08:25:17PM +, Ghannam, Yazen wrote:
>> From: Yazen Ghannam
>>
>> Some systems may report spurious MCA errors. In general, spurious MCA
>> errors may be disabled by clearing a particular bit in MCA_CTL. However,
>>
On Thu, Mar 21, 2019 at 10:51 AM Thomas Gleixner wrote:
>
> On Thu, 21 Mar 2019, Stephane Eranian wrote:
> > On Thu, Mar 21, 2019 at 9:45 AM Thomas Gleixner wrote:
> > >
> > > On Thu, 21 Mar 2019, Peter Zijlstra wrote:
> > > > Subject: perf/x86/intel: Initialize TFA MSR
> > > >
> > > > Stephane
On Thu, Mar 14, 2019 at 09:32:57PM +0900, William Breathitt Gray wrote:
> Utilize for_each_set_clump8 macro, and the bitmap_set_value8 and
> bitmap_get_value8 functions, where appropriate. In addition, remove the
> now unnecessary temp_mask and temp_shift members of the
>
Hi,
Apologies for a possible stupid question.
On 20/03/2019 17:15, Sebastian Andrzej Siewior wrote:
- Applied John Ogness' prinkt rework. One visible change is the
output during boot. Under the hood and for RT: By default, output
that is created at KERN_WARN[0] or higher is
On Thu, Mar 21, 2019 at 8:15 AM Guenter Roeck wrote:
>
> On Wed, Mar 20, 2019 at 2:21 PM Evan Green wrote:
> >
> > Add support in code for the new forms of the host sleep event.
> > Detects the presence of this version of the command at runtime,
> > and use whichever form the EC supports. At
On Wed, Mar 20, 2019 at 8:08 PM Alexey Dobriyan wrote:
>
> pidfd code should be backed out immediately. Forget about /proc.
Seems like Torvalds just merges this sort of "stuff" without reading
it now, or there's something that auto accepted pull request to RC tree?
> The pull request you sent
On 21.03.19 14:56, Mika Westerberg wrote:
> I checked it and you do this:> > + value |= PADCFG0_GPIORXDIS;> +
> value &=
~PADCFG0_GPIOTXDIS;> > which pretty much turns the pin GPIO output
unconditionally. I don't> really think it is good idea. May work in your
case but may cause>
On 21.03.19 10:23, Andy Shevchenko wrote:
> ...and on top of that GPIO sysfs interface is deprecated.
I don't like the idea of deprecating this. It might not be enough for
all usecases, but for a lot of usecases, it's a very easy and simple
interfaces.
--mtx
--
Enrico Weigelt, metux IT
On 3/22/19 12:37 PM, Joao Moreira wrote:
On 2019-03-22 11:54, Joe Lawrence wrote:
On Fri, Mar 01, 2019 at 11:13:10AM -0300, Joao Moreira wrote:
From: Josh Poimboeuf
Create cmd_klp_convert and hook it into scripts/Makefile.modpost.
cmd_klp_convert invokes klp-convert with the right arguments
On 21.03.19 09:53, Arnd Bergmann wrote:
> I think serial port drivers typically have a limit on the number of
> ports, so we likely need the same here.
Except for earlycon (haven't had a closer look at it yet), I don't see
any hard reason for that (maybe Greg could give us more insight here).
I
On Thu, Mar 14, 2019 at 09:30:02PM +0900, William Breathitt Gray wrote:
> This macro iterates for each 8-bit group of bits (clump) with set bits,
> within a bitmap memory region. For each iteration, "start" is set to the
> bit offset of the found clump, while the respective clump value is
> stored
On Thu, Mar 07, 2019 at 08:56:32AM -0800, Greg Thelen wrote:
> Since commit a983b5ebee57 ("mm: memcontrol: fix excessive complexity in
> memory.stat reporting") memcg dirty and writeback counters are managed
> as:
> 1) per-memcg per-cpu values in range of [-32..32]
> 2) per-memcg atomic counter
>
Hi Srinivas,
Thanks for the patch, Something like this only i have tested in the
morning, instead of unused, i have put dev group inside config as well.
We will test the exact patch and update the same.
Regards
Gaurav
On 3/22/2019 8:32 PM, Srinivas Kandagatla wrote:
On 20/03/2019 17:50,
On 03/22/2019 01:50 PM, Christopher Lameter wrote:
> On Fri, 22 Mar 2019, Waiman Long wrote:
>
>> I am looking forward to it.
> There is also alrady rcu being used in these paths. kfree_rcu() would not
> be enough? It is an estalished mechanism that is mature and well
> understood.
>
In this case,
On Fri, Mar 22, 2019 at 7:20 AM Arnd Bergmann wrote:
>
> On Fri, Mar 8, 2019 at 7:38 PM Nathan Chancellor
> wrote:
> >
> > When building with -Wsometimes-uninitialized, Clang warns:
> >
> > drivers/tty/serial/qcom_geni_serial.c:1079:6: warning: variable 'baud'
> > is used uninitialized whenever
On Fri, Mar 22, 2019 at 09:26:35AM -0700, Paul E. McKenney wrote:
> On Fri, Mar 22, 2019 at 11:50:49AM -0400, Joel Fernandes wrote:
> > On Fri, Mar 22, 2019 at 07:58:23AM -0700, Paul E. McKenney wrote:
> > [snip]
> > > > > > #ifdef CONFIG_RCU_NOCB_CPU
> > > > > > static cpumask_var_t
On 2019-03-22 10:43:34 [-0700], Tejun Heo wrote:
> Hello,
Hi,
> We can switch but it doesn't really say why we'd want to. Can you
> please explain why this is better?
there is this undocumented part. Avoiding the sched RCU means also we
are more preemptible which is good :) Especially on -RT
On Fri, Mar 22, 2019 at 03:00:25PM +0100, Arnd Bergmann wrote:
> Sorry, this was my mistake, my email was garbled. The patch was
> correct though: the idea here is not to change the Kconfig symbols
> but to change the Makefile to do the right thing even when Kconfig
> is set wrong.
Well this does
On Thu, 21 Mar 2019, Waiman Long wrote:
> When releasing kernel data structures, freeing up the memory
> occupied by those objects is usually the last step. To avoid races,
> the release operation is commonly done with a lock held. However, the
> freeing operations do not need to be under lock,
On Fri, 22 Mar 2019, Waiman Long wrote:
> I am looking forward to it.
There is also alrady rcu being used in these paths. kfree_rcu() would not
be enough? It is an estalished mechanism that is mature and well
understood.
On Fri, Mar 22, 2019 at 3:04 PM Yue Haibing wrote:
> From: YueHaibing
>
> Fix sparse warning:
>
> security/selinux/hooks.c:3389:5: warning:
> symbol 'selinux_kernfs_init_security' was not declared. Should it be static?
>
> Signed-off-by: YueHaibing
Yup, another trivial mistake on my part...
On Fri, Mar 22, 2019 at 3:29 AM Tomi Valkeinen wrote:
>
> On 22/03/2019 05:28, Andrey Smirnov wrote:
> > A very unfortunate aspect of tc_write()/tc_read() macro helpers is
> > that they capture quite a bit of context around them and thus require
> > the caller to have magic variables 'ret' and
Hi Jeremy,
> Jeremy Linton hat am 22. März 2019 um 00:05
> geschrieben:
>
>
> From: Mian Yousaf Kaukab
>
> Enable CPU vulnerabilty show functions for spectre_v1, spectre_v2,
> meltdown and store-bypass.
>
> Signed-off-by: Mian Yousaf Kaukab
> Signed-off-by: Jeremy Linton
> Reviewed-by:
On Fri, Mar 22, 2019 at 05:52:59PM +0100, Uladzislau Rezki wrote:
> On Thu, Mar 21, 2019 at 03:01:06PM -0700, Andrew Morton wrote:
> > On Thu, 21 Mar 2019 20:03:26 +0100 "Uladzislau Rezki (Sony)"
> > wrote:
> >
> > > Hello.
> > >
> > > This is the v2 of the https://lkml.org/lkml/2018/10/19/786
I observed an issue with return value being set to 0, when a match is
not found in the irqdomain-map.
On Wed, Mar 13 2019 at 15:20 -0600, Lina Iyer wrote:
From: Stephen Boyd
Sometimes interrupts are routed from an interrupt controller to another
in no specific order. Having these in the
Hello,
On Thu, Mar 21, 2019 at 09:59:35PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-03-13 17:55:47 [+0100], To linux-kernel@vger.kernel.org wrote:
> > From: Thomas Gleixner
> >
> > There is no need for sched_rcu. The undocumented reason why sched_rcu
> > is used is to avoid a few
On Thu, 21 Mar 2019, Li RongQing wrote:
> nc is a member of percpu allocation memory, and impossible NULL
Acked-by: Christoph Lameter
> > If the virtual Sparc emulator is using it does that also mean actual
> > Sparc hardware has it. In which case presumably it needs fixing, or at
> > least moving to the generic driver assuming the firmware sets it up ?
> >
>
> The qemu works perfectly with the new Linux driver.
For some
Hello,
When loading the new kernel image file for executing KEXEC system call,
we would like to verify that the kernel image file is signed and
the signer certificate is valid.
If the kernel image file is in Portable Executable (PE) format we want to
validate the PE Signature and measure the
On Thu, Mar 21, 2019 at 08:25:18PM +, Ghannam, Yazen wrote:
> From: Yazen Ghannam
>
> AMD Family 17h Models 10h-2Fh may report a high number of L1 BTB MCA
> errors under certain conditions. The errors are benign and can safely be
> ignored. However, the high error rate may cause the MCA
From: Bartosz Golaszewski
The debugfs read callback must advance ppos or users using read() on
the file descriptor will never get the EOL. This wasn't spotted before
as I was using busybox cat for testing which uses sendfile() internally
and only noticed it now when switched to cat from
Hi,
Currently Kexec (kexec_file_load) code path does not measure the cmdline
arguments passed to the next kernel.The boot_aggregate won't change since
the EFI loader hasn't been triggered. Attesting the same in K2 has no impact.
Adding the cmdline measurement will add some attestable criteria.
On Thu, Mar 21, 2019 at 08:25:17PM +, Ghannam, Yazen wrote:
> From: Yazen Ghannam
>
> Some systems may report spurious MCA errors. In general, spurious MCA
> errors may be disabled by clearing a particular bit in MCA_CTL. However,
> clearing a bit in MCA_CTL may not be recommended for some
> > diff --git a/arch/x86/include/uapi/asm/perf_regs.h
> > b/arch/x86/include/uapi/asm/perf_regs.h
> > index f3329cabce5c..b33995313d17 100644
> > --- a/arch/x86/include/uapi/asm/perf_regs.h
> > +++ b/arch/x86/include/uapi/asm/perf_regs.h
> > @@ -28,7 +28,29 @@ enum perf_event_x86_regs {
> >
On Fri, Mar 22, 2019 at 05:29:30PM +0200, Sakari Ailus wrote:
> Add support for %pfw conversion specifier (with "f" and "P" modifiers) to
> support printing full path of the node, including its name ("f") and only
> the node's name ("P") in the printk family of functions. The two flags
> have
On Sat, Mar 23, 2019 at 12:19:01AM +0800, Pu Wen wrote:
> > Sounds to me like you're programming the initial APIC ID not
> > the same way as AMD do...
>
> In the same way.
So why do you need to do something different than what AMD does?
--
Regards/Gruss,
Boris.
Good mailing practices for
This fixes the checkpatch.pl warning: "Prefer u32 over uint32_t"
Signed-off-by: Bharath Vedartham
---
Changes since v2
- Improved changelog
- Thanks for the good feedback. I am a beginner. I will learn
and grow. :)
---
drivers/staging/ralink-gdma/ralink-gdma.c | 12
On Fri, Mar 22, 2019 at 09:36:56AM -0700, kan.li...@linux.intel.com wrote:
> From: Kan Liang
>
> Starting from Icelake, XMM registers can be collected in PEBS record.
> But current code only output the pt_regs.
>
> Add a new struct x86_perf_regs for both pt_regs and xmm_regs.
> XMM registers
Thanks!
I also expect to start contributing again to maintain the code I have
in the kernel, after I done with upsteaming the nvme-mdev driver I
have just sent for initial review.
I work for Red Hat now, so I hope I'll find some time for that in the
future (still on a hobby basis of course).
Best
On Fri, Mar 22, 2019 at 03:33:37PM +0100, Arnd Bergmann wrote:
> When the driver is used with a subdevice that is disabled in the
> kernel configuration, clang gets a little confused about the
> control flow and fails to notice that n_subdevs is only
> uninitialized when subdevs is NULL, and we
On 3/16/19 2:24 AM, Shenghui Wang wrote:
> "sbitmap_batch_clear" should be "sbitmap_deferred_clear"
Applied, thanks.
--
Jens Axboe
> Lol... we're actively moving away from the C standard on many places.
Yes and also packed is not part of the C standard.
> Why does the silly compiler think it is a problem to take the address of
> a member of a packed structure? That sounds like something that's
> perfectly fine and useful.
On Fri, Mar 22, 2019 at 5:40 PM Peter Zijlstra wrote:
>
> On Fri, Mar 22, 2019 at 02:58:51PM +0100, Arnd Bergmann wrote:
> > On Thu, Mar 21, 2019 at 11:00 PM Andi Kleen wrote:
> > >
> > > From: Andi Kleen
> > >
> > > This warning is very noisy in a default build with gcc 9.
> > > Move it into
On 19.03.19 13:08, Morris Ku wrote:
> diff --git a/mfd/sunix/snx_ieee1284_ops.c b/mfd/sunix/snx_ieee1284_ops.c
> new file mode 100644
> index ..2dac03fd
> --- /dev/null
> +size_t sunix_parport_ieee1284_read_nibble(struct snx_parport *port,
> +void *buffer, size_t len, int flags)
> +{
>
On Thu, Mar 21, 2019 at 03:01:06PM -0700, Andrew Morton wrote:
> On Thu, 21 Mar 2019 20:03:26 +0100 "Uladzislau Rezki (Sony)"
> wrote:
>
> > Hello.
> >
> > This is the v2 of the https://lkml.org/lkml/2018/10/19/786 rework. Instead
> > of
> > referring you to that link, i will go through it
On Fri, Mar 22, 2019 at 05:44:45PM +0100, Borislav Petkov wrote:
> On Sat, Mar 23, 2019 at 12:19:01AM +0800, Pu Wen wrote:
> > That 6 is not a magic number.
>
> Well, if I see a naked 6, then it is only magic to me. Now if it were a
> proper define with a descriptive name...
Does AMD/Hygon not
When the rk3288-jerry device tree was first submitted we left out the
dvs-gpios because I pointed out that the property "dvs-gpios" wasn't
yet supported upstream [1]. Soon after that the property was added in
commit bad47ad2eef3 ("regulator: rk808: fixed the overshoot when
adjust voltage").
On Fri, 2019-03-22 at 17:12 +0100, Thomas Gleixner wrote:
> On Fri, 22 Mar 2019, Borislav Petkov wrote:
>
> > On Fri, Mar 22, 2019 at 03:31:54PM +0100, Thomas Gleixner wrote:
> > > We have no proper decision/recommendation about documentation
> > > licensing. That's being worked on.
> >
> > Ok,
Add generic i.MX8 SoC driver along with the i.MX8MQ SoC specific code.
For now, only i.MX8MQ revision B1 is supported. For any other, i.MX8MQ
revision it will print 'unknown'.
Signed-off-by: Abel Vesa
---
drivers/soc/imx/Makefile | 1 +
drivers/soc/imx/soc-imx8.c | 115
On 19/03/2019 00:58, Aditya Pakki wrote:
> In sirf_audio_codec_driver_probe, of_match_node may fail and return a
> NULL pointer. The patch avoids a potential NULL pointer dereference.
Actually 'match' isn't used in this function... So there's no chance of
a NULL dereference. You might as well
On Fri, Mar 22, 2019 at 04:33:48PM +, Kim Phillips wrote:
> Hi Boris,
>
> I've tested this patch and it gets rid of a slew of these messages:
>
> kernel: EDAC amd64: Error: F0 not found, device 0x1460 (broken BIOS?)
> kernel: EDAC amd64: Error: Error probing instance: 0
>
> So please add
On Sat, Mar 23, 2019 at 12:19:01AM +0800, Pu Wen wrote:
> That 6 is not a magic number.
Well, if I see a naked 6, then it is only magic to me. Now if it were a
proper define with a descriptive name...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the
On 18/03/2019 23:04, Aditya Pakki wrote:
> of_match_device can return NULL if no matching device is found. This patch
> checks and returns -ENODEV in such a scenario.
>
> Signed-off-by: Aditya Pakki
> ---
> drivers/firmware/arm_scmi/driver.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff
On Fri, Mar 22, 2019 at 05:27:43PM +0100, Thomas Renninger wrote:
> Thanks Rafael for your quick look at and all the time you spend for this!
>
> A /sys userspace knob will certainly not be enough for us.
> You'll need a tool installed fixing this.
We won't pick up the second patch converting to
On 3/19/19 11:38 AM, Scott Branden wrote:
> Thanks Srinath and Rob - patch series looks good now.
>
> patch series,
>
> Acked-by: Scott Branden
>
Kishon, can you let me know when you apply patches 1 and 2 so I can
queue up patch 3 for inclusion the 5.2 ARM SoC pull request? Thanks!
>
> On
From: Kan Liang
Add Icelake core PMU perf code, including constraint tables and the main
enable code.
Icelake expanded the generic counters to always 8 even with HT on, but a
range of events cannot be scheduled on the extra 4 counters.
Add new constraint ranges to describe this to the
From: Kan Liang
Adaptive PEBS is a new way to report PEBS sampling information. Instead
of a fixed size record for all PEBS events it allows to configure the
PEBS record to only include the information needed. Events can then opt
in to use such an extended record, or stay with a basic record
201 - 300 of 1923 matches
Mail list logo
