On Wed, Apr 25, 2018 at 12:02:49AM +0900, Masanari Iida wrote:
> This patch fix double words "are are".
These files are auto generated from another source. I don't think
it makes much sense to do a lot of editing on the Linux copies.
I will pass it on to the owners of the original files.
-Andi
Sigh I should have Cc'd Martin Partel as well as this bit is his
original code.
Anton Ivanov writes:
> Hi Richard,
>
> There was a post to uml-devel during the days when the sourceforge mailing
> list
> was working in random drop mode which claimed that "this fixes the arm build".
>
> I have no
On Thursday, April 19, 2018 04:06:27 PM Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
Patch queued for 4.18, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D
> Masahiro Yamada hat am 24. April 2018 um
> 17:51 geschrieben:
>
>
> 2018-04-24 17:44 GMT+09:00 Sedat Dilek :
> > Signed-off-by: Sedat Dilek
> > ---
> > Makefile | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 83b6c541565a..e18
On 24/04/18 16:57, Mark Brown wrote:
On Tue, Apr 24, 2018 at 10:52:26AM -0500, Rob Herring wrote:
On Wed, Apr 18, 2018 at 04:31:35PM +0100, srinivas.kandaga...@linaro.org wrote:
From: Srinivas Kandagatla
This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router)
bus driver.
On 04/24/2018 11:52 AM, Panariti, David wrote:
Hi,
It looks like there can be an infinite loop if neither of the if()'s become
true.
Is that an impossible condition?
That intended, we want to wait until either the fence signals or fatal
signal received, we don't want to terminate the wait
On Tue, Apr 24, 2018 at 10:52:26AM -0500, Rob Herring wrote:
> On Wed, Apr 18, 2018 at 04:31:35PM +0100, srinivas.kandaga...@linaro.org
> wrote:
> > From: Srinivas Kandagatla
> > This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router)
> > bus driver. This bus is used for communi
On Tue, 2018-04-10 at 11:32 -0700, Jae Hyun Yoo wrote:
> drivers/hwmon/peci-cputemp.c | 783
> ++
> drivers/hwmon/peci-dimmtemp.c | 432 +++
Does it make sense one driver per patch?
> +#define CLIENT_CPU_ID_MASK0xf0ff0 /* Mask for
On Tue, Apr 24, 2018 at 5:40 PM, Will Deacon wrote:
> On Tue, Apr 24, 2018 at 03:43:04PM +0200, Jason A. Donenfeld wrote:
>> On Tue, Apr 24, 2018 at 3:34 PM, Will Deacon wrote:
>> > I've not run into any build issues here -- is this specifically with some
>> > out-of-tree module?
>>
>> I received
Dear Theodore,
On 04/24/18 17:49, Theodore Y. Ts'o wrote:
On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote:
On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote:
Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called
from` messages. I believe, this
On Mon, Apr 23, 2018 at 05:22:44PM -0400, Steven Rostedt wrote:
> On Mon, 23 Apr 2018 13:12:21 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>
> > I'm inclined to explicitly declare the tracepoints with their given
> > synchronization method. Tracepoint probe callback functions for currently
> > exis
On Tue, Apr 24, 2018 at 05:51:15PM +0200, Jan Kiszka wrote:
> ...rather than just mysteriously disabling it.
>
> Signed-off-by: Jan Kiszka
> ---
> mm/kmemleak.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 9a085d525bbc..156c0c69cc5c 100644
> ---
On Tue, Apr 24, 2018 at 10:40:36AM +0200, Sebastian Ott wrote:
> On Mon, 23 Apr 2018, Sebastian Ott wrote:
> > This happend once during boot and I could not reproduce this since, but I
> > think the following patch should fix the issue:
>
> I can now recreate the issue reliably. The following patc
Hi Rui,
On Thu, Apr 19, 2018 at 8:00 AM, Rui Miguel Silva wrote:
> Add device tree binding documentation for the OV2680 camera sensor.
>
> Reviewed-by: Rob Herring
> CC: devicet...@vger.kernel.org
> Signed-off-by: Rui Miguel Silva
> ---
> .../devicetree/bindings/media/i2c/ov2680.txt | 40
Hi,
It looks like there can be an infinite loop if neither of the if()'s become
true.
Is that an impossible condition?
-Original Message-
From: Andrey Grodzovsky
Sent: Tuesday, April 24, 2018 11:31 AM
To: linux-kernel@vger.kernel.org; amd-...@lists.freedesktop.org
Cc: Deucher, Alexande
On Wed, Apr 18, 2018 at 04:31:35PM +0100, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla
>
> This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router)
> bus driver. This bus is used for communicating with DSP which provides
> audio and various other services to c
On 04/24/2018 11:46 AM, Michel Dänzer wrote:
Adding the dri-devel list, since this is driver independent code.
Thanks, so many addresses that this one slipped out...
On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
Avoid calling wait_event_killable when you are possibly being called
from
2018-04-24 17:44 GMT+09:00 Sedat Dilek :
> Signed-off-by: Sedat Dilek
> ---
> Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 83b6c541565a..e1869dc08288 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -366,7 +366,7 @@ HOSTCFLAGS :=
On 04/24/2018 11:46 AM, Michel Dänzer wrote:
Adding the dri-devel list, since this is driver independent code.
Thanks, so many addresses that this one slipped out...
On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
Avoid calling wait_event_killable when you are possibly being called
from
On Tuesday, April 10, 2018 09:47:20 AM Jia-Ju Bai wrote:
> radeonfb_pci_suspend() is never called in atomic context.
>
> radeonfb_pci_suspend() is only set as ".suspend" in struct pci_driver.
> This function is not called in atomic context.
>
> Despite never getting called from atomic context, ra
...rather than just mysteriously disabling it.
Signed-off-by: Jan Kiszka
---
mm/kmemleak.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 9a085d525bbc..156c0c69cc5c 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -863,6 +863,7 @@ static void __init log_
On Tue, 24 Apr 2018, Michal Hocko wrote:
> On Mon 23-04-18 20:06:16, Mikulas Patocka wrote:
> [...]
> > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f
> > */
> > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
> >
> > +#ifdef CONFIG_DEBUG_SG
> > + /* Catch bugs when
On 04/23/2018 10:43 AM, Joe Lawrence wrote:
> On Fri, Apr 20, 2018 at 02:56:05PM +0200, Libor Pechacek wrote:
>> On Thu 12-04-18 10:54:31, Joe Lawrence wrote:
>>> + fi
>>> + echo "$ret" > /dev/kmsg
>>> +}
>>> +
>>> +# unload_mod(modname) - unload a kernel module
>>> +# modname - module name to
On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote:
> On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote:
> > Dear Linux folks,
> >
> >
> > Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called
> > from` messages. I believe, this setting should be reverte
On Tuesday, April 10, 2018 09:40:35 AM Jia-Ju Bai wrote:
> aty128_set_suspend() is never called in atomic context.
>
> The call chains ending up at aty128_set_suspend() are:
> [1] aty128_set_suspend() <- aty128_pci_suspend()
> [2] aty128_set_suspend() <- aty128_do_resume() <- aty128_pci_resume()
>
On Tue, Apr 24, 2018 at 8:46 AM, Joel Fernandes wrote:
> On Tue, Apr 24, 2018 at 5:35 AM, Peter Zijlstra wrote:
>> On Tue, Apr 24, 2018 at 12:19:07PM +0100, Valentin Schneider wrote:
>>> On 24/04/18 11:43, Peter Zijlstra wrote:
>>> > On Tue, Apr 24, 2018 at 11:02:26AM +0100, Valentin Schneider wr
On Tue, Apr 24, 2018 at 5:22 PM, Linus Torvalds
wrote:
> On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote:
>>
>> $ objdump -S clang-eflag.o
>>
>> Does this now look good?
>
> Looks fine to me. The instruction choice is still pretty odd:
>
> 1a: f6 c3 fftest $0xff,%bl
> 1
Adding the dri-devel list, since this is driver independent code.
On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
> Avoid calling wait_event_killable when you are possibly being called
> from get_signal routine since in that case you end up in a deadlock
> where you are alreay blocked in singla
On Tue, Apr 24, 2018 at 5:35 AM, Peter Zijlstra wrote:
> On Tue, Apr 24, 2018 at 12:19:07PM +0100, Valentin Schneider wrote:
>> On 24/04/18 11:43, Peter Zijlstra wrote:
>> > On Tue, Apr 24, 2018 at 11:02:26AM +0100, Valentin Schneider wrote:
>> >> I'd argue making things easier to read is a non-ne
2018-04-12 13:45 GMT+09:00 Masahiro Yamada :
> 2018-04-12 11:31 GMT+09:00 Masahiro Yamada :
>> The property of the legacy mode for the eMMC PHY turned out to
>> be worng. Some eMMC devices are unstable due to the set-up/hold
>> timing violation. Correct the delay value.
>
> Reminder for myself:
>
On Tue, 2018-04-24 at 09:39 -0500, Rob Herring wrote:
> On Wed, Apr 18, 2018 at 06:24:54PM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > Add bindings to g3dsys providing necessary clock and reset control to
> > Mali-450.
> >
> > Signed-off-by: Sean Wang
> > ---
> > .../bindi
On Fri, Apr 20, 2018 at 08:28:28AM +0200, Geert Uytterhoeven wrote:
> Hi Stephen, Rob,
>
> On Fri, Apr 20, 2018 at 12:25 AM, Stephen Boyd wrote:
> > Quoting Geert Uytterhoeven (2018-04-18 07:50:01)
> >> The use of of_clk_get_parent_{count,name}() and of_clk_init() is not
> >> limited to clock pro
Hi everybody,
I've proposed to talk about page able manipulation API on the LSF/MM'2018,
so I need something material to talk about.
Below is how better (arguably) API may look like as implemented for x86-64
(both paging modes).
It's very incomplete (notably no PTI and paravirt support), not spl
On Tue, 2018-04-24 at 09:40 -0500, Rob Herring wrote:
> On Wed, Apr 18, 2018 at 06:24:55PM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > Add clock driver support for g3dsys on MT2701 and MT7623, which is
> > providing essential clock gate and reset controller to Mali-450.
> >
On Tuesday, April 10, 2018 09:05:59 AM Jia-Ju Bai wrote:
> savage_init_hw() is never called in atomic context.
>
> The call chains ending up at savage_init_hw() are:
> [1] savage_init_hw() <- savagefb_probe()
> [2] savage_init_hw() <- savagefb_resume()
>
> savagefb_probe() is only set as ".probe"
Fixes: fc3babee0341 ("procfs: share fd/fdinfo with thread group leader when
files are shared")
Signed-off-by: Fengguang Wu
---
base.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 98a847b..deb0950 100644
--- a/fs/proc/base.c
+++ b/f
Hi Jeff,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc2 next-20180424]
[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
From: Jan Kiszka
The only user of that function is of_pci_bus_find_domain_nr. Pure
cleanup.
Signed-off-by: Jan Kiszka
---
drivers/pci/pci.c | 6 ++
include/linux/pci.h | 3 ---
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e597
On Tue, Apr 24, 2018 at 03:43:04PM +0200, Jason A. Donenfeld wrote:
> On Tue, Apr 24, 2018 at 3:34 PM, Will Deacon wrote:
> > I've not run into any build issues here -- is this specifically with some
> > out-of-tree module?
>
> I received a bug report email about this. I'm not sure which specific
Quoting Taniya Das (2018-04-23 09:50:22)
> On 4/16/2018 11:08 PM, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-04-13 19:36:41)
>
> >> +struct clk_rpmh {
> >> + struct clk_hw hw;
> >> + const char *res_name;
> >> + u32 res_addr;
> >> + u32 res_en_offset;
> >
> > Why do
Commit a257e02579e ("arm64/kernel: don't ban ADRP to work around
Cortex-A53 erratum #843419") introduced a function whose name ends with
"_veneer".
This clashes with commit bd8b22d2888e ("Kbuild: kallsyms: ignore veneers
emitted by the ARM linker"), which removes symbols ending in "_veneer"
from k
On 04/24/2018 02:47 AM, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> The MMSYS subsystem includes clocks and drm components.
> This patch adds a MFD device to probe both drivers from the same
> device tree compatible.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/mfd/Kconf
From: Jan Kiszka
Straightforward for all of them, no more leaks afterwards.
CC: Jingoo Han
CC: Joao Pinto
CC: Lorenzo Pieralisi
Signed-off-by: Jan Kiszka
---
drivers/pci/dwc/pcie-designware-host.c | 2 +-
drivers/pci/host/pci-aardvark.c| 5 ++---
drivers/pci/host/pci-ftpci100.c
Hi,
Dne torek, 24. april 2018 ob 15:34:12 CEST je Jagan Teki napisal(a):
> Allwinner A64 has display engine pipeline like other Allwinner SOC's
> A83T/H3/H5.
>
> A64 DE2 behaviour similar to Allwinner A83T where mixer0, connected to tcon0
> with RGB, LVDS MIPI-DSI and mixer1, connected to tcon1 w
If the ring is hanging for some reason allow to recover the waiting
by sending fatal signal.
Originally-by: David Panariti
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu
The function force_sig_fault is just the generic version of
do_trap_siginfo with a (void __user *) instead of an unsigned long
parameter for the address.
So just use force_sig_fault to simplify the code.
Cc: Palmer Dabbelt
Cc: Albert Ou
Cc: linux-ri...@lists.infradead.org
Suggested-by: Christo
Avoid calling wait_event_killable when you are possibly being called
from get_signal routine since in that case you end up in a deadlock
where you are alreay blocked in singla processing any trying to wait
on a new signal.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/gpu_schedu
Currently calling wait_event_killable as part of exiting process
will stall forever since SIGKILL generation is suppresed by PF_EXITING.
In our partilaur case AMDGPU driver wants to flush all GPU jobs in
flight before shutting down. But if some job hangs the pipe we still want to
be able to kill i
Following 3 patches address an issue we encounter in AMDGPU driver.
When GPU pipe is stalling for some reason (shader code error, incorrectly
programmed registers e.t.c...)
uninterruptible wait in kernel puts the user process in unresponsive state
which only can be remedied by system's hard re
On Tue, 24 Apr 2018, Michal Hocko wrote:
> On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:
>
> > Fixing __vmalloc code
> > is easy and it doesn't require cooperation with maintainers.
>
> But it is a hack against the intention of the scope api.
It is not! You can fix __vmalloc now and you c
From: Jan Kiszka
Required when running over Jailhouse, and there is already a physical
host controller that Jailhouse does not intercept and rather adds a
virtual one. That is the case for the Tegra TK1, e.g.
Signed-off-by: Jan Kiszka
---
arch/arm/Kconfig | 7 ++-
1 file changed, 6 inserti
This primarily enables to unbind the generic PCI host controller without
leaving lots of memory leaks behind. A previous proposal patch 5 was
rejected because of those issues [1].
The fixes have been validated in the Jailhouse setup, where we add and
remove a virtual PCI host controller on hypervi
Palmer Dabbelt writes:
> On Fri, 20 Apr 2018 07:38:03 PDT (-0700), ebied...@xmission.com wrote:
>> Filling in struct siginfo before calling force_sig_info a tedious and
>> error prone process, where once in a great while the wrong fields
>> are filled out, and siginfo has been inconsistently clea
On 24/04/18 19:03, lazytyped wrote:
On 4/24/18 4:44 PM, Matthew Wilcox wrote:
On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
On 4/24/18 1:50 PM, Matthew Wilcox wrote:
struct modifiable_data {
struct immutable_data *d;
...
};
Then allocate a new pool, change d a
From: Jan Kiszka
Particularly useful when working in virtual environments where the
controller may come and go, but possibly not only there.
CC: Will Deacon
CC: Lorenzo Pieralisi
Signed-off-by: Jan Kiszka
---
drivers/pci/host/pci-host-common.c | 13 +
drivers/pci/host/pci-host-g
Hi,
Dne torek, 24. april 2018 ob 15:34:21 CEST je Jagan Teki napisal(a):
> HDMI on Allwinner A64 has similar behavior like H3/H5, so
> reuse the same dts node details for A64.
>
> Signed-off-by: Jagan Teki
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 28
> +++
From: Jan Kiszka
of_pci_get_host_bridge_resources allocates the resource structures it
fills dynamically, but none of its callers care to release them so far.
Rather than requiring everyone to do this explicitly, introduce a
managed version of that service. This differs API-wise only in taking a
Stephen Smalley wrote:
> Neither fsopen() nor fscontext_fs_write() appear to perform any kind of
> up-front permission checking (DAC or MAC), although some security hooks may
> be ultimately called to allocate structures, parse security options, etc.
> Is there a reason not apply a may_mount() or
On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote:
>
> $ objdump -S clang-eflag.o
>
> Does this now look good?
Looks fine to me. The instruction choice is still pretty odd:
1a: f6 c3 fftest $0xff,%bl
1d: 74 02 je 21
that "test $0xff,%bl" is a
From: Jan Kiszka
devm_pci_release_host_bridge_dev failed to release the resource list.
Fixes: 5c3f18cce083 ("PCI: Add devm_pci_alloc_host_bridge() interface")
Signed-off-by: Jan Kiszka
---
drivers/pci/probe.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pr
On Tue, 24 Apr 2018 16:23:04 +0200 Christoph Hellwig wrote:
> On Thu, Apr 19, 2018 at 09:57:50PM +0300, Alexey Dobriyan wrote:
> > > git://git.infradead.org/users/hch/misc.git proc_create
> >
> >
> > I want to ask if it is time to start using poorman function overloading
> > with _b_c_e().
On 24 April 2018 at 17:13, Kim Phillips wrote:
> Commit a257e02579e ("arm64/kernel: don't ban ADRP to work around
> Cortex-A53 erratum #843419") introduced a function whose name ends with
> "_veneer".
>
> This clashes with commit bd8b22d2888e ("Kbuild: kallsyms: ignore veneers
> emitted by the ARM
Hi all,
I'm on kernel 4.16.4 and have an issue with eth0, driver is igb. When I
remove the ethernet cable, this is always detected:
[2.772360] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
[2.772363] igb: Copyright (c) 2007-2014 Intel Corporation.
[3.023707] igb
On 04/23/2018 10:01 PM, Ooi, Joyce wrote:
> The HPS EMAC0 drive strength is changed to 4mA because the initial 8mA
> drive strength has caused CE test to fail. This requires changes on the
> pad skew for EMAC0 PHY driver. Based on several measurements done, Tx
> clock does not require the extra 0
Commit a257e02579e ("arm64/kernel: don't ban ADRP to work around
Cortex-A53 erratum #843419") introduced a function whose name ends with
"_veneer".
This clashes with commit bd8b22d2888e ("Kbuild: kallsyms: ignore veneers
emitted by the ARM linker"), which removes symbols ending in "_veneer"
from k
On Tue, 24 Apr 2018, Luc Van Oostenryck wrote:
> All implementations of the method intel_dvo_dev_ops::mode_valid(), as
> well as the underlying struct drm_connector_helper_funcs::mode_valid()
> use 'enum drm_mode_status' for the method's return type but the
> declaration of intel_dvo_dev_ops::mode
On 04/17/2018 04:45 AM, Bartosz Golaszewski wrote:
> Using 'at' or 'at24' as the part of the compatible
> string is now deprecated. Use a correct value: 'atmel,'.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 6 +++---
> 1 file changed, 3
Hi,
On 23-04-18 23:11, Luis R. Rodriguez wrote:
Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new ID
and security for this type of request so IMA can reject it if the policy is
configured for it.
Hmm, interesting, actually it seems like the whole existence
of READING_F
On Tue, Apr 24, 2018 at 03:18:53PM +0200, Luc Van Oostenryck wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
>
> Fix this by returning 'netdev_tx_t' in this driver too.
>
On Tue, Apr 24, 2018 at 10:33:58AM -0400, Steven Rostedt wrote:
> On Tue, 24 Apr 2018 12:17:38 +0200
> Jiri Olsa wrote:
>
> > Recent commit changed the name prefix of syscalls
> > for x86_64 (check the 'Fixes:' for commit number).
> >
> > The names switch from "sys_" prefix to ""__x64_sys_",
> >
On Thu, 15 Mar 2018 14:06:39 +0800
Peter Xu wrote:
> It's been missing for a while but no one is touching that up. Fix it.
I just noticed this patch. I added it, thanks!
-- Steve
>
> CC: Steven Rostedt
> CC: Ingo Molnar
> Signed-off-by: Peter Xu
> ---
> kernel/trace/trace_entries.h | 2 +
According to documentation the function has 2 bits for reset
while iDMA 64-bit has only one.
Rename it accordingly. Note, there is no functional change since
we always handle them together.
Signed-off-by: Andy Shevchenko
---
drivers/mfd/intel-lpss.c | 4 ++--
1 file changed, 2 insertions(+), 2
asciidoc seems behind the recent big wave of python3 conversion, and
we were advised to switch to asciidoctor instead. It's almost
compatible but some extensions used for perf documentation don't work
with it. Here is the patch to cover them, and add the proper support
for asciidoctor.
Pass USE_
On 4/24/18 4:44 PM, Matthew Wilcox wrote:
> On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
>> On 4/24/18 1:50 PM, Matthew Wilcox wrote:
>>> struct modifiable_data {
>>> struct immutable_data *d;
>>> ...
>>> };
>>>
>>> Then allocate a new pool, change d and destroy the old pool
On Tue, 24 Apr 2018 16:58:43 +0200,
Oleksandr Andrushchenko wrote:
>
> On 04/24/2018 05:35 PM, Takashi Iwai wrote:
> > On Tue, 24 Apr 2018 16:29:15 +0200,
> > Oleksandr Andrushchenko wrote:
> >> On 04/24/2018 05:20 PM, Takashi Iwai wrote:
> >>> On Mon, 16 Apr 2018 08:24:51 +0200,
> >>> Oleksandr A
This patch fix double words "are are".
Signed-off-by: Masanari Iida
---
tools/perf/pmu-events/arch/x86/silvermont/cache.json | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/pmu-events/arch/x86/silvermont/cache.json
b/tools/perf/pmu-events/arch/x86/silvermo
The ov7251 sensor is a 1/7.5-Inch B&W VGA (640x480) CMOS Digital Image
Sensor from Omnivision.
The driver supports the following modes:
- 640x480 30fps
- 640x480 60fps
- 640x480 90fps
Output format is 10bit B&W RAW - MEDIA_BUS_FMT_Y10_1X10.
The driver supports configuration via user controls for
The ov7251 sensor is a 1/7.5-Inch B&W VGA (640x480) CMOS Digital Image
Sensor from Omnivision.
--
Version 3:
- DT binding: added that there shall be a single endpoint node in the port node;
- added a comment for regulator ena
Add the document for ov7251 device tree binding.
CC: Rob Herring
CC: Mark Rutland
CC: devicet...@vger.kernel.org
Signed-off-by: Todor Tomov
Reviewed-by: Rob Herring
---
.../devicetree/bindings/media/i2c/ov7251.txt | 52 ++
1 file changed, 52 insertions(+)
create mod
On Tue, 24 Apr 2018, Genki Sky wrote:
> Sorry to have been the bearer of bad news :(.
No problem. We're not shooting the messengers
> Again, I just have my user hat on here. It does seem like this unifying
> would have been nice to have. And even, more compliant with the POSIX
> definition of MON
According to documentation REMAP register has to be programmed in
either DMA or PIO mode of the slice.
Move the DMA capability check below to let REMAP register be programmed
in PIO mode.
Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices")
Cc: Mika Westerberg
Signed-off-
On 04/24/2018 05:35 PM, Takashi Iwai wrote:
On Tue, 24 Apr 2018 16:29:15 +0200,
Oleksandr Andrushchenko wrote:
On 04/24/2018 05:20 PM, Takashi Iwai wrote:
On Mon, 16 Apr 2018 08:24:51 +0200,
Oleksandr Andrushchenko wrote:
+static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id)
+{
+
On Mon, 23 Apr 2018, Thomas Gleixner wrote:
> On Mon, 23 Apr 2018, Wan, Kaike wrote:
> > > Can you apply the following debug patch and enable the hrtimer_start trace
> > > point and send me the full trace or upload it somewhere?
> >
> > The original trace was about 29GB and I filtered it with
> >
On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote:
> Tycho Andersen wrote:
> > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) !=
> > > > GCM_AES_IV_SIZE)) {
> > > > + WARN(1, "big key algorithm changed?");
>
> Please avoid using WARN() WARN_ON() etc.
> syzbot w
On Tue, 24 Apr 2018 11:28:02 +0900
Sergey Senozhatsky wrote:
> Calling console drivers from printk_safe() context does not really
> make call_console_drivers() any safer, because printk_safe() has
> nothing to do with console drivers or the underlying code. At the
> same time printk()-s from cons
On Tue, Apr 24, 2018 at 4:45 PM, Mathieu Malaterre wrote:
> On Tue, Apr 24, 2018 at 4:17 PM, Christophe Leroy
> wrote:
>> Use fault_in_pages_readable() to prefault user context
>> instead of open coding
>>
>> Signed-off-by: Christophe Leroy
>> ---
>> arch/powerpc/kernel/signal_32.c | 13 +--
On 04/19/2018 10:56 PM, Bart Van Assche wrote:
> On Thu, 2018-04-19 at 12:24 -0700, Omar Sandoval wrote:
>> We quiesce and freeze the queue before tearing it down, so it won't be
>> NULL while we're still doing I/O. Cc'ing Bart in case I'm lying to you,
>> though ;)
>
> blk_cleanup_queue() waits
On 04/24/2018 05:15 AM, Peter Zijlstra wrote:
> On Mon, Apr 23, 2018 at 10:55:14PM +0200, Andrea Parri wrote:
+ /*
+ * To avoid missed wakeup of reader, we need to make sure
+ * that task state and waiter->task are properly synchronized.
+ *
+ * wakeup
On Tue, Apr 24, 2018 at 3:17 PM, Luc Van Oostenryck
wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
>
> Fix this by returning 'netdev_tx_t' in this driver too.
>
> Signed
Tycho Andersen wrote:
> > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != GCM_AES_IV_SIZE)) {
> > > + WARN(1, "big key algorithm changed?");
Please avoid using WARN() WARN_ON() etc.
syzbot would catch it and panic() due to panic_on_warn == 1.
On Tue, Apr 24, 2018 at 4:17 PM, Christophe Leroy
wrote:
> Use fault_in_pages_readable() to prefault user context
> instead of open coding
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/kernel/signal_32.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --
On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
> On 4/24/18 1:50 PM, Matthew Wilcox wrote:
> > struct modifiable_data {
> > struct immutable_data *d;
> > ...
> > };
> >
> > Then allocate a new pool, change d and destroy the old pool.
>
> With the above, you have just shifted th
Hi ,
We can also fix below race by smpboot code as well:
@@ -109,7 +109,6 @@ static int smpboot_thread_fn(void *data)
struct smp_hotplug_thread *ht = td->ht;
while (1) {
- set_current_state(TASK_INTERRUPTIBLE);
preempt_disable();
Luc please don't submit such a huge number of patches all at one time.
Also, please fix the indentation of the functions whose arguments
span multiple lines as has been pointed out to you in patch feedback.
Finally, make this a true patch series. It is so much easier for
maintainers to work wit
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
kernel BUG at fs/f2fs/inode.c:LINE!
F2FS-fs (loop5): invalid crc value
F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x0)
F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
F2FS-
percpu_devid interrupts have their affinities stored in a different
field. Let's special-case it.
Signed-off-by: Marc Zyngier
---
kernel/irq/debugfs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c
index 4dadeb3d..da4115032
On Tue, 24 Apr 2018 10:33:36 +0900
Sergey Senozhatsky wrote:
> Petr, Steven, Fengguang, what do you think? Do you have any objections?
> Ideas?
If it can be turned off by a config option, I'm fine with it.
-- Steve
On Wed, Apr 18, 2018 at 06:24:55PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang
>
> Add clock driver support for g3dsys on MT2701 and MT7623, which is
> providing essential clock gate and reset controller to Mali-450.
>
> Signed-off-by: Sean Wang
> ---
> drivers/clk/mediatek/Kconfig
On Tuesday, April 24, 2018 9:45 AM, Gustavo Pimentel wrote:
>
> Adds a callback that defines the maximum number of vectors that can be use
> by the Root Complex.
>
> Since this is a parameter associated to each SoC IP setting, makes sense
> to
> be configurable and easily visible to future modifi
Hi Marcel,
On 24.04.2018 01:05, Marcel Ziswiler wrote:
> Hi Dmitry
>
> On Fri, 2018-04-20 at 13:50 +0300, Dmitry Osipenko wrote:
>> ...
>> I managed to find CDEV clocks in TRM this time.
>
> And where exactly in which TRM? In all my attempts at finding anything
> CDEV2 is just a pad group which
601 - 700 of 1320 matches
Mail list logo
