Hi Liang,
On Wed, Mar 20, 2019 at 4:32 AM Liang Yang wrote:
>
> Hi Martin,
>
> Thanks for your time.
> On 2019/3/20 4:27, Martin Blumenstingl wrote:
> > Hello Liang,
> >
> > On Sat, Mar 16, 2019 at 11:55 AM Martin Blumenstingl
> > wrote:
> > [...]
> >>> Martin, Now i am not sure whether NFC driv
Hi Guenter,
In commit
9940b52b73e4 ("hwmon: (occ) Fix power sensor indexing")
Fixes tag
Fixes: 54076cb ("hwmon (occ): Add sensor attributes and register ...")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for g
Due to has_unmovable_pages() takes an incorrect irqsave flag instead of
the isolation flag in set_migratetype_isolate(), it causes issues with
HWPOSION and error reporting where dump_page() is not called when there
is an unmoveable page.
Fixes: d381c54760dc ("mm: only report isolation failures whe
On Wed, Mar 20, 2019 at 1:47 PM Christian Brauner wrote:
>
> On Wed, Mar 20, 2019 at 11:39:10PM +0300, Alexey Dobriyan wrote:
> > On Wed, Mar 20, 2019 at 01:14:01PM -0700, Daniel Colascione wrote:
> > > On Wed, Mar 20, 2019 at 1:07 PM Alexey Dobriyan
> > > wrote:
> > > > > What would be your opi
On Wed, Mar 20, 2019 at 1:47 PM Stephane Eranian wrote:
>
> On Tue, Mar 19, 2019 at 11:20 AM Peter Zijlstra wrote:
> >
> > On Tue, Mar 19, 2019 at 10:52:01AM -0700, Stephane Eranian wrote:
> > > > Not quite; the control on its own doesn't directly write the MSR. And
> > > > even when the work-aro
[+cc Jon, Jens, Christoph, Sagi, Linus, linux-nvme from related discussion]
[+cc Greg, Oliver, who responded to v2 of this patch]
On Fri, Feb 22, 2019 at 01:48:06PM -0600, Alexandru Gagniuc wrote:
> A SURPRISE removal of a hotplug PCIe device, caused by a Link Down
> event will execute an orderly
Hi Maxime,
On Wed, Mar 20, 2019 at 12:16 PM Maxime Jourdan wrote:
>
> Hi Martin, thanks for looking into the video decoder for meson8!
you're welcome - this is only possible because of your work on the
video decoder driver!
> On Tue, Mar 19, 2019 at 11:00 PM Martin Blumenstingl
> wrote:
> >
> >
On Tue, 19 Mar 2019 16:31:21 +
Alan Cox wrote:
> On Sat, 16 Mar 2019 10:35:43 +0100
> Samuel Thibault wrote:
>
> > Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > > Okash Khawaja writes:
> > > > Finally there is an issue where text in output buffer sometimes
> > > >
Hi all,
In commit
f4d0dd1064b8 ("NTB: ntb_transport: Ensure qp->tx_mw_dma_addr is initaliazed")
Fixes tag
Fixes: c27ccb899219 ("NTB: ntb_transport: Ensure the destination buffer is
mapped for TX DMA")
has these problem(s):
- Target SHA1 does not exist
Did you mean:
c59666bb32b9 ("N
On Wed, Mar 20, 2019 at 01:50:43PM -0700, Daniel Colascione wrote:
> On Wed, Mar 20, 2019 at 1:47 PM Christian Brauner
> wrote:
> >
> > On Wed, Mar 20, 2019 at 11:39:10PM +0300, Alexey Dobriyan wrote:
> > > On Wed, Mar 20, 2019 at 01:14:01PM -0700, Daniel Colascione wrote:
> > > > On Wed, Mar 20,
On 2019-03-20 2:58 p.m., Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> f4d0dd1064b8 ("NTB: ntb_transport: Ensure qp->tx_mw_dma_addr is
> initaliazed")
>
> Fixes tag
>
> Fixes: c27ccb899219 ("NTB: ntb_transport: Ensure the destination buffer is
> mapped for TX DMA")
>
> has these
On 3/20/2019 9:27 PM, Aditya Pakki wrote:
Memory allocated via kmemdup might fail and return a NULL pointer.
This patch adds a check on the return value of kmemdup and passes the
error upstream.
Signed-off-by: Aditya Pakki
---
v1: Missed check on tb_sw_read, suggested by Mukesh
---
drivers
On Wed, Mar 20, 2019 at 12:57:52PM -0700, Xing, Cedric wrote:
> > Using the untrusted stack as a way to exchange data is very convenient,
> > but that doesn't mean it's a good idea. Here are some problems it
> > causes:
> >
> > - It prevents using a normal function to wrap enclave entry (as we'r
Hi!
Am Mittwoch, 20. März 2019, 21:20:51 CET schrieb Gustavo A. R. Silva:
> Hi all,
>
> Friendly ping:
>
> Who can take this?
Hmmm, for MTD I think we can schedule these patches for the next merge window.
But I'm not sure whether these comments are a good solution.
I much more prefer the compil
Am Mittwoch, 20. März 2019, 03:46:33 CET schrieb yang.yan...@zte.com.cn:
> Hi Richard:
>
>
>
>Is the patch make any progress ?
Well, you ignored my questions.
Can you please check my last mail?
Thanks,
//richard
[+cc Jon, Dave, Allen (NTB core maintainers)]
Hi Enrico,
I added the NTB maintainers, who will deal with these, but since
you're fixing pedantic issues, I'll give you some pedantic comments :)
The first is that you might put something here in the commit log, eg,
"fix Kconfig help text indentatio
Running RCU out of softirq is a problem for some workloads that would
like to manage RCU core processing independently of other softirq
work, for example, setting kthread priority. This commit therefore
introduces the `rcunosoftirq' option which moves the RCU core work
from softirq to a per-CPU/pe
From: Arnaldo Carvalho de Melo
commit 7d7d1bf1d1dabe435ef50efb051724b8664749cb upstream.
We can't access kernel files directly from tools/, so copy the required
bits, and make sure that we detect when the original files, in the
kernel, gets modified.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Jiri
[+cc Jon, Dave, Allen]
On Wed, Mar 06, 2019 at 11:02:54PM +0100, Enrico Weigelt, metux IT consult
wrote:
> Formatting of Kconfig files doesn't look so pretty, so just
> take damp cloth and clean it up.
Oops, I didn't notice that this was a v2. I first thought this was a
2/2 patch. Sorry for th
info->stream is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
sound/core/rawmidi.c:604 __snd_rawmidi_info_select() warn: potential spectre
issue 'rmidi->streams' [r] (local c
On Wed, Mar 20, 2019 at 09:30:59AM +, Sudip Mukherjee wrote:
> Sorry, I didn't get the chance to look at it yet and have kept it
> pending for this weekend. But just had a quick look and I was
> wondering if the machine on which you are trying the modprobe has an
> actual parallel port or the m
On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote:
> >> Another way of looking at this issue which also explains our reluctance
> >> is that the only difference between a secure guest and a regular guest
> >> (at least regarding virtio) is that the former uses swiotlb while the
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 this time, always
request the default timeout, and only report the failing response
via a WARN(). Future versions could accept th
The Chrome OS EC has an updated set of parameters for the host
sleep event command. With the new parameters, the host can indicate
a timeout along with suspend messages. Specifically S0ix suspend
messages are supported now, though the host command format isn't
specific to S0ix. When the EC sees an
Introduce the command and response structures for the second revision
of the host sleep event. These structures are part of a new EC change
that enables detection of failure to enter S0ix. The EC waits a
kernel-specified timeout (or a default amount of time) for the S0_SLP
pin to change, and wakes
From: Colin Ian King
There is a typo in the module author's email address. Fix this.
Signed-off-by: Colin Ian King
---
drivers/phy/mediatek/phy-mtk-ufs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/mediatek/phy-mtk-ufs.c
b/drivers/phy/mediatek/phy-mtk-ufs.c
From: Colin Ian King
There is a typo in the module author's email address. Fix this.
Signed-off-by: Colin Ian King
---
drivers/phy/mediatek/phy-mtk-ufs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/mediatek/phy-mtk-ufs.c
b/drivers/phy/mediatek/phy-mtk-ufs.c
On 3/20/19 4:05 PM, Richard Weinberger wrote:
> Hi!
>
> Am Mittwoch, 20. März 2019, 21:20:51 CET schrieb Gustavo A. R. Silva:
>> Hi all,
>>
>> Friendly ping:
>>
>> Who can take this?
>
> Hmmm, for MTD I think we can schedule these patches for the next merge window.
> But I'm not sure whether t
On 3/20/19 4:22 PM, Colin King wrote:
> From: Colin Ian King
>
> There is a typo in the module author's email address. Fix this.
>
This is priceless!
Acked-by: Gustavo A. R. Silva
Thanks, Colin.
--
Gustavo
> Signed-off-by: Colin Ian King
> ---
> drivers/phy/mediatek/phy-mtk-ufs.c | 2 +
Hi Matthias,
On Tue, Mar 19, 2019 at 05:33:52PM -0700, Matthias Kaehlcke wrote:
> ...
> > @@ -95,6 +103,19 @@ static int rk3399_dmcfreq_target(struct device *dev,
> > unsigned long *freq,
> >
> > mutex_lock(&dmcfreq->lock);
> >
> > + if (target_rate >= dmcfreq->odt_dis_freq)
> > +
On Wed, Mar 20, 2019 at 1:52 PM Bjorn Helgaas wrote:
>
> AFAICT, the consensus there was that it would be better to find some
> sort of platform solution instead of dealing with it in individual
> drivers. The PCI core isn't really a driver, but I think the same
> argument applies to it: if we ha
On Wed, 20 Mar 2019 16:33:38 -0400 Qian Cai wrote:
> In a low-memory situation, cc->fast_search_fail can keep increasing as
> it is unable to find an available page to isolate in
> fast_isolate_freepages(). As the result, it could trigger an error
> below, so just compare with the maximum bits ca
When ever notification of IRQ affinity changes, call
cancel_work_sync from irq_set_affinity_notifier to cancel
all pending works to avoid work list corruption.
Signed-off-by: Prasad Sodagudi
---
kernel/irq/manage.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/irq/manage.c b/kern
Hi Gaël,
On Wed, Mar 20, 2019 at 05:50:13PM -0400, Gaël PORTAY wrote:
> Hi Matthias,
>
> On Tue, Mar 19, 2019 at 05:33:52PM -0700, Matthias Kaehlcke wrote:
> > ...
> > > @@ -95,6 +103,19 @@ static int rk3399_dmcfreq_target(struct device *dev,
> > > unsigned long *freq,
> > >
> > > mutex_lock
On Wed, 20 Mar 2019 at 16:23, Robert Richter wrote:
>
> On 20.03.19 14:16:07, Robert Richter wrote:
> > On 20.03.19 13:05:37, Robert Richter wrote:
> > > @@ -167,6 +167,7 @@ static int __init arm_dmi_init(void)
> > > * itself, depends on dmi_scan_machine() having been called already.
> > >
On 3/20/19 5:58 PM, Andrew Morton wrote:
>> ---
>> mm/compaction.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index e1a08fc92353..0d1156578114 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -1157,7 +1157,9
On Wed, 20 Mar 2019 11:23:03 +0530 Souptick Joarder
wrote:
> > --- a/mm/mempolicy.c
> > +++ b/mm/mempolicy.c
> > @@ -447,6 +447,13 @@ static inline bool queue_pages_required(struct page
> > *page,
> > return node_isset(nid, *qp->nmask) == !(flags & MPOL_MF_INVERT);
> > }
> >
> > +/*
>
On Wed, Mar 20, 2019 at 3:17 PM Thomas Renninger wrote:
>
> Rafael,
>
> I top post the general things and answer in only a few sentences embedded in
> context below:
>
> I very much honour your work and your neutral opinions and reasoning and
> I always have.
>
> This patch is a resend and while I
On Wed, Mar 20, 2019 at 01:47:28PM -0700, Stephane Eranian wrote:
> Right now, if I do:
>
> echo 0 > /sys/bus/event_source/devices/cpu/allow_tsx_force_abort
>
> Then I don't have the guarantee on when there will be no abort when I
> return from the echo. the MSR is accessed only on PMU scheduli
From: Eric Sandeen
Today, proc_do_large_bitmap() truncates a large write input buffer
to PAGE_SIZE - 1, which may result in misparsed numbers at the
(truncated) end of the buffer. Further, it fails to notify the caller
that the buffer was truncated, so it doesn't get called iteratively
to finish
On old kernels older new test knobs implemented on the test_sysctl
module may not be available. This is expected, and the selftests test
scripts should be able to run without failures on older kernels.
Generalize a solution so that we test for each required test target
file for each test by requir
When verify_diff_w() is used we care about the result, not
the verbose output, and although we use -q, that still
gives us a chatty message about if the files differ or not.
Since verify_diff_w() uses stdinput the chatty message says
whether or not "-" matches the target file, and this just
seems r
From: Eric Sandeen
The kernel has only two users of proc_do_large_bitmap(), the kernel
CPU watchdog, and the ip_local_reserved_ports. Refer to watchdog_cpumask
and ip_local_reserved_ports in Documentation for further details on
these. When you input a large buffer into these, when it is larger th
We already call test_reqs(), no need to call it twice.
Signed-off-by: Luis Chamberlain
---
tools/testing/selftests/sysctl/sysctl.sh | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/testing/selftests/sysctl/sysctl.sh
b/tools/testing/selftests/sysctl/sysctl.sh
index 780ce7123374..87df7e
Andrew, Kees,
Eric sent a fix out for proc_do_large_bitmap() last month for when
using a large input buffer. After patch review a test case for the issue
was built and submitted. I noticed there were a few issues with the
tests, but instead of just asking Eric to address them I've taken
care of th
Currently the test script checks for the existance of the
sysctl test module's directory path prior to loading it.
We must first try to load the module prior to checking for
that path. This fixes the order for the load / test.
Signed-off-by: Luis Chamberlain
---
tools/testing/selftests/sysctl/sy
Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
clearing ACPI IRQs during suspend/resume") was added to stop clearing
of event status bits unconditionally on suspend and resume paths. This
was done because of an issue
reported (https://bugzilla.kernel.org/show_bug.cgi?id=196249) where
li
The selinux-testsuite found an issue resulting in a BUG_ON()
where a conditional relied on a size_t going negative when
checking the validity of a buffer offset.
Fixes: 7a67a39320df ("binder: add function to copy binder object from buffer")
Reported-by: Paul Moore
Tested-by: Paul Moore
Signed-of
According to the FU540 and E31 manuals the PLIC source priority
address starts at an offset of 0x04 and not 0x00. To aviod confusion
update the address and source offset to match the documentation. This
causes no difference in functionality.
Signed-off-by: Alistair Francis
---
drivers/irqchip/ir
This series improves up the patches that needed more work from v2 I sent
a couple days ago. BUG_ON()s have been removed.
Let me know if you don't want the 'Remove obsolete Kconfig flags' patch I sent
in the previous series; I didn't see any mail about it.
Thanks!
George
The buffer descriptor setup loop is correct only if it is setting up at
least one bd struct. Besides, there is an error if dma_map_sg() returns
0, which is possible and must be handled.
Additionally, remove the BUG_ON() checking sglen, which is unnecessary
because we configure DMA with that const
The kernel complained:
[ 510.277151] WARNING: CPU: 0 PID: 395 at fs/proc/generic.c:360
proc_register+0xf0/0x108
[ 510.292891] proc_dir_entry '/proc/msdc_debug' already registered
when doing a modprobe/rmmod/modprobe of this module if debug messages
are compiled in. Fix this by removin
The module was initializing completions whenever it was going to wait on
them, and not when the completion was allocated. This is incorrect
according to the completion docs:
Calling init_completion() on the same completion object twice is
most likely a bug [...]
Re-initialization is also
Adding authors of the original commit whom I failed to copy in the
original patch.
On Wed, Mar 20, 2019 at 4:34 PM Furquan Shaikh wrote:
>
> Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> clearing ACPI IRQs during suspend/resume") was added to stop clearing
> of event status bits un
Hi Colin,
On Wed, 2019-03-20 at 21:22 +, Colin King wrote:
> From: Colin Ian King
>
> There is a typo in the module author's email address. Fix this.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/phy/mediatek/phy-mtk-ufs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
On 3/20/19 3:16 PM, Andrew Morton wrote:
On Wed, 20 Mar 2019 11:23:03 +0530 Souptick Joarder
wrote:
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -447,6 +447,13 @@ static inline bool queue_pages_required(struct page *page,
return node_isset(nid, *qp->nmask) == !(flags & MPOL_MF_INV
On Mon, Feb 18, 2019 at 8:57 PM Andrey Smirnov wrote:
>
> On Mon, Feb 18, 2019 at 4:58 AM Marcel Holtmann wrote:
> >
> > Hi Andrey,
> >
> > > Due to:
> > >
> > > - current implementation of l2cap_config_rsp() dropping BT
> > > connection if sender of configuration response replied with unknown
Hi Colin,
On Thu, 2019-03-21 at 07:02 +0800, Chunfeng Yun wrote:
> Hi Colin,
>
> On Wed, 2019-03-20 at 21:22 +, Colin King wrote:
> > From: Colin Ian King
> >
> > There is a typo in the module author's email address. Fix this.
> >
> > Signed-off-by: Colin Ian King
> > ---
> > drivers/phy
On Wed, Mar 20, 2019 at 11:34 PM Furquan Shaikh wrote:
>
> Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> clearing ACPI IRQs during suspend/resume") was added to stop clearing
> of event status bits unconditionally on suspend and resume paths. This
> was done because of an issue
> re
On Wed, Sep 19, 2018 at 10:31:55AM -0400, Jim Quinlan wrote:
> This patch series adds support for the Broadcom Settopbox PCIe host
> controller. It is targeted to Broadcom Settopbox chips running on
> ARM, ARM64, and MIPS platforms.
Whatever happened with this series? I saw some discussion that
On 3/20/19 4:15 PM, Bjorn Helgaas wrote:
> On Wed, Sep 19, 2018 at 10:31:55AM -0400, Jim Quinlan wrote:
>> This patch series adds support for the Broadcom Settopbox PCIe host
>> controller. It is targeted to Broadcom Settopbox chips running on
>> ARM, ARM64, and MIPS platforms.
>
> Whatever happe
Am Mittwoch, 20. März 2019, 22:23:21 CET schrieb Gustavo A. R. Silva:
> So, if this is too much of a burden for people, I can add all these
> MTD patches to my own tree for 5.2.
Taking the patches via MTD is not a big deal, let's go that path.
For you it is more work to send many patches and getti
Applied, thanks!
On Fri, Aug 17, 2018 at 12:35 PM Calvin Walton wrote:
>
> This is an updated version of my RAPL patchset for Zen CPUs, rebased on
> top of the current state of kernel/git/lenb/linux.get turbostat branch.
> (In particular, this fixes conflicts with the AMD APIC-id patch)
>
> I've
On 3/20/19 6:25 PM, Richard Weinberger wrote:
> Am Mittwoch, 20. März 2019, 22:23:21 CET schrieb Gustavo A. R. Silva:
>> So, if this is too much of a burden for people, I can add all these
>> MTD patches to my own tree for 5.2.
>
> Taking the patches via MTD is not a big deal, let's go that pat
Hi Calvin,
I'm inclined to apply this -- because it will not break anything,
and it would at least enable testing by people, who have this hardware.
thoughts?
-Len
On Fri, Aug 17, 2018 at 12:35 PM Calvin Walton wrote:
>
> The package power can also be read from an MSR. It's not clear exactly
> w
On Wed, Mar 20, 2019 at 10:13:33PM +0100, Sebastian Andrzej Siewior wrote:
> Running RCU out of softirq is a problem for some workloads that would
> like to manage RCU core processing independently of other softirq
> work, for example, setting kthread priority. This commit therefore
> introduces t
The cpu-map DT entry in ARM can describe the CPU topology in much better
way compared to other existing approaches. RISC-V can easily adopt this
binding to represent its own CPU topology. Thus, both cpu-map DT
binding and topology parsing code can be moved to a common location so
that RISC-V or any
Both RISC-V & ARM64 are using cpu-map device tree to describe
their cpu topology. It's better to move the relevant code to
a common place instead of duplicate code.
Signed-off-by: Atish Patra
Tested-by: Jeffrey Hugo
---
arch/arm64/include/asm/topology.h | 23 ---
arch/arm64/kernel/topology.c
Currently, ARM32 and ARM64 uses different data structures to
represent their cpu toplogies. Since, we are moving the ARM64
topology to common code to be used by other architectures, we
can reuse that for ARM32 as well.
Signed-off-by: Atish Patra
---
arch/arm/include/asm/topology.h | 22 +
On Wed, Mar 20, 2019 at 10:39:52PM +, Alistair Francis wrote:
> According to the FU540 and E31 manuals the PLIC source priority
> address starts at an offset of 0x04 and not 0x00. To aviod confusion
> update the address and source offset to match the documentation. This
> causes no difference i
cpu-map binding can be used to described cpu topology for both
RISC-V & ARM. It makes more sense to move the binding to document
to a common place.
The relevant discussion can be found here.
https://lkml.org/lkml/2018/11/6/19
Signed-off-by: Atish Patra
Reviewed-by: Sudeep Holla
---
.../topolog
From: Sudeep Holla
The current ARM DT topology description provides the operating system
with a topological view of the system that is based on leaf nodes
representing either cores or threads (in an SMT system) and a
hierarchical set of cluster nodes that creates a hierarchical topology
view of h
Currently, there are no topology defined for RISC-V.
Parse the cpu-map node from device tree and setup the
cpu topology.
CPU topology after applying the patch.
$cat /sys/devices/system/cpu/cpu2/topology/core_siblings_list
0-3
$cat /sys/devices/system/cpu/cpu3/topology/core_siblings_list
0-3
$cat /
From: Rafael J. Wysocki
The current handling of MSR_IA32_ENERGY_PERF_BIAS in the kernel is
problematic, because it may cause changes made by user space to that
MSR (with the help of the x86_energy_perf_policy tool, for example)
to be lost every time a CPU goes offline and then back online as well
dev is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn:
potential spectre issue 'dp->synths' [w] (loca
On Wed, Mar 20, 2019 at 4:49 PM Christoph Hellwig wrote:
>
> On Wed, Mar 20, 2019 at 10:39:52PM +, Alistair Francis wrote:
> > According to the FU540 and E31 manuals the PLIC source priority
> > address starts at an offset of 0x04 and not 0x00. To aviod confusion
> > update the address and sou
On 3/20/19 11:16 AM, Gustavo A. R. Silva wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warning:
drivers/watchdog/alim7101_wdt.c: In function ‘fop_ioctl’:
drivers/watchdog/alim7101_wdt.c:279:3: w
On 3/20/19 7:12 PM, Guenter Roeck wrote:
> On 3/20/19 11:16 AM, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> This patch fixes the following warning:
>>
>> drivers/watchdog/alim7101_wdt.c: In fu
This patch adds a binding that describes the HDMI controller for
rk3066.
Signed-off-by: Johan Jonker
Reviewed-by: Rob Herring
---
.../display/rockchip/rockchip,rk3066-hdmi.txt | 72 ++
1 file changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindin
> On Wed, Mar 20, 2019 at 12:57:52PM -0700, Xing, Cedric wrote:
> > > Using the untrusted stack as a way to exchange data is very
> > > convenient, but that doesn't mean it's a good idea. Here are some
> > > problems it
> > > causes:
> > >
> > > - It prevents using a normal function to wrap encla
Hi, Guenter
Best Regards!
Anson Huang
> -Original Message-
> From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter
> Roeck
> Sent: 2019年3月20日 21:44
> To: Anson Huang
> Cc: w...@linux-watchdog.org; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; s.ha...@peng
On 3/20/19 5:22 PM, Anson Huang wrote:
Hi, Guenter
Best Regards!
Anson Huang
-Original Message-
From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter
Roeck
Sent: 2019年3月20日 21:44
To: Anson Huang
Cc: w...@linux-watchdog.org; robh...@kernel.org; mark.rutl...@arm.com;
shawn
This is just a resend with scheduler patches split from the driver fixes and
Paul's Reviewed-by(s) added.
These patches fix various sparse errors ccaused as a result of the recent check
to add rcu_check_sparse() to rcu_assign_pointer(). The errors are due to
missing annotations. The annotations a
The scheduler uses RCU API in various places to access sched_domain
pointers. These cause sparse errors as below.
Many new errors show up because of an annotation check I added to
rcu_assign_pointer(). Let us annotate the pointers correctly which also
will help sparse catch any potential future bu
This suppresses sparse error generated due to the recently added
rcu_assign_pointer sparse check.
percpu-rwsem.c:162:9: sparse: error: incompatible types in comparison expression
exit.c:316:16: sparse: error: incompatible types in comparison expression
[From an RCU perspective]
Reviewed-by: Paul
Recently I added an RCU annotation check to rcu_assign_pointer(). All
pointers assigned to RCU protected data are to be annotated with __rcu
inorder to be able to use rcu_assign_pointer() similar to checks in
other RCU APIs.
This resulted in a sparse error: kernel//sched/cpufreq.c:41:9: sparse:
er
This fixes the following sparse errors in sched/fair.c:
fair.c:6506:14: error: incompatible types in comparison expression
fair.c:8642:21: error: incompatible types in comparison expression
Using __rcu will also help sparse catch any future bugs.
[From an RCU perspective]
Reviewed-by: Paul E. Mc
Hi, Guenter
Best Regards!
Anson Huang
> -Original Message-
> From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter
> Roeck
> Sent: 2019年3月21日 8:32
> To: Anson Huang
> Cc: w...@linux-watchdog.org; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; s.ha...@pengu
wow. Commit 70b62c25665f636c9f6c700b26af7df296b0887e
from last Sept. 14, 2018, total commit description says:
LoadPin: Initialize as ordered LSM
This converts LoadPin from being a direct "minor" LSM into an ordered LSM.
Nowhere does it say anything like "this also deletes any notion
On 3/20/2019 10:39 AM, Greg KH wrote:
On Tue, Jan 15, 2019 at 02:41:17PM -0800, James Smart wrote:
On 1/14/2019 5:15 PM, Kees Cook wrote:
On Sat, Jan 12, 2019 at 7:29 AM Willy Tarreau wrote:
From: Silvio Cesare
Change snprintf to scnprintf. There are generally two cases where using
snprintf
Add i.MX TPM(Low Power Timer/Pulse Width Modulation Module) PWM binding.
Signed-off-by: Anson Huang
---
no changes.
---
.../devicetree/bindings/pwm/imx-tpm-pwm.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/imx-t
i.MX7ULP EVK board has MIPI-DSI display, its backlight is supplied by
TPM PWM module, this patch set enables i.MX7ULP TPM PWM driver support
and also add backlight support for MIPI-DSI display.
Changes since V7:
- ONLY change the pwm driver patch.
Anson Huang (5):
dt-bindings: pwm: Add
Select CONFIG_PWM_IMX_TPM by default to support i.MX7ULP
TPM PWM.
Signed-off-by: Anson Huang
---
no changes.
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig
b/arch/arm/configs/imx_v6_v7_defconfig
index 5586a50..57
This patch adds i.MX7ULP EVK board MIPI-DSI backlight support.
Signed-off-by: Anson Huang
---
no changes.
---
arch/arm/boot/dts/imx7ulp-evk.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp-evk.dts
b/arch/arm/boot/dts/imx7ulp-evk.dts
index
Add i.MX7ULP EVK board PWM0 support.
Signed-off-by: Anson Huang
---
no changes.
---
arch/arm/boot/dts/imx7ulp.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index eb349fd..15d04fb 100644
--- a/arch/arm/boot/dts
i.MX7ULP has TPM(Low Power Timer/Pulse Width Modulation Module)
inside, it can support multiple PWM channels, all the channels
share same counter and period setting, but each channel can
configure its duty and polarity independently.
There are several TPM modules in i.MX7ULP, the number of channel
Dear Friend,
I am Mrs Clara David. am sending you this brief letter to solicit your
partnership to transfer $18.5 million US Dollars.I shall send you more
information and procedures when I receive positive response from you.
please send me a message in my Email box (mrsclarad...@gmail.com)
as i wa
> -Original Message-
> From: Shawn Guo
> Sent: 2019年3月20日 22:49
> To: Andy Tang
> Cc: Daniel Lezcano ; mark.rutl...@arm.com;
> devicet...@vger.kernel.org; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Leo Li ;
> edubez...@gmail.com; robh...@kernel.org; rui.zh...@intel.com;
>
On Tue, Mar 19, 2019 at 1:03 PM Masahiro Yamada
wrote:
>
> Commit 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
> annoyed people who want to wrap the top Makefile with GNUmakefile
> or something in order to customize it for their use.
>
> On second thought, we do not need to run the
On 3/20/19 4:44 PM, Linus Torvalds wrote:
On Wed, Mar 20, 2019 at 1:52 PM Bjorn Helgaas wrote:
AFAICT, the consensus there was that it would be better to find some
sort of platform solution instead of dealing with it in individual
drivers. The PCI core isn't really a driver, but I think the s
601 - 700 of 769 matches
Mail list logo
