On Thu, Mar 7, 2019 at 10:53 AM Michael S. Tsirkin wrote:
>
> On Thu, Mar 07, 2019 at 10:45:58AM -0800, Alexander Duyck wrote:
> > To that end what I think w may want to do is instead just walk the LRU
> > list for a given zone/order in reverse order so that we can try to
> > identify the pages
Hi!
I should have read Kens code more carefully, before signing off on it...
Review comments inline...
On 2019-03-07 00:15, Peter Rosin wrote:
> Heavily based on code from Ken Chen .
>
> Signed-off-by: Peter Rosin
> ---
> drivers/i2c/muxes/Kconfig | 6 +-
>
On Thu, Mar 07, 2019 at 08:49:34AM +1100, Tobin C. Harding wrote:
> On Thu, Mar 07, 2019 at 08:42:19AM +1100, Tobin C. Harding wrote:
> > Hi,
>
> Man, I didn't see the merge window was open, I thought rc8 only came out
> on Sunday.
>
> Sorry, please ignore this. Will re-send again later in the
> -Original Message-
> From: Kirti Wankhede
> Sent: Thursday, March 7, 2019 3:08 PM
> To: Parav Pandit ; Jakub Kicinski
>
> Cc: Or Gerlitz ; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; michal.l...@markovi.net; da...@davemloft.net;
> gre...@linuxfoundation.org; Jiri Pirko ;
On Mar 7, 2019, Aaro Koskinen wrote:
> Hi,
> On Thu, Mar 07, 2019 at 03:41:01AM -0300, Alexandre Oliva wrote:
>> On Feb 17, 2019, "Maciej W. Rozycki" wrote:
>>
>> > Is there an MMIO completion barrier missing there somewhere by any chance
>> > causing an IRQ that has been handled already to
From: Yazen Ghannam
Export the smca_get_bank_type() function so it can be used in the AMD
MCE decoder module.
Cc: # 4.14.x
Signed-off-by: Yazen Ghannam
---
arch/x86/include/asm/mce.h| 1 +
arch/x86/kernel/cpu/mce/amd.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git
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.
Hello Jerome,
On Thu, Mar 07, 2019 at 03:17:22PM -0500, Jerome Glisse wrote:
> So for the above the easiest thing is to call set_page_dirty() from
> the mmu notifier callback. It is always safe to use the non locking
> variant from such callback. Well it is safe only if the page was
> map with
When building with -Wsometimes-uninitialized, Clang warns:
arch/x86/kernel/hw_breakpoint.c:355:2: warning: variable 'align' is used
uninitialized whenever switch default is taken
[-Wsometimes-uninitialized]
It's not wrong but we can see that arch_build_bp_info will only ever
initialize hw->len
On 07.03.19 22:14, Alexander Duyck wrote:
> On Thu, Mar 7, 2019 at 10:53 AM Michael S. Tsirkin wrote:
>>
>> On Thu, Mar 07, 2019 at 10:45:58AM -0800, Alexander Duyck wrote:
>>> To that end what I think w may want to do is instead just walk the LRU
>>> list for a given zone/order in reverse order
Hi Sowjanya,
On 02/03/2019 05:20, Sowjanya Komatineni wrote:
> ddr_signaling is set to true for DDR50 and DDR52 modes but is
> not set back to false for other modes. This programs incorrect
> host clock when mode change happens from DDR52/DDR50 to other
> SDR or HS modes like incase of mmc_retune
On Thu, Mar 7, 2019 at 11:30 AM David Hildenbrand wrote:
>
> On 07.03.19 20:23, Nitesh Narayan Lal wrote:
> >
> > On 3/7/19 1:30 PM, Alexander Duyck wrote:
> >> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal
> >> wrote:
> >>> This patch enables the kernel to scan the per cpu array
> >>>
On Thu, Mar 07, 2019 at 10:39:23AM +0100, Geert Uytterhoeven wrote:
> On Thu, Mar 7, 2019 at 10:00 AM Jani Nikula
> wrote:
> > It's possible to do this using a reboot notifier. I am not sure if there
> > are better ways to achieve the same, but there's at least one example of
> > using reboot
This is only used within drivers/pci, and there is no reason to make
it available outside of the PCI core.
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/pci-acpi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index
Every decade or so, give or take a decade, our ACPI overlords realize
that the table they so generously gifted us is not really that useful.
Not to be outdone, they make a betterer version of it, which seems
like a good idea at the time. This is the story of the _HPX3 (well,
most of ACPI really).
We used to first parse all the _HPP and _HPX tables before using the
information to program registers of PCIe devices. Up until HPX type 2,
there was only one structure of each type, so we could cheat and store
it on the stack.
With HPX type 3 we get an arbitrary number of entries, so the above
_HPX Type 3 is intended to be more generic and allow configuration of
settings not possible with Type 2 tables. For example, FW could ensure
that the completion timeout value is set accordingly throughout the PCI
tree.
Implement support for _HPX3 tables.
Signed-off-by: Alexandru Gagniuc
---
The pull request you sent on Thu, 7 Mar 2019 07:52:18 -0800:
> git://github.com/jcmvbkbc/linux-xtensa.git tags/xtensa-20190307
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dd1c3ed76f26504621b5ce08b894666aafa38e47
Thank you!
--
Deet-doot-dot, I am a bot.
ht
The pull request you sent on Tue, 05 Mar 2019 13:42:15 -0800 (PST):
> git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git
> tags/riscv-for-linus-5.1-mw0
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d72cb8c7d9dbd9ce820c80f3fddb56b296ba96fc
Thank
On 07.03.19 22:32, Alexander Duyck wrote:
> On Thu, Mar 7, 2019 at 11:30 AM David Hildenbrand wrote:
>>
>> On 07.03.19 20:23, Nitesh Narayan Lal wrote:
>>>
>>> On 3/7/19 1:30 PM, Alexander Duyck wrote:
On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal
wrote:
> This patch enables
The pull request you sent on Fri, 08 Mar 2019 00:12:51 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-5.1-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6c3ac1134371b51c9601171af2c32153ccb11100
Thank you!
--
On Thu, 7 Mar 2019, Geert Uytterhoeven wrote:
> On Thu, Mar 7, 2019 at 3:59 AM Finn Thain wrote:
> > On Tue, 5 Mar 2019, Andreas Schwab wrote:
> > > On Mar 05 2019, Finn Thain wrote:
> > >
> > > > interesting that the kernel's strlen implementation in
> > > > include/linux/string.h can't
Both the capture and playback channels are optional in the axi_i2s IP
block. Document how to tell the driver which channels are
instantiated.
Signed-off-by: Luca Ceresoli
---
Documentation/devicetree/bindings/sound/adi,axi-i2s.txt | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Both the capture and playback channels are optional in the axi_i2s IP
block. Reflect this in the driver by enabling only the channel(s) that
have a DMA.
Signed-off-by: Luca Ceresoli
---
sound/soc/adi/axi-i2s.c | 68 +
1 file changed, 48 insertions(+), 20
On Thu, Mar 7, 2019 at 5:46 PM Oleg Nesterov wrote:
>
> On 03/07, Arnd Bergmann wrote:
> >
> > We could use % everywhere,
>
> Yes.
>
> But again, why not simply use the "for (;;)" loops? Why we can't kill the
> supid switch(_NSIG_WORDS) tricks altogether?
I'd have to try, but I think you are
When building with -Wsometimes-uninitialized, Clang warns:
drivers/iio/common/ssp_sensors/ssp_iio.c:95:6: warning: variable
'calculated_time' is used uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
While it isn't wrong, this will never be a problem because
From: kbuild test robot
Use BUG_ON instead of if condition followed by BUG.
Generated by: scripts/coccinelle/misc/bugon.cocci
Fixes: c105b7abf400 ("ath11k: collect DDR dump after fw crash")
CC: Venkateswara Naralasetty
Signed-off-by: kbuild test robot
Signed-off-by: Julia Lawall
---
tree:
Cc: Michael Schmitz
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 01c23d27f290..7fed9bb72784 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@
Adjust comments accordingly.
Cc: Gustavo A. R. Silva
Cc: Michael Schmitz
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 7fed9bb72784..fe0535affc14 100644
---
On Wed, 2019-03-06 at 22:48 -0800, Manoj Srivastava wrote:
> Hi,
>
> Does this have any users? I can take a stand at making it work, but I am
> unsure of there are enough people interested in make-kpkg anymore to make
> it worthwhile.
>
> There is a man pager that might be of minor interest,
On 3/8/2019 2:51 AM, Parav Pandit wrote:
>
>
>> -Original Message-
>> From: Kirti Wankhede
>> Sent: Thursday, March 7, 2019 3:08 PM
>> To: Parav Pandit ; Jakub Kicinski
>>
>> Cc: Or Gerlitz ; net...@vger.kernel.org; linux-
>> ker...@vger.kernel.org; michal.l...@markovi.net;
On Thu, Mar 7, 2019 at 6:46 PM David Miller wrote:
>
> From: Arnd Bergmann
> Date: Thu, 7 Mar 2019 16:58:35 +0100
>
> > clang inlines the dev_ethtool() more aggressively than gcc does, leading
> > to a larger amount of used stack space:
> >
> > net/core/ethtool.c:2536:24: error: stack frame
On 22/02/19 15:10, Peter Zijlstra wrote:
>> I agree on not bike shedding about the API, but can we agree on some of
>> the high level properties? For example, who generates the core
>> scheduling ids, what properties about them are enforced, etc.?
> It's an opaque cookie; the scheduler really
When switching from speakup_soft to another synth, speakup_soft would
keep calling synth_buffer_getc() from softsynthx_read.
Let's thus make synth.c export the knowledge of the current synth, so
that speakup_soft can determine whether it should be running.
speakup_soft also needs to set itself
On Thu, Mar 07, 2019 at 07:08:34PM +0100, Andrea Righi wrote:
> Keep track of the inodes that have been dirtied by each blkcg cgroup and
> make sure that a blkcg issuing a sync() can trigger the writeback + wait
> of only those pages that belong to the cgroup itself.
>
> This behavior is applied
Add the lm3532 device tree documentation.
Remove lm3532 device tree reference from the ti_lmu devicetree
documentation.
With the addition of the dedicated lm3532 documentation the device
can be removed from the ti_lmu.txt.
The reason for this is that the lm3532 dt documentation now defines
the
Introduce the Texas Instruments LM3532 White LED driver.
The driver supports ALS configurability or manual brightness
control.
The driver also supports associating LED strings with specific
control banks in a group or as individually controlled strings.
Signed-off-by: Dan Murphy
---
Remove the LM3532 backlight driver references from the ti-lmu
code as dedicated driver support is available.
Signed-off-by: Dan Murphy
---
drivers/mfd/ti-lmu.c | 11 ---
include/linux/mfd/ti-lmu.h | 1 -
2 files changed, 12 deletions(-)
diff --git a/drivers/mfd/ti-lmu.c
Update the properties for the lm3532 device node for droid4.
With this change the backlight LED string and the keypad
LED strings will be controlled separately.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/omap4-droid4-xt894.dts | 27 +---
1 file changed, 19
On Thu, Mar 07, 2019 at 07:08:32PM +0100, Andrea Righi wrote:
> Prevent priority inversion problem when a high-priority blkcg issues a
> sync() and it is forced to wait the completion of all the writeback I/O
> generated by any other low-priority blkcg, causing massive latencies to
> processes
When building with -Wsometimes-uninitialized, Clang warns:
drivers/md/bcache/alloc.c:333:4: warning: variable 'bucket' is used
uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
fifo_pop expands to a conditional depending on '!fifo_empty(...)', which
is the same condition
On Thu, Mar 07, 2019 at 07:08:33PM +0100, Andrea Righi wrote:
> Add a flag to the blkcg cgroups to make sync()'ers in a cgroup only be
> allowed to write out pages that have been dirtied by the cgroup itself.
>
> This flag is disabled by default (meaning that we are not changing the
> previous
Hi.
On 07.03.2019 17:25, Paolo Valente wrote:
since I didn't make it to submit these ones for 5.1, let me be
early for 5.2 :)
These patches fix some bug affecting performance, reduce execution
time a little bit, and boost throughput and responsiveness.
They are meant to be applied on top of
On 07.03.19 21:55, Greg KH wrote:
> Ick, no, no more squashfs please, let's just kill that mess once and for
> all :)
okay, then: s/squashfs/whatever_fs_image_or_archive_you_like/;
> Again, putting this in a simple compressed tar image allows anyone to do
> whatever they need to with this. If
On 06.03.19 22:43, Richard Weinberger wrote:
> Am Mittwoch, 6. März 2019, 19:32:44 CET schrieb Enrico Weigelt, metux IT
> consult:
>
> Here please also a changelog. :-)
Sorry, forgotten that :o
Those things happen if you're doing the same thing a hundred times
(yes, I took the time to go
The following changes since commit
0358affb5cd8bbd685a6ab163a36dd28a818da73:
Documentation: change linux-4.x references to 5.x (2019-02-17 15:41:05 -0700)
are available in the Git repository at:
git://git.lwn.net/linux.git tags/docs-5.1
for you to fetch changes up to
Formatting of Kconfig files doesn't look so pretty, so just
take damp cloth and clean it up. Just indention changes.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/sh/Kconfig| 24
arch/sh/boards/Kconfig | 10 +-
arch/sh/mm/Kconfig | 6
On Thu, Mar 7, 2019 at 1:28 PM David Hildenbrand wrote:
>
> On 07.03.19 22:14, Alexander Duyck wrote:
> > On Thu, Mar 7, 2019 at 10:53 AM Michael S. Tsirkin wrote:
> >>
> >> On Thu, Mar 07, 2019 at 10:45:58AM -0800, Alexander Duyck wrote:
> >>> To that end what I think w may want to do is
Formatting of Kconfig files doesn't look so pretty, so just
take damp cloth and clean it up. Just indention changes.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/um/drivers/Kconfig | 352
1 file changed, 176 insertions(+), 176
On Thu, Mar 7, 2019 at 7:21 PM Nathan Chancellor
wrote:
>
> On Thu, Mar 07, 2019 at 10:12:11AM -0800, Nick Desaulniers wrote:
> > On Thu, Mar 7, 2019 at 1:15 AM Arnd Bergmann wrote:
> > >
> > > On 32-bit ARM, I got a link failure in futex_init() when building
> > > with clang in some random
When building with -Wsometimes-uninitialized, Clang warns:
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3964:7: warning: variable
'handle' is used uninitialized whenever '?:' condition is false
[-Wsometimes-uninitialized]
It's not wrong; however, in practice, this is never an issue because
the value
On Wed, Feb 13, 2019 at 4:18 AM Mimi Zohar wrote:
> - if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot())
> + if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
> + if (IS_ENABLED(CONFIG_MODULE_SIG))
> +
On Mon, Nov 19, 2018 at 11:57 AM Mimi Zohar wrote:
>
> The secure boot mode may not be detected on boot for some reason (eg.
> buggy firmware). This patch attempts one more time to detect the
> secure boot mode.
Do we have cases where this has actually been seen? I'm not sure what
the
> -Original Message-
> From: Kirti Wankhede
> Sent: Thursday, March 7, 2019 4:02 PM
> To: Parav Pandit ; Jakub Kicinski
>
> Cc: Or Gerlitz ; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; michal.l...@markovi.net; da...@davemloft.net;
> gre...@linuxfoundation.org; Jiri Pirko ;
On Thu, Mar 07, 2019 at 08:51:23AM -0800, Andi Kleen wrote:
> On Thu, Mar 07, 2019 at 04:35:00PM +0100, Jiri Olsa wrote:
> > On Tue, Mar 05, 2019 at 08:40:17AM -0800, Andi Kleen wrote:
> > > On Tue, Mar 05, 2019 at 05:28:54PM +0100, Jiri Olsa wrote:
> > > > On Tue, Mar 05, 2019 at 08:13:19AM
On Thu, 2019-03-07 at 14:27 -0800, Matthew Garrett wrote:
> On Wed, Feb 13, 2019 at 4:18 AM Mimi Zohar wrote:
> > - if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot())
> > + if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) &&
> > arch_ima_get_secureboot()) {
> > +
On Thu, Mar 7, 2019 at 1:40 PM David Hildenbrand wrote:
>
> On 07.03.19 22:32, Alexander Duyck wrote:
> > On Thu, Mar 7, 2019 at 11:30 AM David Hildenbrand wrote:
> >>
> >> On 07.03.19 20:23, Nitesh Narayan Lal wrote:
> >>>
> >>> On 3/7/19 1:30 PM, Alexander Duyck wrote:
> On Wed, Mar 6,
When building with -Wsometimes-uninitialized, Clang warns:
drivers/pwm/pwm-img.c:126:13: error: variable 'timebase' is used
uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
The final else if functions as an else; make that explicit so that Clang
understands that
On Thu, Mar 7, 2019 at 2:34 PM Mimi Zohar wrote:
>
> On Thu, 2019-03-07 at 14:27 -0800, Matthew Garrett wrote:
> > On Wed, Feb 13, 2019 at 4:18 AM Mimi Zohar wrote:
> > > - if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) &&
> > > arch_ima_get_secureboot())
> > > + if
On Thu, 2019-03-07 at 14:36 -0800, Matthew Garrett wrote:
> On Thu, Mar 7, 2019 at 2:34 PM Mimi Zohar wrote:
> >
> > On Thu, 2019-03-07 at 14:27 -0800, Matthew Garrett wrote:
> > > On Wed, Feb 13, 2019 at 4:18 AM Mimi Zohar wrote:
> > > > - if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) &&
> > >
On Thu, Mar 7, 2019 at 1:19 PM Tobin C. Harding wrote:
>
> On Thu, Mar 07, 2019 at 08:49:34AM +1100, Tobin C. Harding wrote:
> > On Thu, Mar 07, 2019 at 08:42:19AM +1100, Tobin C. Harding wrote:
> > > Hi,
> >
> > Man, I didn't see the merge window was open, I thought rc8 only came out
> > on
On Thu, Mar 7, 2019 at 2:38 PM Justin Forbes wrote:
> On Thu, Mar 7, 2019 at 4:29 PM Matthew Garrett wrote:
>>
>> On Mon, Nov 19, 2018 at 11:57 AM Mimi Zohar wrote:
>> >
>> > The secure boot mode may not be detected on boot for some reason (eg.
>> > buggy firmware). This patch attempts one
On Thu, Mar 7, 2019 at 2:41 PM Mimi Zohar wrote:
> On Thu, 2019-03-07 at 14:36 -0800, Matthew Garrett wrote:
> > Right, but how is this different to what Linus was objecting to?
>
> Both Andy Lutomirski and Linus objected to limiting the "lockdown"
> patch set to secure boot enabled systems.
No,
On Thu, 2019-03-07 at 14:44 -0800, Matthew Garrett wrote:
> On Thu, Mar 7, 2019 at 2:38 PM Justin Forbes wrote:
> > On Thu, Mar 7, 2019 at 4:29 PM Matthew Garrett wrote:
> >>
> >> On Mon, Nov 19, 2018 at 11:57 AM Mimi Zohar wrote:
> >> >
> >> > The secure boot mode may not be detected on boot
On Thu, Mar 7, 2019 at 2:48 PM Mimi Zohar wrote:
> I added this last attempt because I'm seeing this on my laptop, with
> some older, buggy firmware.
Is the issue that it gives incorrect results on the first read, or is
the issue that it gives incorrect results before ExitBootServices() is
When building with -Wsometimes-uninitialized, Clang warns:
drivers/soc/mediatek/mtk-pmic-wrap.c:1358:6: error: variable 'rdata' is
used uninitialized whenever '||' condition is true
[-Werror,-Wsometimes-uninitialized]
If pwrap_write returns non-zero, pwrap_read will not be called to
initialize
A cgroup can remain in the dying state for a long time, being pinned in the
memory by any kernel object. It can be pinned by a page, shared with other
cgroup (e.g. mlocked by a process in the other cgroup). It can be pinned
by a vfs cache object, etc.
Mostly because of percpu data, the size of a
Prepare to handle premature release of memcg->vmstats_percpu data.
Currently it's a generic pointer which is expected to be non-NULL
during the whole life time of a memcg. Switch over to the
rcu-protected pointer, and carefully check it for being non-NULL.
This change is a required step towards
Similar to memcg-level statistics, per-node data isn't expected
to be hot after cgroup removal. Switching over to atomics and
prematurely releasing percpu data helps to reduce the memory
footprint of dying cgroups.
Signed-off-by: Roman Gushchin
---
include/linux/memcontrol.h | 1 +
Similar to the memcg's vmstats_percpu, per-memcg per-node stats
consists of percpu- and atomic counterparts, and we do expect
that both coexist during the whole life-cycle of the memcg.
To prepare for a premature release of percpu per-node data,
let's pretend that lruvec_stat_cpu is a
Spill percpu stats and events data to corresponding before releasing
percpu memory.
Although per-cpu stats are never exactly precise, dropping them on
floor regularly may lead to an accumulation of an error. So, it's
safer to sync them before releasing.
To minimize the number of atomic updates,
To reduce the memory footprint of a dying memory cgroup, let's
release massive percpu data (vmstats_percpu) as early as possible,
and use atomic counterparts instead.
A dying cgroup can remain in the dying state for quite a long
time, being pinned in memory by any reference. For example,
if a
Hello,
On Thu, Mar 7, 2019 at 12:37 PM Hans de Goede wrote:
>
> Hi,
>
> On 07-03-19 21:27, Gwendal Grignou wrote:
> > Srinivas,
> >
> > I am looking at problem on a laptop machine that suspends to S01x, but
> > link_management is set to max_performance, because the machine is
> > connected to a
Enrico,
On Thu, Mar 07, 2019 at 11:11:22PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 07.03.19 21:55, Greg KH wrote:
>
> > Ick, no, no more squashfs please, let's just kill that mess once and for
> > all :)
>
> okay, then: s/squashfs/whatever_fs_image_or_archive_you_like/;
>
> >
On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong wrote:
>
> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
> Scrambling when supported or mandatory.
>
> This patch also adds an helper to setup the control bit to support
> the high TMDS Bit Period/TMDS Clock-Period Ratio as
-Original Message-
> From: platform-driver-x86-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Jiaxun Yang
> Sent: Thursday, March 7, 2019 2:08 AM
> To: ibm-a...@hmh.eng.br
> Cc: dvh...@infradead.org; a...@infradead.org; ibm-acpi-
> de...@lists.sourceforge.net;
When building with -Wsometimes-uninitialized, Clang warns:
drivers/scsi/qla4xxx/ql4_os.c:5915:7: warning: variable 'buf_dma' is
used uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
Don't call dma_free_coherent when buf is NULL, meaning that we never
called
When building with -Wsometimes-uninitialized, Clang warns:
drivers/scsi/gdth.c:3662:6: warning: variable 'paddr' is used
uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
Don't attempt to call dma_free_coherent when buf is NULL (meaning that
we never called
Would you consider this more reliable than the make install_headers,
and am curious about DKMS applications / whether this should be
preferable to the /lib/modules/kernver/biuld symlinks
On Wed, Mar 6, 2019 at 6:48 AM Masahiro Yamada
wrote:
>
> On Mon, Mar 4, 2019 at 1:15 AM Joel Fernandes
On 03/07, Song Liu wrote:
> Both libbfd and libopcodes are distributed with binutil-dev/devel. When
> libbfd presents, it is OK to assume libopcodes also presents. This has
> been a safe assumption for bpftool.
>
> This patch adds -lopcodes to perf/Makefile.config. libopcodes will be
> used in
When building with -Wsometimes-uninitialized, Clang warns:
drivers/net/ethernet/sun/niu.c:7466:5: warning: variable 'class' is used
uninitialized whenever switch default is taken
[-Wsometimes-uninitialized]
The default case can never happen because i can only be 0 to 3
(NIU_L3_PROG_CLS is
On Thu, 7 Mar 2019 14:44:00 -0300
Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> 'perf probe' supports using just the kernel module name, but that will
> work only when the module is loaded, or using the full pathname to the
> file with the DWARF debug info, but the
On Thu, Mar 07, 2019 at 10:20:09AM -0800, Matthias Kaehlcke wrote:
> Hi Balakrishna,
>
> On Thu, Mar 07, 2019 at 10:35:08AM +0530, Balakrishna Godavarthi wrote:
> > hi Matthias,
> >
> > On 2019-03-07 06:10, Matthias Kaehlcke wrote:
> > > Firmware download to the WCN3990 often fails with a 'TLV
Only providing the input and output RGB/YUV space to the IC task init
functions is not sufficient. To fully characterize a colorspace
conversion, the colorspace (chromaticities), Y'CbCr encoding standard,
and quantization also need to be specified.
Define a 'struct ipu_ic_colorspace' that
The ycbcr2rgb and inverse rgb2ycbcr tables define the BT.601 Y'CbCr
encoding coefficients.
The rgb2ycbcr table specifically describes the BT.601 encoding from
full range RGB to full range YUV. Add table comments to make this more
clear.
The ycbcr2rgb inverse table describes encoding YUV limited
The IC now supports BT.709 Y'CbCr encoding, in addition to existing BT.601
encoding, so allow both, for pipelines that route through the IC.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v5:
- rebased this patch on top of repurposing the function to
Add support for the following conversions:
- YUV full-range to YUV limited-range
- YUV limited-range to YUV full-range
- YUV limited-range to RGB full-range
- RGB full-range to YUV limited-range
The last two conversions require operating on the YUV full-range
encoding and inverse encoding
Add support for Rec.709 encoding and inverse encoding.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v5:
- moved API changes to a previous patch.
- moved CSC coeff calc to new function calc_csc_coeffs().
Changes in v4:
- fix compile error.
Chnges in v3:
- none.
Changes
The saturation bit was being set at bit 9 in the second 32-bit word
of the TPMEM CSC. This isn't correct, the saturation bit is bit 42,
which is bit 10 of the second word.
Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")
Signed-off-by: Steve Longerbeam
Cc: sta...@vger.kernel.org
The colorimetry parameters need to be tested at both sink and source
pads. Specifically, for prpencvf, the IC only supports RGB full-range
quantization at input and output.
Fix this by cleaning up imx_media_fill_default_mbus_fields(), renaming
to imx_media_try_colorimetry(), and call it at both
It's been 1.5 weeks. Could I get some feedback on this patch? Thanks.
On 02/25/2019 11:59 AM, eugene@oracle.com wrote:
From: Eugene Loh
When a module is loaded, its symbols' Elf_Sym information is stored
in a symtab. Further, type information is also captured. Since
Elf_Sym has no
On March 7, 2019 3:12:07 PM PST, Joel Fernandes wrote:
>Enrico,
>
>On Thu, Mar 07, 2019 at 11:11:22PM +0100, Enrico Weigelt, metux IT
>consult wrote:
>> On 07.03.19 21:55, Greg KH wrote:
>>
>> > Ick, no, no more squashfs please, let's just kill that mess once
>and for
>> > all :)
>>
>> okay,
Hello,
syzbot found the following crash on:
HEAD commit:1fc1cd8399ab Merge branch 'for-5.1' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10dab41b20
kernel config: https://syzkaller.appspot.com/x/.config?x=83f72881c3c30b7c
Dear friend,
I know that this letter may be a very big surprise to you, My name is
Mr. Frank Yacouba, Head of file Department in Africa Develop bank
Burkina Faso. I need your sincere cooperation to transfer the sum of
$15 million U.S.A dollars to your bank account.
I want you stand as next of
> On Mar 7, 2019, at 3:26 PM, Stanislav Fomichev wrote:
>
> On 03/07, Song Liu wrote:
>> Both libbfd and libopcodes are distributed with binutil-dev/devel. When
>> libbfd presents, it is OK to assume libopcodes also presents. This has
>> been a safe assumption for bpftool.
>>
>> This patch
On Thu, Mar 07, 2019 at 11:39:08AM -0800, Nick Desaulniers wrote:
> On Thu, Mar 7, 2019 at 1:15 AM Arnd Bergmann wrote:
> >
> > Passing registers containing zero as both the address (NULL pointer)
> > and data into cmpxchg_futex_value_locked() leads clang to assign
> > the same register for both
IS_ENABLED should generally use CONFIG_ prefaced symbols and
it doesn't appear as if there is a BLK_DEV_INITRD define.
Signed-off-by: Joe Perches
---
arch/s390/boot/mem_detect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/boot/mem_detect.c
Adding others on Cc to see if they have comments or opinions.
On 3/6/19 3:52 PM, Mike Kravetz wrote:
> On 3/5/19 10:10 PM, Yufen Yu wrote:
>> When .mknod create a block device file in hugetlbfs, it will
>> allocate an inode, and kmalloc a 'struct resv_map' in resv_map_alloc().
>> For now,
On Thu, 7 Mar 2019 00:44:54 -0800
Neo Jia wrote:
> On Fri, Feb 22, 2019 at 10:19:27AM +0800, Lu Baolu wrote:
> > This adds the support to determine the isolation type
> > of a mediated device group by checking whether it has
> > an iommu device. If an iommu device exists, an iommu
> > domain
IS_ENABLED should generally use CONFIG_ prefaced symbols and
it doesn't appear as if there is a CMODEL_MEDLOW define.
Signed-off-by: Joe Perches
---
arch/riscv/kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/module.c
1 - 100 of 1012 matches
Mail list logo
