In sleep mode, the clocks of CPU core and unused IP blocks are turned
off (IP blocks allowed to wake up system will running).
Some QorIQ SoCs like MPC8536, P1022 and T104x, have deep sleep PM mode
in addtion to the sleep PM mode. While in deep sleep mode,
additionally, the power supply is removed
On 10 April 2018 at 13:04, Patrick Bellasi wrote:
> Hi Vincent,
>
> On 09-Apr 10:51, Vincent Guittot wrote:
>> Hi Patrick
>>
>> On 6 April 2018 at 19:28, Patrick Bellasi wrote:
>> > Schedutil is not properly updated when the first FAIR task wakes up on a
>> > CPU and when a RQ is (un)throttled. T
Enable Power Management feature on device tree, including MPC8536,
MPC8544, MPC8548, MPC8572, P1010, P1020, P1021, P1022, P2020, P2041,
P3041, T104X, T1024.
Signed-off-by: Zhao Chenhui
Signed-off-by: Ran Wang
---
Changes in v2:
- no change
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 14
From: Li Yang
Signed-off-by: Li Yang
Signed-off-by: Zhao Chenhui
Signed-off-by: Ran Wang
---
Changes in v2:
- new file
.../devicetree/bindings/powerpc/fsl/pmc.txt| 59 +++
1 files changed, 34 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bi
Various e500 core have different cache architecture, so they
need different cache flush operations. Therefore, add a callback
function cpu_flush_caches to the struct cpu_spec. The cache flush
operation for the specific kind of e500 is selected at init time.
The callback function will flush all cach
In the last stage of deep sleep, software will trigger a Finite
State Machine (FSM) to control the hardware procedure, such a
board isolation, killing PLLs, removing power, and so on.
When the system is waked up by an interrupt, the FSM controls
the hardware to complete the early resume procedure.
Also, unselect FSL_PMC which is for older platfroms instead.
Signed-off-by: Ran Wang
---
Changes in v2:
- no change
arch/powerpc/Kconfig |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 73ce5dd..ed60c83 100644
--- a/
On Wed, Apr 11, 2018 at 02:36:52PM +0800, Edward Chang wrote:
> This patch adds support for HP LT4220
>
> Signed-off-by: Edward Chang
> ---
Thanks for the update. Please always include a changelog here when
revising patches so we know what has changed since the previous
version(s). Also include
Hi Heiko,
On 4/10/2018 7:37 PM, Heiko Stübner wrote:
> Am Dienstag, 10. April 2018, 15:52:25 CEST schrieb Minas Harutyunyan:
>> Hi Heiko,
>>
>> On 4/10/2018 4:28 PM, Heiko Stuebner wrote:
>>> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso:
devm_regulator_get_optional returns -EN
On Tue, Apr 10, 2018 at 11:15:28PM -0700, Joe Perches wrote:
> On Tue, 2018-04-10 at 17:51 -0700, Kees Cook wrote:
> > On Tue, Apr 10, 2018 at 5:33 PM, Al Viro wrote:
> > > On Tue, Apr 10, 2018 at 04:45:32PM -0700, Kyle Spiers wrote:
> > > > As part of the effort to remove VLAs from the kernel[1],
This patch adds support for HP LT4220
Signed-off-by: Edward Chang
---
drivers/usb/serial/option.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index c3f2522..d866cc0 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/seri
> On Apr 3, 2018, at 2:12 PM, Matthew Wilcox wrote:
>
> On Tue, Apr 03, 2018 at 01:49:25PM -0700, Buddy Lumpkin wrote:
>>> Yes, very much this. If you have a single-threaded workload which is
>>> using the entirety of memory and would like to use even more, then it
>>> makes sense to use as man
On Tue 10-04-18 23:03:20, Matthew Wilcox wrote:
> diff --git a/mm/slab.c b/mm/slab.c
> index 58c8cecc26ab..9ad85fd9fca8 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -2661,6 +2661,7 @@ static struct page *cache_grow_begin(struct kmem_cache
> *cachep,
> invalid_mask,
On Tue, Apr 10, 2018 at 11:31:27PM +0200, Paul Kocialkowski wrote:
> This adds timings for the RGB666 variant of the Innolux AT070TN92 panel,
> as found on the Ainol AW1 tablet.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/panel/panel-simple.c | 26 ++
> 1
Hi Andreas,
On Wed, Apr 11, 2018 at 06:59:03AM +0200, Andreas Kemnade wrote:
> Hi Ladis,
>
> On Tue, 10 Apr 2018 22:56:43 +0200
> Ladislav Michl wrote:
>
> > Hi Nikolaus,
> >
> > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> > > Hi,
> > > we just started testing the v
On Tue, Apr 10, 2018 at 04:59:55PM -0400, Sinan Kaya wrote:
> Code is expecing to observe the same number of buffers returned from
> dma_map_sg() function compared to sg_alloc_table_from_pages(). This
> doesn't hold true universally especially for systems with IOMMU.
>
> IOMMU driver tries to comb
On 05-04-18, 18:16, Daniel Lezcano wrote:
> The next changes will add new way to cool down a CPU. In order to
> sanitize and make the overall cpu cooling code consistent and robust
> we must prevent the cpu cooling devices to co-exists with the same
> purpose at the same time in the kernel.
>
> Ma
On Mon, Apr 09, 2018 at 01:56:36AM -0400, Kevin Easton wrote:
> On Sun, Apr 08, 2018 at 09:04:33PM -0700, Eric Biggers wrote:
> ...
> >
> > Looks like this is going to be fixed by
> > https://patchwork.kernel.org/patch/10327883/ ("af_key: Always verify length
> > of
> > provided sadb_key"), but i
On Wed, 11 Apr 2018 02:37:44 +0200,
Ram Pai wrote:
>
> On Tue, Apr 10, 2018 at 01:42:39PM -0700, Andrew Morton wrote:
> > On Tue, 10 Apr 2018 06:54:11 +0200 Takashi Iwai wrote:
> >
> > > On Tue, 10 Apr 2018 02:23:26 +0200,
> > > Andrew Morton wrote:
> > > >
> > > > On Sun, 8 Apr 2018 09:20:26
On Tue, 2018-04-10 at 17:51 -0700, Kees Cook wrote:
> On Tue, Apr 10, 2018 at 5:33 PM, Al Viro wrote:
> > On Tue, Apr 10, 2018 at 04:45:32PM -0700, Kyle Spiers wrote:
> > > As part of the effort to remove VLAs from the kernel[1], this changes
> > > the allocation of the bhs and pages arrays from b
On 05-04-18, 18:16, Daniel Lezcano wrote:
> The copyright format does not conform to the format requested by
> Linaro: https://wiki.linaro.org/Copyright
>
> Fix it.
>
> Signed-off-by: Daniel Lezcano
You forgot to include my Ack ?
> ---
> drivers/thermal/cpu_cooling.c | 6 --
> 1 file chan
Hi Steve,
Can you please pull these patches.
Thanks,
Ravi
On 03/15/2018 01:57 PM, Ravi Bangoria wrote:
> tu->offset is unsigned long, not a pointer, thus %lx should
> be used to print it, not the %px.
>
> Fixes: 0e4d819d0893 ("trace_uprobe: Display correct offset in uprobe_events")
> Suggested-b
Hi,
Le mardi 10 avril 2018 à 23:35 +0200, Paul Kocialkowski a écrit :
> Le mardi 10 avril 2018 à 23:31 +0200, Paul Kocialkowski a écrit :
> > This adds support for the Ainol AW1, an A20-based 7" tablet from
> > Ainol.
>
> This version didn't use the dedicated binding for the panel and will
> be
>
2018-04-10 23:23 GMT+02:00 Kees Cook :
> On Wed, Feb 28, 2018 at 1:22 AM, Salvatore Mesoraca
> wrote:
>> 2018-02-27 21:22 GMT+01:00 Kees Cook :
>>> On Tue, Feb 27, 2018 at 11:47 AM, Kees Cook wrote:
[...]
I think this looks great.
Acked-by: Kees Cook
>>>
>>> Tested-by: K
Hi!
> Ping?
See the thread... akpm pointed out fix for autofs, and the problem is
gone with newer -next kernels, so I assume the fix fixes it :-).
Pavel
--
(english)
From: Matthew Wilcox
f2fs specifies the __GFP_ZERO flag for allocating some of its pages.
Unfortunately, the page cache also uses the mapping's GFP flags for
allocating radix tree nodes. It always masked off the __GFP_HIGHMEM
flag, and masks off __GFP_ZERO in some paths, but not all. That cause
From: Matthew Wilcox
__GFP_ZERO requests that the object be initialised to all-zeroes,
while the purpose of a constructor is to initialise an object to a
particular pattern. We cannot do both. Add a warning to catch any
users who mistakenly pass a __GFP_ZERO flag when allocating a slab with
a c
From: Matthew Wilcox
v1->v2:
- Added review/ack tags (thanks!)
- Switched the order of the patches
- Reworded commit message of the patch which actually fixes the bug
- Moved slab debug patches under CONFIG_DEBUG_VM to check _every_
allocation and added checks in the slowpath for the alloc
On 04/10/2018 08:26 PM, Dongwon Kim wrote:
On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote:
On 04/06/2018 09:57 PM, Dongwon Kim wrote:
On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote:
On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:
Hi,
I fail
On Tue 10-04-18 13:48:37, Andrew Morton wrote:
> On Tue, 10 Apr 2018 08:33:57 +0200 Michal Hocko wrote:
>
> > > Reported-by: Wang Long
> > > Signed-off-by: Greg Thelen
> > > Change-Id: Ibb773e8045852978f6207074491d262f1b3fb613
> >
> > Not a stable material IMHO
>
> Why's that? Wang Long said
syzbot has found reproducer for the following crash on
https://github.com/google/kmsan.git/master commit
35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +)
Merge pull request #11 from parkerduckworth/readme
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=7
Hi Dmitry,
On Tue, Mar 20, 2018 at 03:31:24PM -0700, Dmitry Torokhov wrote:
> Hi,
>
> This series is a combination of Atmel touchscreen driver stopping using
> platform data and moving over to generic device properties, and
> chromeos-laptop switching from being platform driver, which is the wron
On 2018-04-05 23:12, Rob Herring wrote:
> On Thu, Apr 5, 2018 at 2:28 PM, Frank Rowand wrote:
>> On 04/05/18 12:13, Jan Kiszka wrote:
>>> On 2018-04-05 20:59, Frank Rowand wrote:
Hi Jan,
On 04/04/18 15:35, Jan Kiszka wrote:
> Hi Frank,
>
> On 2018-03-04 01:17, frowand.l.
Hi Lee,
Please take a look at this IB that incorporates v4 of Enric's cros_ec debugfs
and sysfs series.
Thanks!
Benson
The following changes since commit 3eb2ce825ea1ad89d20f7a3b5780df850e4be274:
Linux 4.16-rc7 (2018-03-25 12:44:30 -1000)
are available in the Git repository at:
git://git.
On 11/04/2018 09:51, Jia-Ju Bai wrote:
b53_switch_reset_gpio() is never called in atomic context.
The call chain ending up at b53_switch_reset_gpio() is:
[1] b53_switch_reset_gpio() <- b53_switch_reset() <-
b53_reset_switch() <- b53_setup()
b53_switch_reset_gpio() is set as ".setup" in
Hi,
Please pull these apparmor changes for v4.17
Thanks!
- John
The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff:
Linux 4.15 (2018-01-28 13:20:33 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor
ta
To keep driver up to date we add generic pinctrl binding support, which covers
the features used in this driver and has additional node properties that this
SoC has compatibility, so enabling future implementations of these properties
without the need to create new node properties in the device tre
Properties to set initial value of pin output buffer.
This can be useful for configure hardware in overlay files, and in early boot
for checking it states in QA sanity tests.
Signed-off-by: Matheus Castello
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 5 +
1 file changed, 5 insertions(+)
dif
Added generic pin configuration and multiplexing support,
and should be preferred than brcm legacy one.
Signed-off-by: Matheus Castello
---
.../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bind
This series adds support for generic binding for pinctrl bcm2835 driver,
and add the code for set output buffer of a pin using the output-low and
output-high generic properties.
Tested on Raspberry Pi Zero W, based on bcm2835 SoC.
Changes since v4:
(Suggested by Rob Herring)
- Change dt-bindings
After commit 82958366cfea ("sched: Replace update_shares weight
distribution with per-entity computation"), tg_unthrottle_up
did not update the weight
Signed-off-by: Li RongQing
---
kernel/sched/fair.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
i
Bindings describe hardware, not drivers.
Use reference to hardware Allwinner A1X Pin Controller instead driver.
Signed-off-by: Matheus Castello
---
.../devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
a/Docum
Hi Yisheng,
On 4/11/2018 6:52 AM, Yisheng Xie wrote:
Hi Tomasz,
On 2018/4/10 21:14, Tomasz Figa wrote:
Hi Yisheng,
Sorry, I think we missed your question here.
On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote:
Hi Vivek,
On 2018/3/28 12:37, Vivek Gautam wrote:
Hi Yisheng
On 3/28/2018
On Tue, 10 Apr 2018, Gabriel Francisco Mandaji wrote:
> Fix most checkpatch.pl issues of type:
>
> CHECK: Alignment should match open parenthesis
>
> Signed-off-by: Gabriel Francisco Mandaji
> ---
> drivers/staging/comedi/drivers/cb_pcidas64.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 d
>2018-04-11 6:00 GMT+02:00 Gabriel C :
> 2018-04-09 11:42 GMT+02:00 Christian König :
>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
...
> I can help testing code for 4.17/++ if you wish but that is *different*
> storry.
>
Quick tested an 4.16.0-11490-gb284d4d5a678 , amdgpu and radeon driver
Hi Andy,
> Am 10.04.2018 um 20:06 schrieb Andy Shevchenko :
>
> On Tue, Apr 10, 2018 at 7:07 PM, H. Nikolaus Schaller
> wrote:
>> PCAL chips ("L" seems to stand for "latched") have additional
>> registers starting at address 0x40 to control the latches,
>> interrupt mask, pull-up and pull down
Hi all,
Please do not add any v4.18 destined stuff to your linux-next included
trees until after v4.17-rc1 has been released.
Changes since 20180410:
The parisc-hd tree still had its build failure for which I applied a patch.
Non-merge commits (relative to Linus' tree): 1234
1303
Hi Ladis,
On Tue, 10 Apr 2018 22:56:43 +0200
Ladislav Michl wrote:
> Hi Nikolaus,
>
> On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> > Hi,
> > we just started testing the v4.16 kernel and found the
> > device no longer bootable (works with v4.15). It turned
> > out that
> Am 10.04.2018 um 20:10 schrieb Andy Shevchenko :
>
> #define PCA_LATCH_INT (PCA_PCAL | PCA_INT)
Looks the best.
I have queued it for v4.
BR and thanks,
Nikolaus
On 4/2/2018 3:53 PM, Ard Biesheuvel Wrote:
On 2 April 2018 at 09:49, Jia He wrote:
On 4/2/2018 2:55 PM, Ard Biesheuvel Wrote:
On 2 April 2018 at 04:30, Jia He wrote:
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_
On the quest to remove all VLAs from the kernel[1], this avoids VLAs
in dm-raid1.c by just using the maximum size for the stack arrays.
The nr_mirrors value was already capped at 9, so this makes it a trivial
adjustment to the array sizes.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Kee
From: Ian W MORRISON
As the Geminilake firmware is now merged to linux-firmware.git
use MODUE_FIRMWARE to load the firmware.
This removes the error message in the dmesg log:
i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
i915 :00:
On 10-04-18, 15:40, Lucas Stach wrote:
> Can you please describe how this bootconstraints core integration is
> simpler than a "run things at max performance until late kernel init",
> which could be triggered by a simple initcall similar to what is done
> for clocks and regulators?
>
> To me the
Quoting Lina Iyer (2018-04-05 09:18:25)
> Add controller driver for QCOM SoCs that have hardware based shared
> resource management. The hardware IP known as RSC (Resource State
> Coordinator) houses multiple Direct Resource Voter (DRV) for different
> execution levels. A DRV is a unique voter on t
On 10-04-18, 16:59, Patrick Bellasi wrote:
> The iowait boosting code has been recently updated to add a progressive
> boosting behavior which allows to be less aggressive in boosting tasks
> doing only sporadic IO operations, thus being more energy efficient for
> example on mobile platforms.
>
>
Hi Benjamin,
-Original Message-
From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
Sent: Tuesday, April 10, 2018 3:35 PM
To: 廖崇榮
Cc: Dmitry Torokhov; Oliver Haessler; Benjamin Berg; open list:HID CORE LAYER;
lkml
Subject: Re: [PATCH 0/8] Input: support for latest Lenovo thin
Ping?
On Fri, Apr 06, 2018 at 07:43:55AM -0700, Matthew Wilcox wrote:
> Pavel Machek wrote:
> > > Failure is not a hang, as they expect, but... machine locks up, but
> > > does not suspend, and then continues running after a delay..
> > >
> > > [ 35.038766] PM: Syncing filesystems ... done.
>
Hi Oleg,
On 04/10/2018 04:36 PM, Oleg Nesterov wrote:
> Hi Ravi,
>
> On 04/10, Ravi Bangoria wrote:
>>> and what if __mmu_notifier_register() fails simply because signal_pending()
>>> == T?
>>> see mm_take_all_locks().
>>>
>>> at first glance this all look suspicious and sub-optimal,
>> Yes. I sh
> On Apr 10, 2018, at 6:26 PM, Eric W. Biederman wrote:
>
>
> Andy,
>
> I am looking at copy_siginfo_to_user32 and find it very unfortunate
> that x86 with _sigchld_x32 needs to be the odd man out. I am looking
> at ways to simplify the special case.
>
> The core of the special case comes from:
>
Hey Arnd,
On 22 February 2018 at 15:33, Joel Stanley wrote:
> I am interested in all ASPEED drivers, and the previous match wasn't
> grabbing files in nested directories. Use N instead.
>
> Add the arm kernel mailing list so that patches get reviewed there, and
> the linux-aspeed list which exist
2018-04-09 11:42 GMT+02:00 Christian König :
> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
>>
>> Hi Christian,
>>
>> Thanks for the info. FYI, I've also opened a Firefox bug for that at:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
>> Feel free to comment since you have a better unde
The sig_enforce parameter could be always shown to reflect the
current status of modsign. For the case of CONFIG_MODULE_SIG_FORCE=y,
this modification does nothing harmless.
Signed-off-by: Jia Zhang
---
kernel/module.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/module.c b/kernel
Call is_module_sig_enforced() instead.
Signed-off-by: Jia Zhang
---
kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/module.c b/kernel/module.c
index a6e43a5..f695474 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2785,7 +2785,7 @@ static int mod
> On Apr 3, 2018, at 12:07 PM, Matthew Wilcox wrote:
>
> On Tue, Apr 03, 2018 at 03:31:15PM +0200, Michal Hocko wrote:
>> On Mon 02-04-18 09:24:22, Buddy Lumpkin wrote:
>>> The presence of direct reclaims 10 years ago was a fairly reliable
>>> indicator that too much was being asked of a Linux s
In case of xspi work in busy condition, may send bytes failed.
Add one bytes delay
Signed-off-by: sxauwsk
Signed-off-by: guojian
Signed-off-by: wangshikai
---
drivers/spi/spi-cadence.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cade
Hi,
On Apr 3, 2018, at 4:51 PM, Thomas Gleixner wrote:
Bah. The patch is broken. New version written with brain awake below.
Actually I can't reproduce this issue anymore on latest Linus' tree.
I'll do a bisect and ask linux-stable maintainer to include the commit.
Thanks for your help!
Ka
Hi Joe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16]
[also build test ERROR on next-20180410]
[cannot apply to linus/master jikos-livepatching/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
fcpci_init() is never called in atomic context.
The call chain ending up at fcpci_init() is:
[1] fcpci_init() <- fcpcipnp_setup() <- fcpnp_probe()
fcpnp_probe() is set as ".probe" in struct pnp_driver.
This function is not called in atomic context.
Despite never getting called from atomic contex
On 2018年04月11日 10:35, Stefan Hajnoczi wrote:
v3:
* Rebased onto net/master and resolved conflict [DaveM]
v2:
* Rewrote the conditional to make the vq access check clearer [Linus]
* Added Patch 2 to make the return type consistent and harder to misuse
[Linus]
The first patch fixes the v
fcpcipnp_setup() is never called in atomic context.
The call chain ending up at fcpcipnp_setup() is:
[1] fcpcipnp_setup() <- fcpnp_probe()
fcpnp_probe() is set as ".probe" in struct pnp_driver.
This function is not called in atomic context.
Despite never getting called from atomic context, fcpci
usb_isoc_urb_init() is never called in atomic context.
The call chains ending up at usb_isoc_urb_init() are:
[1] usb_isoc_urb_init() <- usb_urb_init()
<- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init
<- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe()
xxx_probe inclu
Shuah Khan writes:
> On 04/10/2018 03:45 AM, Christian Brauner wrote:
>> On Tue, Apr 10, 2018 at 04:20:53PM +1000, Michael Ellerman wrote:
>>> In commit ce290a19609d ("selftests: add devpts selftests"), the
>>> filesystems directory was added to the top-level selftests Makefile.
>>>
>>> That had t
usb_bulk_urb_init() is never called in atomic context.
The call chains ending up at usb_bulk_urb_init() are:
[1] usb_bulk_urb_init() <- usb_urb_init()
<- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init
<- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe()
xxx_probe inclu
usb_allocate_stream_buffers() is never called in atomic context.
The call chains ending up at usb_allocate_stream_buffers() are:
[1] usb_allocate_stream_buffers() <- usb_bulk_urb_init() <- usb_urb_init()
<- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init
<- dvb_usb_init() <-
On Tue, Apr 10, 2018 at 09:44:16PM +0800, Baoquan He wrote:
>Hi Rob,
>
>Thanks a lot for looking into this and involve Nico to this thread!
>
>On 04/09/18 at 09:49am, Rob Herring wrote:
>> +Nico who has been working on tinification of the kernel.
>>
>> On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He w
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Robin Murphy
> Sent: Monday, April 09, 2018 8:11 PM
> To: Wang, Dongsheng ; Lorenzo Pieralisi
>
> Cc: r...@rjwysocki.net; gre...@linuxfoundation.org; hanjun@linaro.org
On Tue, Apr 10, 2018 at 7:44 PM Wang Long wrote:
> > Hi,
> >
> > [This is an automated email]
> >
> > This commit has been processed by the -stable helper bot and determined
> > to be a high probability candidate for -stable trees. (score: 44.5575)
> >
> > The bot has tested the following trees:
On Tue, Apr 10, 2018 at 10:16 AM, Oleksandr Natalenko
wrote:
> Hi, Kees, Paolo et al.
>
> 10.04.2018 08:53, Kees Cook wrote:
>>
>> Unfortunately I only had a single hang with no dumps. I haven't been
>> able to reproduce it since. :(
>
>
> For your convenience I've prepared a VM that contains a re
On 2018年04月10日 05:11, Jonathan Helman wrote:
On 03/22/2018 07:38 PM, Jason Wang wrote:
On 2018年03月22日 11:10, Michael S. Tsirkin wrote:
On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote:
On 2018年03月20日 12:26, Jonathan Helman wrote:
On Mar 19, 2018, at 7:31 PM, Jason Wang wrote:
> On Apr 3, 2018, at 6:31 AM, Michal Hocko wrote:
>
> On Mon 02-04-18 09:24:22, Buddy Lumpkin wrote:
>> Page replacement is handled in the Linux Kernel in one of two ways:
>>
>> 1) Asynchronously via kswapd
>> 2) Synchronously, via direct reclaim
>>
>> At page allocation time the allocating ta
kim_probe() is never called in atomic context.
This function is only set as ".probe" in struct platform_driver.
Despite never getting called from atomic context,
kim_probe() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with G
doc_probe() is never called in atomic context.
doc_probe() is only called by init_nanddoc(), which is only set as
a parameter of module_init().
This function is not called in atomic context.
Despite never getting called from atomic context, doc_probe()
calls mdelay() to busily wait.
This is not
Hi Jerome,
On 2018/4/9 22:13, Jerome Brunet wrote:
In clk_bulk_get(), if we fail to get the clock due to probe deferal, we
shouldn't print an error message. Just be silent in this case.
I saw a confusing clk get failure log occasionally, but didn't pay
much attention to it as the driver final
wbsd_platform_resume() is never called in atomic context.
This function is only set as ".resume" in struct platform_driver.
Despite never getting called from atomic context, wbsd_platform_resume()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid
wbsd_pnp_resume() is never called in atomic context.
This function is only set as ".resume" in struct pnp_driver.
Despite never getting called from atomic context, wbsd_pnp_resume()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.
wbsd_init() is never called in atomic context.
The call chains ending up at wbsd_init() are:
[1] wbsd_init() <- wbsd_probe()
[2] wbsd_init() <- wbsd_pnp_probe()
wbsd_probe() is set as ".probe" in struct platform_driver.
wbsd_pnp_probe() is set as ".probe" in struct pnp_driver.
These functions are
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 44.5575)
The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33, v4.9.93,
v4.4.127.
v4.16.1: Build OK!
v4.15.16
Commit d65026c6c62e7d9616c8ceb5a53b68bcdc050525 ("vhost: validate log
when IOTLB is enabled") introduced a regression. The logic was
originally:
if (vq->iotlb)
return 1;
return A && B;
After the patch the short-circuit logic for A was inverted:
if (A || vq->iotlb)
return A;
Currently vhost *_access_ok() functions return int. This is error-prone
because there are two popular conventions:
1. 0 means failure, 1 means success
2. -errno means failure, 0 means success
Although vhost mostly uses #1, it does not do so consistently.
umem_access_ok() uses #2.
This patch cha
v3:
* Rebased onto net/master and resolved conflict [DaveM]
v2:
* Rewrote the conditional to make the vq access check clearer [Linus]
* Added Patch 2 to make the return type consistent and harder to misuse [Linus]
The first patch fixes the vhost virtqueue access check which was recently
broken
cas_check_invariants() is never called in atomic context.
cas_check_invariants() is only called by cas_init_one(), which is
only set as ".probe" in struct pci_driver.
Despite never getting called from atomic context,
cas_check_invariants() calls alloc_pages() with GFP_ATOMIC,
which does not slee
Quoting Lina Iyer (2018-04-09 08:36:31)
> On Fri, Apr 06 2018 at 19:21 -0600, Stephen Boyd wrote:
> >Quoting Lina Iyer (2018-04-05 09:18:28)
> >> diff --git a/include/soc/qcom/rpmh.h b/include/soc/qcom/rpmh.h
> >> new file mode 100644
> >> index ..95334d4c1ede
> >> --- /dev/null
> >> ++
sxgbe_sw_reset() is never called in atomic context.
sxgbe_sw_reset() is only called by sxgbe_drv_probe(), which is
only called by sxgbe_platform_probe().
sxgbe_platform_probe() is set as ".probe" in struct platform_driver.
This function is not called in atomic context.
Despite never getting call
On 2018年04月10日 22:23, Liang, Cunming wrote:
-Original Message-
From: Michael S. Tsirkin [mailto:m...@redhat.com]
Sent: Tuesday, April 10, 2018 9:36 PM
To: Liang, Cunming
Cc: Paolo Bonzini; Bie, Tiwei;
Jason Wang;alex.william...@redhat.com;
ddut...@redhat.com; Duyck, Alexander H;
virtio-
atusb_probe() is never called in atomic context.
This function is only set as ".probe" in struct usb_driver.
Despite never getting called from atomic context,
atusb_probe() calls usb_alloc_urb() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced w
On Tue, 10 Apr 2018 20:00:59 -0400
Steven Rostedt wrote:
> On Tue, 10 Apr 2018 16:10:30 -0700
> Howard McLauchlan wrote:
>
> > uprobes cannot successfully attach to binaries located in a directory
> > mounted with overlayfs.
> >
> > To verify, create directories for mounting overlayfs
> > (upp
On 2018年04月10日 17:23, Liang, Cunming wrote:
-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: Tuesday, April 10, 2018 3:52 PM
To: Bie, Tiwei ; Jason Wang
Cc: m...@redhat.com; alex.william...@redhat.com; ddut...@redhat.com;
Duyck, Alexander H ; virtio-dev@lists
i40evf_add_vlan() is never called in atomic context.
i40evf_add_vlan() is only called by i40evf_vlan_rx_add_vid(),
which is only set as ".ndo_vlan_rx_add_vid" in struct net_device_ops.
".ndo_vlan_rx_add_vid" is not called in atomic context.
Despite never getting called from atomic context,
i40e
On Tue, Apr 10, 2018 at 09:23:53AM +, Liang, Cunming wrote:
> If QEMU is going to build a user space driver framework there, we're open
> mind on that, even leveraging DPDK as the underlay library. Looking forward
> to more others' comments from community.
There is already an NVMe VFIO drive
Srinivas:
This series is a second iteration of the patchset adding NVMEM support
for EEPROMs connected to RAVE SP MFD device (support for which landed
in 4.15).
Changes since [v1]:
- Patchset rebased on latest master from Linus which contains
all necessary dependencies
1 - 100 of 1296 matches
Mail list logo
