On Wed, 2018-04-18 at 19:42 +0800, kbuild test robot wrote:
>sound/soc/intel/atom/sst/sst_loader.c: In function
> 'sst_request_fw':
> > > sound/soc/intel/atom/sst/sst_loader.c:357:9: warning: 'fw' is used
> > > uninitialized in this function [-Wuninitialized]
>
> if (fw == NULL) {
>
Implement namespacing within AFS, but don't yet let mounts occur outside
the init namespace. An additional patch will be required propagate the
network namespace across automounts.
Signed-off-by: David Howells
---
cell.c |4 +-
internal.h | 39 +++---
main.c
Export get_proc_net() so that write() routines attached to net-namespaced
proc files can find the network namespace that they're in. Currently, this
is only accessible via seqfile routines.
This will permit AFS to have a separate cell database per-network namespace
and to manage each one inde
2018-04-12 17:08 GMT+02:00 Peter Rosin :
> On 2018-04-11 16:38, Bartosz Golaszewski wrote:
>> This is a follow-up to the big series merged for 4.17. The patches
>> contain some bits and pieces that were missing in the last submission
>> or depend on some new features merged this merge window.
>>
>>
David Howells wrote:
> > Use remove_proc_subtree to remove the whole subtree on cleanup, and
> > unwind the registration loop into individual calls. Switch to use
> > proc_create_seq where applicable.
>
> Note that this is likely going to clash with my patch to net-namespace all of
> the afs pr
On 20.04.2018 14:26, David Hildenbrand wrote:
> On 19.04.2018 23:13, Tony Krowiak wrote:
>> Introduces a new function to reset the crypto attributes for all
>> vcpus whether they are running or not. Each vcpu in KVM will
>> be removed from SIE prior to resetting the crypto attributes in its
>> SIE
On Fri, 20 Apr 2018 12:58:27 +0200
Peter Zijlstra wrote:
> On Fri, Apr 20, 2018 at 07:01:47PM +1000, Nicholas Piggin wrote:
> > On Fri, 20 Apr 2018 09:44:56 +0200
> > Peter Zijlstra wrote:
> >
> > > On Sun, Apr 15, 2018 at 11:31:49PM +1000, Nicholas Piggin wrote:
> > > > This is a quick hac
On Thu, 19 Apr 2018, Dan Carpenter wrote:
> Several people have asked me to write this and I think one person was
> maybe working on writing it themselves...
>
> The point of this check is to find place which might be vulnerable to
> the Spectre vulnerability. In the kernel we have the array_ind
On 19.04.2018 23:13, Tony Krowiak wrote:
> Introduces a new function to reset the crypto attributes for all
> vcpus whether they are running or not. Each vcpu in KVM will
> be removed from SIE prior to resetting the crypto attributes in its
> SIE state description. After all vcpus have had their cr
The hardware has a single block for applying a CTM prior to gamma lut.
It can be fed with pixels from one of our CRTC at a time and uses a
matrix with S0.9 scalars. Use private atomic state to reject attempts
from userland to apply CTM for more than one CRTC at a time and reject
matrices with scala
Now that we set the OLED* registers to do CTM, it's helpful to have them
in the register dump.
Signed-off-by: Stefan Schake
---
v4: new in the series.
drivers/gpu/drm/vc4/vc4_hvs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hv
On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote:
> > Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then
> > uses DMA-API on the returned memory or frees it with kfree. Such bugs were
> > found in the virtio-net drive
On Thu, 19 Apr 2018, Andrew Morton wrote:
> On Thu, 19 Apr 2018 17:19:20 -0400 (EDT) Mikulas Patocka
> wrote:
>
> > > > In order to detect these bugs reliably I submit this patch that changes
> > > > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on.
> > > >
> > > > ...
> > > >
During probe check whether the vdd-io regulator of sdhc platform device
can support 1.8V and 3V and store this information as a capability of
platform device.
Signed-off-by: Vijay Viswanath
Reviewed-by: Douglas Anderson
---
drivers/mmc/host/sdhci-msm.c | 29 -
1 file
On 20.04.2018 13:59, Janosch Frank wrote:
> Thanks, applied.
>
Well this does not compile, as you use kvm_s390_vcpu_crypto_setup before
declaration. Please fix, then I'll take the patch.
>
> On 19.04.2018 23:13, Tony Krowiak wrote:
>> Introduces a new function to reset the crypto attributes fo
The PADs for SD card are dual-voltage that support 3v/1.8v. Those PADs
have a control signal (io_pad_pwr_switch/mode18 ) that indicates
whether the PAD works in 3v or 1.8v.
SDHC core on msm platforms should have IO_PAD_PWR_SWITCH bit set/unset
based on actual voltage used for IO lines. So when po
>From the HPG:
In some platform, SDCC controller can be connected to either an eMMC device or
an SD card. The PADs for SD card are dual-voltage that support 3v/1.8v. Those
PADs have a control signal (io_pad_pwr_switch/mode18 ) that indicates whether
the PAD works in 3v or 1.8v.
For SD usage the d
On 04/10/2018 05:25 PM, Alex Elder wrote:
> This series contains mostly bug fixes to the Qualcomm shared memory
> ("smem") code. Although the bugs are real, they have most likely
> never been observed.
>
> -Alex
Ping? -Alex
>
> Alex Elder (6):
> soc: q
On Fri, 20 Apr 2018 11:44:32 +0200,
Kai-Heng Feng wrote:
>
> Now it's a typical discrete-only system. HDMI audio comes from AMD audio
> controller, others from Intel audio controller.
>
> When SG is enabled, the unused AMD audio contoller still exposes its
> sysfs, so userspace still opens the co
On Thu, 19 Apr 2018 09:34:02 +0800 Leo Yan wrote:
> Fix typo by replacing 'iif' with 'if'.
>
> Signed-off-by: Leo Yan
> ---
> samples/bpf/bpf_load.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
> index bebe418..28e46
As part of the y2038 system call work, the getrusage/wait4/waitid system
calls came up, since they pass time data to user space in 'timeval'
format as required by POSIX. This means the existing kernel data structure
is no longer compatible with the one from user space once we have a C
library expos
'struct rusage' contains the run times of a process in 'timeval' format
and is accessed through the wait4() and getrusage() system calls. This
is not a problem for y2038 safety by itself, but causes an issue when
the C library starts using 64-bit time_t on 32-bit architectures because
the structure
On Fri, 20 Apr 2018 11:12:24 +0200
Petr Mladek wrote:
> Yes, my number was arbitrary. The important thing is that it was long
> enough. Or do you know about an console that will not be able to write
> 100 lines within one hour?
The problem is the way rate limit works. If you print 100 lines (or
2018-04-20 18:41 GMT+08:00 Christoph Hellwig :
>> +++ b/arch/nds32/kernel/stacktrace.c
>> @@ -9,6 +9,7 @@ void save_stack_trace(struct stack_trace *trace)
>> {
>> save_stack_trace_tsk(current, trace);
>> }
>> +EXPORT_SYMBOL(save_stack_trace);
>
> All other architectures use EXPORT_SYMBOL_GP
Thanks, applied.
On 19.04.2018 23:13, Tony Krowiak wrote:
> Introduces a new function to reset the crypto attributes for all
> vcpus whether they are running or not. Each vcpu in KVM will
> be removed from SIE prior to resetting the crypto attributes in its
> SIE state description. After all vcpu
Hi Dan,
awesome stuff...
So I fear that many are actually things we want to fix. Our policy was
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store.
Also, many of the reported things (for the ones I looked at) are on slow
paths and fixing t
On Thu, Apr 19, 2018 at 06:27:51PM +0200, Peter Rosin wrote:
> This makes this driver work with all(?) drivers that are not
> componentized and instead expect to connect to a panel/bridge. That
> said, the only one tested is atmel_hlcdc.
>
> This hooks the relevant work function previously called
On Fri, 20 Apr 2018 07:44:25 +0200
Dominik Brodowski wrote:
> For v4.17-rc1, the naming of syscall stubs changed. Update stack
> traces and similar instances in the documentation to avoid sources
> for confusion.
>
> Signed-off-by: Dominik Brodowski
Except that on x86 I don't see any __se_sys_
On 04/20/2018 01:36 PM, Cornelia Huck wrote:
On Fri, 20 Apr 2018 12:54:26 +0200
Halil Pasic wrote:
ping
I think get this fixed. Better sooner than later.
[..]
Hm, it seems that drowned in other patches... can I get a re-send,
please?
I guess Dong Jia will handle it. If not I will on
2018-04-20 2:38 GMT+08:00 Guenter Roeck :
> On Thu, Apr 19, 2018 at 09:18:15PM +0800, Greentime Hu wrote:
>> This way we can build kernel with CONFIG_CPU_LITTLE_ENDIAN=y and allmodconfig
>> will be available.
>>
>> Signed-off-by: Greentime Hu
>
> As Arnd suspected, this causes allnoconfig to fail.
Hi Alex,
After days of intensive test, the bug did not show up any more.
So I think the new patch does solve this problem.
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, April 20, 2018 3:55 AM
> To: xuyandong
> Cc: k...@vger.kernel.org;
This fixes a NULL pointer dereference that can happen if the UDL
driver is unloaded before the framebuffer is initialized. This can
happen e.g. if the USB device is unplugged right after it was plugged
in.
Signed-off-by: Emil Lundmark
---
drivers/gpu/drm/udl/udl_fb.c | 8 +---
1 file changed
> I'm fine with the patch, but shouldn't this be part of a larger series /
> cocinelle script?
>
This one is trivial but many others are not.
As part of this clean up we have fixed many
existing bugs in fault handlers of drivers/
file systems. Also we are replacing existing
vm_insert_foo() with ne
On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote:
> Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then
> uses DMA-API on the returned memory or frees it with kfree. Such bugs were
> found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific
> code.
May
Support was added for factoring out common arch events in
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/tools/perf/pmu-events?h=next-20180420&id=e9d32c1bf0cd7a98358ec4aa1625bf2b3459b9ac
>
> ARM64 chips use this feature. I am not familiar with the s390 arch,
Hi Peter,
On Fri, Apr 20, 2018 at 01:05:21PM +0200, Peter Rosin wrote:
> On 2018-04-20 12:18, Laurent Pinchart wrote:
> > Hello,
> >
> > On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
> >> Hi Peter,
> >> I've been a bit a pain in the arse for you recently, but please
> >> bear with
According to the documentation the interrupt line is active low.
The patch will silence the warning from gic_irq_domain_translate():
"Make it clear that broken DTs are... broken"
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am437x-gp-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 dele
According to the documentation the interrupt line is active low.
The patch will silence the warning from gic_irq_domain_translate():
"Make it clear that broken DTs are... broken"
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 del
According to the documentation the interrupt line is active low.
The patch will silence the warning from gic_irq_domain_translate():
"Make it clear that broken DTs are... broken"
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am437x-cm-t43.dts | 2 +-
1 file changed, 1 insertion(+), 1 dele
According to the documentation the interrupt line is active low.
The patch will silence the warning from gic_irq_domain_translate():
"Make it clear that broken DTs are... broken"
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am437x-sk-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 dele
[2.833311] Modules linked in:
[2.836417] CPU: 0 PID: 19 Comm: kworker/0:2 Not tainted
4.17.0-rc1-next-20180420-00057-gffd03ee19b9b #182
[2.846113] Hardware name: Generic AM43 (Flattened Device Tree)
[2.852073] Workqueue: events deferred_probe_work_func
...
Becasue most of the am437x boards had
On Fri, 20 Apr 2018 12:54:26 +0200
Halil Pasic wrote:
> ping
>
> I think get this fixed. Better sooner than later.
>
> On 03/27/2018 03:42 AM, Dong Jia Shi wrote:
> > * Cornelia Huck [2018-03-26 14:28:39 +0200]:
> >
> > [...]
> >
> >>> By the way, since you will propose a new version,
> >>
On Fri 20-04-18 13:20:10, Stefan Agner wrote:
> On 20.04.2018 13:15, Matthew Wilcox wrote:
> > On Thu, Apr 19, 2018 at 11:42:04PM +0200, Stefan Agner wrote:
> >> With PHYS_ADDR_MAX there is now a type safe variant for all
> >> bits set. Make use of it.
> >
> > There is? I don't see it in linux-ne
On 20/04/18 12:47, Stanislav Kinsburskii wrote:
> This patch adds wrapper helpers around generic Xen fault inject
> facility.
> The major reason is to keep all the module fault injection directories
> in a dedicated subdirectory instead of Xen fault inject root.
>
> IOW, when using these helpers,
Commit 7378f1149884 ("media: omap2: omapfb: allow building it with
COMPILE_TEST") broke compilation without CONFIG_OF selected.
CC drivers/video/fbdev/core/fbmem.o
drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c: In function
‘omapdss_update_prop’:
drivers/video/fbdev/omap2/omapfb/d
On 04/20/2018 10:19 AM, Daniel Vetter wrote:
On Wed, Apr 18, 2018 at 11:10:58AM +0100, Roger Pau Monné wrote:
On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote:
On 04/18/2018 10:35 AM, Roger Pau Monné wrote:
On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenk
On 20/04/18 12:47, Stanislav Kinsburskii wrote:
> This patch adds wrapper helpers around generic Xen fault inject facility.
> The major reason is to keep all the module fault injection directories
> in a dedicated subdirectory instead of Xen fault inject root.
>
> IOW, when using these helpers, pe
Store user space frame-pointer value (BP register) into Perf trace
on a sample for a process so the value becomes available when
unwinding call stacks for functions gaining event samples.
Test executable for the example below was compiled with frame pointer
support enabled:
g++ -o futex-fp -f
Hi Laurent,
On Fri, Apr 20, 2018 at 01:18:13PM +0300, Laurent Pinchart wrote:
> Hello,
>
> On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
> > Hi Peter,
> > I've been a bit a pain in the arse for you recently, but please
> > bear with me a bit more, and sorry for jumping late on the
Commit-ID: 15a3e845b01ce2342cf187dc123c92c44c3c8170
Gitweb: https://git.kernel.org/tip/15a3e845b01ce2342cf187dc123c92c44c3c8170
Author: Oskar Senft
AuthorDate: Fri, 23 Mar 2018 09:11:30 -0400
Committer: Thomas Gleixner
CommitDate: Fri, 20 Apr 2018 13:17:50 +0200
perf/x86/intel/uncore:
On 20.04.2018 13:58, Juri Lelli wrote:
> On 20/04/18 12:43, Kirill Tkhai wrote:
>> On 20.04.2018 12:25, Juri Lelli wrote:
>
> [...]
>
>>> Isn't this however checking against the current (dynamic) number of
>>> runnable tasks/groups instead of the "static" group membership (which
>>> shouldn't be
On 20.04.2018 13:15, Matthew Wilcox wrote:
> On Thu, Apr 19, 2018 at 11:42:04PM +0200, Stefan Agner wrote:
>> With PHYS_ADDR_MAX there is now a type safe variant for all
>> bits set. Make use of it.
>
> There is? I don't see it in linux-next.
The patch "mm/memblock: introduce PHYS_ADDR_MAX" got
On Thu, Apr 19, 2018 at 11:42:04PM +0200, Stefan Agner wrote:
> With PHYS_ADDR_MAX there is now a type safe variant for all
> bits set. Make use of it.
There is? I don't see it in linux-next.
On 19.04.2018 04:58, Fengguang Wu wrote:
> FYI this happens in mainline kernel 4.17.0-rc1.
> It at least dates back to v4.5 .
This is likely the result of compiling the kernel with GCC 7 while
specifying that gcov-kernel should expect GCC <= 3.4 format data:
dmesg:
> (gcc version 7.3.0 (Debian 7.
On 2018-04-20 12:18, Laurent Pinchart wrote:
> Hello,
>
> On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
>> Hi Peter,
>> I've been a bit a pain in the arse for you recently, but please
>> bear with me a bit more, and sorry for jumping late on the band wagon.
>>
>> On Thu, Apr 19, 2
On 20/04/18 12:47, Stanislav Kinsburskii wrote:
> The overall idea of this patch is to add a generic fault injection facility
> to Xen, which later can be used in various places by different Xen parts.
>
> Core implementation ideas:
>
> - The facility build is controlled by boolean config
> CON
On 20/04/18 12:43, Kirill Tkhai wrote:
> On 20.04.2018 12:25, Juri Lelli wrote:
[...]
> > Isn't this however checking against the current (dynamic) number of
> > runnable tasks/groups instead of the "static" group membership (which
> > shouldn't be affected by a task running state)?
>
> Ah, you
On Fri, Apr 20, 2018 at 07:01:47PM +1000, Nicholas Piggin wrote:
> On Fri, 20 Apr 2018 09:44:56 +0200
> Peter Zijlstra wrote:
>
> > On Sun, Apr 15, 2018 at 11:31:49PM +1000, Nicholas Piggin wrote:
> > > This is a quick hack for comments, but I've always wondered --
> > > if we have a short term p
Hi Enric,
Am Donnerstag, 19. April 2018, 13:30:16 CEST schrieb Enric Balletbo i Serra:
> On 19/04/18 13:10, Heiko Stuebner wrote:
> > Am Donnerstag, 19. April 2018, 12:40:15 CEST schrieb Enric Balletbo i Serra:
> >> DDR3 SDRAM Standard (JESD79-3F) defines some standard speed bins for
> >> DDR3 mem
ping
I think get this fixed. Better sooner than later.
On 03/27/2018 03:42 AM, Dong Jia Shi wrote:
* Cornelia Huck [2018-03-26 14:28:39 +0200]:
[...]
By the way, since you will propose a new version,
you have a long description of the cp_prefetch function in the code.
I think you should m
On Fri, Apr 20, 2018 at 12:37:08PM +0200, Borislav Petkov wrote:
> Vitezslav reported a case where the
>
> "Timeout during microcode update!"
>
> panic would hit. After a deeper look, it turned out that his .config had
> CONFIG_HOTPLUG_CPU disabled which practically made save_mc_for_early() a
>
On Fri, Apr 20, 2018 at 12:34:28PM +0200, Borislav Petkov wrote:
> save_mc_for_early() was a no-op on !CONFIG_HOTPLUG_CPU but the
> generic_load_microcode() path saves the microcode patches it has found
> into our cache of patches which is used for late loading too. Regardless
> of whether we do CP
; [also build test ERROR on v4.17-rc1 next-20180420]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Peter-Rosin/Add-tda998x-HDMI-support-to-atmel
On Fri, Apr 20, 2018 at 01:38:33PM +0800, Ji Zhang wrote:
> When we dump the backtrace of some tasks there is a potential infinity
> loop if the content of the stack changed, no matter the change is
> because the task is running or other unexpected cases.
>
> This patch add stronger check on frame
/pub/scm/linux/kernel/git/next/linux-next.git/commit/tools/perf/pmu-events?h=next-20180420&id=e9d32c1bf0cd7a98358ec4aa1625bf2b3459b9ac
ARM64 chips use this feature. I am not familiar with the s390 arch, but
do you think you could also use this feature?
Thanks,
John
On 2018-04-20 12:41, kbuild test robot wrote:
> Hi Peter,
>
> I love your patch! Yet something to improve:
Yup, right you are!
> [auto build test ERROR on drm/drm-next]
> [also build test ERROR on v4.17-rc1 next-20180420]
> [if your patch is applied to the wrong git tree, ple
On 20.04.2018 11:52, Marc Dietrich wrote:
> Hi Marcel,
>
> Am Montag, 19. Februar 2018, 16:12:52 CEST schrieb Marcel Ziswiler:
>> From: Marcel Ziswiler
>>
>> Since commit f8f8f1d04494 ("clk: Don't touch hardware when reparenting
>> during registration") ULPI has been broken on Tegra20 leading to
This patch adds wrapper helpers around generic Xen fault inject
facility.
The major reason is to keep all the module fault injection directories
in a dedicated subdirectory instead of Xen fault inject root.
IOW, when using these helpers, per-device and named by device name
fault injection control
This series adds a facility, which can be used to instrument Xen code with
fault injections.
It is based "Fault injection capabilities infrastructure" described here:
- Documentation/fault-injection/fault-injection.txt
First patch adds a generic facility to use anywhere in Xen.
When using it all t
This patch adds wrapper helpers around generic Xen fault inject facility.
The major reason is to keep all the module fault injection directories
in a dedicated subdirectory instead of Xen fault inject root.
IOW, when using these helpers, per-device and named by device name fault
injection control
The overall idea of this patch is to add a generic fault injection facility
to Xen, which later can be used in various places by different Xen parts.
Core implementation ideas:
- The facility build is controlled by boolean config
CONFIG_XEN_FAULT_INJECTION option ("N" by default).
- All fault
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.17-rc2-tag
xen: fixes and one header update for 4.17-rc2
It contains some fixes of kmalloc() flags, one fix of the xenbus driver
and an update of the pv sound driver interface neede
Commit-ID: d7717587ac6deae00e0b66c0113a046be2c6fb1c
Gitweb: https://git.kernel.org/tip/d7717587ac6deae00e0b66c0113a046be2c6fb1c
Author: Stephane Eranian
AuthorDate: Fri, 23 Mar 2018 09:11:29 -0400
Committer: Thomas Gleixner
CommitDate: Fri, 20 Apr 2018 12:41:17 +0200
perf/x86/intel/unc
Am 20.04.2018 um 12:17 schrieb Christoph Hellwig:
On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote:
Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into dma-buf", but that doesn't ren
Commit-ID: ca2f6779608e364443cd82d31b1efd8b76f23bf6
Gitweb: https://git.kernel.org/tip/ca2f6779608e364443cd82d31b1efd8b76f23bf6
Author: Oskar Senft
AuthorDate: Fri, 23 Mar 2018 09:11:30 -0400
Committer: Thomas Gleixner
CommitDate: Fri, 20 Apr 2018 12:41:17 +0200
perf/x86/intel/uncore:
> +++ b/arch/nds32/kernel/stacktrace.c
> @@ -9,6 +9,7 @@ void save_stack_trace(struct stack_trace *trace)
> {
> save_stack_trace_tsk(current, trace);
> }
> +EXPORT_SYMBOL(save_stack_trace);
All other architectures use EXPORT_SYMBOL_GPL here.
Hi Peter,
I love your patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.17-rc1 next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
Remove the usage of IRQ_TYPE_NONE to fix loud warnings from
patch (83a86fbb5b56b "irqchip/gic: Loudly complain about
the use of IRQ_TYPE_NONE").
Signed-off-by: Thierry Escande
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 52 ++---
1 file changed, 26 insertions(+), 26
Vitezslav reported a case where the
"Timeout during microcode update!"
panic would hit. After a deeper look, it turned out that his .config had
CONFIG_HOTPLUG_CPU disabled which practically made save_mc_for_early() a
no-op.
When that happened, the discovered microcode patch wasn't saved into o
save_mc_for_early() was a no-op on !CONFIG_HOTPLUG_CPU but the
generic_load_microcode() path saves the microcode patches it has found
into our cache of patches which is used for late loading too. Regardless
of whether we do CPU hotplug or not.
So make the saving unconditional so that late loading
Also, please don't cross-post with moderated lists, that's just
annoying.
On Fri, Apr 20, 2018 at 12:01:31PM +0200, Vitezslav Samel wrote:
> > Ok, cleaned up patches with commit messages coming up.
>
> Good.
Ok, here they are as a reply to this message. I'm running them here, you
could run them one last time to make sure all is good.
@Ashok: please run them too, bef
On Fri, Mar 23, 2018 at 09:11:30AM -0400, Kan Liang wrote:
> @@ -3067,7 +3069,15 @@ void bdx_uncore_cpu_init(void)
> /* BDX-DE doesn't have SBOX */
> if (boot_cpu_data.x86_model == 86)
> uncore_msr_uncores[BDX_MSR_UNCORE_SBOX] = NULL;
> -
> + /* Detect systems with no
Andres Rodriguez writes:
> Currently the firmware loader only exposes one silent path for querying
> optional firmware, and that is firmware_request_direct(). This function
> also disables the fallback path, which might not always be the
> desired behaviour. [0]
>
> This patch introduces variatio
The presence of per TC performance counters is now detected by
cpu-probe.c and indicated by MIPS_CPU_MT_PER_TC_PERF_COUNTERS in
cpu_data. Switch detection of the feature to use this new flag rather
than blindly testing the implementation specific config7 register with a
magic number.
Signed-off-by
When perf is used in system mode, i.e. specifying a set of CPUs to
count (perf -a -C cpu), event->cpu is set to the CPU number on which
events should be counted. The current BMIPS500 variation of
mipsxx_pmu_enable_event only over sets the counter to count the current
CPU, so system mode does not wo
The vpe_id() macro is now used only in mipsxx_pmu_enable_event when
CONFIG_CPU_BMIPS5000 is defined. Fold the one used definition of the
macro into it's usage and remove the now unused definitions.
Since we know that cpu_has_mipsmt_pertccounters == 0 on BMIPS5000,
remove the test on it and just se
Previously when performance counters are per-core, rather than
per-thread, the number available were divided by 2 on detection, and the
counters used by each thread in a core were "swizzled" to ensure
separation. However, this solution is suboptimal since it relies on a
couple of assumptions:
a) Al
Andres Rodriguez writes:
> This reduces the unnecessary spew when trying to load optional firmware:
> "Direct firmware load for ... failed with error -2"
>
> Signed-off-by: Andres Rodriguez
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 7 ---
> 1 file changed, 4 inse
When perf is used in non-system mode, i.e. without specifying CPUs to
count on, check_and_calc_range falls into the case when it sets
M_TC_EN_ALL in the counter config_base. This has the impact of always
counting for all of the threads in a core, even when the user has not
requested it. For example
There are a couple of FIXME's in the perf code which state that
cpu_data[event->cpu].vpe_id reports 0 for both CPUs. This is no longer
the case, since the vpe_id is used extensively by SMP CPS.
VPE local counting gets around this by using smp_processor_id() instead.
As it happens this does work co
On Fri, Apr 20, 2018 at 01:06:49PM +0300, Laurent Pinchart wrote:
> Hi Peter,
>
> Thank you for the patch.
>
> On Thursday, 19 April 2018 19:27:51 EEST Peter Rosin wrote:
> > This makes this driver work with all(?) drivers that are not
> > componentized and instead expect to connect to a panel/br
Hi Christoph,
Nice cleanup! Looks good overall, just a couple of nits.
On 20/04/18 09:02, Christoph Hellwig wrote:
[...]
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 7f5cdc1e6b29..712a897174e4 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -41,6 +41,11 @@
#define HASH_FN_SHIFT
Processors implementing the MIPS MT ASE may have performance counters
implemented per core or per TC. Processors implemented by MIPS
Technologies signify presence per TC through a bit in the implementation
specific Config7 register. Currently the code which probes for their
presence blindly reads a
This series addresses a few issues with how the MIPS performance
counters code supports the hardware multithreading MT ASE.
Firstly, implementations of the MT ASE may implement performance
counters
per core or per thread(TC). MIPS Techologies implementations signal this
via a bit in the implmentat
On Thu 19-04-18 21:37:25, Dexuan Cui wrote:
> > From: Jan Kara
> > Sent: Thursday, April 19, 2018 13:23
> > Good news guys, Robert has just spotted a bug which looks like what I'd
> > expect can cause your lockups / crashes. I've merged his patch to my tree
> > and will push it to Linus for -rc3 so
Some displays on SUN4i devices wouldn't properly stay on unless
'clk_ignore_unused' is used.
Change the duplicate clocks to the probably intended ones.
Signed-off-by: Pascal Roeleven
---
arch/arm/boot/dts/sun4i-a10.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/
Some displays on SUN4i devices wouldn't properly stay on unless
'clk_ignore_unused' is used.
Change the duplicate clocks to the probably intended ones.
Signed-off-by: Pascal Roeleven
---
arch/arm/boot/dts/sun4i-a10.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/
Hi Tomi,
On 20 April 2018 at 08:09, Tomi Valkeinen wrote:
> It's actually not quite clear to me how manual update displays work with
> DRM...
>
> As far as I see, we have essentially two cases: 1) single buffering,
> where the userspace must set an area in the fb dirty, which then
> triggers the
(adding linux-wireless and ath10k lists)
Andres Rodriguez writes:
> This reduces the unnecessary spew when trying to load optional firmware:
> "Direct firmware load for ... failed with error -2"
>
> Signed-off-by: Andres Rodriguez
> ---
> drivers/net/wireless/ath/ath10k/core.c | 2 +-
> 1 file
601 - 700 of 936 matches
Mail list logo
