On Wed 03-10-18 15:51:05, David Rientjes wrote:
> On Wed, 3 Oct 2018, Michal Hocko wrote:
>
> > > > So how about this? (not tested yet but it should be pretty
> > > > straightforward)
> > >
> > > Umm, prctl(PR_GET_THP_DISABLE)?
> >
> > /me confused. I thought you want to query for the flag on a
On Wed 03-10-18 15:51:05, David Rientjes wrote:
> On Wed, 3 Oct 2018, Michal Hocko wrote:
>
> > > > So how about this? (not tested yet but it should be pretty
> > > > straightforward)
> > >
> > > Umm, prctl(PR_GET_THP_DISABLE)?
> >
> > /me confused. I thought you want to query for the flag on a
Clang warns:
drivers/staging/emxx_udc/emxx_udc.c:1373:37: warning: variable
'device_desc' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static struct usb_device_descriptor device_desc = {
^
1 warning generated.
This definition hasn't
Clang warns:
drivers/staging/emxx_udc/emxx_udc.c:1373:37: warning: variable
'device_desc' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static struct usb_device_descriptor device_desc = {
^
1 warning generated.
This definition hasn't
We have the scenario that first autoidle is disabled for all clocks,
then it is disabled for selected ones and then enabled for all. So
we should have some counting here, also according to the
comment in _setup_iclk_autoidle()
Signed-off-by: Andreas Kemnade
---
drivers/clk/ti/autoidle.c | 20
Deny autoidle for hwmods with the OCPIF_SWSUP_IDLE flag,
that makes hwmods working properly which cannot handle
autoidle properly in lower power states.
Affected is e. g. the omap_hdq.
It also disables CM_AUTOIDLE_DSS. Need to check if
that is wanted or not.
Note: Autoidle is not enabled
We have the scenario that first autoidle is disabled for all clocks,
then it is disabled for selected ones and then enabled for all. So
we should have some counting here, also according to the
comment in _setup_iclk_autoidle()
Signed-off-by: Andreas Kemnade
---
drivers/clk/ti/autoidle.c | 20
Deny autoidle for hwmods with the OCPIF_SWSUP_IDLE flag,
that makes hwmods working properly which cannot handle
autoidle properly in lower power states.
Affected is e. g. the omap_hdq.
It also disables CM_AUTOIDLE_DSS. Need to check if
that is wanted or not.
Note: Autoidle is not enabled
On the gta04 with a dm3730 omap_hdq does not work properly when the
device enters lower power states. Idling uart1 and 2 is enough
to show up that problem, if there are no other things enabled.
Further research reveals that hdq iclk must not be turned off during
transfers, also according to the
On the gta04 with a dm3730 omap_hdq does not work properly when the
device enters lower power states. Idling uart1 and 2 is enough
to show up that problem, if there are no other things enabled.
Further research reveals that hdq iclk must not be turned off during
transfers, also according to the
On Thu, 04 Oct 2018 05:39:42 +0200,
Kai-Heng Feng wrote:
>
> The issue is the same as commit dd9aa335c880 ("ALSA: hda/realtek - Can't
> adjust speaker's volume on a Dell AIO"), the output requires to connect
> to a node with Amp-out capability.
>
> Applying the same fixup ALC298_FIXUP_SPK_VOLUME
On Thu, 04 Oct 2018 05:39:42 +0200,
Kai-Heng Feng wrote:
>
> The issue is the same as commit dd9aa335c880 ("ALSA: hda/realtek - Can't
> adjust speaker's volume on a Dell AIO"), the output requires to connect
> to a node with Amp-out capability.
>
> Applying the same fixup ALC298_FIXUP_SPK_VOLUME
ove' into next")
which reintroduced a whole lot of stuff into drivers/dma/fsl-edma.c that
had been modev out in commit
9d831528a656 ("dmaengine: fsl-edma: extract common fsl-edma code (no changes
in behavior intended)")
I used the slave-dma tree from next-20181003 fo
ove' into next")
which reintroduced a whole lot of stuff into drivers/dma/fsl-edma.c that
had been modev out in commit
9d831528a656 ("dmaengine: fsl-edma: extract common fsl-edma code (no changes
in behavior intended)")
I used the slave-dma tree from next-20181003 fo
Hi Will,
can you please pull this patch?
On Mon, Oct 1, 2018 at 10:09 PM Ganapatrao Kulkarni wrote:
>
> Hi Will,
>
> On Mon, Oct 1, 2018 at 7:58 PM Will Deacon wrote:
> >
> > Hi Ganapat,
> >
> > On Mon, Oct 01, 2018 at 10:07:43AM +, Kulkarni, Ganapatrao wrote:
> > > Perf events
Hi Will,
can you please pull this patch?
On Mon, Oct 1, 2018 at 10:09 PM Ganapatrao Kulkarni wrote:
>
> Hi Will,
>
> On Mon, Oct 1, 2018 at 7:58 PM Will Deacon wrote:
> >
> > Hi Ganapat,
> >
> > On Mon, Oct 01, 2018 at 10:07:43AM +, Kulkarni, Ganapatrao wrote:
> > > Perf events
On Thu, 04 Oct 2018 05:08:45 +0200,
Jia-Ju Bai wrote:
>
> Thanks for the reply :)
>
>
> On 2018/10/3 23:54, Takashi Iwai wrote:
> > On Wed, 03 Oct 2018 14:50:25 +0200,
> > Jia-Ju Bai wrote:
> >> CPU0:
> >> snd_trident_hw_free
> >> snd_trident_free_voice
> >> line 3870:
On Thu, 04 Oct 2018 05:08:45 +0200,
Jia-Ju Bai wrote:
>
> Thanks for the reply :)
>
>
> On 2018/10/3 23:54, Takashi Iwai wrote:
> > On Wed, 03 Oct 2018 14:50:25 +0200,
> > Jia-Ju Bai wrote:
> >> CPU0:
> >> snd_trident_hw_free
> >> snd_trident_free_voice
> >> line 3870:
^
drivers/tty/serial/samsung.c:1968:8: note: in expansion of macro 'rx_enabled'
if (rx_enabled(port))
^~
Caused by commit
c550f01c810f ("serial:serial_core: Allow use of CTS for PPS line discipline")
Looks like a suprise from some "interesting"
^
drivers/tty/serial/samsung.c:1968:8: note: in expansion of macro 'rx_enabled'
if (rx_enabled(port))
^~
Caused by commit
c550f01c810f ("serial:serial_core: Allow use of CTS for PPS line discipline")
Looks like a suprise from some "interesting"
It is not safe to dereference an object before a null test. It is
not needed and just remove them. Ftrace can be used instead.
Signed-off-by: zhong jiang
---
drivers/misc/cxl/guest.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c
index
It is not safe to dereference an object before a null test. It is
not needed and just remove them. Ftrace can be used instead.
Signed-off-by: zhong jiang
---
drivers/misc/cxl/guest.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c
index
This RFC proposes to return part of the entry-area back to the fixmap to
improve system-call performance. Currently, since the entry-area is
mapped far (more than 2GB) away from the kernel text, an indirect branch
is needed to jump from the trampoline into the kernel. Due to Spectre
v2, vulnerable
This RFC proposes to return part of the entry-area back to the fixmap to
improve system-call performance. Currently, since the entry-area is
mapped far (more than 2GB) away from the kernel text, an indirect branch
is needed to jump from the trampoline into the kernel. Due to Spectre
v2, vulnerable
On 2018/10/4 12:38, Greg KH wrote:
> On Thu, Oct 04, 2018 at 10:56:48AM +0800, zhong jiang wrote:
>> It is safe to dereference an object below a NULL test. For the sake
>> of debugging. Just delete the call of possible null pointer dereference.
>>
>> Signed-off-by: zhong jiang
>> ---
>>
On 2018/10/4 12:38, Greg KH wrote:
> On Thu, Oct 04, 2018 at 10:56:48AM +0800, zhong jiang wrote:
>> It is safe to dereference an object below a NULL test. For the sake
>> of debugging. Just delete the call of possible null pointer dereference.
>>
>> Signed-off-by: zhong jiang
>> ---
>>
On Wed, 2018-10-03 at 21:31 -0300, Leonardo Bras wrote:
> On Fri, Sep 28, 2018 at 4:15 AM James Bottomley
> wrote:
> >
> > On Thu, 2018-09-27 at 23:08 -0300, Leonardo Brás wrote:
> > > Avoids building driver if 'make drivers/parisc/' is called and
> > > CONFIG_PARISC is disabled.
> >
> > Is
On Wed, 2018-10-03 at 21:31 -0300, Leonardo Bras wrote:
> On Fri, Sep 28, 2018 at 4:15 AM James Bottomley
> wrote:
> >
> > On Thu, 2018-09-27 at 23:08 -0300, Leonardo Brás wrote:
> > > Avoids building driver if 'make drivers/parisc/' is called and
> > > CONFIG_PARISC is disabled.
> >
> > Is
On Thu, Oct 04, 2018 at 10:56:48AM +0800, zhong jiang wrote:
> It is safe to dereference an object below a NULL test. For the sake
> of debugging. Just delete the call of possible null pointer dereference.
>
> Signed-off-by: zhong jiang
> ---
> drivers/misc/cxl/guest.c | 2 +-
> 1 file changed,
On Thu, Oct 04, 2018 at 10:56:48AM +0800, zhong jiang wrote:
> It is safe to dereference an object below a NULL test. For the sake
> of debugging. Just delete the call of possible null pointer dereference.
>
> Signed-off-by: zhong jiang
> ---
> drivers/misc/cxl/guest.c | 2 +-
> 1 file changed,
Since commit c8589d1e9e01 ("kbuild: handle multi-objs dependency
appropriately"), $^ really represents all the prerequisite of the
composite object being built.
Hence, $(filter %.o,$^) contains all the objects to link together,
which is much simpler than link_multi_deps calculation.
Please note
Since commit c8589d1e9e01 ("kbuild: handle multi-objs dependency
appropriately"), $^ really represents all the prerequisite of the
composite object being built.
Hence, $(filter %.o,$^) contains all the objects to link together,
which is much simpler than link_multi_deps calculation.
Please note
Hi all,
Today's linux-next merge of the kvm-arm tree got conflicts in:
arch/arm/include/asm/kvm_mmu.h
arch/arm64/include/asm/kvm_arm.h
arch/arm64/include/asm/kvm_mmu.h
between commit:
ab510027dc4d ("arm64: KVM: Enable Common Not Private translations")
from the arm64 tree and commit:
Hi all,
Today's linux-next merge of the kvm-arm tree got conflicts in:
arch/arm/include/asm/kvm_mmu.h
arch/arm64/include/asm/kvm_arm.h
arch/arm64/include/asm/kvm_mmu.h
between commit:
ab510027dc4d ("arm64: KVM: Enable Common Not Private translations")
from the arm64 tree and commit:
We can not call dev_pm_opp_of_cpumask_remove_table() freely anymore
since the latest OPP core updates as that uses reference counting to
free resources. There are cases where no static OPPs are added (using
DT) for a platform and trying to remove the OPP table may end up
decrementing refcount
We can not call dev_pm_opp_of_cpumask_remove_table() freely anymore
since the latest OPP core updates as that uses reference counting to
free resources. There are cases where no static OPPs are added (using
DT) for a platform and trying to remove the OPP table may end up
decrementing refcount
Hello,
Few more bugs have surfaced recently, few of which have been there
forever but came to light only after the recent changes in OPP core.
Dave already sent fix for one of them sometime back and as he isn't
around for a week, I picked up the patch, modified it and posting V2 of
it here.
The error handling wasn't appropriate in
dev_pm_opp_of_cpumask_add_table(). For example it returns 0 on success
and also for the case where cpumask is empty or cpu_device wasn't found
for any of the CPUs.
It should really return error on such cases, so that the callers can be
aware of the
Return error number instead of 0 on failures.
Fixes: a1e8c13600bf ("PM / OPP: "opp-hz" is optional for power domains")
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index
From: Dave Gerlach
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however there are cases
where
Hello,
Few more bugs have surfaced recently, few of which have been there
forever but came to light only after the recent changes in OPP core.
Dave already sent fix for one of them sometime back and as he isn't
around for a week, I picked up the patch, modified it and posting V2 of
it here.
The error handling wasn't appropriate in
dev_pm_opp_of_cpumask_add_table(). For example it returns 0 on success
and also for the case where cpumask is empty or cpu_device wasn't found
for any of the CPUs.
It should really return error on such cases, so that the callers can be
aware of the
Return error number instead of 0 on failures.
Fixes: a1e8c13600bf ("PM / OPP: "opp-hz" is optional for power domains")
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index
From: Dave Gerlach
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however there are cases
where
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
arch/arm64/include/asm/cpufeature.h
between commit:
520ad98871a0 ("arm64/cpufeatures: Factorize emulate_mrs()")
from the arm64 tree and commit:
ce00e3cb4fb4 ("arm64: Add a helper for PARange to physical shift
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
arch/arm64/include/asm/cpufeature.h
between commit:
520ad98871a0 ("arm64/cpufeatures: Factorize emulate_mrs()")
from the arm64 tree and commit:
ce00e3cb4fb4 ("arm64: Add a helper for PARange to physical shift
On Tue, 2018-10-02 at 21:36 +0200, Jann Horn wrote:
> +Andy for opinions on things in write handlers
> +Mimi Zohar as EVM maintainer
>
> On Tue, Oct 2, 2018 at 9:55 AM joeyli wrote:
> > On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote:
> > > On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi
On Tue, 2018-10-02 at 21:36 +0200, Jann Horn wrote:
> +Andy for opinions on things in write handlers
> +Mimi Zohar as EVM maintainer
>
> On Tue, Oct 2, 2018 at 9:55 AM joeyli wrote:
> > On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote:
> > > On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi
Hi Jiada
Thank you for your feedback
> >> in GEN3 SSI may use different BUSIF for data transfer,
> >> this patch adds busif property to each dai stream,
> >> to indicate the BUSIF used by playback/capture stream.
> >>
> >> Also adds rsnd_ssi_select_busif() to automatically select
> >> BUSIF
Hi Jiada
Thank you for your feedback
> >> in GEN3 SSI may use different BUSIF for data transfer,
> >> this patch adds busif property to each dai stream,
> >> to indicate the BUSIF used by playback/capture stream.
> >>
> >> Also adds rsnd_ssi_select_busif() to automatically select
> >> BUSIF
Hi Masahiro,
On Thu, 4 Oct 2018 12:09:54 +0900 Masahiro Yamada
wrote:
>
> OK, confirmed.
>
>
> This is a regression of
>
> commit bb5de5d28f730eeec0aa1ced51a6f11327cd1201
> Author: Masahiro Yamada
> Date: Thu Sep 13 17:20:41 2018 +0900
>
> kbuild: remove unneeded link_multi_deps
>
>
Hi Masahiro,
On Thu, 4 Oct 2018 12:09:54 +0900 Masahiro Yamada
wrote:
>
> OK, confirmed.
>
>
> This is a regression of
>
> commit bb5de5d28f730eeec0aa1ced51a6f11327cd1201
> Author: Masahiro Yamada
> Date: Thu Sep 13 17:20:41 2018 +0900
>
> kbuild: remove unneeded link_multi_deps
>
>
The issue is the same as commit dd9aa335c880 ("ALSA: hda/realtek - Can't
adjust speaker's volume on a Dell AIO"), the output requires to connect
to a node with Amp-out capability.
Applying the same fixup ALC298_FIXUP_SPK_VOLUME can fix the issue.
BugLink: https://bugs.launchpad.net/bugs/1775068
The issue is the same as commit dd9aa335c880 ("ALSA: hda/realtek - Can't
adjust speaker's volume on a Dell AIO"), the output requires to connect
to a node with Amp-out capability.
Applying the same fixup ALC298_FIXUP_SPK_VOLUME can fix the issue.
BugLink: https://bugs.launchpad.net/bugs/1775068
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Jason Gunthorpe
> Sent: Wednesday, October 3, 2018 9:48 PM
> To: Parav Pandit
> Cc: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
> l...@kernel.org; Daniel Jurgens ;
>
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Jason Gunthorpe
> Sent: Wednesday, October 3, 2018 9:48 PM
> To: Parav Pandit
> Cc: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
> l...@kernel.org; Daniel Jurgens ;
>
Dear Arnaldo,
Am 03.10.2018 um 22:57 schrieb Arnaldo Carvalho de Melo:
Em Wed, Oct 03, 2018 at 10:42:39PM +0200, Paul Menzel escreveu:
For profiling the boot on my Debian Sid/unstable system (32-bit user space),
the following service unit is used.
You forgot to mention what is the version
Dear Arnaldo,
Am 03.10.2018 um 22:57 schrieb Arnaldo Carvalho de Melo:
Em Wed, Oct 03, 2018 at 10:42:39PM +0200, Paul Menzel escreveu:
For profiling the boot on my Debian Sid/unstable system (32-bit user space),
the following service unit is used.
You forgot to mention what is the version
Hi Morimoto-san
On 2018/10/04 9:55, Kuninori Morimoto wrote:
Hi Jiada
Thank you for your patch
From: Jiada Wang
This patch adds dma request number for busif0 ~ busif7
to be used by GEN3 series. GEN2 continues to use rxu/txu
for busif data transfer.
Signed-off-by: Jiada Wang
---
Hi Morimoto-san
On 2018/10/04 9:55, Kuninori Morimoto wrote:
Hi Jiada
Thank you for your patch
From: Jiada Wang
This patch adds dma request number for busif0 ~ busif7
to be used by GEN3 series. GEN2 continues to use rxu/txu
for busif data transfer.
Signed-off-by: Jiada Wang
---
On 2018/9/30 3:20, Jiri Kosina wrote:
On Sat, 29 Sep 2018, Jia-Ju Bai wrote:
picolcd_send_and_wait (acquire a spinlock)
hid_hw_request
__hid_request
hid_alloc_report_buf(GFP_KERNEL)
picolcd_reset (acquire a spinlock)
hid_hw_request
__hid_request
On 2018/9/30 3:20, Jiri Kosina wrote:
On Sat, 29 Sep 2018, Jia-Ju Bai wrote:
picolcd_send_and_wait (acquire a spinlock)
hid_hw_request
__hid_request
hid_alloc_report_buf(GFP_KERNEL)
picolcd_reset (acquire a spinlock)
hid_hw_request
__hid_request
Dear Borislav,
Am 03.10.2018 um 23:22 schrieb Borislav Petkov:
On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
Sorry for the delay and thanks for the data. A quick diff did not reveal
anything obvious. I'll have a closer look and we probably need more (other)
information to
Hi Stephen,
On Thu, Oct 4, 2018 at 10:57 AM Stephen Rothwell wrote:
>
> Hi Masahiro,
>
> On Thu, 4 Oct 2018 10:39:37 +1000 Stephen Rothwell
> wrote:
> >
> > On Wed, 3 Oct 2018 16:55:34 +1000 Stephen Rothwell
> > wrote:
> > >
> > > > > The latest example is this:
> > > > >
> > > > >
Dear Borislav,
Am 03.10.2018 um 23:22 schrieb Borislav Petkov:
On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
Sorry for the delay and thanks for the data. A quick diff did not reveal
anything obvious. I'll have a closer look and we probably need more (other)
information to
Hi Stephen,
On Thu, Oct 4, 2018 at 10:57 AM Stephen Rothwell wrote:
>
> Hi Masahiro,
>
> On Thu, 4 Oct 2018 10:39:37 +1000 Stephen Rothwell
> wrote:
> >
> > On Wed, 3 Oct 2018 16:55:34 +1000 Stephen Rothwell
> > wrote:
> > >
> > > > > The latest example is this:
> > > > >
> > > > >
It is safe to dereference an object below a NULL test. For the sake
of debugging. Just delete the call of possible null pointer dereference.
Signed-off-by: zhong jiang
---
drivers/misc/cxl/guest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/guest.c
It is safe to dereference an object below a NULL test. For the sake
of debugging. Just delete the call of possible null pointer dereference.
Signed-off-by: zhong jiang
---
drivers/misc/cxl/guest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/guest.c
Thanks for the reply :)
On 2018/10/3 23:54, Takashi Iwai wrote:
On Wed, 03 Oct 2018 14:50:25 +0200,
Jia-Ju Bai wrote:
CPU0:
snd_trident_hw_free
snd_trident_free_voice
line 3870: spin_lock_irqsave()
line 3881: voice->substream = NULL; [WRITE]
CPU1:
Thanks for the reply :)
On 2018/10/3 23:54, Takashi Iwai wrote:
On Wed, 03 Oct 2018 14:50:25 +0200,
Jia-Ju Bai wrote:
CPU0:
snd_trident_hw_free
snd_trident_free_voice
line 3870: spin_lock_irqsave()
line 3881: voice->substream = NULL; [WRITE]
CPU1:
Hi Morimoto-san
On 2018/10/04 10:12, Kuninori Morimoto wrote:
Hi Jiada
Thank you for your patch
Currently ssi driver only request dma channel for SSI_0,
which is used to transfer data to/from busif0.
But in GEN3 busif1 to busif7 also maybe used, dedicated dma channels
are requested for
Hi Morimoto-san
On 2018/10/04 10:12, Kuninori Morimoto wrote:
Hi Jiada
Thank you for your patch
Currently ssi driver only request dma channel for SSI_0,
which is used to transfer data to/from busif0.
But in GEN3 busif1 to busif7 also maybe used, dedicated dma channels
are requested for
On Thu, Oct 04, 2018 at 02:28:54AM +, Parav Pandit wrote:
> Hi Doug, Jason,
>
> > From: Parav Pandit
> > Sent: Friday, September 21, 2018 10:00 AM
> > To: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > l...@kernel.org; j...@ziepe.ca; syzkaller-b...@googlegroups.com; Daniel
> >
On Thu, Oct 04, 2018 at 02:28:54AM +, Parav Pandit wrote:
> Hi Doug, Jason,
>
> > From: Parav Pandit
> > Sent: Friday, September 21, 2018 10:00 AM
> > To: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > l...@kernel.org; j...@ziepe.ca; syzkaller-b...@googlegroups.com; Daniel
> >
On 2018/10/3 6:55, Greg KH wrote:
> On Wed, Sep 26, 2018 at 07:41:12PM +0800, zhong jiang wrote:
>> It is safe to move a deference below a NULL test.
>>
>> Signed-off-by: zhong jiang
>> Acked-by: Andrew Donnellan
>> ---
>> drivers/misc/cxl/guest.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2
On 2018/10/3 6:55, Greg KH wrote:
> On Wed, Sep 26, 2018 at 07:41:12PM +0800, zhong jiang wrote:
>> It is safe to move a deference below a NULL test.
>>
>> Signed-off-by: zhong jiang
>> Acked-by: Andrew Donnellan
>> ---
>> drivers/misc/cxl/guest.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2
Hi Morimoto-san
On 2018/10/04 10:41, Kuninori Morimoto wrote:
Hi Jiada
Thank you for your patch
in GEN3 SSI may use different BUSIF for data transfer,
this patch adds busif property to each dai stream,
to indicate the BUSIF used by playback/capture stream.
Also adds rsnd_ssi_select_busif()
Hi Morimoto-san
On 2018/10/04 10:41, Kuninori Morimoto wrote:
Hi Jiada
Thank you for your patch
in GEN3 SSI may use different BUSIF for data transfer,
this patch adds busif property to each dai stream,
to indicate the BUSIF used by playback/capture stream.
Also adds rsnd_ssi_select_busif()
Clang warns when one enumerated type is implicitly converted to another.
drivers/spi/spi-ep93xx.c:342:62: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
nents =
Clang warns when one enumerated type is implicitly converted to another.
drivers/spi/spi-ep93xx.c:342:62: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
nents =
Clang warns when one enumerated type is implicitly converted to another.
drivers/spi/spi-ep93xx.c:342:62: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
nents =
Clang warns when one enumerated type is implicitly converted to another.
drivers/spi/spi-ep93xx.c:342:62: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
nents =
Clang warns when one enumerated type is implicitly converted to another.
drivers/ata/pata_ep93xx.c:662:36: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
Clang warns when one enumerated type is implicitly converted to another.
drivers/ata/pata_ep93xx.c:662:36: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
When freeing a page with an order >= shuffle_page_order randomly select
the front or back of the list for insertion.
While the mm tries to defragment physical pages into huge pages this can
tend to make the page allocator more predictable over time. Inject the
front-back randomness to preserve
When freeing a page with an order >= shuffle_page_order randomly select
the front or back of the list for insertion.
While the mm tries to defragment physical pages into huge pages this can
tend to make the page allocator more predictable over time. Inject the
front-back randomness to preserve
Hi Doug, Jason,
> -Original Message-
> From: Parav Pandit
> Sent: Friday, September 21, 2018 10:00 AM
> To: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
> l...@kernel.org; j...@ziepe.ca; syzkaller-b...@googlegroups.com; Daniel
> Jurgens ; dledf...@redhat.com
> Cc: Parav
Hi Doug, Jason,
> -Original Message-
> From: Parav Pandit
> Sent: Friday, September 21, 2018 10:00 AM
> To: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org;
> l...@kernel.org; j...@ziepe.ca; syzkaller-b...@googlegroups.com; Daniel
> Jurgens ; dledf...@redhat.com
> Cc: Parav
Some data exfiltration and return-oriented-programming attacks rely on
the ability to infer the location of sensitive data objects. The kernel
page allocator, especially early in system boot, has predictable
first-in-first out behavior for physical pages. Pages are freed in
physical address order
In preparation for runtime randomization of the zone lists, take all
(well, most of) the list_*() functions in the buddy allocator and put
them in helper functions. Provide a common control point for injecting
additional behavior when freeing pages.
Cc: Michal Hocko
Cc: Dave Hansen
Some data exfiltration and return-oriented-programming attacks rely on
the ability to infer the location of sensitive data objects. The kernel
page allocator, especially early in system boot, has predictable
first-in-first out behavior for physical pages. Pages are freed in
physical address order
In preparation for runtime randomization of the zone lists, take all
(well, most of) the list_*() functions in the buddy allocator and put
them in helper functions. Provide a common control point for injecting
additional behavior when freeing pages.
Cc: Michal Hocko
Cc: Dave Hansen
Changes since v1:
* Add support for shuffling hot-added memory (Andrew)
* Update cover letter and commit message to clarify the performance impact
and relevance to future platforms
[1]: https://lkml.org/lkml/2018/9/15/366
---
Some data exfiltration and return-oriented-programming attacks rely
Changes since v1:
* Add support for shuffling hot-added memory (Andrew)
* Update cover letter and commit message to clarify the performance impact
and relevance to future platforms
[1]: https://lkml.org/lkml/2018/9/15/366
---
Some data exfiltration and return-oriented-programming attacks rely
NFSD uses permission flags similar to the MAY_* flags,
with some overlap, and depends on the overlap matching.
This is currently a little fragile and hard to extend.
So add __MAY_UNUSED to identify the first unused flag,
and have NFSD use that flag and later flags for its
non-standard
NFSD uses permission flags similar to the MAY_* flags,
with some overlap, and depends on the overlap matching.
This is currently a little fragile and hard to extend.
So add __MAY_UNUSED to identify the first unused flag,
and have NFSD use that flag and later flags for its
non-standard
On Wed, 3 Oct 2018, Leonardo Bras wrote:
> Both ccache and distcc seem very interesting, I will take my time to
> study them better as they can solve some situations I face. Thanks for
> sharing!
>
You might also want to check out 'gcc -O0', 'gcc -fopt-info' and 'gcc
--help=optimizers' etc
On Wed, 3 Oct 2018, Leonardo Bras wrote:
> Both ccache and distcc seem very interesting, I will take my time to
> study them better as they can solve some situations I face. Thanks for
> sharing!
>
You might also want to check out 'gcc -O0', 'gcc -fopt-info' and 'gcc
--help=optimizers' etc
Hi Masahiro,
On Thu, 4 Oct 2018 10:39:37 +1000 Stephen Rothwell
wrote:
>
> On Wed, 3 Oct 2018 16:55:34 +1000 Stephen Rothwell
> wrote:
> >
> > > > The latest example is this:
> > > >
> > > > include/linux/kconfig.h: file not recognized: file format not recognized
> > > > make[2]: ***
Hi Masahiro,
On Thu, 4 Oct 2018 10:39:37 +1000 Stephen Rothwell
wrote:
>
> On Wed, 3 Oct 2018 16:55:34 +1000 Stephen Rothwell
> wrote:
> >
> > > > The latest example is this:
> > > >
> > > > include/linux/kconfig.h: file not recognized: file format not recognized
> > > > make[2]: ***
1 - 100 of 1152 matches
Mail list logo
