On Tue, Jun 12, 2018 at 08:31:06AM +0200, Samuel Thibault wrote:
> The load/unload is about the module itself, i.e. modprobe speakup_bns ;
> modprobe speakup_soft, switch between them, then rmmod speakup_bns ;
> speakup_soft or the converse (to exercise both orders).
# uname -a
Linux p41box
On Mon, Jun 18, 2018 at 01:35:23PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 8 Jun 2018 13:37:48 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the random tree, today's linux-next build (arm
> > multi_v7_defconfig) produced this warning:
> >
> > lib/vsprintf.c:1668:13:
On Tue, Jun 12, 2018 at 08:31:06AM +0200, Samuel Thibault wrote:
> The load/unload is about the module itself, i.e. modprobe speakup_bns ;
> modprobe speakup_soft, switch between them, then rmmod speakup_bns ;
> speakup_soft or the converse (to exercise both orders).
# uname -a
Linux p41box
On Mon, Jun 18, 2018 at 01:35:23PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 8 Jun 2018 13:37:48 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the random tree, today's linux-next build (arm
> > multi_v7_defconfig) produced this warning:
> >
> > lib/vsprintf.c:1668:13:
On 06/13/2018 07:36 AM, Andrew Morton wrote:
> On Tue, 12 Jun 2018 08:36:32 +0200 Takashi Iwai wrote:
>
>>> Well the present behaviour is to convert higher values downwards, yes?
>>>
>>> int ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int limit)
>>> {
>>> kuid_t euid;
>>>
On 06/13/2018 07:36 AM, Andrew Morton wrote:
> On Tue, 12 Jun 2018 08:36:32 +0200 Takashi Iwai wrote:
>
>>> Well the present behaviour is to convert higher values downwards, yes?
>>>
>>> int ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int limit)
>>> {
>>> kuid_t euid;
>>>
For CS_ETM_TRACE_ON packet, its fields 'packet->start_addr' and
'packet->end_addr' equal to 0xdeadbeefdeadbeefUL which are emitted in
the decoder layer as dummy value, but the dummy value is pointless for
branch sample when we use 'perf script' command to check program flow.
This patch is a
On Monday, 18 June 2018 2:46:33 PM AEST Benjamin Herrenschmidt wrote:
> On Mon, 2018-06-18 at 14:09 +1000, Alistair Popple wrote:
> > On Sunday, 17 June 2018 11:22:11 AM AEST Benjamin Herrenschmidt wrote:
> > > On Sun, 2018-06-17 at 11:17 +1000, Benjamin Herrenschmidt wrote:
> > > >
> > > > We
For CS_ETM_TRACE_ON packet, its fields 'packet->start_addr' and
'packet->end_addr' equal to 0xdeadbeefdeadbeefUL which are emitted in
the decoder layer as dummy value, but the dummy value is pointless for
branch sample when we use 'perf script' command to check program flow.
This patch is a
On Monday, 18 June 2018 2:46:33 PM AEST Benjamin Herrenschmidt wrote:
> On Mon, 2018-06-18 at 14:09 +1000, Alistair Popple wrote:
> > On Sunday, 17 June 2018 11:22:11 AM AEST Benjamin Herrenschmidt wrote:
> > > On Sun, 2018-06-17 at 11:17 +1000, Benjamin Herrenschmidt wrote:
> > > >
> > > > We
If one CS_ETM_TRACE_ON packet is inserted, we miss to generate branch
sample for the previous CS_ETM_RANGE packet.
This patch is to generate branch sample when receiving a CS_ETM_TRACE_ON
packet, so this can save complete info for the previous CS_ETM_RANGE
packet just before CS_ETM_TRACE_ON
If one CS_ETM_TRACE_ON packet is inserted, we miss to generate branch
sample for the previous CS_ETM_RANGE packet.
This patch is to generate branch sample when receiving a CS_ETM_TRACE_ON
packet, so this can save complete info for the previous CS_ETM_RANGE
packet just before CS_ETM_TRACE_ON
CS_ETM_TRACE_ON packet itself can give the info that there have a
discontinuity in the trace, this patch is to add branch sample for
CS_ETM_TRACE_ON packet if it is inserted in the middle of CS_ETM_RANGE
packets; as result we can have hint for the trace discontinuity.
Signed-off-by: Leo Yan
---
CS_ETM_TRACE_ON packet itself can give the info that there have a
discontinuity in the trace, this patch is to add branch sample for
CS_ETM_TRACE_ON packet if it is inserted in the middle of CS_ETM_RANGE
packets; as result we can have hint for the trace discontinuity.
Signed-off-by: Leo Yan
---
Due the current code is missing to handle cs-etm start tracing packet
and CS_ETM_TRACE_ON packet, we fail to generate branch sample for them.
This patch series is to fix cs-etm tracing packet handling:
Patch 0001 is to add invalid address macro for readable coding;
Patch 0002 is one minor
If the instruction sample failure has happened, it isn't necessary to
execute to the end of the function cs_etm__flush(). This commit is to
bail out immediately and return the error code.
Signed-off-by: Leo Yan
---
tools/perf/util/cs-etm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Usually the start tracing packet is a CS_ETM_TRACE_ON packet, this
packet is passed to cs_etm__flush(); cs_etm__flush() will check the
condition 'prev_packet->sample_type == CS_ETM_RANGE' but 'prev_packet'
is allocated by zalloc() so 'prev_packet->sample_type' is zero in
initialization and this
This patch introduces invalid address macro and uses it to replace dummy
value '0xdeadbeefdeadbeefUL'.
Signed-off-by: Leo Yan
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
Due the current code is missing to handle cs-etm start tracing packet
and CS_ETM_TRACE_ON packet, we fail to generate branch sample for them.
This patch series is to fix cs-etm tracing packet handling:
Patch 0001 is to add invalid address macro for readable coding;
Patch 0002 is one minor
If the instruction sample failure has happened, it isn't necessary to
execute to the end of the function cs_etm__flush(). This commit is to
bail out immediately and return the error code.
Signed-off-by: Leo Yan
---
tools/perf/util/cs-etm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Usually the start tracing packet is a CS_ETM_TRACE_ON packet, this
packet is passed to cs_etm__flush(); cs_etm__flush() will check the
condition 'prev_packet->sample_type == CS_ETM_RANGE' but 'prev_packet'
is allocated by zalloc() so 'prev_packet->sample_type' is zero in
initialization and this
This patch introduces invalid address macro and uses it to replace dummy
value '0xdeadbeefdeadbeefUL'.
Signed-off-by: Leo Yan
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
Hello Steven,
I've changed the code a little bit to avoid a compile warning caused by
'const' args of find_cpu(). Can I keep your Reviewed-by?
BEFORE:
static int find_cpu(const struct cpumask *mask,
const struct sched_domain *sd,
const struct sched_domain
Hello Steven,
I've changed the code a little bit to avoid a compile warning caused by
'const' args of find_cpu(). Can I keep your Reviewed-by?
BEFORE:
static int find_cpu(const struct cpumask *mask,
const struct sched_domain *sd,
const struct sched_domain
Hello Steven and Daniel,
I've changed the 2nd patch a little bit to consider cpudl_clear()
additionally. Can I keep your Acked-by on?
(I temporarily removed the Acked-by you gave me.)
Acked-by: Steven Rostedt (VMware)
Acked-by: Daniel Bristot de Oliveira
-8<-
>From
Hello Steven and Daniel,
I've changed the 2nd patch a little bit to consider cpudl_clear()
additionally. Can I keep your Acked-by on?
(I temporarily removed the Acked-by you gave me.)
Acked-by: Steven Rostedt (VMware)
Acked-by: Daniel Bristot de Oliveira
-8<-
>From
Change from v11
-. Rebase onto the latest tip/sched/core
-. make the word 'cpu' in comments be upper case as Ingo did
in the commit 97fb7a0a89
-. Avoid a compile warning caused by mismatching bwt const and
non-const 'struct sched_domain' in find_cpu()
Change from v10
-.
Change from v11
-. Rebase onto the latest tip/sched/core
-. make the word 'cpu' in comments be upper case as Ingo did
in the commit 97fb7a0a89
-. Avoid a compile warning caused by mismatching bwt const and
non-const 'struct sched_domain' in find_cpu()
Change from v10
-.
Changes from v4
- Fix a typo in cpudl_init() of the 2nd patch
Changes from v3
- Rebase onto the latest tip/sched/core
- Apply what Joel suggests, to set cp->elements[0].cpu to -1
when the heap becomes empty in cpudl_clear()
Changes from v2
- Run spellchecker over the text and fix typos
-
Changes from v4
- Fix a typo in cpudl_init() of the 2nd patch
Changes from v3
- Rebase onto the latest tip/sched/core
- Apply what Joel suggests, to set cp->elements[0].cpu to -1
when the heap becomes empty in cpudl_clear()
Changes from v2
- Run spellchecker over the text and fix typos
-
Hello Juri,
I've changed the code a little bit to avoid a compile warning caused by
'const' args of find_cpu(). Can I keep your Acked-by?
BEFORE:
static int find_cpu(const struct cpumask *mask,
const struct sched_domain *sd,
const struct sched_domain
Hello Juri,
I've changed the code a little bit to avoid a compile warning caused by
'const' args of find_cpu(). Can I keep your Acked-by?
BEFORE:
static int find_cpu(const struct cpumask *mask,
const struct sched_domain *sd,
const struct sched_domain
Add documentation for building modules
from multiple directories using modobj-m.
Signed-off-by: NeilBrown
---
Documentation/kbuild/makefiles.txt | 65 ++--
1 file changed, 61 insertions(+), 4 deletions(-)
diff --git a/Documentation/kbuild/makefiles.txt
Add documentation for building modules
from multiple directories using modobj-m.
Signed-off-by: NeilBrown
---
Documentation/kbuild/makefiles.txt | 65 ++--
1 file changed, 61 insertions(+), 4 deletions(-)
diff --git a/Documentation/kbuild/makefiles.txt
When building an object to be included in mod.a we
cannot know the name of the module. So don't define
KBUILD_MODNAME. This will ensure attempt to use
that macro when the module name isn't know will
trigger an error.
Signed-off-by: NeilBrown
---
scripts/Makefile.lib |4 ++--
1 file
This is a first step in a larger change and so can
only be fully understood in the larger context.
This patch changes the code for extracting directories
from a list of objects to extract them from real-obj-X
instead of obj-X.
This should not cause any change in behaviour yet
as listing
Currently a directory is not permitted in a composite
object.
This patch changes kbuild so that a directory it assumed
to mean the file "mod.a" in that directory.
The file cannot, yet, be created, so this does not yet
affect behaviour.
There are several parts to this.
1/ strip out all the
When building an object to be included in mod.a we
cannot know the name of the module. So don't define
KBUILD_MODNAME. This will ensure attempt to use
that macro when the module name isn't know will
trigger an error.
Signed-off-by: NeilBrown
---
scripts/Makefile.lib |4 ++--
1 file
This is a first step in a larger change and so can
only be fully understood in the larger context.
This patch changes the code for extracting directories
from a list of objects to extract them from real-obj-X
instead of obj-X.
This should not cause any change in behaviour yet
as listing
Currently a directory is not permitted in a composite
object.
This patch changes kbuild so that a directory it assumed
to mean the file "mod.a" in that directory.
The file cannot, yet, be created, so this does not yet
affect behaviour.
There are several parts to this.
1/ strip out all the
This set of patches makes it possible to build a module from
code in multiple directories without needing to list files from one
directory in the Makefile of another directory.
The code was developed for lustre (which is now out-of-tree :-( ) but
can be useful elsewhere, such as for xfs and btrfs
This patch allows a "mod.a" to be built in any
directory. A previous patch allows that mod.a
to be included in any module or another mod.a.
This is achieved via a new pair of macros: modobj-y and modobj-m.
Anything in modobj-y is added to obj-y and is otherwise
ignored.
Anything listed in
On 17-06-18, 22:01, ilia@gmail.com wrote:
> From: Ilia Lin
>
> Add device remove and module exit code to make the driver
> functioning as a loadable module.
>
> Fixes: ac28927659be (cpufreq: kryo: allow building as a loadable module)
> Signed-off-by: Ilia Lin
> ---
>
On 17-06-18, 22:01, ilia@gmail.com wrote:
> From: Ilia Lin
>
> Add device remove and module exit code to make the driver
> functioning as a loadable module.
>
> Fixes: ac28927659be (cpufreq: kryo: allow building as a loadable module)
> Signed-off-by: Ilia Lin
> ---
>
This set of patches makes it possible to build a module from
code in multiple directories without needing to list files from one
directory in the Makefile of another directory.
The code was developed for lustre (which is now out-of-tree :-( ) but
can be useful elsewhere, such as for xfs and btrfs
This patch allows a "mod.a" to be built in any
directory. A previous patch allows that mod.a
to be included in any module or another mod.a.
This is achieved via a new pair of macros: modobj-y and modobj-m.
Anything in modobj-y is added to obj-y and is otherwise
ignored.
Anything listed in
On 17-06-18, 21:58, ilia@gmail.com wrote:
> From: Ilia Lin
>
> In event of error returned by the nvmem_cell_read() non-pointer value
> may be dereferenced. Fix this with error handling.
> Additionally free the allocated speedbin buffer, as per the API.
>
> Fixes: 9ce36edd1a52 (cpufreq: Add
On 17-06-18, 21:58, ilia@gmail.com wrote:
> From: Ilia Lin
>
> In event of error returned by the nvmem_cell_read() non-pointer value
> may be dereferenced. Fix this with error handling.
> Additionally free the allocated speedbin buffer, as per the API.
>
> Fixes: 9ce36edd1a52 (cpufreq: Add
Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
revision number field of the ONFI parameter page. Rather than rejecting
these outright assume ONFI version 1.0 if the revision number is 00 00.
Signed-off-by: Chris Packham
---
At the moment I haven't qualified this check on
Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
revision number field of the ONFI parameter page. Rather than rejecting
these outright assume ONFI version 1.0 if the revision number is 00 00.
Signed-off-by: Chris Packham
---
At the moment I haven't qualified this check on
On 14 June 2018 at 05:06, Eddie James wrote:
> This series adds an algorithm for an I2C master physically located on an FSI
> slave device. The I2C master has multiple ports, each of which may be
> connected
> to an I2C slave. Access to the I2C master registers is achieved over FSI bus.
>
> Due
The MT29F1G08ABAFAWP-ITE:F chip has 2048 byte pages and requires a
minimum ECC strength of 8-bits. Allow for this combination of
requirements using the marvell_nand controller.
Signed-off-by: Chris Packham
---
I've tried to follow the recommended AN-379 from Marvell. They do seem
to have
Hi,
I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
to one of our boards which uses the Marvell NFCv2 controller.
This particular chip is a bit odd in that the datasheet states support
for ONFI 1.0 but the revision number field is 00 00. It also is marked
ABAFA but
On 14 June 2018 at 05:06, Eddie James wrote:
> This series adds an algorithm for an I2C master physically located on an FSI
> slave device. The I2C master has multiple ports, each of which may be
> connected
> to an I2C slave. Access to the I2C master registers is achieved over FSI bus.
>
> Due
The MT29F1G08ABAFAWP-ITE:F chip has 2048 byte pages and requires a
minimum ECC strength of 8-bits. Allow for this combination of
requirements using the marvell_nand controller.
Signed-off-by: Chris Packham
---
I've tried to follow the recommended AN-379 from Marvell. They do seem
to have
Hi,
I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
to one of our boards which uses the Marvell NFCv2 controller.
This particular chip is a bit odd in that the datasheet states support
for ONFI 1.0 but the revision number field is 00 00. It also is marked
ABAFA but
Hi Dmitry,
On Fri, 15 Jun 2018 11:54:16 +0200 Dmitry Vyukov wrote:
>
> Re backwards bisection (when bug is introduced), we can actually test
> linux-next-history instead of linux-next, right?
I don't see why using linux-next-history would be any better, it just
contains all the linux-next
Hi Dmitry,
On Fri, 15 Jun 2018 11:54:16 +0200 Dmitry Vyukov wrote:
>
> Re backwards bisection (when bug is introduced), we can actually test
> linux-next-history instead of linux-next, right?
I don't see why using linux-next-history would be any better, it just
contains all the linux-next
Hi David,
On Sunday 17 June 2018 09:18 PM, David Lechner wrote:
> Hi Sekhar,
>
> On 05/22/2018 04:38 AM, Sekhar Nori wrote:
>> Hi David,
>>
>> On Friday 18 May 2018 10:18 PM, David Lechner wrote:
>>> This series converts mach-davinci to use the common clock framework.
>>>
>>> The series works
Hi all,
Changes since 20180615:
Added trees: xarray, mlx5-next
Removed tree: powerpc-pkey (finished with)
The mac80211-next tree gained a conflict against Linus' tree.
The xarray tree gained a build failure due to an interaction with the
nvdimm tree for which I applied a fix.
Non-merge
Hi David,
On Sunday 17 June 2018 09:18 PM, David Lechner wrote:
> Hi Sekhar,
>
> On 05/22/2018 04:38 AM, Sekhar Nori wrote:
>> Hi David,
>>
>> On Friday 18 May 2018 10:18 PM, David Lechner wrote:
>>> This series converts mach-davinci to use the common clock framework.
>>>
>>> The series works
Hi all,
Changes since 20180615:
Added trees: xarray, mlx5-next
Removed tree: powerpc-pkey (finished with)
The mac80211-next tree gained a conflict against Linus' tree.
The xarray tree gained a build failure due to an interaction with the
nvdimm tree for which I applied a fix.
Non-merge
On Mon, 2018-06-18 at 14:09 +1000, Alistair Popple wrote:
> On Sunday, 17 June 2018 11:22:11 AM AEST Benjamin Herrenschmidt wrote:
> > On Sun, 2018-06-17 at 11:17 +1000, Benjamin Herrenschmidt wrote:
> > >
> > > We have everything that cronus needs and more than pdbg needs afaik :-)
>
> Yep, has
On Mon, 2018-06-18 at 14:09 +1000, Alistair Popple wrote:
> On Sunday, 17 June 2018 11:22:11 AM AEST Benjamin Herrenschmidt wrote:
> > On Sun, 2018-06-17 at 11:17 +1000, Benjamin Herrenschmidt wrote:
> > >
> > > We have everything that cronus needs and more than pdbg needs afaik :-)
>
> Yep, has
Unfortunately the patch for adding list_for_each_entry_from_rcu()
wasn't the final patch after all review. It is functionally
correct but the documentation was incomplete.
This patch adds this missing documentation which includes an update to
the documentation for
Unfortunately the patch for adding list_for_each_entry_from_rcu()
wasn't the final patch after all review. It is functionally
correct but the documentation was incomplete.
This patch adds this missing documentation which includes an update to
the documentation for
Making a cgroup a domain root will reserve cpu resource at its parent.
So when a domain root cgroup is destroyed, we need to free the
reserved cpus at its parent. This is now done by doing an auto-off of
the sched.domain_root flag in the offlining phase when a domain root
cgroup is being removed.
Making a cgroup a domain root will reserve cpu resource at its parent.
So when a domain root cgroup is destroyed, we need to free the
reserved cpus at its parent. This is now done by doing an auto-off of
the sched.domain_root flag in the offlining phase when a domain root
cgroup is being removed.
v10:
- Remove the cpuset.sched.load_balance patch for now as it may not
be that useful.
- Break the large patch 2 into smaller patches to make them a bit
easier to review.
- Test and fix issues related to changing "cpuset.cpus" and cpu
online/offline in a domain root.
- Rename
Given the fact that thread mode had been merged into 4.14, it is now
time to enable cpuset to be used in the default hierarchy (cgroup v2)
as it is clearly threaded.
The cpuset controller had experienced feature creep since its
introduction more than a decade ago. Besides the core cpus and mems
v10:
- Remove the cpuset.sched.load_balance patch for now as it may not
be that useful.
- Break the large patch 2 into smaller patches to make them a bit
easier to review.
- Test and fix issues related to changing "cpuset.cpus" and cpu
online/offline in a domain root.
- Rename
Given the fact that thread mode had been merged into 4.14, it is now
time to enable cpuset to be used in the default hierarchy (cgroup v2)
as it is clearly threaded.
The cpuset controller had experienced feature creep since its
introduction more than a decade ago. Besides the core cpus and mems
On Sunday, 17 June 2018 11:22:11 AM AEST Benjamin Herrenschmidt wrote:
> On Sun, 2018-06-17 at 11:17 +1000, Benjamin Herrenschmidt wrote:
> >
> > We have everything that cronus needs and more than pdbg needs afaik :-)
Yep, has what we need and more (such as put scom under mask and indirect
On Sunday, 17 June 2018 11:22:11 AM AEST Benjamin Herrenschmidt wrote:
> On Sun, 2018-06-17 at 11:17 +1000, Benjamin Herrenschmidt wrote:
> >
> > We have everything that cronus needs and more than pdbg needs afaik :-)
Yep, has what we need and more (such as put scom under mask and indirect
Hi Sebastian,
[Adding Martin on Cc who also tried to enable DBGEN bit in a previous patch]
On Mon, Feb 26, 2018 at 10:47 AM, Sebastian Reichel
wrote:
> Hi Shawn,
>
> On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote:
>> On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote:
Hi Sebastian,
[Adding Martin on Cc who also tried to enable DBGEN bit in a previous patch]
On Mon, Feb 26, 2018 at 10:47 AM, Sebastian Reichel
wrote:
> Hi Shawn,
>
> On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote:
>> On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote:
Hi all,
On Tue, 12 Jun 2018 12:26:40 +1000 Stephen Rothwell
wrote:
>
> Building Linus' tree, today's linux-next build (powerpc allyesconfig)
> failed like this:
>
> ld: net/bpfilter/bpfilter_umh.o: compiled for a little endian system and
> target is big endian
> ld: failed to merge target
Hi all,
On Tue, 12 Jun 2018 12:26:40 +1000 Stephen Rothwell
wrote:
>
> Building Linus' tree, today's linux-next build (powerpc allyesconfig)
> failed like this:
>
> ld: net/bpfilter/bpfilter_umh.o: compiled for a little endian system and
> target is big endian
> ld: failed to merge target
Hi Paul,
On Mon, 18 Jun 2018 13:48:49 +1000 Stephen Rothwell
wrote:
>
> I am still getting this.
Maybe this was a bit premature :-)
--
Cheers,
Stephen Rothwell
pgpctU4_DnFxM.pgp
Description: OpenPGP digital signature
Hi Paul,
On Mon, 18 Jun 2018 13:48:49 +1000 Stephen Rothwell
wrote:
>
> I am still getting this.
Maybe this was a bit premature :-)
--
Cheers,
Stephen Rothwell
pgpctU4_DnFxM.pgp
Description: OpenPGP digital signature
Hi all,
On Tue, 12 Jun 2018 10:46:07 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the rcu tree got a conflict in:
>
> drivers/iommu/amd_iommu.c
>
> between commit:
>
> 94c793accacd ("iommu/amd: Hide unused iommu_table_lock")
>
> from Linus' tree and commit:
>
>
Hi all,
On Tue, 12 Jun 2018 10:46:07 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the rcu tree got a conflict in:
>
> drivers/iommu/amd_iommu.c
>
> between commit:
>
> 94c793accacd ("iommu/amd: Hide unused iommu_table_lock")
>
> from Linus' tree and commit:
>
>
Hi all,
On Tue, 12 Jun 2018 10:19:54 +1000 Stephen Rothwell
wrote:
>
> After merging the nfc-next tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/nfc/fdp/fdp.c: In function 'fdp_nci_open':
> drivers/nfc/fdp/fdp.c:250:17: warning: unused variable 'dev'
Hi all,
On Tue, 12 Jun 2018 10:19:54 +1000 Stephen Rothwell
wrote:
>
> After merging the nfc-next tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/nfc/fdp/fdp.c: In function 'fdp_nci_open':
> drivers/nfc/fdp/fdp.c:250:17: warning: unused variable 'dev'
Hi all,
On Tue, 29 May 2018 11:30:35 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the vfs tree got a conflict in:
>
> fs/read_write.c
>
> between commit:
>
> 63ea46a359b2 ("vfs: dedupe: extract helper for a single dedup")
>
> from the overlayfs tree and commit:
>
>
Hi all,
On Tue, 29 May 2018 11:30:35 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the vfs tree got a conflict in:
>
> fs/read_write.c
>
> between commit:
>
> 63ea46a359b2 ("vfs: dedupe: extract helper for a single dedup")
>
> from the overlayfs tree and commit:
>
>
Hi all,
On Tue, 29 May 2018 09:52:50 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the overlayfs tree got a conflict in:
>
> fs/btrfs/ioctl.c
>
> between commit:
>
> 0b4dc087e29a ("Btrfs: dedupe_file_range ioctl: remove 16MiB restriction")
>
> from the btrfs-kdave tree
Hi all,
On Tue, 29 May 2018 09:52:50 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the overlayfs tree got a conflict in:
>
> fs/btrfs/ioctl.c
>
> between commit:
>
> 0b4dc087e29a ("Btrfs: dedupe_file_range ioctl: remove 16MiB restriction")
>
> from the btrfs-kdave tree
On Thu, May 31, 2018 at 11:29 PM, Jordan Crouse wrote:
> On Mon, May 28, 2018 at 12:38:41PM +0530, Souptick Joarder wrote:
>> On Mon, May 21, 2018 at 10:59 PM, Souptick Joarder
>> wrote:
>> > Use new return type vm_fault_t for fault handler. For
>> > now, this is just documenting that the
On Thu, May 31, 2018 at 11:29 PM, Jordan Crouse wrote:
> On Mon, May 28, 2018 at 12:38:41PM +0530, Souptick Joarder wrote:
>> On Mon, May 21, 2018 at 10:59 PM, Souptick Joarder
>> wrote:
>> > Use new return type vm_fault_t for fault handler. For
>> > now, this is just documenting that the
Hi Chris,
On Tue, 3 Apr 2018 12:29:19 +1000 Stephen Rothwell
wrote:
>
> Ping?
>
> On Wed, 14 Mar 2018 10:17:04 +1100 Stephen Rothwell
> wrote:
> >
> > On Thu, 1 Feb 2018 09:25:51 +1100 Stephen Rothwell
> > wrote:
> > >
> > > On Tue, 30 Jan 2018 16:25:35 -0800 Jaegeuk Kim
> > > wrote:
Hi Chris,
On Tue, 3 Apr 2018 12:29:19 +1000 Stephen Rothwell
wrote:
>
> Ping?
>
> On Wed, 14 Mar 2018 10:17:04 +1100 Stephen Rothwell
> wrote:
> >
> > On Thu, 1 Feb 2018 09:25:51 +1100 Stephen Rothwell
> > wrote:
> > >
> > > On Tue, 30 Jan 2018 16:25:35 -0800 Jaegeuk Kim
> > > wrote:
Hi all,
On Fri, 8 Jun 2018 13:37:48 +1000 Stephen Rothwell
wrote:
>
> After merging the random tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> lib/vsprintf.c:1668:13: warning: 'have_filled_random_ptr_key' defined but not
> used [-Wunused-variable]
>
Hi all,
On Fri, 8 Jun 2018 13:37:48 +1000 Stephen Rothwell
wrote:
>
> After merging the random tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> lib/vsprintf.c:1668:13: warning: 'have_filled_random_ptr_key' defined but not
> used [-Wunused-variable]
>
Hi all,
After merging the xarray tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
WARNING: modpost: missing MODULE_LICENSE() in lib/test_xarray.o
Introduced by commit
d968f529e39f ("xarray: Add XArray load operation")
--
Cheers,
Stephen Rothwell
Hi all,
After merging the xarray tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
WARNING: modpost: missing MODULE_LICENSE() in lib/test_xarray.o
Introduced by commit
d968f529e39f ("xarray: Add XArray load operation")
--
Cheers,
Stephen Rothwell
Hi all,
After merging the xarray tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from arch/powerpc/include/asm/bug.h:128:0,
from include/linux/bug.h:5,
from arch/powerpc/include/asm/cmpxchg.h:9,
from
Hi all,
After merging the xarray tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from arch/powerpc/include/asm/bug.h:128:0,
from include/linux/bug.h:5,
from arch/powerpc/include/asm/cmpxchg.h:9,
from
On Sun, 2018-06-17 at 21:47 +0200, Borislav Petkov wrote:
> On Sun, Jun 17, 2018 at 04:02:58PM +0200, Mike Galbraith wrote:
> > (/me does that.. all better)
> >
> > From 6ac281ee69f4cb5b581d5f49662fb56b6326155a Mon Sep 17 00:00:00 2001
> > From: Borislav Petkov
> > Date: Sun, 17 Jun 2018
On Sun, 2018-06-17 at 21:47 +0200, Borislav Petkov wrote:
> On Sun, Jun 17, 2018 at 04:02:58PM +0200, Mike Galbraith wrote:
> > (/me does that.. all better)
> >
> > From 6ac281ee69f4cb5b581d5f49662fb56b6326155a Mon Sep 17 00:00:00 2001
> > From: Borislav Petkov
> > Date: Sun, 17 Jun 2018
1 - 100 of 336 matches
Mail list logo
