On Tue, 13 Nov 2018, Michal Hocko wrote:
> From: Michal Hocko
>
> Swap storage is restricted to max_swapfile_size (~16TB on x86_64)
> whenever the system is deemed affected by L1TF vulnerability. Even
> though the limit is quite high for most deployments it seems to be
> too restrictive for
On Tue, 13 Nov 2018, Michal Hocko wrote:
> From: Michal Hocko
>
> Swap storage is restricted to max_swapfile_size (~16TB on x86_64)
> whenever the system is deemed affected by L1TF vulnerability. Even
> though the limit is quite high for most deployments it seems to be
> too restrictive for
On 11/12/2018 10:23 PM, Linus Walleij wrote:
> On Sun, Nov 11, 2018 at 1:03 PM Pavel Machek wrote:
>
>>> -"devicename:colour:function"
>>> +"colour:function"
>>
>> I don't think we want to do it in all cases.
>>
>> So, on my cellphone seeing lp5523:green:led is indeed not useful.
>>
>> But on
On 11/12/2018 10:23 PM, Linus Walleij wrote:
> On Sun, Nov 11, 2018 at 1:03 PM Pavel Machek wrote:
>
>>> -"devicename:colour:function"
>>> +"colour:function"
>>
>> I don't think we want to do it in all cases.
>>
>> So, on my cellphone seeing lp5523:green:led is indeed not useful.
>>
>> But on
On Thu, Sep 27, 2018 at 02:07:36PM +, Anand Moon wrote:
> Add SD card write-protect pin configuration to be sure that it will be
> properly pulled down to indicate write access.
>
> Suggested-by: Krzysztof Kozlowski
> Signed-off-by: Anand Moon
> ---
> Changes since v4:
> 1. Remove cd-gpios
On Thu, Sep 27, 2018 at 02:07:36PM +, Anand Moon wrote:
> Add SD card write-protect pin configuration to be sure that it will be
> properly pulled down to indicate write access.
>
> Suggested-by: Krzysztof Kozlowski
> Signed-off-by: Anand Moon
> ---
> Changes since v4:
> 1. Remove cd-gpios
The patch
regulator: bd718x7: Use regulator_map_voltage_ascend for buck5 and buck7
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually
The patch
regulator: bd718x7: Use regulator_map_voltage_ascend for buck5 and buck7
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually
On 11/12/18, 5:23 PM, "John Stultz" wrote:
On Mon, Nov 12, 2018 at 10:56 AM, Michael Zhivich
wrote:
> Revert commit 1f45f1f33c8c ("clocksource: Make clocksource validation work
> for all clocksources") to restore correct clocksource_delta() computation
> for clocksources that
On 11/12/18, 5:23 PM, "John Stultz" wrote:
On Mon, Nov 12, 2018 at 10:56 AM, Michael Zhivich
wrote:
> Revert commit 1f45f1f33c8c ("clocksource: Make clocksource validation work
> for all clocksources") to restore correct clocksource_delta() computation
> for clocksources that
On Thu, Sep 27, 2018 at 02:07:37PM +, Anand Moon wrote:
> Set the max-frequency to 200MHz for optimal performace of eMMC.
>
Thanks, applied.
Best regards,
Krzysztof
On Thu, Sep 27, 2018 at 02:07:37PM +, Anand Moon wrote:
> Set the max-frequency to 200MHz for optimal performace of eMMC.
>
Thanks, applied.
Best regards,
Krzysztof
On 11/13/2018 08:41 AM, Lendacky, Thomas wrote:
> On 11/13/2018 04:20 AM, Borislav Petkov wrote:
>> On Tue, Nov 13, 2018 at 08:17:12AM +0100, Ingo Molnar wrote:
>>>
>>> * Bjorn Helgaas wrote:
>>>
PCI changes:
- Pay attention to device-specific _PXM node values (Jonathan Cameron)
Hi Mark,
On Tue, 13 Nov 2018 at 19:35, Mark Brown wrote:
> On Mon, Nov 12, 2018 at 03:27:36PM +0100, Emil Renner Berthing wrote:
>
> > I know the discussions about the sifive devicetree compatible
> > strings haven't come to a conclusion, so I'm sending this as
> > an RFC to get some feedback on
On 11/13/2018 08:41 AM, Lendacky, Thomas wrote:
> On 11/13/2018 04:20 AM, Borislav Petkov wrote:
>> On Tue, Nov 13, 2018 at 08:17:12AM +0100, Ingo Molnar wrote:
>>>
>>> * Bjorn Helgaas wrote:
>>>
PCI changes:
- Pay attention to device-specific _PXM node values (Jonathan Cameron)
Hi Mark,
On Tue, 13 Nov 2018 at 19:35, Mark Brown wrote:
> On Mon, Nov 12, 2018 at 03:27:36PM +0100, Emil Renner Berthing wrote:
>
> > I know the discussions about the sifive devicetree compatible
> > strings haven't come to a conclusion, so I'm sending this as
> > an RFC to get some feedback on
Thanks all,
On Tue, 13 Nov 2018 11:03:36 -0800, Brian Norris
wrote:
> [ ... ]
>
> Cc: Genki Sky
> Cc: Christian Kujau
> Cc: Guenter Roeck
> Suggested-by: Alexander Kapshuk
> Signed-off-by: Brian Norris
Tested-by: Genki Sky
Thanks all,
On Tue, 13 Nov 2018 11:03:36 -0800, Brian Norris
wrote:
> [ ... ]
>
> Cc: Genki Sky
> Cc: Christian Kujau
> Cc: Guenter Roeck
> Suggested-by: Alexander Kapshuk
> Signed-off-by: Brian Norris
Tested-by: Genki Sky
The patch
ASoC: AMD: add ACP 3.x IP register header
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
ASoC: AMD: add ACP3.0 PCI driver
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: AMD: add ACP 3.x IP register header
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
ASoC: AMD: add ACP3.0 PCI driver
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: amd: create ACP3x PCM platform device
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
ASoC: amd: create ACP3x PCM platform device
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
ASoC: amd: add acp3x pcm driver dma ops
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
There are two common DTSI files for Exynos5422 Odroid XU3 family of
boards. One is shared between all of them (XU3, XU3-Lite, XU4 and HC1)
and the second skips HC1. Document this in the files.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +-
The patch
ASoC: amd: add acp3x pcm driver dma ops
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
There are two common DTSI files for Exynos5422 Odroid XU3 family of
boards. One is shared between all of them (XU3, XU3-Lite, XU4 and HC1)
and the second skips HC1. Document this in the files.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +-
The patch
ASoC: amd: Interrupt handler changes for ACP3x DMA driver
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
ASoC: amd: add ACP3x PCM platform driver
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
ASoC: amd: Interrupt handler changes for ACP3x DMA driver
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
ASoC: amd: add ACP3x PCM platform driver
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
ASoC: amd: add acp3x i2s ops
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
The patch
ASoC: amd: add acp3x i2s ops
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
The patch
ASoC: amd: add acp3x runtime pm ops
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: amd: add acp3x system resume pm op
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
ASoC: amd: add acp3x tdm mode support
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
On Mon, Nov 12, 2018 at 11:05:02AM +0530, Vijendar Mukunda wrote:
> ACP3x drivers can be built by selecting necessary kernel config option.
> The patch enables build support of the same.
Apart from the SPDX headers this all looks fine so I've applied it,
please send followup patches converting
On Mon, Nov 12, 2018 at 11:05:02AM +0530, Vijendar Mukunda wrote:
> ACP3x drivers can be built by selecting necessary kernel config option.
> The patch enables build support of the same.
Apart from the SPDX headers this all looks fine so I've applied it,
please send followup patches converting
The patch
ASoC: amd: add acp3x runtime pm ops
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: amd: add acp3x system resume pm op
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
ASoC: amd: add acp3x tdm mode support
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: amd: enable acp3x drivers build
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: amd: enable acp3x drivers build
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
Quoting Phil Edworthy (2018-09-03 06:21:02)
> Hi Stephen,
>
> On 03 September 2018 10:33 Phil Edworthy wrote:
> > On 01 September 2018 03:46, Stephen Boyd wrote:
> > > Quoting Phil Edworthy (2018-08-31 07:07:22)
> > > > diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c index
> > > >
Quoting Phil Edworthy (2018-09-03 06:21:02)
> Hi Stephen,
>
> On 03 September 2018 10:33 Phil Edworthy wrote:
> > On 01 September 2018 03:46, Stephen Boyd wrote:
> > > Quoting Phil Edworthy (2018-08-31 07:07:22)
> > > > diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c index
> > > >
On Mon, Nov 12, 2018 at 11:04:55AM +0530, Vijendar Mukunda wrote:
> +static struct snd_pcm_ops acp3x_dma_ops = {
> + .open = NULL,
> + .close = NULL,
> + .ioctl = NULL,
> + .hw_params = NULL,
> + .hw_free = NULL,
> + .pointer = NULL,
> + .mmap = NULL,
> +};
> +
>
On Mon, Nov 12, 2018 at 11:04:55AM +0530, Vijendar Mukunda wrote:
> +static struct snd_pcm_ops acp3x_dma_ops = {
> + .open = NULL,
> + .close = NULL,
> + .ioctl = NULL,
> + .hw_params = NULL,
> + .hw_free = NULL,
> + .pointer = NULL,
> + .mmap = NULL,
> +};
> +
>
On Tue, 13 Nov 2018 at 08:31, Tigran Aivazian wrote:
> Andrew, if you would like me to make the same patch against 4.19.1 as
> well, please let me know.
I decided to just go ahead and backport it to 4.19.1 anyway (see
attached). Tested thoroughly under 4.19.1.
From: Tigran Aivazian
Subject:
On Tue, 13 Nov 2018 at 08:31, Tigran Aivazian wrote:
> Andrew, if you would like me to make the same patch against 4.19.1 as
> well, please let me know.
I decided to just go ahead and backport it to 4.19.1 anyway (see
attached). Tested thoroughly under 4.19.1.
From: Tigran Aivazian
Subject:
On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
[...]
> We can learn something from how Windows does things. On that system,
> what we think of as "libc" is actually two parts. (More, actually, but
> I'm simplifying.) At the lowest level, you have the semi-documented
>
On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
[...]
> We can learn something from how Windows does things. On that system,
> what we think of as "libc" is actually two parts. (More, actually, but
> I'm simplifying.) At the lowest level, you have the semi-documented
>
On Thu, Sep 27, 2018 at 02:07:35PM +, Anand Moon wrote:
> set the max-frequency to 200MHz for optimal performace.
>
Thanks, applied.
Best regards,
Krzysztof
On Thu, Sep 27, 2018 at 02:07:35PM +, Anand Moon wrote:
> set the max-frequency to 200MHz for optimal performace.
>
Thanks, applied.
Best regards,
Krzysztof
On Mon, Nov 12, 2018 at 11:04:52AM +0530, Vijendar Mukunda wrote:
> @@ -0,0 +1,655 @@
> +/*
> + * ACP 3.0 Register documentation
> + *
> + * Copyright (C) 2016 Advanced Micro Devices, Inc.
Please use SPDX headers on new files.
signature.asc
Description: PGP signature
On Mon, Nov 12, 2018 at 11:04:52AM +0530, Vijendar Mukunda wrote:
> @@ -0,0 +1,655 @@
> +/*
> + * ACP 3.0 Register documentation
> + *
> + * Copyright (C) 2016 Advanced Micro Devices, Inc.
Please use SPDX headers on new files.
signature.asc
Description: PGP signature
On Mon, Nov 5, 2018 at 10:43 PM Weiyi Lu wrote:
>
> Add scpsys driver for MT8183
>
> Signed-off-by: Weiyi Lu
> ---
> drivers/soc/mediatek/mtk-scpsys.c | 226 ++
> 1 file changed, 226 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c
>
Added before parameters some spaces to match open parenthesis
on previous line.
Signed-off-by: Cristian Sicilia
---
drivers/staging/rtlwifi/ps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtlwifi/ps.c b/drivers/staging/rtlwifi/ps.c
index
The parameter is sent to next line to stay in 80
characters
Signed-off-by: Cristian Sicilia
---
drivers/staging/rtlwifi/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtlwifi/core.c b/drivers/staging/rtlwifi/core.c
index ca37f75..a990281 100644
---
On Mon, Nov 5, 2018 at 10:43 PM Weiyi Lu wrote:
>
> Add scpsys driver for MT8183
>
> Signed-off-by: Weiyi Lu
> ---
> drivers/soc/mediatek/mtk-scpsys.c | 226 ++
> 1 file changed, 226 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c
>
Added before parameters some spaces to match open parenthesis
on previous line.
Signed-off-by: Cristian Sicilia
---
drivers/staging/rtlwifi/ps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtlwifi/ps.c b/drivers/staging/rtlwifi/ps.c
index
The parameter is sent to next line to stay in 80
characters
Signed-off-by: Cristian Sicilia
---
drivers/staging/rtlwifi/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtlwifi/core.c b/drivers/staging/rtlwifi/core.c
index ca37f75..a990281 100644
---
In the first patch I added some space to align previous
parenthesis.
In the second patch split a line to stay in 80 characters.
Cristian Sicilia (2):
staging: rtlwifi: Add spaces to match open parenthesis
staging: rtlwifi: Add new line to stay in 80 characters
drivers/staging/rtlwifi/core.c
In the first patch I added some space to align previous
parenthesis.
In the second patch split a line to stay in 80 characters.
Cristian Sicilia (2):
staging: rtlwifi: Add spaces to match open parenthesis
staging: rtlwifi: Add new line to stay in 80 characters
drivers/staging/rtlwifi/core.c
On Thu, Sep 27, 2018 at 02:07:34PM +, Anand Moon wrote:
> Looking at the schematic sd_2 min/max range from 1.8V/2.8V so fix the
> regulator min value to 1.8V. Without these changes sdcard will failed
> to detect on booting when UHS-I tuning is enabled.
>
Thanks, applied.
Best regards,
On Thu, Sep 27, 2018 at 02:07:34PM +, Anand Moon wrote:
> Looking at the schematic sd_2 min/max range from 1.8V/2.8V so fix the
> regulator min value to 1.8V. Without these changes sdcard will failed
> to detect on booting when UHS-I tuning is enabled.
>
Thanks, applied.
Best regards,
(not a complete review...)
On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu wrote:
>
> From: Owen Chen
>
> Both MT8183 & MT6765 add more bus protect node than previous project,
> therefore we add two more register for setup bus protect, which reside
> at INFRA_CFG & SMI_COMMON.
>
> With the following
(not a complete review...)
On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu wrote:
>
> From: Owen Chen
>
> Both MT8183 & MT6765 add more bus protect node than previous project,
> therefore we add two more register for setup bus protect, which reside
> at INFRA_CFG & SMI_COMMON.
>
> With the following
Currently the ti-cpufreq driver blindly registers a 'ti-cpufreq' to force
the driver to probe on any platforms where the driver is built in.
However, this should only happen on platforms that actually can make use
of the driver. There is already functionality in place to match the
SoC compatible
Currently the ti-cpufreq driver blindly registers a 'ti-cpufreq' to force
the driver to probe on any platforms where the driver is built in.
However, this should only happen on platforms that actually can make use
of the driver. There is already functionality in place to match the
SoC compatible
On Thu, Sep 27, 2018 at 02:07:33PM +, Anand Moon wrote:
> Added support for UHS-I bus speed tuning for SDR50, DDR50 SDR104.
>
Thanks, applied.
Best regards,
Krzysztof
On Thu, Sep 27, 2018 at 02:07:33PM +, Anand Moon wrote:
> Added support for UHS-I bus speed tuning for SDR50, DDR50 SDR104.
>
Thanks, applied.
Best regards,
Krzysztof
On Tue, Nov 13, 2018 at 09:51:05AM -0800, Bo Yan wrote:
> The function tegra_read_chipid is declared twice in fuse.h. Remove
> the redundant declaration.
>
> Signed-off-by: Bo Yan
> ---
> include/soc/tegra/fuse.h | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks.
Thierry
signature.asc
On Tue, Nov 13, 2018 at 09:51:05AM -0800, Bo Yan wrote:
> The function tegra_read_chipid is declared twice in fuse.h. Remove
> the redundant declaration.
>
> Signed-off-by: Bo Yan
> ---
> include/soc/tegra/fuse.h | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks.
Thierry
signature.asc
On Tue, 13 Nov 2018 13:58:18 -0500
Qian Cai wrote:
> > Care to print the len and name parameters before this line?
> len = 60612; name =
How big are pages on arm64? Because we shouldn't get to this path if
the string is bigger than PAGE_SIZE. But I know that on PPC64,
PAGE_SIZE can be 64K,
On Tue, 13 Nov 2018 13:58:18 -0500
Qian Cai wrote:
> > Care to print the len and name parameters before this line?
> len = 60612; name =
How big are pages on arm64? Because we shouldn't get to this path if
the string is bigger than PAGE_SIZE. But I know that on PPC64,
PAGE_SIZE can be 64K,
On Tue, Nov 13, 2018 at 10:08:36AM -0800, Masami Hiramatsu wrote:
> On Sun, 11 Nov 2018 19:19:16 -0800
> "Paul E. McKenney" wrote:
>
> > On Mon, Nov 12, 2018 at 12:00:48PM +0900, Masami Hiramatsu wrote:
> > > On Sun, 11 Nov 2018 11:43:49 -0800
> > > "Paul E. McKenney" wrote:
> > >
> > > > Now
On Tue, Nov 13, 2018 at 10:08:36AM -0800, Masami Hiramatsu wrote:
> On Sun, 11 Nov 2018 19:19:16 -0800
> "Paul E. McKenney" wrote:
>
> > On Mon, Nov 12, 2018 at 12:00:48PM +0900, Masami Hiramatsu wrote:
> > > On Sun, 11 Nov 2018 11:43:49 -0800
> > > "Paul E. McKenney" wrote:
> > >
> > > > Now
On Tue, Nov 13, 2018 at 07:48:03AM -0800, Tejun Heo wrote:
> On Sun, Nov 11, 2018 at 11:43:54AM -0800, Paul E. McKenney wrote:
> > Now that call_rcu()'s callback is not invoked until after all
> > preempt-disable regions of code have completed (in addition to explicitly
> > marked RCU read-side
On Tue, Nov 13, 2018 at 07:48:03AM -0800, Tejun Heo wrote:
> On Sun, Nov 11, 2018 at 11:43:54AM -0800, Paul E. McKenney wrote:
> > Now that call_rcu()'s callback is not invoked until after all
> > preempt-disable regions of code have completed (in addition to explicitly
> > marked RCU read-side
On Tue, 2018-11-13 at 16:16 +0100, Ondrej Mosnacek wrote:
> selinux_sctp_bind_connect() must verify if the address buffer has
> sufficient length before accessing the 'sa_family' field. See
> __sctp_connect() for a similar check.
>
> The length of the whole address ('len') is already checked in
On Tue, 2018-11-13 at 16:16 +0100, Ondrej Mosnacek wrote:
> selinux_sctp_bind_connect() must verify if the address buffer has
> sufficient length before accessing the 'sa_family' field. See
> __sctp_connect() for a similar check.
>
> The length of the whole address ('len') is already checked in
On 18-11-13 19:49:10, Michal Hocko wrote:
> From: Michal Hocko
>
> Swap storage is restricted to max_swapfile_size (~16TB on x86_64)
> whenever the system is deemed affected by L1TF vulnerability. Even
> though the limit is quite high for most deployments it seems to be
> too restrictive for
On 18-11-13 19:49:10, Michal Hocko wrote:
> From: Michal Hocko
>
> Swap storage is restricted to max_swapfile_size (~16TB on x86_64)
> whenever the system is deemed affected by L1TF vulnerability. Even
> though the limit is quite high for most deployments it seems to be
> too restrictive for
On Tue, Nov 13, 2018 at 8:32 PM Brian Norris wrote:
>
> Hi Alexander,
>
> On Tue, Nov 13, 2018 at 12:36 AM Alexander Kapshuk
> wrote:
> >
> > On Tue, Nov 13, 2018 at 2:09 AM Brian Norris
> > wrote:
> > >
> > > On Mon, Nov 12, 2018 at 10:42:26AM +0200, Alexander Kapshuk wrote:
> > > > An even
Hello, Roman.
On Tue, Nov 13, 2018 at 06:47:55PM +, Roman Gushchin wrote:
> > > + /* Should the cgroup and its descendants be frozen. */
> > > + bool freeze;
> >
> > Why not have this in freezer too?
>
> I thought that this variable is just the state of the cgroup.freeze knob,
> where the
On Tue, Nov 13, 2018 at 8:32 PM Brian Norris wrote:
>
> Hi Alexander,
>
> On Tue, Nov 13, 2018 at 12:36 AM Alexander Kapshuk
> wrote:
> >
> > On Tue, Nov 13, 2018 at 2:09 AM Brian Norris
> > wrote:
> > >
> > > On Mon, Nov 12, 2018 at 10:42:26AM +0200, Alexander Kapshuk wrote:
> > > > An even
Hello, Roman.
On Tue, Nov 13, 2018 at 06:47:55PM +, Roman Gushchin wrote:
> > > + /* Should the cgroup and its descendants be frozen. */
> > > + bool freeze;
> >
> > Why not have this in freezer too?
>
> I thought that this variable is just the state of the cgroup.freeze knob,
> where the
On Tue, Nov 13, 2018 at 07:09:24PM +, Ernst, Justin wrote:
> Looks good on a 32 socket system. All 64 memory controllers show up
> and I'm able to see the same sysfs diff. Thanks
Thanks for testing, much appreciated!
I'm queuing the stuff for 4.21.
--
Regards/Gruss,
Boris.
Good
On Tue, Nov 13, 2018 at 07:09:24PM +, Ernst, Justin wrote:
> Looks good on a 32 socket system. All 64 memory controllers show up
> and I'm able to see the same sysfs diff. Thanks
Thanks for testing, much appreciated!
I'm queuing the stuff for 4.21.
--
Regards/Gruss,
Boris.
Good
On 11/13/2018 11:58 AM, Johan Hovold wrote:
> On Tue, Nov 13, 2018 at 11:39:12AM -0600, Dave Gerlach wrote:
>> Currently the ti-cpufreq driver blindly registers a 'ti-cpufreq' to force
>> the driver to probe on any platforms where the driver is built in.
>> However, this should only happen on
On 11/13/2018 11:58 AM, Johan Hovold wrote:
> On Tue, Nov 13, 2018 at 11:39:12AM -0600, Dave Gerlach wrote:
>> Currently the ti-cpufreq driver blindly registers a 'ti-cpufreq' to force
>> the driver to probe on any platforms where the driver is built in.
>> However, this should only happen on
On Tue, Nov 13, 2018 at 10:39:56AM +0530, Naresh Kamboju wrote:
> On Mon, 12 Nov 2018 at 19:03, Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Nov 12, 2018 at 08:38:44AM -0200, Rafael David Tinoco wrote:
> > > On 11/11/18 8:24 PM, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable
On Tue, Nov 13, 2018 at 10:39:56AM +0530, Naresh Kamboju wrote:
> On Mon, 12 Nov 2018 at 19:03, Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Nov 12, 2018 at 08:38:44AM -0200, Rafael David Tinoco wrote:
> > > On 11/11/18 8:24 PM, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable
On Tue, Nov 13, 2018 at 08:40:02AM +, Jon Hunter wrote:
>
> On 11/11/2018 22:21, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.81 release.
> > There are 222 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Tue, Nov 13, 2018 at 08:40:02AM +, Jon Hunter wrote:
>
> On 11/11/2018 22:21, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.81 release.
> > There are 222 patches in this series, all will be posted as a response
> > to this one. If anyone has any
Looks good on a 32 socket system. All 64 memory controllers show up and I'm
able to see the same sysfs diff.
Thanks
-Justin
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Tuesday, November 6, 2018 8:46 AM
> To: Ernst, Justin ; Luck, Tony
> Cc: Greg KH ;
Looks good on a 32 socket system. All 64 memory controllers show up and I'm
able to see the same sysfs diff.
Thanks
-Justin
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Tuesday, November 6, 2018 8:46 AM
> To: Ernst, Justin ; Luck, Tony
> Cc: Greg KH ;
git-diff-index does not refresh the index for you, so using it for a
"-dirty" check can give misleading results. Commit 6147b1cf19651
("scripts/setlocalversion: git: Make -dirty check more robust") tried to
fix this by switching to git-status, but it overlooked the fact that
git-status also writes
git-diff-index does not refresh the index for you, so using it for a
"-dirty" check can give misleading results. Commit 6147b1cf19651
("scripts/setlocalversion: git: Make -dirty check more robust") tried to
fix this by switching to git-status, but it overlooked the fact that
git-status also writes
401 - 500 of 1256 matches
Mail list logo
