+LKML
I can not find the possibility when I check the code. because the mmap_sem and
spin_lock will
protect the concurrence.
I will be appreciated if anyone has some clue.
Thanks,
zhong jiang
On 2018/11/8 23:01, zhong jiang wrote:
> Hi,
>
> Recently, I hit the following issue in linux
+LKML
I can not find the possibility when I check the code. because the mmap_sem and
spin_lock will
protect the concurrence.
I will be appreciated if anyone has some clue.
Thanks,
zhong jiang
On 2018/11/8 23:01, zhong jiang wrote:
> Hi,
>
> Recently, I hit the following issue in linux
On 11/2/18 10:28 AM, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: d81f50bd34646d8373b989e55180c0fc9af94e0b
> commit: 3c670dba864d9ab0a23612a93b7d98700734bd44 ACPI / PMIC: xpower: Block
> P-Unit I2C access during
On 11/2/18 10:28 AM, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: d81f50bd34646d8373b989e55180c0fc9af94e0b
> commit: 3c670dba864d9ab0a23612a93b7d98700734bd44 ACPI / PMIC: xpower: Block
> P-Unit I2C access during
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
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
The cpu-map DT entry in ARM64 can describe the CPU topology in
much better way compared to other existing approaches. RISC-V can
easily adopt this binding to represent it's 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
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
---
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.
No functional changes done.
Signed-off-by: Atish Patra
---
arch/arm64/include/asm/topology.h | 23 +--
The cpu-map DT entry in ARM64 can describe the CPU topology in
much better way compared to other existing approaches. RISC-V can
easily adopt this binding to represent it's 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
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
---
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.
No functional changes done.
Signed-off-by: Atish Patra
---
arch/arm64/include/asm/topology.h | 23 +--
This driver works for controlling the reset lines including USB3
glue layer, however, this can be applied to other glue layers.
Now this patch renames the driver from "reset-uniphier-usb3" to
"reset-uniphier-glue".
At the same time, this changes CONFIG_RESET_UNIPHIER_USB3 to
This driver works for controlling the reset lines including USB3
glue layer, however, this can be applied to other glue layers.
Now this patch renames the driver from "reset-uniphier-usb3" to
"reset-uniphier-glue".
At the same time, this changes CONFIG_RESET_UNIPHIER_USB3 to
This series renames the reset control of core reset included in USB3 glue
layer with in the glue layer for generic peripherals to allow other devices
to use it.
And this series adds support for the core reset included in AHCI glue layer.
Kunihiko Hayashi (4):
dt-bindings: reset: uniphier:
Add compatible strings for reset control of AHCI core implemented in
UniPhier SoCs. The reset control belongs to AHCI glue layer.
Signed-off-by: Kunihiko Hayashi
---
Documentation/devicetree/bindings/reset/uniphier-reset.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
This series renames the reset control of core reset included in USB3 glue
layer with in the glue layer for generic peripherals to allow other devices
to use it.
And this series adds support for the core reset included in AHCI glue layer.
Kunihiko Hayashi (4):
dt-bindings: reset: uniphier:
Add compatible strings for reset control of AHCI core implemented in
UniPhier SoCs. The reset control belongs to AHCI glue layer.
Signed-off-by: Kunihiko Hayashi
---
Documentation/devicetree/bindings/reset/uniphier-reset.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
Add a reset line included in AHCI glue layer to enable AHCI core
implemented in UniPhier SoCs.
Signed-off-by: Kunihiko Hayashi
---
drivers/reset/reset-uniphier-glue.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/reset/reset-uniphier-glue.c
Replace the expression of "USB3 glue layer" with the glue layer of the
generic peripherals to allow other devices to use it. The reset control
belongs to this glue layer.
Signed-off-by: Kunihiko Hayashi
---
.../devicetree/bindings/reset/uniphier-reset.txt | 22 +++---
1 file
Add a reset line included in AHCI glue layer to enable AHCI core
implemented in UniPhier SoCs.
Signed-off-by: Kunihiko Hayashi
---
drivers/reset/reset-uniphier-glue.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/reset/reset-uniphier-glue.c
Replace the expression of "USB3 glue layer" with the glue layer of the
generic peripherals to allow other devices to use it. The reset control
belongs to this glue layer.
Signed-off-by: Kunihiko Hayashi
---
.../devicetree/bindings/reset/uniphier-reset.txt | 22 +++---
1 file
Hi Christian,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.20-rc1 next-20181108]
[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
Hi Christian,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.20-rc1 next-20181108]
[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
Hi, Fabio
Best Regards!
Anson Huang
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018年11月8日 23:38
> To: Anson Huang
> Cc: Rob Herring ; Mark Rutland
> ; Shawn Guo ; Sascha
> Hauer ; Sascha Hauer ;
> Fabio Estevam ; open list:OPEN FIRMWARE AND
>
Hi, Fabio
Best Regards!
Anson Huang
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018年11月8日 23:38
> To: Anson Huang
> Cc: Rob Herring ; Mark Rutland
> ; Shawn Guo ; Sascha
> Hauer ; Sascha Hauer ;
> Fabio Estevam ; open list:OPEN FIRMWARE AND
>
Current imx7d-sdb.dts has some incorrect settings about
Rev-A and Rev-B boards, some of the settings are based on
Rev-A board but some are based on Rev-B board, clean up it
by adding i.MX7D SDB Rev-A board support, make default
imx7d-sdb.dts for Rev-B board as usual, and introduce
Current imx7d-sdb.dts has some incorrect settings about
Rev-A and Rev-B boards, some of the settings are based on
Rev-A board but some are based on Rev-B board, clean up it
by adding i.MX7D SDB Rev-A board support, make default
imx7d-sdb.dts for Rev-B board as usual, and introduce
Hi All,
On Thu, Nov 08, 2018 at 02:20:52PM -0800, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 08 Nov 2018 13:48:25 + bugzilla-dae...@bugzilla.kernel.org wrote:
>
> >
Hi All,
On Thu, Nov 08, 2018 at 02:20:52PM -0800, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 08 Nov 2018 13:48:25 + bugzilla-dae...@bugzilla.kernel.org wrote:
>
> >
Rian Quinn writes:
> I apologize upfront if this is the wrong place to post this, pretty new to
> this.
>
> We are working on the Bareflank Hypervisor (www.bareflank.org), and we
> are passing through the INIT/SIPI process (similar to how a VMX
> rootkit from EFI might boot the OS) and we
Rian Quinn writes:
> I apologize upfront if this is the wrong place to post this, pretty new to
> this.
>
> We are working on the Bareflank Hypervisor (www.bareflank.org), and we
> are passing through the INIT/SIPI process (similar to how a VMX
> rootkit from EFI might boot the OS) and we
On Wed, Oct 10, 2018 at 03:19:03PM +0800, Huang Ying wrote:
> And for all, Any comment is welcome!
Hi Ying,
Looks like an edge case. I'd run the program at the bottom like
./stress-usage-counts -l 4 -s 4 -U 780g
where the 780g was big enough to cause swapping on the machine. This
On Wed, Oct 10, 2018 at 03:19:03PM +0800, Huang Ying wrote:
> And for all, Any comment is welcome!
Hi Ying,
Looks like an edge case. I'd run the program at the bottom like
./stress-usage-counts -l 4 -s 4 -U 780g
where the 780g was big enough to cause swapping on the machine. This
SND_SOC_RK3399_GRU_SOUND selects SND_SOC_DA7219, SND_SOC_MAX98357A,
SND_SOC_RT5514, SND_SOC_RT5514_SPI.
SND_SOC_ROCKCHIP_RT5645 selects SND_SOC_RT5645.
SND_SOC_RL6231 is pulled in for SND_SOC_RT5514 and SND_SOC_RT5645.
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 6 --
SND_SOC_RK3399_GRU_SOUND selects SND_SOC_DA7219, SND_SOC_MAX98357A,
SND_SOC_RT5514, SND_SOC_RT5514_SPI.
SND_SOC_ROCKCHIP_RT5645 selects SND_SOC_RT5645.
SND_SOC_RL6231 is pulled in for SND_SOC_RT5514 and SND_SOC_RT5645.
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 6 --
Commit e8342cc7954e ("enable CAAM crypto engine on QorIQ DPAA2 SoCs")
enabled CRYPTO_DEV_FSL_DPAA2_CAAM, which depends on FSL_MC_DPIO,
which is not set. Enable FSL_MC_BUS, and build FSL_MC_DPIO and
CRYPTO_DEV_FSL_DPAA2_CAAM as modules.
Signed-off-by: Marc Gonzalez
---
Commit e78d57b2f87c ("pinctrl: mediatek: add pinctrl-moore that
implements the generic pinctrl dt-bindings") made PINCTRL_MT7622
depend on PINCTRL_MTK_MOORE.
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
SND_SOC_ROCKCHIP_RT5645 selects SND_SOC_ROCKCHIP_I2S
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 725b9471b21c..8e181cca0a05 100644
---
SCSI_UFS_HISI depends on SCSI_UFSHCD_PLATFORM=m
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2662f83c481c..2e173978eef8 100644
---
Commit e8342cc7954e ("enable CAAM crypto engine on QorIQ DPAA2 SoCs")
enabled CRYPTO_DEV_FSL_DPAA2_CAAM, which depends on FSL_MC_DPIO,
which is not set. Enable FSL_MC_BUS, and build FSL_MC_DPIO and
CRYPTO_DEV_FSL_DPAA2_CAAM as modules.
Signed-off-by: Marc Gonzalez
---
Commit e78d57b2f87c ("pinctrl: mediatek: add pinctrl-moore that
implements the generic pinctrl dt-bindings") made PINCTRL_MT7622
depend on PINCTRL_MTK_MOORE.
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
SND_SOC_ROCKCHIP_RT5645 selects SND_SOC_ROCKCHIP_I2S
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 725b9471b21c..8e181cca0a05 100644
---
SCSI_UFS_HISI depends on SCSI_UFSHCD_PLATFORM=m
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2662f83c481c..2e173978eef8 100644
---
Commit a0ae2562c6c4 ("netfilter: conntrack: remove l3proto abstraction")
folded NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6 into NF_CONNTRACK.
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/configs/defconfig
Commit a0ae2562c6c4 ("netfilter: conntrack: remove l3proto abstraction")
folded NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6 into NF_CONNTRACK.
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/configs/defconfig
Commit a7314405d83c ("drop ARM_BIG_LITTLE_CPUFREQ support for ARM64")
dropped ARM_BIG_LITTLE_CPUFREQ support for ARM64, so remove it from
the defconfig.
Acked-by: Viresh Kumar
Acked-by: Sudeep Holla
Acked-by: Mark Rutland
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 1 -
1
Run the platform defconfig through kbuild, and handle the trivial case
where options merely move around.
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 90 ++--
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git
Commit a930d8bd94d8 ("usb: chipidea: Always build ULPI code") made
USB_CHIPIDEA select USB_ULPI_BUS, and removed USB_CHIPIDEA_ULPI.
Reviewed-by: Fabio Estevam
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git
Hello ARM maintainers,
v3: Keep CRYPTO_DEV_FSL_DPAA2_CAAM in patch 7/9
v2: Improve commit message for a few patches
The set of Kconfig options slowly changes with every kernel version.
This patch series regenerates the arm64 defconfig for v4.20
No functional change intended, except adding
Hello ARM maintainers,
v3: Keep CRYPTO_DEV_FSL_DPAA2_CAAM in patch 7/9
v2: Improve commit message for a few patches
The set of Kconfig options slowly changes with every kernel version.
This patch series regenerates the arm64 defconfig for v4.20
No functional change intended, except adding
Commit a7314405d83c ("drop ARM_BIG_LITTLE_CPUFREQ support for ARM64")
dropped ARM_BIG_LITTLE_CPUFREQ support for ARM64, so remove it from
the defconfig.
Acked-by: Viresh Kumar
Acked-by: Sudeep Holla
Acked-by: Mark Rutland
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 1 -
1
Run the platform defconfig through kbuild, and handle the trivial case
where options merely move around.
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 90 ++--
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git
Commit a930d8bd94d8 ("usb: chipidea: Always build ULPI code") made
USB_CHIPIDEA select USB_ULPI_BUS, and removed USB_CHIPIDEA_ULPI.
Reviewed-by: Fabio Estevam
Signed-off-by: Marc Gonzalez
---
arch/arm64/configs/defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git
From: Jiri Olsa
Date: Thu, 8 Nov 2018 08:13:03 +0100
> we could separated fork/mmaps to separate dummy event map, or just
> parse them out in the read thread and create special queue for them
> and drop just samples in case we are behind
What you say at the end here is basically what I am
From: Jiri Olsa
Date: Thu, 8 Nov 2018 08:13:03 +0100
> we could separated fork/mmaps to separate dummy event map, or just
> parse them out in the read thread and create special queue for them
> and drop just samples in case we are behind
What you say at the end here is basically what I am
Hi Stephen,
On 10/25/18 12:47 AM, Stephen Boyd wrote:
> Quoting Paul Walmsley (2018-10-20 06:50:22)
>> Cc: Wesley Terpstra
>> Cc: Palmer Dabbelt
>> Cc: Michael Turquette
>> Cc: Stephen Boyd
>> Cc: Megan Wachs
>>
Hi Stephen,
On 10/25/18 12:47 AM, Stephen Boyd wrote:
> Quoting Paul Walmsley (2018-10-20 06:50:22)
>> Cc: Wesley Terpstra
>> Cc: Palmer Dabbelt
>> Cc: Michael Turquette
>> Cc: Stephen Boyd
>> Cc: Megan Wachs
>>
> Can we change this, such that perf_event_output also takes a second set of
> registers (iregs) that get sampled for PERF_SAMPLE_REGS_INTR? I'm very new to
> real kernel development, what kind of ABI/API stability guarantees exist for
> something like "perf_event_output"?
Yes you can change
> Can we change this, such that perf_event_output also takes a second set of
> registers (iregs) that get sampled for PERF_SAMPLE_REGS_INTR? I'm very new to
> real kernel development, what kind of ABI/API stability guarantees exist for
> something like "perf_event_output"?
Yes you can change
> - Independently, when I add a custom printk manually in `arch/x86/events/
> intel/ds.c` at the end of `setup_pebs_sample_data`, then I'm never seeing any
> differences between SP in iregs/pebs/regs. Shouldn't it also be recorded via
> PEBS? Or is it just chance that I'm never seeing any
> - Independently, when I add a custom printk manually in `arch/x86/events/
> intel/ds.c` at the end of `setup_pebs_sample_data`, then I'm never seeing any
> differences between SP in iregs/pebs/regs. Shouldn't it also be recorded via
> PEBS? Or is it just chance that I'm never seeing any
On Thu, Nov 08 2018, Chuck Lever wrote:
>
> Point taken, but having a single mempool for all RPC transports
> and users is also going to be a shared resource that can
> bottleneck.
Agreed.
mempools will only access the pre-allocated memory if a regular
kmalloc(GFP_NOWAIT) fails. I asked an mm
On Thu, Nov 08 2018, Chuck Lever wrote:
>
> Point taken, but having a single mempool for all RPC transports
> and users is also going to be a shared resource that can
> bottleneck.
Agreed.
mempools will only access the pre-allocated memory if a regular
kmalloc(GFP_NOWAIT) fails. I asked an mm
On Thu, Nov 08 2018, J. Bruce Fields wrote:
> On Mon, Nov 05, 2018 at 12:30:48PM +1100, NeilBrown wrote:
>> When we find an existing lock which conflicts with a request,
>> and the request wants to wait, we currently add the request
>> to a list. When the lock is removed, the whole list is
On Thu, Nov 08 2018, J. Bruce Fields wrote:
> On Mon, Nov 05, 2018 at 12:30:48PM +1100, NeilBrown wrote:
>> When we find an existing lock which conflicts with a request,
>> and the request wants to wait, we currently add the request
>> to a list. When the lock is removed, the whole list is
On Thu, Nov 08 2018, J. Bruce Fields wrote:
> On Mon, Nov 05, 2018 at 12:30:47PM +1100, NeilBrown wrote:
>> struct file lock contains an 'fl_next' pointer which
>> is used to point to the lock that this request is blocked
>> waiting for. So rename it to fl_blocker.
>>
>> The fl_blocked
On Thu, Nov 08 2018, J. Bruce Fields wrote:
> On Mon, Nov 05, 2018 at 12:30:47PM +1100, NeilBrown wrote:
>> struct file lock contains an 'fl_next' pointer which
>> is used to point to the lock that this request is blocked
>> waiting for. So rename it to fl_blocker.
>>
>> The fl_blocked
> >
> > To fix this, I suggest a patch by emboding the mentioned solution.
> > First, revive and rework cancel_freezing_and_thaw() function whitch
> > stops the task from sleeping in refrigirator reliably. And, The task
> > to be killed does not allow to freeze.
>
> Can't we simply change
> >
> > To fix this, I suggest a patch by emboding the mentioned solution.
> > First, revive and rework cancel_freezing_and_thaw() function whitch
> > stops the task from sleeping in refrigirator reliably. And, The task
> > to be killed does not allow to freeze.
>
> Can't we simply change
On Thu, Nov 08, 2018 at 07:04:38PM -0500, Sasha Levin wrote:
> On Fri, Nov 09, 2018 at 12:28:10AM +0100, David Sterba wrote:
> > On Thu, Nov 08, 2018 at 01:50:41PM -0800, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch. If anyone has any objections, please let me
> > > know.
> >
> > > [
On Thu, Nov 08, 2018 at 07:04:38PM -0500, Sasha Levin wrote:
> On Fri, Nov 09, 2018 at 12:28:10AM +0100, David Sterba wrote:
> > On Thu, Nov 08, 2018 at 01:50:41PM -0800, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch. If anyone has any objections, please let me
> > > know.
> >
> > > [
On Tue, Nov 06, 2018 at 03:12:13PM +0800, AceLan Kao wrote:
> It leads to the power consumption raises to 2.2W during s2idle, while
> it consumes less than 1W during long idle if put SK hynix nvme to D3
> and then enter s2idle.
> From SK hynix FE, MS Windows doesn't put nvme to D3, and uses its
On Tue, Nov 06, 2018 at 03:12:13PM +0800, AceLan Kao wrote:
> It leads to the power consumption raises to 2.2W during s2idle, while
> it consumes less than 1W during long idle if put SK hynix nvme to D3
> and then enter s2idle.
> From SK hynix FE, MS Windows doesn't put nvme to D3, and uses its
On 11/02/2018 04:36 PM, Daniel Borkmann wrote:
Hi Rong,
On 11/02/2018 03:14 AM, kernel test robot wrote:
Greeting,
FYI, we noticed a -4.0% regression of will-it-scale.per_process_ops due to
commit:
commit: fd978bf7fd312581a7ca454a991f0ffb34c4204b ("bpf: Add reference tracking to
On 11/02/2018 04:36 PM, Daniel Borkmann wrote:
Hi Rong,
On 11/02/2018 03:14 AM, kernel test robot wrote:
Greeting,
FYI, we noticed a -4.0% regression of will-it-scale.per_process_ops due to
commit:
commit: fd978bf7fd312581a7ca454a991f0ffb34c4204b ("bpf: Add reference tracking to
On Fri, Nov 09, 2018 at 12:28:10AM +0100, David Sterba wrote:
On Thu, Nov 08, 2018 at 01:50:41PM -0800, Greg Kroah-Hartman wrote:
4.4-stable review patch. If anyone has any objections, please let me know.
[ Upstream commit 838fe1887765f4cc679febea60d87d2a06bd300e ]
Please check the
On Fri, Nov 09, 2018 at 12:28:10AM +0100, David Sterba wrote:
On Thu, Nov 08, 2018 at 01:50:41PM -0800, Greg Kroah-Hartman wrote:
4.4-stable review patch. If anyone has any objections, please let me know.
[ Upstream commit 838fe1887765f4cc679febea60d87d2a06bd300e ]
Please check the
On Thu, Oct 25, 2018 at 02:52:31PM +0100, Colin King wrote:
> From: Colin Ian King
>
> In the expression "word1 << 16", word1 starts as u16, but is promoted to
> a signed int, then sign-extended to resource_size_t, which is probably
> not what was intended. Cast to resource_size_t to avoid the
On Thu, Oct 25, 2018 at 02:52:31PM +0100, Colin King wrote:
> From: Colin Ian King
>
> In the expression "word1 << 16", word1 starts as u16, but is promoted to
> a signed int, then sign-extended to resource_size_t, which is probably
> not what was intended. Cast to resource_size_t to avoid the
The Motorola/Zebra Symbol DS4308-HD is a handheld USB barcode scanner
which does not have a battery, but reports one anyway that always has
capacity 2.
Let's apply the IGNORE quirk to prevent it from being treated like a
power supply so that userspaces don't get confused that this
accessory is
The Motorola/Zebra Symbol DS4308-HD is a handheld USB barcode scanner
which does not have a battery, but reports one anyway that always has
capacity 2.
Let's apply the IGNORE quirk to prevent it from being treated like a
power supply so that userspaces don't get confused that this
accessory is
On Thu, Nov 8, 2018 at 4:40 PM Darrick J. Wong wrote:
>
> - fix incorrect dropping of error code from bmap
>
> - print buffer offsets instead of useless hashed pointers when dumping
> corrupt metadata
>
> - fix integer overflow in attribute verifier
Pulled,
Linus
On Thu, Nov 8, 2018 at 4:40 PM Darrick J. Wong wrote:
>
> - fix incorrect dropping of error code from bmap
>
> - print buffer offsets instead of useless hashed pointers when dumping
> corrupt metadata
>
> - fix integer overflow in attribute verifier
Pulled,
Linus
Hi Zubin,
On Thu, Nov 08, 2018 at 09:11:15AM -0800, Zubin Mithra wrote:
> pci_root_ops is only written to from within intel_mid_pci_init. This
> is linked in only when CONFIG_X86_INTEL_MID is set. If not for this,
> pci_root_ops could be marked as const.
>
> Fix this by replacing pci_root_ops
On Thu, Nov 8, 2018 at 1:29 PM Jacek Anaszewski
wrote:
>
>
> All three fixes are related to the newly added pattern trigger:
>
> - remove mutex_lock() from timer callback, which would trigger problems
> related to sleeping in atomic context, the removal is harmless since
> mutex protection
Hi Zubin,
On Thu, Nov 08, 2018 at 09:11:15AM -0800, Zubin Mithra wrote:
> pci_root_ops is only written to from within intel_mid_pci_init. This
> is linked in only when CONFIG_X86_INTEL_MID is set. If not for this,
> pci_root_ops could be marked as const.
>
> Fix this by replacing pci_root_ops
On Thu, Nov 8, 2018 at 1:29 PM Jacek Anaszewski
wrote:
>
>
> All three fixes are related to the newly added pattern trigger:
>
> - remove mutex_lock() from timer callback, which would trigger problems
> related to sleeping in atomic context, the removal is harmless since
> mutex protection
On Wed, Oct 24, 2018 at 05:13:59PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> arch/x86/kernel/early-quirks.c contains special PCI quirks that need to
> run even before the usual DECLARE_PCI_FIXUP_EARLY() quirks. These have
> typically been merged by the x86 maintainers, which is
On Wed, Oct 24, 2018 at 05:13:59PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> arch/x86/kernel/early-quirks.c contains special PCI quirks that need to
> run even before the usual DECLARE_PCI_FIXUP_EARLY() quirks. These have
> typically been merged by the x86 maintainers, which is
On Thu, Nov 8, 2018 at 10:05 AM Takashi Iwai wrote:
>
> sound fixes for 4.20-rc2
>
> Two small regression fixes for HD-audio: one about vga_switcheroo and
> runtime PM, and another about Oops on some Thinkpads.
Pulled,
Linus
On Thu, Nov 8, 2018 at 10:05 AM Takashi Iwai wrote:
>
> sound fixes for 4.20-rc2
>
> Two small regression fixes for HD-audio: one about vga_switcheroo and
> runtime PM, and another about Oops on some Thinkpads.
Pulled,
Linus
Select CONFIG_CPU_NO_EFFICIENT_FFS via Kconfig when the kernel is
configured for a pre-MIPS32r1 CPU, rather than defining its equivalent
in asm/cpu-features.h based upon overrides of cpu_has_mips* macros.
The latter only works if a platform has an cpu-feature-overrides.h
header which defines
The CPU_NO_EFFICIENT_FFS pre-processor macro is no longer used, with all
architectures toggling the equivalent Kconfig symbol
CONFIG_CPU_NO_EFFICIENT_FFS instead. Remove our check for the unused
macro.
Signed-off-by: Paul Burton
Cc: Andrew Morton
Cc: Zhaoxiu Zeng
---
lib/gcd.c | 2 +-
1
Select CONFIG_CPU_NO_EFFICIENT_FFS via Kconfig when the kernel is
configured for a pre-MIPS32r1 CPU, rather than defining its equivalent
in asm/cpu-features.h based upon overrides of cpu_has_mips* macros.
The latter only works if a platform has an cpu-feature-overrides.h
header which defines
The CPU_NO_EFFICIENT_FFS pre-processor macro is no longer used, with all
architectures toggling the equivalent Kconfig symbol
CONFIG_CPU_NO_EFFICIENT_FFS instead. Remove our check for the unused
macro.
Signed-off-by: Paul Burton
Cc: Andrew Morton
Cc: Zhaoxiu Zeng
---
lib/gcd.c | 2 +-
1
Dear Sir/Madam,
Its really nice contacting you and hope to have a good business
relationship.
I have urgent Investment proposal from Algeria, as i was
informed, and i
think you might be interested.
I was in contact with a high profile past Government Official in
Algeria,
who i happen to
Dear Sir/Madam,
Its really nice contacting you and hope to have a good business
relationship.
I have urgent Investment proposal from Algeria, as i was
informed, and i
think you might be interested.
I was in contact with a high profile past Government Official in
Algeria,
who i happen to
On Thu, Nov 08, 2018 at 01:50:41PM -0800, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
> [ Upstream commit 838fe1887765f4cc679febea60d87d2a06bd300e ]
Please check the discussion under
Now that flag PHY_HAS_INTERRUPT has been replaced with a check for
callbacks config_intr and ack_interrupt, we can remove setting this
flag from all driver configs.
Last but not least remove flag PHY_HAS_INTERRUPT completely.
Signed-off-by: Heiner Kallweit
---
v2:
- remove flag from all driver
201 - 300 of 2670 matches
Mail list logo
