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
> >
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
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:
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:
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
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
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
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,
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:
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:
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
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
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
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
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
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
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(+)
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
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
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
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
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
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
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
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 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
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
>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
>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
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 files
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 files
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).
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
> 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
> 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
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
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:
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:
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
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
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
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
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
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.
>
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
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
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
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
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
> 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
> 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
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
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
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
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
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
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
@@
> 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
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
> 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
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
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
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.
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!
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
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
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
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
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,
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
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,
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
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
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
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
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
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
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()
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
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
> -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:
> -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;
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
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
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
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
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
1 - 100 of 2606 matches
Mail list logo