Fixed lines over 80 characters by adding braces where control flow
statements are more than one line, aligned parenthesis of function
arguments.
Signed-off-by: Arnold Chand
---
.../vc04_services/bcm2835-audio/bcm2835-ctl.c | 27 +++
1 file changed, 16 insertions(+), 11
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the
> system call table generation support implementation
> across all the
On Mon, 2018-11-12 at 17:08 -0800, gre...@linuxfoundation.org wrote:
> On Mon, Nov 12, 2018 at 07:29:09PM -0500, Arnold Chand wrote:
> > Corrected warnings and checks issued by scripts/checkpatch.pl which
> > includes:
> > alignment of
> > parenthesis, lines over 80 characters and mutex
On Mon, 2018-11-12 at 17:08 -0800, gre...@linuxfoundation.org wrote:
> On Mon, Nov 12, 2018 at 07:29:09PM -0500, Arnold Chand wrote:
> > Corrected warnings and checks issued by scripts/checkpatch.pl which
> > includes:
> > alignment of
> > parenthesis, lines over 80 characters and mutex
On Tue, Nov 13, 2018 at 02:34:39PM +0100, Roberto Sassu wrote:
> On 11/8/2018 2:46 PM, Jarkko Sakkinen wrote:
> > Orrayn Tue, Nov 06, 2018 at 04:01:54PM +0100, Roberto Sassu wrote:
> > > This patch removes the hard-coded limit of the active_banks array size.
> > > It stores in the tpm_chip
On Tue, Nov 13, 2018 at 02:34:39PM +0100, Roberto Sassu wrote:
> On 11/8/2018 2:46 PM, Jarkko Sakkinen wrote:
> > Orrayn Tue, Nov 06, 2018 at 04:01:54PM +0100, Roberto Sassu wrote:
> > > This patch removes the hard-coded limit of the active_banks array size.
> > > It stores in the tpm_chip
The following linker failure can be seen for a certain heavily reduced
defconfig:
drivers/soc/sunxi/sunxi_sram.o: In function `sunxi_sram_probe':
drivers/soc/sunxi/sunxi_sram.c:353: undefined reference to
`__devm_regmap_init_mmio_clk'
drivers/soc/sunxi/sunxi_sram.c:353:(.text+0x3c4): relocation
The following linker failure can be seen for a certain heavily reduced
defconfig:
drivers/soc/sunxi/sunxi_sram.o: In function `sunxi_sram_probe':
drivers/soc/sunxi/sunxi_sram.c:353: undefined reference to
`__devm_regmap_init_mmio_clk'
drivers/soc/sunxi/sunxi_sram.c:353:(.text+0x3c4): relocation
Lubomir Rintel writes:
> Use a proper PHY driver, instead of hooks to a board support package.
Hi Lubomir,
This specific patch caught my attention, because of its title : I don't see what
phy-pxa-usb stands for, is it a typo ? I don't think anybody implemented so far
a proper phy support for
Lubomir Rintel writes:
> Use a proper PHY driver, instead of hooks to a board support package.
Hi Lubomir,
This specific patch caught my attention, because of its title : I don't see what
phy-pxa-usb stands for, is it a typo ? I don't think anybody implemented so far
a proper phy support for
On Tue, Nov 13, 2018 at 07:54:46PM +0300, Alexey Dobriyan wrote:
> https://bugs.linaro.org/show_bug.cgi?id=3782
>
> Turns out arm doesn't allow to map address 0, so try minimum virtual
> address instead.
>
> Reported-by: Rafael David Tinoco
> Tested-by: Rafael David Tinoco
> Signed-off-by:
On Tue, Nov 13, 2018 at 07:54:46PM +0300, Alexey Dobriyan wrote:
> https://bugs.linaro.org/show_bug.cgi?id=3782
>
> Turns out arm doesn't allow to map address 0, so try minimum virtual
> address instead.
>
> Reported-by: Rafael David Tinoco
> Tested-by: Rafael David Tinoco
> Signed-off-by:
On Tue, Nov 13, 2018 at 02:08:39PM +0100, Roberto Sassu wrote:
> On 11/8/2018 3:08 PM, Jarkko Sakkinen wrote:
> > On Tue, Nov 06, 2018 at 04:01:59PM +0100, Roberto Sassu wrote:
> > > This patch protects against data corruption that could happen in the bus,
> > > by checking that that the digest
On Tue, Nov 13, 2018 at 02:08:39PM +0100, Roberto Sassu wrote:
> On 11/8/2018 3:08 PM, Jarkko Sakkinen wrote:
> > On Tue, Nov 06, 2018 at 04:01:59PM +0100, Roberto Sassu wrote:
> > > This patch protects against data corruption that could happen in the bus,
> > > by checking that that the digest
Running the trinity fuzzer with a non-root user on an aarch64 server with the
latest mainline (rc2) generated this. Is it just a false alarm to ignore?
[ 807.847370] precision 65525 too large
[ 807.847449] WARNING: CPU: 26 PID: 64391 at lib/vsprintf.c:2193
set_precision+0x84/0x90
[ 807.860161]
Running the trinity fuzzer with a non-root user on an aarch64 server with the
latest mainline (rc2) generated this. Is it just a false alarm to ignore?
[ 807.847370] precision 65525 too large
[ 807.847449] WARNING: CPU: 26 PID: 64391 at lib/vsprintf.c:2193
set_precision+0x84/0x90
[ 807.860161]
On Tue, Nov 13, 2018 at 01:39:26PM +0100, Roberto Sassu wrote:
> > AFAIK the kernel development process does not disallow to use direct
> > git protocol for maintainer branches. Please, correct me if I'm
> > mistaken.
>
> I solved the issue by creating a mirror of your repository with gitlab.
On Tue, Nov 13, 2018 at 01:39:26PM +0100, Roberto Sassu wrote:
> > AFAIK the kernel development process does not disallow to use direct
> > git protocol for maintainer branches. Please, correct me if I'm
> > mistaken.
>
> I solved the issue by creating a mirror of your repository with gitlab.
On Tue, Nov 13, 2018 at 12:30:55PM +, Winkler, Tomas wrote:
> >
> > [was Detach TPM space code out of the tpm_transmit() flow but the scope
> > expanded a bit.]
>
> I believe you making this series artificially large we can merge the
> first 4 patches and leave the rest for further
On Tue, Nov 13, 2018 at 12:30:55PM +, Winkler, Tomas wrote:
> >
> > [was Detach TPM space code out of the tpm_transmit() flow but the scope
> > expanded a bit.]
>
> I believe you making this series artificially large we can merge the
> first 4 patches and leave the rest for further
On 11/12, Andrew Morton wrote:
> On Mon, 12 Nov 2018 17:09:56 +0100 Oleg Nesterov wrote:
>
> > /* sizeof(linux_binprm->buf) */
> > -#define BINPRM_BUF_SIZE 128
> > +#define BINPRM_BUF_SIZE 256
> >
> > #endif /* _UAPI_LINUX_BINFMTS_H */
>
> It does seem a rather silly restriction, and it's
On 11/12, Andrew Morton wrote:
> On Mon, 12 Nov 2018 17:09:56 +0100 Oleg Nesterov wrote:
>
> > /* sizeof(linux_binprm->buf) */
> > -#define BINPRM_BUF_SIZE 128
> > +#define BINPRM_BUF_SIZE 256
> >
> > #endif /* _UAPI_LINUX_BINFMTS_H */
>
> It does seem a rather silly restriction, and it's
https://bugs.linaro.org/show_bug.cgi?id=3782
Turns out arm doesn't allow to map address 0, so try minimum virtual
address instead.
Reported-by: Rafael David Tinoco
Tested-by: Rafael David Tinoco
Signed-off-by: Alexey Dobriyan
---
tools/testing/selftests/proc/proc-self-map-files-002.c |9
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Paul E. McKenney
> Sent: Sunday, November 11, 2018 11:44 AM
> To: linux-kernel@vger.kernel.org
> Cc: t...@linutronix.de; David S. Miller ;
> pet...@infradead.org; fweis...@gmail.com;
https://bugs.linaro.org/show_bug.cgi?id=3782
Turns out arm doesn't allow to map address 0, so try minimum virtual
address instead.
Reported-by: Rafael David Tinoco
Tested-by: Rafael David Tinoco
Signed-off-by: Alexey Dobriyan
---
tools/testing/selftests/proc/proc-self-map-files-002.c |9
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Paul E. McKenney
> Sent: Sunday, November 11, 2018 11:44 AM
> To: linux-kernel@vger.kernel.org
> Cc: t...@linutronix.de; David S. Miller ;
> pet...@infradead.org; fweis...@gmail.com;
On Sun, 11 Nov 2018 19:21:29 +0100,
Mike Brady wrote:
>
> /* hardware definition */
> static const struct snd_pcm_hardware snd_bcm2835_playback_hw = {
> .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER |
>SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID |
On Sun, 11 Nov 2018 19:21:29 +0100,
Mike Brady wrote:
>
> /* hardware definition */
> static const struct snd_pcm_hardware snd_bcm2835_playback_hw = {
> .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER |
>SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID |
Hi Stable team,
Le 08/11/2018 10:31, Jerome Brunet a écrit :
> Similar to gxbb and gxl platforms, axg SCPI Cortex-M co-processor
> uses the fdiv2 and fdiv3 to, among other things, provide the cpu
> clock.
>
> Until clock hand-off mechanism makes its way to CCF and the generic
> SCPI claims
Hi Stable team,
Le 08/11/2018 10:31, Jerome Brunet a écrit :
> Similar to gxbb and gxl platforms, axg SCPI Cortex-M co-processor
> uses the fdiv2 and fdiv3 to, among other things, provide the cpu
> clock.
>
> Until clock hand-off mechanism makes its way to CCF and the generic
> SCPI claims
Running the trinity fuzzer with a non-root user on an aarch64 server with the
latest mainline (rc2) triggered this,
[ 2058.662628] page:7fe022fe7d80 count:0 mapcount:0 mapping:808ea6153160
index:0x5a
[ 2058.670842] flags: 0x9f04(uptodate)
[ 2058.675448] raw: 9f04
Running the trinity fuzzer with a non-root user on an aarch64 server with the
latest mainline (rc2) triggered this,
[ 2058.662628] page:7fe022fe7d80 count:0 mapcount:0 mapping:808ea6153160
index:0x5a
[ 2058.670842] flags: 0x9f04(uptodate)
[ 2058.675448] raw: 9f04
Le 13/11/2018 17:38, Neil Armstrong a écrit :
> Hi Stable team,
>
> Le 06/11/2018 00:08, Jerome Brunet a écrit :
>> From: Christian Hewitt
>>
>> On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems
>> with reboot; e.g. a ~60 second delay between issuing reboot and the
>> board
Le 13/11/2018 17:38, Neil Armstrong a écrit :
> Hi Stable team,
>
> Le 06/11/2018 00:08, Jerome Brunet a écrit :
>> From: Christian Hewitt
>>
>> On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems
>> with reboot; e.g. a ~60 second delay between issuing reboot and the
>> board
On 11/13, Michal Hocko wrote:
>
> A bit cryptic to my taste
Ys, because I didn't want to touch the code below. We need to cleanup
the whole "parse bprm->buf" code, not only this part.
> but it looks correct. I have tried to come up
> with something more tasty but I am afraid it would be just
On 11/13, Michal Hocko wrote:
>
> A bit cryptic to my taste
Ys, because I didn't want to touch the code below. We need to cleanup
the whole "parse bprm->buf" code, not only this part.
> but it looks correct. I have tried to come up
> with something more tasty but I am afraid it would be just
Hi Stable team,
Le 06/11/2018 00:08, Jerome Brunet a écrit :
> From: Christian Hewitt
>
> On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems
> with reboot; e.g. a ~60 second delay between issuing reboot and the
> board power cycling (and in some OS configurations reboot will
Hi Stable team,
Le 06/11/2018 00:08, Jerome Brunet a écrit :
> From: Christian Hewitt
>
> On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems
> with reboot; e.g. a ~60 second delay between issuing reboot and the
> board power cycling (and in some OS configurations reboot will
Running the trinity fuzzer with a non-root user on an aarch64 server with the
latest mainline (rc2) generated this,
[ 378.743211] WARNING: CPU: 31 PID: 15473 at lib/iov_iter.c:1109
iov_iter_pipe+0xe0/0xe8
[ 378.751590] Modules linked in: bridge 8021q garp mrp stp llc dlci tcp_diag
inet_diag
Running the trinity fuzzer with a non-root user on an aarch64 server with the
latest mainline (rc2) generated this,
[ 378.743211] WARNING: CPU: 31 PID: 15473 at lib/iov_iter.c:1109
iov_iter_pipe+0xe0/0xe8
[ 378.751590] Modules linked in: bridge 8021q garp mrp stp llc dlci tcp_diag
inet_diag
On Tue, 13 Nov 2018 15:42:49 +0100
Auger Eric wrote:
> Hi Alex,
>
> On 11/9/18 11:09 PM, Alex Williamson wrote:
> > In commit 61d792562b53 ("vfio-pci: Use mutex around open, release, and
> > remove") a mutex was added to freeze the refcnt for a device so that
> > we can handle errors and
On Tue, 13 Nov 2018 15:42:49 +0100
Auger Eric wrote:
> Hi Alex,
>
> On 11/9/18 11:09 PM, Alex Williamson wrote:
> > In commit 61d792562b53 ("vfio-pci: Use mutex around open, release, and
> > remove") a mutex was added to freeze the refcnt for a device so that
> > we can handle errors and
On Mon, 1 Oct 2018, Yasha Cherikovsky wrote:
> The Lexra LX5280 CPU [1][2] implements the MIPS-I ISA,
> without unaligned load/store instructions (lwl, lwr, swl, swr).
I think you actually need to emulate these missing instructions for user
programs, so that the 32-bit MIPS psABI is supported
On Mon, 1 Oct 2018, Yasha Cherikovsky wrote:
> The Lexra LX5280 CPU [1][2] implements the MIPS-I ISA,
> without unaligned load/store instructions (lwl, lwr, swl, swr).
I think you actually need to emulate these missing instructions for user
programs, so that the 32-bit MIPS psABI is supported
Hello, Daniel.
On Mon, Nov 05, 2018 at 11:55:50AM -0500, Daniel Jordan wrote:
> static bool start_flush_work(struct work_struct *work, struct wq_barrier
> *barr,
> - bool from_cancel)
> + struct nice_work *nice_work, int flags)
> {
>
Hello, Daniel.
On Mon, Nov 05, 2018 at 11:55:50AM -0500, Daniel Jordan wrote:
> static bool start_flush_work(struct work_struct *work, struct wq_barrier
> *barr,
> - bool from_cancel)
> + struct nice_work *nice_work, int flags)
> {
>
Since a lot of clocks on imx8m are formed by a mux, gate, predivider and
divider, the idea here is to combine all of those into one composite clock,
but we need to deal with both predivider and divider at the same time and
therefore we add the imx8m_clk_composite_divider_ops and register
the
Since a lot of clocks on imx8m are formed by a mux, gate, predivider and
divider, the idea here is to combine all of those into one composite clock,
but we need to deal with both predivider and divider at the same time and
therefore we add the imx8m_clk_composite_divider_ops and register
the
Add driver for the Clock Control Module found on i.MX8MQ.
Signed-off-by: Anson Huang
Signed-off-by: Bai Ping
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
drivers/clk/imx/Makefile | 1 +
drivers/clk/imx/clk-imx8mq.c | 589
Add driver for the Clock Control Module found on i.MX8MQ.
Signed-off-by: Anson Huang
Signed-off-by: Bai Ping
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
drivers/clk/imx/Makefile | 1 +
drivers/clk/imx/clk-imx8mq.c | 589
From: Lucas Stach
This adds the binding for the i.MX8MQ Clock Controller Module.
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Rob Herring
---
.../devicetree/bindings/clock/imx8mq-clock.txt | 20 ++
include/dt-bindings/clock/imx8mq-clock.h | 395
Here is a link to the 12th version:
https://lkml.org/lkml/2018/11/7/642
Changes since v12:
* replaced the division in clk_pll_recalc_rate in clk-frac
with do_div as suggested by Stephen
Abel Vesa (2):
clk: imx: Add imx composite clock
clk: imx: Add clock driver for i.MX8MQ CCM
Lucas
From: Lucas Stach
The SCCG is a new PLL type introduced on i.MX8.
The description of this SCCG clock can be found here:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
From: Lucas Stach
This adds the binding for the i.MX8MQ Clock Controller Module.
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Rob Herring
---
.../devicetree/bindings/clock/imx8mq-clock.txt | 20 ++
include/dt-bindings/clock/imx8mq-clock.h | 395
Here is a link to the 12th version:
https://lkml.org/lkml/2018/11/7/642
Changes since v12:
* replaced the division in clk_pll_recalc_rate in clk-frac
with do_div as suggested by Stephen
Abel Vesa (2):
clk: imx: Add imx composite clock
clk: imx: Add clock driver for i.MX8MQ CCM
Lucas
From: Lucas Stach
The SCCG is a new PLL type introduced on i.MX8.
The description of this SCCG clock can be found here:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
From: Lucas Stach
This is a new fractional clock type introduced on i.MX8.
The description of this fractional clock can be found here:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
From: Lucas Stach
This is a new fractional clock type introduced on i.MX8.
The description of this fractional clock can be found here:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
On Mon, Nov 5, 2018 at 10:43 PM Weiyi Lu wrote:
>
> From: Owen Chen
>
> 1. pcwibits: The integer bits of pcw for plls is extend to 8 bits,
>add a variable to indicate this change and
>backward-compatible.
> 2. fmin: The pll freqency lower-bound is vary from 1GMhz to
>1.5Ghz, add a
On Mon, Nov 5, 2018 at 10:43 PM Weiyi Lu wrote:
>
> From: Owen Chen
>
> 1. pcwibits: The integer bits of pcw for plls is extend to 8 bits,
>add a variable to indicate this change and
>backward-compatible.
> 2. fmin: The pll freqency lower-bound is vary from 1GMhz to
>1.5Ghz, add a
On 11/13, Michal Hocko wrote:
>
> On Mon 12-11-18 12:54:45, Chanho Min wrote:
> > Suspend fails due to the exec family of functions blocking the freezer.
> > The casue is that de_thread() sleeps in TASK_UNINTERRUPTIBLE waiting for
> > all sub-threads to die, and we have the deadlock if one of them
On 11/13, Michal Hocko wrote:
>
> On Mon 12-11-18 12:54:45, Chanho Min wrote:
> > Suspend fails due to the exec family of functions blocking the freezer.
> > The casue is that de_thread() sleeps in TASK_UNINTERRUPTIBLE waiting for
> > all sub-threads to die, and we have the deadlock if one of them
On Tue, Nov 13, 2018 at 12:12 AM chouryzhou(周威) wrote:
>
> > I have not received an answer to my questions in the last version of this
> > patch
> > set. Also it would be good if I could be Cc'ed by default. I can't hunt
> > down all
> > patches.
> > I do not know of any kernel entity,
On Tue, Nov 13, 2018 at 12:12 AM chouryzhou(周威) wrote:
>
> > I have not received an answer to my questions in the last version of this
> > patch
> > set. Also it would be good if I could be Cc'ed by default. I can't hunt
> > down all
> > patches.
> > I do not know of any kernel entity,
On Mon, 12 Nov 2018 18:17:38 -0600
Rob Herring wrote:
> On Mon, Nov 12, 2018 at 4:27 PM Sebastian Reichel
> wrote:
> >
> > Hi,
> >
> > On Mon, Nov 12, 2018 at 10:19:02PM +0100, H. Nikolaus Schaller wrote:
> > > > Am 12.11.2018 um 21:59 schrieb Andreas Kemnade :
> > > > On Sun, 11 Nov 2018
On Mon, 12 Nov 2018 18:17:38 -0600
Rob Herring wrote:
> On Mon, Nov 12, 2018 at 4:27 PM Sebastian Reichel
> wrote:
> >
> > Hi,
> >
> > On Mon, Nov 12, 2018 at 10:19:02PM +0100, H. Nikolaus Schaller wrote:
> > > > Am 12.11.2018 um 21:59 schrieb Andreas Kemnade :
> > > > On Sun, 11 Nov 2018
On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu wrote:
>
> From: Owen Chen
>
> On both MT8183 & MT6765, there add "set/clr" register for
> each clkmux setting, and one update register to trigger value change.
> It is designed to prevent read-modify-write racing issue.
> The sw design need to add a new
On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu wrote:
>
> From: Owen Chen
>
> On both MT8183 & MT6765, there add "set/clr" register for
> each clkmux setting, and one update register to trigger value change.
> It is designed to prevent read-modify-write racing issue.
> The sw design need to add a new
Hi Tejun,
On 11/13, Tejun Heo wrote:
>
> > OK, please forget for now, but perhaps it would be more clean to add
> > JOBCTL_TRAP_FREEZE to the JOBCTL_PENDING_MASK check in recalc_sigpending()
> > and change get_signal to check JOBCTL_TRAP_MASK | JOBCTL_TRAP_FREEZE; and
> > I am not even sure
Hi Tejun,
On 11/13, Tejun Heo wrote:
>
> > OK, please forget for now, but perhaps it would be more clean to add
> > JOBCTL_TRAP_FREEZE to the JOBCTL_PENDING_MASK check in recalc_sigpending()
> > and change get_signal to check JOBCTL_TRAP_MASK | JOBCTL_TRAP_FREEZE; and
> > I am not even sure
> -Original Message-
> From: mika.westerb...@linux.intel.com
> [mailto:mika.westerb...@linux.intel.com]
> Sent: 13 November 2018 15:08
> To: Shameerali Kolothum Thodi
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Wangzhou (B)
> ; Linuxarm ; Lukas
> Wunner
> Subject:
> -Original Message-
> From: mika.westerb...@linux.intel.com
> [mailto:mika.westerb...@linux.intel.com]
> Sent: 13 November 2018 15:08
> To: Shameerali Kolothum Thodi
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Wangzhou (B)
> ; Linuxarm ; Lukas
> Wunner
> Subject:
On Tue, Nov 13, 2018 at 11:58:58AM +, Winkler, Tomas wrote:
> Yes, w/o this constrain it would be okay to request locality only once,
> we can ask tboot ask again but at the time the requirement was that locality
> can be taken of at any point,
> I believe that the locality won't be granted
On Tue, Nov 13, 2018 at 11:58:58AM +, Winkler, Tomas wrote:
> Yes, w/o this constrain it would be okay to request locality only once,
> we can ask tboot ask again but at the time the requirement was that locality
> can be taken of at any point,
> I believe that the locality won't be granted
On Tue, Nov 13, 2018 at 10:18 AM 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, Nov 13, 2018 at 10:18 AM 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 Sun, Nov 11, 2018 at 11:44:05AM -0800, Paul E. McKenney wrote:
> Now that synchronize_rcu() waits for preempt-disable regions of code
> as well as RCU read-side critical sections, synchronize_sched() can be
> replaced by synchronize_rcu(). This commit therefore makes this change,
> even though
On Sun, Nov 11, 2018 at 11:44:05AM -0800, Paul E. McKenney wrote:
> Now that synchronize_rcu() waits for preempt-disable regions of code
> as well as RCU read-side critical sections, synchronize_sched() can be
> replaced by synchronize_rcu(). This commit therefore makes this change,
> even though
On Sun, Nov 11, 2018 at 11:44:03AM -0800, Paul E. McKenney wrote:
> Now that synchronize_rcu() waits for preempt-disable regions of code
> as well as RCU read-side critical sections, synchronize_sched() can be
> replaced by synchronize_rcu(). This commit therefore makes this change,
> even though
On Sun, Nov 11, 2018 at 11:44:03AM -0800, Paul E. McKenney wrote:
> Now that synchronize_rcu() waits for preempt-disable regions of code
> as well as RCU read-side critical sections, synchronize_sched() can be
> replaced by synchronize_rcu(). This commit therefore makes this change,
> even though
On Sun, Nov 11, 2018 at 11:43:56AM -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 critical sections), call_rcu() can be used in place
> of
On 11/12, Roman Gushchin wrote:
>
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -83,7 +83,8 @@ struct task_group;
> #define TASK_WAKING 0x0200
> #define TASK_NOLOAD 0x0400
> #define TASK_NEW 0x0800
> -#define
On Sun, Nov 11, 2018 at 11:43:56AM -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 critical sections), call_rcu() can be used in place
> of
On 11/12, Roman Gushchin wrote:
>
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -83,7 +83,8 @@ struct task_group;
> #define TASK_WAKING 0x0200
> #define TASK_NOLOAD 0x0400
> #define TASK_NEW 0x0800
> -#define
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 critical sections), call_rcu() can be used in place
> of
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 critical sections), call_rcu() can be used in place
> of
Hello, Oleg.
On Tue, Nov 13, 2018 at 04:37:01PM +0100, Oleg Nesterov wrote:
> On 11/12, Roman Gushchin wrote:
> >
> > This patch implements freezer for cgroup v2. However the functionality
> > is similar, the interface is different to cgroup v1: it follows
> > cgroup v2 interface principles.
>
>
Hello, Oleg.
On Tue, Nov 13, 2018 at 04:37:01PM +0100, Oleg Nesterov wrote:
> On 11/12, Roman Gushchin wrote:
> >
> > This patch implements freezer for cgroup v2. However the functionality
> > is similar, the interface is different to cgroup v1: it follows
> > cgroup v2 interface principles.
>
>
On 11/7/18 5:31 PM, Pierre Morel wrote:
On 06/11/2018 21:21, Tony Krowiak wrote:
On 10/31/18 2:12 PM, Pierre Morel wrote:
This is the implementation of the VFIO ioctl calls to handle
the AQIC interception and use GISA to handle interrupts.
Signed-off-by: Pierre Morel
---
On 11/7/18 5:31 PM, Pierre Morel wrote:
On 06/11/2018 21:21, Tony Krowiak wrote:
On 10/31/18 2:12 PM, Pierre Morel wrote:
This is the implementation of the VFIO ioctl calls to handle
the AQIC interception and use GISA to handle interrupts.
Signed-off-by: Pierre Morel
---
MAX8997 driver disables automatic path selection from MicroUSB connector
and manually sets path to either UART or USB lines. However the code for
setting USB path worked only for USB host mode (when ID pin is set
to ground). When standard USB cable (USB device mode) is connected, path
registers
MAX8997 driver disables automatic path selection from MicroUSB connector
and manually sets path to either UART or USB lines. However the code for
setting USB path worked only for USB host mode (when ID pin is set
to ground). When standard USB cable (USB device mode) is connected, path
registers
On 11/12, Roman Gushchin wrote:
>
> This patch implements freezer for cgroup v2. However the functionality
> is similar, the interface is different to cgroup v1: it follows
> cgroup v2 interface principles.
Oh, it seems that I actually need to apply this patch to (try to) understand
the details
On 11/12, Roman Gushchin wrote:
>
> This patch implements freezer for cgroup v2. However the functionality
> is similar, the interface is different to cgroup v1: it follows
> cgroup v2 interface principles.
Oh, it seems that I actually need to apply this patch to (try to) understand
the details
On 12-Nov 01:09, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 06:33:02PM +, Patrick Bellasi wrote:
> > The number of clamp groups configured at compile time defines the range
> > of utilization clamp values tracked by each CPU clamp group.
> > For example, with the default configuration:
>
On 12-Nov 01:09, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 06:33:02PM +, Patrick Bellasi wrote:
> > The number of clamp groups configured at compile time defines the range
> > of utilization clamp values tracked by each CPU clamp group.
> > For example, with the default configuration:
>
[Please do not top-post]
On Tue 13-11-18 23:12:24, Yongkai Wu wrote:
> Dear Maintainer,
> Actually i met a VM_BUG_ON_PAGE issue in centos7.4 some days ago.When the
> issue first happen,
> i just can know that it happen in free_huge_page() when doing soft offline
> huge page.
> But because
[Please do not top-post]
On Tue 13-11-18 23:12:24, Yongkai Wu wrote:
> Dear Maintainer,
> Actually i met a VM_BUG_ON_PAGE issue in centos7.4 some days ago.When the
> issue first happen,
> i just can know that it happen in free_huge_page() when doing soft offline
> huge page.
> But because
Turns out Hyper-V on KVM (as of 2016) will only use synthetic timers
if direct mode is available. With direct mode we notify the guest by
asserting APIC irq instead of sending a SynIC message.
The implementation uses existing vec_bitmap for letting lapic code
know that we're interested in the
Turns out Hyper-V on KVM (as of 2016) will only use synthetic timers
if direct mode is available. With direct mode we notify the guest by
asserting APIC irq instead of sending a SynIC message.
The implementation uses existing vec_bitmap for letting lapic code
know that we're interested in the
701 - 800 of 1256 matches
Mail list logo
