* Re: efi_enabled(EFI_PARAVIRT) use
From: Matt Fleming @ 2016-05-01 13:26 UTC (permalink / raw)
To: Shannon Zhao
Cc: Ard Biesheuvel, Stefano Stabellini, Ingo Molnar, Stephen Rothwell,
Luis R. Rodriguez, Jeremy Fitzhardinge, Konrad Rzeszutek Wilk,
Stefano Stabellini, Xen Devel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next,
linux-kernel@vger.kernel.org, Borislav Petkov
In-Reply-To: <572576E2.7060508@linaro.org>
On Sun, 01 May, at 11:24:18AM, Shannon Zhao wrote:
> Because the UEFI params for Dom0 are located under /hypervisor/uefi node
> instead of /chosen. So it needs to check whether it's a Dom0 then search
> and parse different node with different params arrays.
Why can't you search both nodes? Would you ever expect to see both for
a Dom0 kernel?
> So it still needs add another check to firstly parse the fdt to see if
> there is "xen,uefi-system-table" under /hypervisor/uefi node, right? I
> think it's a bit redundant compared with xen_initial_domain().
Sometimes you really do need to check xen_initial_domain(), but I do
not think this is such a case. And if we can get by without adding
that check, the code will be better for it.
^ permalink raw reply
* Re: linux-next: build failure after merge of the tpmdd tree
From: Stephen Rothwell @ 2016-05-01 13:12 UTC (permalink / raw)
To: Jarkko Sakkinen; +Cc: linux-next, linux-kernel, Christophe Ricard
In-Reply-To: <1461834144.3482.4.camel@linux.intel.com>
Hi Jarkko,
On Thu, 28 Apr 2016 12:02:24 +0300 Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
>
> On Thu, 2016-04-28 at 15:32 +1000, Stephen Rothwell wrote:
> > Hi Jarkko,
> >
> > After merging the tpmdd tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> > In file included from /home/sfr/next/next/include/linux/rcupdate.h:38:0,
> > from /home/sfr/next/next/include/linux/idr.h:18,
> > from /home/sfr/next/next/include/linux/kernfs.h:14,
> > from /home/sfr/next/next/include/linux/sysfs.h:15,
> > from /home/sfr/next/next/include/linux/kobject.h:21,
> > from /home/sfr/next/next/include/linux/device.h:17,
> > from /home/sfr/next/next/include/linux/dma-mapping.h:6,
> > from /home/sfr/next/next/drivers/char/tpm/tpm_ibmvtpm.c:18:
> > /home/sfr/next/next/drivers/char/tpm/tpm_ibmvtpm.c: In function 'tpm_ibmvtpm_probe':
> > /home/sfr/next/next/include/linux/spinlock.h:295:1: error: expected ';' before 'do'
> > do { \
> > ^
> > /home/sfr/next/next/drivers/char/tpm/tpm_ibmvtpm.c:632:2: note: in expansion of macro
> > 'spin_lock_init'
> > spin_lock_init(&ibmvtpm->rtce_lock);
> > ^
> >
> > Caused by commit
> >
> > 28157164b056 ("tpm: Remove useless priv field in struct tpm_vendor_specific")
> >
> > A ';' was missed.
> >
> > I added the following patch for today.
>
> Sorry about this and thank you.
>
> /Jarkko
>
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 28 Apr 2016 15:27:17 +1000
> > Subject: [PATCH] tpm: fix for typo in tpm/tpm_ibmvtpm.c
> >
> > Fixes: 28157164b056 ("tpm: Remove useless priv field in struct tpm_vendor_specific")
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > drivers/char/tpm/tpm_ibmvtpm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
> > index 6b22826f0e11..946025a7413b 100644
> > --- a/drivers/char/tpm/tpm_ibmvtpm.c
> > +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> > @@ -627,7 +627,7 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
> >
> > crq_q->index = 0;
> >
> > - dev_set_drvdata(&chip->dev, ibmvtpm)
> > + dev_set_drvdata(&chip->dev, ibmvtpm);
> >
> > spin_lock_init(&ibmvtpm->rtce_lock);
> >
> > --
> > 2.7.0
> >
Ping?
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Shannon Zhao @ 2016-05-01 3:24 UTC (permalink / raw)
To: Matt Fleming
Cc: Ard Biesheuvel, Stefano Stabellini, Ingo Molnar, Stephen Rothwell,
Luis R. Rodriguez, Jeremy Fitzhardinge, Konrad Rzeszutek Wilk,
Stefano Stabellini, Xen Devel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next,
linux-kernel@vger.kernel.org, Borislav Petkov
In-Reply-To: <20160430204420.GM2839@codeblueprint.co.uk>
On 2016年05月01日 04:44, Matt Fleming wrote:
>> While I still have a question, in this patch we use
>> > efi_enabled(EFI_PARAVIRT) as a condition to make fdt_find_uefi_params()
>> > and efi_get_fdt_params() execute different ways. So it needs to find a
>> > new condition for that if we need to get rid of EFI_PARAVIRT. One I
>> > think is that xen_initial_domain() check. Is that fine?
> Hmm... why do you actually need to check whether you're running on a
> PV machine in fdt_find_uefi_params()?
Because the UEFI params for Dom0 are located under /hypervisor/uefi node
instead of /chosen. So it needs to check whether it's a Dom0 then search
and parse different node with different params arrays.
> Can't you infer that from the DT
> params you discover?
>
> I could understand maybe only accepting the "xen,uefi-system-table"
> property if IS_ENABLED(CONFIG_XEN) but surely you don't also need to
> filter based on whether you're booting a PV kernel?
>
> Let me put it this way: when would you see "xen,uefi-system-table" and
> *not* be booting a PV kernel?
So it still needs add another check to firstly parse the fdt to see if
there is "xen,uefi-system-table" under /hypervisor/uefi node, right? I
think it's a bit redundant compared with xen_initial_domain().
Thanks,
--
Shannon
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Matt Fleming @ 2016-04-30 20:44 UTC (permalink / raw)
To: Shannon Zhao
Cc: Ard Biesheuvel, Stefano Stabellini, Ingo Molnar, Stephen Rothwell,
Luis R. Rodriguez, Jeremy Fitzhardinge, Konrad Rzeszutek Wilk,
Stefano Stabellini, Xen Devel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next,
linux-kernel@vger.kernel.org, Borislav Petkov
In-Reply-To: <5724BDD2.5020600@linaro.org>
On Sat, 30 Apr, at 10:14:42PM, Shannon Zhao wrote:
> Sure. How should I add this change? Rework this patch or add new one on
> top of it?
Rework this patch, please.
> Yes, in this patch we could set EFI_RUNTIME_SERVICES flag in
> fdt_find_hyper_node instead of setting EFI_PARAVIRT flag, and then bail
> out early in arm_enable_runtime_services() as you said. Then call
> xen_efi_runtime_setup() in xen_guest_init().
Sounds good.
> While I still have a question, in this patch we use
> efi_enabled(EFI_PARAVIRT) as a condition to make fdt_find_uefi_params()
> and efi_get_fdt_params() execute different ways. So it needs to find a
> new condition for that if we need to get rid of EFI_PARAVIRT. One I
> think is that xen_initial_domain() check. Is that fine?
Hmm... why do you actually need to check whether you're running on a
PV machine in fdt_find_uefi_params()? Can't you infer that from the DT
params you discover?
I could understand maybe only accepting the "xen,uefi-system-table"
property if IS_ENABLED(CONFIG_XEN) but surely you don't also need to
filter based on whether you're booting a PV kernel?
Let me put it this way: when would you see "xen,uefi-system-table" and
*not* be booting a PV kernel?
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Shannon Zhao @ 2016-04-30 14:14 UTC (permalink / raw)
To: Ard Biesheuvel, Matt Fleming
Cc: Stefano Stabellini, Ingo Molnar, Stephen Rothwell,
Luis R. Rodriguez, Jeremy Fitzhardinge, Konrad Rzeszutek Wilk,
Stefano Stabellini, Xen Devel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next,
linux-kernel@vger.kernel.org, Borislav Petkov
In-Reply-To: <CAKv+Gu_k45_r0mke6ELb3Pi05BnJiEMqweJRfsy7S55FzCpF7Q@mail.gmail.com>
On 2016年04月29日 22:53, Ard Biesheuvel wrote:
> On 29 April 2016 at 16:39, Matt Fleming <matt@codeblueprint.co.uk> wrote:
>> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
>>> On Fri, 29 Apr 2016, Ingo Molnar wrote:
>>>> Also, it would be nice to have all things EFI in a single tree, the conflicts are
>>>> going to be painful! There's very little reason not to carry this kind of commit:
>>>>
>>>> arch/arm/xen/enlighten.c | 6 +++++
>>>> drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
>>>> drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
>>>> 3 files changed, 56 insertions(+), 12 deletions(-)
>>>>
>>>> in the EFI tree.
>>>
>>> That's true. I'll drop this commit from xentip and let Matt pick it up
>>> or request changes as he sees fit.
>>
>> One small change I think would be sensible to make is to expand
>> EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
>> Xen, and in the process, to delete EFI_PARAVIRT.
>>
Sure. How should I add this change? Rework this patch or add new one on
top of it?
>> That should address Ingo's major concern, and also make it much easier
>> to rework the code in a piecemeal fashion.
>>
>> Could somebody enumerate the things that make Xen (dom0) different on
>> arm* compared with bare metal EFI boot? The list I made for x86 was,
>>
>> 1. Has no EFI memory map
>> 2. Runtime regions do not need to be mapped
>> 3. Cannot call SetVirtualAddressMap()
>> 4. /sys/firmware/efi/fw_vendor is invisible
>>
>> The first maps to not setting EFI_MEMMAP, the second to not setting
>> EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
>> to efi.flags that should cover everything on x86. Does arm* require
>> anything else?
>
> I already proposed when this patch was first under review to make the
> arm_enable_runtime_services() function bail early without error if the
> EFI_RUNTIME_SERVICES flag is already set, and the xen code could set
> that bit as well when it installs its paravirtualized alternatives. I
> don't remember exactly why that was shot down, though, but I think it
> is the only reason this code introduces references to EFI_PARAVIRT in
> the first place.
>
Yes, in this patch we could set EFI_RUNTIME_SERVICES flag in
fdt_find_hyper_node instead of setting EFI_PARAVIRT flag, and then bail
out early in arm_enable_runtime_services() as you said. Then call
xen_efi_runtime_setup() in xen_guest_init().
While I still have a question, in this patch we use
efi_enabled(EFI_PARAVIRT) as a condition to make fdt_find_uefi_params()
and efi_get_fdt_params() execute different ways. So it needs to find a
new condition for that if we need to get rid of EFI_PARAVIRT. One I
think is that xen_initial_domain() check. Is that fine?
Thanks,
--
Shannon
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Shannon Zhao @ 2016-04-30 14:04 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Matt Fleming, Ingo Molnar, Stephen Rothwell, Luis R. Rodriguez,
Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, Stefano Stabellini,
Xen Devel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Ard Biesheuvel,
Borislav Petkov
In-Reply-To: <alpine.DEB.2.10.1604291634000.3312@sstabellini-ThinkPad-X260>
On 2016年04月29日 23:37, Stefano Stabellini wrote:
> On Fri, 29 Apr 2016, Stefano Stabellini wrote:
>> On Fri, 29 Apr 2016, Matt Fleming wrote:
>>> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
>>>> On Fri, 29 Apr 2016, Ingo Molnar wrote:
>>>>> Also, it would be nice to have all things EFI in a single tree, the conflicts are
>>>>> going to be painful! There's very little reason not to carry this kind of commit:
>>>>>
>>>>> arch/arm/xen/enlighten.c | 6 +++++
>>>>> drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
>>>>> drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
>>>>> 3 files changed, 56 insertions(+), 12 deletions(-)
>>>>>
>>>>> in the EFI tree.
>>>>
>>>> That's true. I'll drop this commit from xentip and let Matt pick it up
>>>> or request changes as he sees fit.
>>>
>>> One small change I think would be sensible to make is to expand
>>> EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
>>> Xen, and in the process, to delete EFI_PARAVIRT.
>>>
>>> That should address Ingo's major concern, and also make it much easier
>>> to rework the code in a piecemeal fashion.
>>>
>>> Could somebody enumerate the things that make Xen (dom0) different on
>>> arm* compared with bare metal EFI boot? The list I made for x86 was,
>>>
>>> 1. Has no EFI memory map
>>> 2. Runtime regions do not need to be mapped
>>> 3. Cannot call SetVirtualAddressMap()
>>> 4. /sys/firmware/efi/fw_vendor is invisible
>>>
>>> The first maps to not setting EFI_MEMMAP, the second to not setting
>>> EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
>>> to efi.flags that should cover everything on x86. Does arm* require
>>> anything else?
>>
>> Xen on ARM is different, the impact should be limited:
>>
>> - there are no BootServices (ExitBootServices has already been called)
>> - RuntimeServices go via hypercalls
>>
>> The UEFI memory map is still available at an address specified on device
>> tree like on native, but the compatibility string is different
>> ("xen,uefi-mmap-start") to clarify that we are booting on Xen rather
>> than native.
>>
>> That's pretty much it, Shannon please confirm.
>
> This is to say that Xen on ARM might only need EFI_RUNTIME.
>
Yes, it needs EFI_RUNTIME_SERVICES.
Thanks,
--
Shannon
^ permalink raw reply
* Re: linux-next: manual merge of the akpm-current tree with the gpio tree
From: Linus Walleij @ 2016-04-30 11:20 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Jiri Slaby
In-Reply-To: <20160427160646.486aa3fa@canb.auug.org.au>
On Wed, Apr 27, 2016 at 8:06 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/cris/Kconfig
>
> between commit:
>
> f518abf00d50 ("cris: do away with ARCH_REQUIRE_GPIOLIB")
>
> from the gpio tree and commit:
>
> 11eaeaeaa756 ("exit_thread: remove empty bodies")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Thanks!
> This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Hm I have the ACK of the CRIS maintainer on the patch to the
GPIO tree, is the left hand not aware what the right hand is doing :D
Anyway: this conflict looks very trivial so I believe Torvalds will
deal with it without problems.
Yours,
Linus Walleij
^ permalink raw reply
* Re: linux-next: build warning after merge of the akpm-current tree
From: Stephen Rothwell @ 2016-04-30 5:52 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Andrew Morton, linux-next, linux-kernel, Arnd Bergmann,
Quinn Tran
In-Reply-To: <20160429140342.ygb477u36ajmcoax@treble>
Hi Josh,
On Fri, 29 Apr 2016 09:03:42 -0500 Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Fri, Apr 29, 2016 at 08:32:19AM -0500, Josh Poimboeuf wrote:
> > On Fri, Apr 29, 2016 at 04:45:43PM +1000, Stephen Rothwell wrote:
> > > Hi Andrew,
> > >
> > > After merging the akpm-current tree, today's linux-next build (x86_64
> > > allmodconfig) produced this warning:
> > >
> > > drivers/scsi/ipr.c: In function 'ipr_show_device_id':
> > > drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
> > > len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
> > > ^
> > >
> > > Lots and lots like this :-(
> > >
> > > Probably introduced by commit
> > >
> > > eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
> > >
> > > I guess __builtin_bswap64() has type "unsigned long int" :-(
> >
> > Hm, I suppose this is cross-compiled on a powerpc host?
> >
> > We probably need to add a (__u64) cast to the return value of
> > __builtin_bswap64(), like:
> >
> > diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
> > index de56fd5..d737804 100644
> > --- a/include/uapi/linux/swab.h
> > +++ b/include/uapi/linux/swab.h
> > @@ -123,7 +123,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
> > * @x: value to byteswap
> > */
> > #ifdef __HAVE_BUILTIN_BSWAP64__
> > -#define __swab64(x) __builtin_bswap64((__u64)(x))
> > +#define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
> > #else
> > #define __swab64(x) \
> > (__builtin_constant_p((__u64)(x)) ? \
>
>
> Never mind about cross-compiling on powerpc, this has nothing to do with
> that. But the above patch does seem to fix it.
Thanks. I have added Andrew's tidied up version to linux-next to
replace the revert.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Stefano Stabellini @ 2016-04-29 15:37 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Matt Fleming, Ingo Molnar, Stephen Rothwell, Luis R. Rodriguez,
Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, Stefano Stabellini,
Xen Devel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Shannon Zhao,
Ard Biesheuvel, Borislav Petkov
In-Reply-To: <alpine.DEB.2.10.1604291547130.3312@sstabellini-ThinkPad-X260>
On Fri, 29 Apr 2016, Stefano Stabellini wrote:
> On Fri, 29 Apr 2016, Matt Fleming wrote:
> > On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
> > > On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > > > Also, it would be nice to have all things EFI in a single tree, the conflicts are
> > > > going to be painful! There's very little reason not to carry this kind of commit:
> > > >
> > > > arch/arm/xen/enlighten.c | 6 +++++
> > > > drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
> > > > drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
> > > > 3 files changed, 56 insertions(+), 12 deletions(-)
> > > >
> > > > in the EFI tree.
> > >
> > > That's true. I'll drop this commit from xentip and let Matt pick it up
> > > or request changes as he sees fit.
> >
> > One small change I think would be sensible to make is to expand
> > EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
> > Xen, and in the process, to delete EFI_PARAVIRT.
> >
> > That should address Ingo's major concern, and also make it much easier
> > to rework the code in a piecemeal fashion.
> >
> > Could somebody enumerate the things that make Xen (dom0) different on
> > arm* compared with bare metal EFI boot? The list I made for x86 was,
> >
> > 1. Has no EFI memory map
> > 2. Runtime regions do not need to be mapped
> > 3. Cannot call SetVirtualAddressMap()
> > 4. /sys/firmware/efi/fw_vendor is invisible
> >
> > The first maps to not setting EFI_MEMMAP, the second to not setting
> > EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
> > to efi.flags that should cover everything on x86. Does arm* require
> > anything else?
>
> Xen on ARM is different, the impact should be limited:
>
> - there are no BootServices (ExitBootServices has already been called)
> - RuntimeServices go via hypercalls
>
> The UEFI memory map is still available at an address specified on device
> tree like on native, but the compatibility string is different
> ("xen,uefi-mmap-start") to clarify that we are booting on Xen rather
> than native.
>
> That's pretty much it, Shannon please confirm.
This is to say that Xen on ARM might only need EFI_RUNTIME.
^ permalink raw reply
* Re: linux-next: Tree for Apr 29 (btrfs)
From: Randy Dunlap @ 2016-04-29 15:35 UTC (permalink / raw)
To: Stephen Rothwell, linux-next; +Cc: linux-kernel, linux-btrfs
In-Reply-To: <20160429171354.3b98c8f3@canb.auug.org.au>
On 04/29/16 00:13, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20160428:
>
on i386:
fs/built-in.o: In function `scrub_raid56_parity':
scrub.c:(.text+0x2d06fb): undefined reference to `__udivdi3'
--
~Randy
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Stefano Stabellini @ 2016-04-29 14:58 UTC (permalink / raw)
To: Matt Fleming
Cc: Stefano Stabellini, Ingo Molnar, Stephen Rothwell,
Luis R. Rodriguez, Jeremy Fitzhardinge, Konrad Rzeszutek Wilk,
Stefano Stabellini, Xen Devel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
Shannon Zhao, Ard Biesheuvel, Borislav Petkov
In-Reply-To: <20160429143931.GG2839@codeblueprint.co.uk>
On Fri, 29 Apr 2016, Matt Fleming wrote:
> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
> > On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > > Also, it would be nice to have all things EFI in a single tree, the conflicts are
> > > going to be painful! There's very little reason not to carry this kind of commit:
> > >
> > > arch/arm/xen/enlighten.c | 6 +++++
> > > drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
> > > drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
> > > 3 files changed, 56 insertions(+), 12 deletions(-)
> > >
> > > in the EFI tree.
> >
> > That's true. I'll drop this commit from xentip and let Matt pick it up
> > or request changes as he sees fit.
>
> One small change I think would be sensible to make is to expand
> EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
> Xen, and in the process, to delete EFI_PARAVIRT.
>
> That should address Ingo's major concern, and also make it much easier
> to rework the code in a piecemeal fashion.
>
> Could somebody enumerate the things that make Xen (dom0) different on
> arm* compared with bare metal EFI boot? The list I made for x86 was,
>
> 1. Has no EFI memory map
> 2. Runtime regions do not need to be mapped
> 3. Cannot call SetVirtualAddressMap()
> 4. /sys/firmware/efi/fw_vendor is invisible
>
> The first maps to not setting EFI_MEMMAP, the second to not setting
> EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
> to efi.flags that should cover everything on x86. Does arm* require
> anything else?
Xen on ARM is different, the impact should be limited:
- there are no BootServices (ExitBootServices has already been called)
- RuntimeServices go via hypercalls
The UEFI memory map is still available at an address specified on device
tree like on native, but the compatibility string is different
("xen,uefi-mmap-start") to clarify that we are booting on Xen rather
than native.
That's pretty much it, Shannon please confirm.
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Ard Biesheuvel @ 2016-04-29 14:53 UTC (permalink / raw)
To: Matt Fleming
Cc: Stefano Stabellini, Ingo Molnar, Stephen Rothwell,
Luis R. Rodriguez, Jeremy Fitzhardinge, Konrad Rzeszutek Wilk,
Stefano Stabellini, Xen Devel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next,
linux-kernel@vger.kernel.org, Shannon Zhao, Borislav Petkov
In-Reply-To: <20160429143931.GG2839@codeblueprint.co.uk>
On 29 April 2016 at 16:39, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
>> On Fri, 29 Apr 2016, Ingo Molnar wrote:
>> > Also, it would be nice to have all things EFI in a single tree, the conflicts are
>> > going to be painful! There's very little reason not to carry this kind of commit:
>> >
>> > arch/arm/xen/enlighten.c | 6 +++++
>> > drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
>> > drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
>> > 3 files changed, 56 insertions(+), 12 deletions(-)
>> >
>> > in the EFI tree.
>>
>> That's true. I'll drop this commit from xentip and let Matt pick it up
>> or request changes as he sees fit.
>
> One small change I think would be sensible to make is to expand
> EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
> Xen, and in the process, to delete EFI_PARAVIRT.
>
> That should address Ingo's major concern, and also make it much easier
> to rework the code in a piecemeal fashion.
>
> Could somebody enumerate the things that make Xen (dom0) different on
> arm* compared with bare metal EFI boot? The list I made for x86 was,
>
> 1. Has no EFI memory map
> 2. Runtime regions do not need to be mapped
> 3. Cannot call SetVirtualAddressMap()
> 4. /sys/firmware/efi/fw_vendor is invisible
>
> The first maps to not setting EFI_MEMMAP, the second to not setting
> EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
> to efi.flags that should cover everything on x86. Does arm* require
> anything else?
I already proposed when this patch was first under review to make the
arm_enable_runtime_services() function bail early without error if the
EFI_RUNTIME_SERVICES flag is already set, and the xen code could set
that bit as well when it installs its paravirtualized alternatives. I
don't remember exactly why that was shot down, though, but I think it
is the only reason this code introduces references to EFI_PARAVIRT in
the first place.
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Matt Fleming @ 2016-04-29 14:39 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Ingo Molnar, Stephen Rothwell, Luis R. Rodriguez,
Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, Stefano Stabellini,
Xen Devel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Shannon Zhao,
Ard Biesheuvel, Borislav Petkov
In-Reply-To: <alpine.DEB.2.10.1604291123260.3312@sstabellini-ThinkPad-X260>
On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
> On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > Also, it would be nice to have all things EFI in a single tree, the conflicts are
> > going to be painful! There's very little reason not to carry this kind of commit:
> >
> > arch/arm/xen/enlighten.c | 6 +++++
> > drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
> > drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
> > 3 files changed, 56 insertions(+), 12 deletions(-)
> >
> > in the EFI tree.
>
> That's true. I'll drop this commit from xentip and let Matt pick it up
> or request changes as he sees fit.
One small change I think would be sensible to make is to expand
EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
Xen, and in the process, to delete EFI_PARAVIRT.
That should address Ingo's major concern, and also make it much easier
to rework the code in a piecemeal fashion.
Could somebody enumerate the things that make Xen (dom0) different on
arm* compared with bare metal EFI boot? The list I made for x86 was,
1. Has no EFI memory map
2. Runtime regions do not need to be mapped
3. Cannot call SetVirtualAddressMap()
4. /sys/firmware/efi/fw_vendor is invisible
The first maps to not setting EFI_MEMMAP, the second to not setting
EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
to efi.flags that should cover everything on x86. Does arm* require
anything else?
^ permalink raw reply
* Re: linux-next: build warning after merge of the akpm-current tree
From: Josh Poimboeuf @ 2016-04-29 14:03 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Arnd Bergmann,
Quinn Tran
In-Reply-To: <20160429133219.bhu3picl6jwxdedj@treble>
On Fri, Apr 29, 2016 at 08:32:19AM -0500, Josh Poimboeuf wrote:
> On Fri, Apr 29, 2016 at 04:45:43PM +1000, Stephen Rothwell wrote:
> > Hi Andrew,
> >
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning:
> >
> > drivers/scsi/ipr.c: In function 'ipr_show_device_id':
> > drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
> > len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
> > ^
> >
> > Lots and lots like this :-(
> >
> > Probably introduced by commit
> >
> > eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
> >
> > I guess __builtin_bswap64() has type "unsigned long int" :-(
>
> Hm, I suppose this is cross-compiled on a powerpc host?
>
> We probably need to add a (__u64) cast to the return value of
> __builtin_bswap64(), like:
>
> diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
> index de56fd5..d737804 100644
> --- a/include/uapi/linux/swab.h
> +++ b/include/uapi/linux/swab.h
> @@ -123,7 +123,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
> * @x: value to byteswap
> */
> #ifdef __HAVE_BUILTIN_BSWAP64__
> -#define __swab64(x) __builtin_bswap64((__u64)(x))
> +#define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
> #else
> #define __swab64(x) \
> (__builtin_constant_p((__u64)(x)) ? \
Never mind about cross-compiling on powerpc, this has nothing to do with
that. But the above patch does seem to fix it.
--
Josh
^ permalink raw reply
* Re: linux-next: build warning after merge of the akpm-current tree
From: Josh Poimboeuf @ 2016-04-29 13:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Arnd Bergmann,
Quinn Tran
In-Reply-To: <20160429164543.039df436@canb.auug.org.au>
On Fri, Apr 29, 2016 at 04:45:43PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/scsi/ipr.c: In function 'ipr_show_device_id':
> drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
> len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
> ^
>
> Lots and lots like this :-(
>
> Probably introduced by commit
>
> eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
>
> I guess __builtin_bswap64() has type "unsigned long int" :-(
Hm, I suppose this is cross-compiled on a powerpc host?
We probably need to add a (__u64) cast to the return value of
__builtin_bswap64(), like:
diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
index de56fd5..d737804 100644
--- a/include/uapi/linux/swab.h
+++ b/include/uapi/linux/swab.h
@@ -123,7 +123,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
* @x: value to byteswap
*/
#ifdef __HAVE_BUILTIN_BSWAP64__
-#define __swab64(x) __builtin_bswap64((__u64)(x))
+#define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
#else
#define __swab64(x) \
(__builtin_constant_p((__u64)(x)) ? \
--
Josh
^ permalink raw reply related
* next-20160429 build: 1 failures 14 warnings (next-20160429)
From: Build bot for Mark Brown @ 2016-04-29 11:59 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, linux-next
Tree/Branch: next-20160429
Git describe: next-20160429
Commit: 3111f3fff0 Add linux-next specific files for 20160429
Build Time: 94 min 14 sec
Passed: 8 / 9 ( 88.89 %)
Failed: 1 / 9 ( 11.11 %)
Errors: 1
Warnings: 14
Section Mismatches: 0
Failed defconfigs:
arm-allmodconfig
Errors:
arm-allmodconfig
ERROR: "__aeabi_uldivmod" [fs/btrfs/btrfs.ko] undefined!
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
8 warnings 0 mismatches : arm64-allmodconfig
5 warnings 0 mismatches : arm-multi_v7_defconfig
11 warnings 0 mismatches : arm-allmodconfig
2 warnings 0 mismatches : arm-multi_v5_defconfig
3 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Errors summary: 1
1 ERROR: "__aeabi_uldivmod" [fs/btrfs/btrfs.ko] undefined!
Warnings Summary: 14
5 ../include/linux/export.h:63:25: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
5 ../drivers/regulator/core.c:2536:1: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
3 ../drivers/gpu/drm/msm/msm_drv.c:468:18: warning: unused variable 'kms' [-Wunused-variable]
3 ../drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:181:3: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
3 ../drivers/gpu/drm/msm/dsi/dsi_host.c:329:3: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
2 ../drivers/pinctrl/sh-pfc/core.c:603:17: warning: unused variable 'pfc' [-Wunused-variable]
1 ../lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1472 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../include/soc/nps/common.h:162:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../include/soc/nps/common.h:148:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../include/linux/cpumask.h:550:25: warning: passing argument 2 of 'dev_pm_opp_set_sharing_cpus' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
1 ../drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../drivers/gpu/drm/omapdrm/dss/hdmi5.c:134:2: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
1 ../drivers/gpu/drm/omapdrm/dss/hdmi4.c:117:2: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
1 ../drivers/gpu/drm/omapdrm/dss/dsi.c:1183:2: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 8 warnings, 0 section mismatches
Warnings:
../drivers/gpu/drm/msm/msm_drv.c:468:18: warning: unused variable 'kms' [-Wunused-variable]
../drivers/gpu/drm/msm/dsi/dsi_host.c:329:3: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:181:3: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../include/soc/nps/common.h:148:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../include/soc/nps/common.h:162:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../drivers/pinctrl/sh-pfc/core.c:603:17: warning: unused variable 'pfc' [-Wunused-variable]
../drivers/regulator/core.c:2536:1: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../include/linux/export.h:63:25: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings:
../drivers/gpu/drm/msm/msm_drv.c:468:18: warning: unused variable 'kms' [-Wunused-variable]
../drivers/gpu/drm/msm/dsi/dsi_host.c:329:3: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:181:3: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../drivers/regulator/core.c:2536:1: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../include/linux/export.h:63:25: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 1 errors, 11 warnings, 0 section mismatches
Errors:
ERROR: "__aeabi_uldivmod" [fs/btrfs/btrfs.ko] undefined!
Warnings:
../lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1472 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../include/linux/cpumask.h:550:25: warning: passing argument 2 of 'dev_pm_opp_set_sharing_cpus' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
../drivers/gpu/drm/msm/msm_drv.c:468:18: warning: unused variable 'kms' [-Wunused-variable]
../drivers/gpu/drm/msm/dsi/dsi_host.c:329:3: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:181:3: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../drivers/gpu/drm/omapdrm/dss/dsi.c:1183:2: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../drivers/gpu/drm/omapdrm/dss/hdmi4.c:117:2: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../drivers/gpu/drm/omapdrm/dss/hdmi5.c:134:2: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../drivers/regulator/core.c:2536:1: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../include/linux/export.h:63:25: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../drivers/regulator/core.c:2536:1: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../include/linux/export.h:63:25: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
../drivers/pinctrl/sh-pfc/core.c:603:17: warning: unused variable 'pfc' [-Wunused-variable]
../drivers/regulator/core.c:2536:1: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
../include/linux/export.h:63:25: warning: 'regulator_can_change_voltage' is deprecated [-Wdeprecated-declarations]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
x86_64-allnoconfig
arm64-allnoconfig
arm-allnoconfig
x86_64-defconfig
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Ingo Molnar @ 2016-04-29 10:46 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Stephen Rothwell, Luis R. Rodriguez, Matt Fleming,
Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, Stefano Stabellini,
Xen Devel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Shannon Zhao,
Ard Biesheuvel, Borislav Petkov
In-Reply-To: <alpine.DEB.2.10.1604291123260.3312@sstabellini-ThinkPad-X260>
* Stefano Stabellini <sstabellini@kernel.org> wrote:
> On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > Also, it would be nice to have all things EFI in a single tree, the conflicts are
> > going to be painful! There's very little reason not to carry this kind of commit:
> >
> > arch/arm/xen/enlighten.c | 6 +++++
> > drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
> > drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
> > 3 files changed, 56 insertions(+), 12 deletions(-)
> >
> > in the EFI tree.
>
> That's true. I'll drop this commit from xentip and let Matt pick it up
> or request changes as he sees fit.
Thanks!
Ingo
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Stefano Stabellini @ 2016-04-29 10:34 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Luis R. Rodriguez, Matt Fleming,
Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, Stefano Stabellini,
Xen Devel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Shannon Zhao,
Ard Biesheuvel, Borislav Petkov
In-Reply-To: <20160429063936.GA28320@gmail.com>
On Fri, 29 Apr 2016, Ingo Molnar wrote:
> Also, it would be nice to have all things EFI in a single tree, the conflicts are
> going to be painful! There's very little reason not to carry this kind of commit:
>
> arch/arm/xen/enlighten.c | 6 +++++
> drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
> drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
> 3 files changed, 56 insertions(+), 12 deletions(-)
>
> in the EFI tree.
That's true. I'll drop this commit from xentip and let Matt pick it up
or request changes as he sees fit.
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Matt Fleming @ 2016-04-29 9:26 UTC (permalink / raw)
To: Borislav Petkov
Cc: Ingo Molnar, Stephen Rothwell, Luis R. Rodriguez,
Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, Stefano Stabellini,
Xen Devel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Shannon Zhao,
Ard Biesheuvel
In-Reply-To: <20160429082501.GA20762@pd.tnic>
On Fri, 29 Apr, at 10:25:02AM, Borislav Petkov wrote:
> On Fri, Apr 29, 2016 at 08:39:36AM +0200, Ingo Molnar wrote:
> > With considerable pain we just got rid of paravirt_enabled() in the
> > x86 tree, and Xen is now reintroducing it in the EFI code.
>
> I think Matt is working towards removing EFI_PARAVIRT but he'll comment
> himself when he wakes up... :)
Yeah, I haven't actually got around to dropping EFI_PARAVIRT yet but
since it's basically used to skip certain initialisation operations on
boot I figured we could just provide empty stub functions as part of
struct efi (probably).
The concerns Ingo voiced about EFI_PARAVIRT being a catch-all flag are
very true.
Incidentally kexec and arm64 would need a similar stub functions if we
move more EFI runtime setup code to drivers/firmware/efi, which is my
long-term plan, since neither can call SetVirtualAddressMap().
On x86, I think EFI_PARAVIRT is code for,
1. Has no EFI memory map
2. Runtime regions do not need to be mapped
3. Cannot call SetVirtualAddressMap()
4. /sys/firmware/efi/fw_vendor is invisible
1. and 2. should be covered by never setting EFI_MEMMAP and
EFI_RUNTIME_SERVICES in efi.flags. We have no bits for 3. and 4. yet.
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the arm64 tree
From: Matt Fleming @ 2016-04-29 9:04 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Catalin Marinas, linux-next, linux-kernel, Ard Biesheuvel,
Arnd Bergmann, Will Deacon
In-Reply-To: <20160429135645.20e288dd@canb.auug.org.au>
On Fri, 29 Apr, at 01:56:45PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/firmware/efi/arm-init.c
>
> between commits:
>
> 500899c2cc3e ("efi: ARM/arm64: ignore DT memory nodes instead of removing them")
> 7464b6e3a5fb ("efi: ARM: avoid warning about phys_addr_t cast")
>
> from the arm64 tree and commits:
>
> 78ce248faa3c ("efi: Iterate over efi.memmap in for_each_efi_memory_desc()")
> 884f4f66ffd6 ("efi: Remove global 'memmap' EFI memory map")
>
> from the tip tree.
[...]
> diff --cc drivers/firmware/efi/arm-init.c
> index fac567c3b66a,ef90f0c4b70a..000000000000
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@@ -143,15 -178,7 +178,15 @@@ static __init void reserve_regions(void
> if (efi_enabled(EFI_DBG))
> pr_info("Processing EFI memory map:\n");
>
> + /*
> + * Discard memblocks discovered so far: if there are any at this
> + * point, they originate from memory nodes in the DT, and UEFI
> + * uses its own memory map instead.
> + */
> + memblock_dump_all();
> + memblock_remove(0, (phys_addr_t)ULLONG_MAX);
> +
> - for_each_efi_memory_desc(&memmap, md) {
> + for_each_efi_memory_desc(md) {
> paddr = md->phys_addr;
> npages = md->num_pages;
>
This looks fine, thanks Stephen.
^ permalink raw reply
* Re: linux-next: manual merge of the arm64 tree with Linus' tree
From: Will Deacon @ 2016-04-29 8:49 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Catalin Marinas, linux-next, linux-kernel, Sudeep Holla,
Christoffer Dall, AKASHI Takahiro, james.morse
In-Reply-To: <20160429095958.007976da@canb.auug.org.au>
On Fri, Apr 29, 2016 at 09:59:58AM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got a conflict in:
>
> arch/arm/kvm/arm.c
>
> between commit:
>
> 06a71a24bae5 ("arm64: KVM: unregister notifiers in hyp mode teardown path")
>
> from Linus' tree and commit:
>
> 67f691976662 ("arm64: kvm: allows kvm cpu hotplug")
>
> from the arm64 tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm/kvm/arm.c
> index dded1b763c16,1687e1450c3a..000000000000
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@@ -1198,8 -1226,6 +1233,7 @@@ static void teardown_hyp_mode(void
> free_hyp_pgds();
> for_each_possible_cpu(cpu)
> free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
> - unregister_cpu_notifier(&hyp_init_cpu_nb);
> + hyp_cpu_pm_exit();
> }
>
> static int init_vhe_mode(void)
Thanks Stephen, this looks good to me.
Will
^ permalink raw reply
* Re: efi_enabled(EFI_PARAVIRT) use
From: Borislav Petkov @ 2016-04-29 8:25 UTC (permalink / raw)
To: Ingo Molnar, Matt Fleming
Cc: Stephen Rothwell, Luis R. Rodriguez, Jeremy Fitzhardinge,
Konrad Rzeszutek Wilk, Stefano Stabellini, Xen Devel,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel, Shannon Zhao, Ard Biesheuvel
In-Reply-To: <20160429063936.GA28320@gmail.com>
On Fri, Apr 29, 2016 at 08:39:36AM +0200, Ingo Molnar wrote:
> With considerable pain we just got rid of paravirt_enabled() in the
> x86 tree, and Xen is now reintroducing it in the EFI code.
I think Matt is working towards removing EFI_PARAVIRT but he'll comment
himself when he wakes up... :)
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
^ permalink raw reply
* linux-next: Tree for Apr 29
From: Stephen Rothwell @ 2016-04-29 7:13 UTC (permalink / raw)
To: linux-next; +Cc: linux-kernel
Hi all,
Changes since 20160428:
The arm64 tree gained a conflict against Linus' tree.
The pm tree gained a conflict against the arm-soc tree.
The tpmdd tree still had its build failure for which I added a fix patch.
The tip tree gained a conflict against the arm64 tree.
The xen-tip tree gained a conflict against the tip tree.
The akpm-current tree gained conflicts against the tile and tip trees
and I reverted a commit that produced many new warnings.
Non-merge commits (relative to Linus' tree): 6770
6109 files changed, 255051 insertions(+), 125899 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.
Below is a summary of the state of the merge.
I am currently merging 234 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (b75a2bf899b6 Merge branch 'for-4.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install)
Merging arc-current/for-curr (1b10cb21d888 ARC: add support for reserved memory defined by device tree)
Merging arm-current/fixes (ac36a881b72a ARM: 8564/1: fix cpu feature extracting helper)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors)
Merging powerpc-fixes/fixes (d701cca6744f powerpc: wire up preadv2 and pwritev2 syscalls)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (49fa5230462f sparc64: Fix bootup regressions on some Kconfig combinations.)
Merging net/master (1dfcd832b1a9 Merge branch 'bpf-fixes')
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (bcf493428840 netfilter: ebtables: Fix extension lookup with identical name)
Merging wireless-drivers/master (e2841ea91611 Merge tag 'iwlwifi-for-kalle-2016-04-12_2' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if dev_alloc_name() fails)
Merging sound-current/for-linus (af9cc93c0dee Merge tag 'asoc-fix-v4.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (67e658794ca1 cxgb4: Set VPD size so we can read both VPD structures)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (02da2d72174c Linux 4.6-rc5)
Merging usb.current/usb-linus (97b9b7dc7722 usb: musb: jz4740: fix error check of usb_get_phy())
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix use-after-free)
Merging usb-serial-fixes/usb-linus (613ac23a46e1 USB: serial: cp210x: add Straizona Focusers device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (431adc0aeca6 Merge tag 'iio-fixes-for-4.6c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (82dc4afd7e65 misc: mic: Fix for double fetch security bug in VOP driver)
Merging input-current/for-linus (eb43335c4095 Input: atmel_mxt_ts - use mxt_acquire_irq in mxt_soft_reset)
Merging crypto-current/master (9e209fcfb804 crypto: qat - fix invalid pf2vf_resp_wq logic)
Merging ide/master (1993b176a822 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling)
Merging kselftest-fixes/fixes (505ce68c6da3 selftest/seccomp: Fix the seccomp(2) signature)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have branch tracer use recursive field of task struct)
Merging mfd-fixes/for-mfd-fixes (1b52e50f2a40 mfd: max77843: Fix max77843_chg_init() return on error)
Merging drm-intel-fixes/for-linux-next-fixes (4ea3959018d0 drm/i915: Make RPS EI/thresholds multiple of 25 on SNB-BDW)
Merging asm-generic/master (987aedb5d6f6 generic syscalls: wire up preadv2 and pwritev2 syscalls)
Merging arc/for-next (767cb9d8abfa ARC: Add eznps platform to Kconfig and Makefile)
Merging arm/for-next (c6433ebdc184 Merge branch 'devel-stable' into for-next)
Merging arm-perf/for-next/perf (4ba2578fa7b5 arm64: perf: don't expose CHAIN event in sysfs)
Merging arm-soc/for-next (71085229c8e1 arm-soc: describe merges)
Merging at91/at91-next (1e12a77f8a5d Merge tags 'at91-soc' and 'at91-dt2' into at91-next)
Merging bcm2835-dt/bcm2835-dt-next (896ad420db8d dt/bindings: bcm2835: correct description for DMA-int)
Merging bcm2835-soc/bcm2835-soc-next (92e963f50fc7 Linux 4.5-rc1)
Merging bcm2835-drivers/bcm2835-drivers-next (92e963f50fc7 Linux 4.5-rc1)
Merging bcm2835-defconfig/bcm2835-defconfig-next (3652bb35abf6 ARM: bcm2835: Enable NFS root support.)
Merging berlin/berlin/for-next (9a7e06833249 Merge branch 'berlin/fixes' into berlin/for-next)
Merging cortex-m/for-next (f719a0d6a854 ARM: efm32: switch to vendor,device compatible strings)
Merging imx-mxs/for-next (ca2c44b4980c Merge branch 'imx/defconfig64' into for-next)
Merging keystone/next (02e15d234006 Merge branch 'for_4.7/kesytone' into next)
Merging mvebu/for-next (21263e08826d Merge branch 'mvebu/defconfig' into mvebu/for-next)
Merging omap/for-next (5c62bda50efd Merge branch 'omap-for-v4.7/dt' into for-next)
Merging omap-pending/for-next (c20c8f750d9f ARM: OMAP2+: hwmod: fix _idle() hwmod state sanity check sequence)
Merging qcom/for-next (100b83d52f51 ARM: dts: msm8974: Add SCM firmware node)
Merging renesas/next (e5c640c6f9cc Merge branches 'heads/arm64-defconfig-for-v4.7', 'heads/arm64-dt-pm-domain-for-v4.7', 'heads/dt-for-v4.7' and 'heads/pci-defconfig-for-v4.7' into next)
Merging rockchip/for-next (48f2a282081f Merge branch 'v4.7-clk/next' into for-next)
Merging rpi/for-rpi-next (bc0195aad0da Linux 4.2-rc2)
Merging samsung/for-next (92e963f50fc7 Linux 4.5-rc1)
Merging samsung-krzk/for-next (be28390fe8f5 Merge branch 'fixes' into for-next)
Merging sunxi/sunxi/for-next (f1e9b6675c26 Merge branches 'sunxi/clocks-for-4.7', 'sunxi/dt-for-4.7' and 'sunxi/fixes-for-4.6' into sunxi/for-next)
Merging tegra/for-next (fe34d567f1f3 Merge branch for-4.7/gm20b into for-next)
Merging arm64/for-next/core (6f26b3671184 arm64: kaslr: increase randomization granularity)
CONFLICT (content): Merge conflict in arch/arm/kvm/arm.c
Merging blackfin/for-linus (391e74a51ea2 eth: bf609 eth clock: add pclk clock for stmmac driver probe)
CONFLICT (content): Merge conflict in arch/blackfin/mach-common/pm.c
Merging c6x/for-linux-next (ca3060d39ae7 c6x: Use generic clkdev.h header)
Merging cris/for-next (f9f3f864b5e8 cris: Fix section mismatches in architecture startup code)
Merging h8300/h8300-next (8cad489261c5 h8300: switch EARLYCON)
Merging hexagon/linux-next (02cc2ccfe771 Revert "Hexagon: fix signal.c compile error")
Merging ia64/next (7e26e9ff0a93 pstore: Fix return type of pstore_is_mounted())
Merging m68k/for-next (efbec135f11d m68k: Fix misspellings in comments.)
Merging m68knommu/for-next (02da2d72174c Linux 4.6-rc5)
Merging metag/for-next (c8b6ad8b3f87 metag: ftrace: remove the misleading comment for ftrace_dyn_arch_init)
Merging microblaze/next (10f4b26deb41 microblaze/PCI: export isa_io_base to fix link errors)
Merging mips/mips-for-linux-next (7620fecf8342 Merge branch '4.6-fixes' into mips-for-linux-next)
Merging nios2/for-next (a8950e49bd24 nios2: memset: use the right constraint modifier for the %4 output operand)
Merging parisc-hd/for-next (695499920489 parisc: Add native high-resolution sched_clock() implementation)
Merging powerpc/next (5bcca743cb6e powerpc/perf: Replace raw event hex values with #defines)
Merging powerpc-mpe/next (bc0195aad0da Linux 4.2-rc2)
Merging fsl/next (fba4e9f9898a powerpc/fsl/dts: Add "jedec,spi-nor" flash compatible)
Merging mpc5xxx/next (39e69f55f857 powerpc: Introduce the use of the managed version of kzalloc)
Merging s390/features (7072276e6c0e s390/Kconfig: make z196 the default processor type)
Merging sparc-next/master (9f935675d41a Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging tile/master (4ef00aa30a3f tile: sort the "select" lines in the TILE/TILEGX configs)
Merging uml/linux-next (ad32a1f3c36b um: use %lx format specifiers for unsigned longs)
Merging unicore32/unicore32 (d670878e2c9a unicore32: Remove ARCH_HAS_CPUFREQ config option)
Merging xtensa/for_next (9da8320bb977 xtensa: add test_kc705_hifi variant)
Merging btrfs/next (bb7ab3b92e46 btrfs: Fix misspellings in comments.)
Merging btrfs-kdave/for-next (bd3fc9c6d3c0 Merge branch 'for-next-current-4.7-20160428' into for-next-20160428)
Merging ceph/master (d3767f0faeda rbd: report unsupported features to syslog)
Merging cifs/for-next (2b6c3239da3f cifs: remove any preceding delimiter from prefix_path)
Merging configfs/for-next (96c22a329351 configfs: fix CONFIGFS_BIN_ATTR_[RW]O definitions)
Merging ecryptfs/next (933c32fe0e42 ecryptfs: drop null test before destroy functions)
Merging ext3/for_next (2a28900be206 udf: Export superblock magic to userspace)
Merging ext4/dev (8f4c50d70cc1 ext4: remove trailing \n from ext4_warning/ext4_error calls)
Merging f2fs/dev (aca9958e97b7 ext4 crypto: migrate into vfs's crypto engine)
Merging fscache/fscache (b00c2ae2ed3c FS-Cache: Don't override netfs's primary_index if registering failed)
Merging fuse/for-next (2c932d4c9165 fuse: Fix return value from fuse_get_user_pages())
Merging gfs2/for-next (9c7fe83530a3 GFS2: Add calls to gfs2_holder_uninit in two error handlers)
Merging jfs/jfs-next (6ed71e9819ac jfs: Coalesce some formats)
Merging nfs/linux-next (02da2d72174c Linux 4.6-rc5)
Merging nfsd/nfsd-next (ac503e4a309a nfsd: use short read as well as i_size to set eof)
Merging orangefs/for-next (e56f49814250 orangefs: remove unused variable)
Merging overlayfs/overlayfs-next (e3608e3f68f6 Btrfs: fix crash/invalid memory access on fsync when using overlayfs)
CONFLICT (content): Merge conflict in fs/ext4/file.c
Merging v9fs/for-next (a333e4bf2556 fs/9p: use fscache mutex rather than spinlock)
Merging ubifs/linux-next (c27cb97218b3 ubifs: Remove unused header)
Merging xfs/for-next (d8bdd04e309b Merge branch 'xfs-4.7-misc-fixes' into for-next)
Merging file-locks/linux-next (5af9c2e19da6 Merge branch 'akpm' (patches from Andrew))
Merging vfs/for-next (489eda8cd1a6 Merge branches 'work.acl', 'work.const-path' and 'work.misc' into for-next)
Merging pci/next (a8dd1a5cd502 Merge branches 'pci/host-designware', 'pci/host-imx6', 'pci/host-mvebu' and 'pci/host-vmd' into next)
Applying: iommu/amd: fix up for aliases API change
Merging hid/for-next (a299086f23d1 Merge branch 'for-4.7/upstream' into for-next)
Merging i2c/i2c/for-next (b3b859225348 Merge branch 'i2c/for-4.7' into i2c/for-next)
Merging jdelvare-hwmon/master (f02de116250d Documentation/hwmon: Update links in max34440)
Merging dmi/master (c3db05ecf8ac firmware: dmi_scan: Save SMBIOS Type 9 System Slots)
Merging hwmon-staging/hwmon-next (71a9c23246fe hwmon: (it87) Add support for IT8628E)
Merging v4l-dvb/master (dcb7c0b9e2ad Merge branch 'patchwork' into to_next)
Merging libata/for-next (c5cf484d03f1 Merge branch 'for-4.6-fixes' into for-next)
Merging pm/linux-next (1fc5f4aa1f65 Merge branch 'device-properties-fixes' into linux-next)
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/Makefile
CONFLICT (content): Merge conflict in MAINTAINERS
Merging idle/next (f55532a0c0b8 Linux 4.6-rc1)
Merging thermal/next (81ad4276b505 Thermal: Ignore invalid trip points)
Merging thermal-soc/next (ddc8fdc6e2f0 Merge branch 'work-fixes' into work-next)
Merging ieee1394/for-next (384fbb96f926 firewire: nosy: Replace timeval with timespec64)
Merging dlm/next (82c7d823cc31 dlm: config: Fix ENOMEM failures in make_cluster())
Merging swiotlb/linux-next (386744425e35 swiotlb: Make linux/swiotlb.h standalone includible)
Merging slave-dma/next (6ebe83cb5b65 Merge branch 'topic/pxa' into next)
Merging net-next/master (494e8489db50 ipvlan: Fix failure path in dev registration during link creation)
Merging ipsec-next/master (cb866e3298cd xfrm: Increment statistic counter on inner mode error)
Merging ipvs-next/master (8fb04d9fc70a ipvs: don't alter conntrack in OPS mode)
Merging wireless-drivers-next/master (9d3f65b0c2dd mwifiex: increase dwell time for active scan)
Merging bluetooth/master (50d5d2bd1d42 Merge branch 'sh_eth-next')
Merging mac80211-next/master (d686b920abb7 nl80211: use nla_put_u64_64bit() for the remaining u64 attributes)
Merging rdma/for-next (520a07bff6fb Merge branches 'i40iw', 'sriov' and 'hfi1' into k.o/for-4.6)
Merging rdma-leon/rdma-next (c3b46c73264b Linux 4.6-rc4)
Merging rdma-leon-test/testing/rdma-next (c3b46c73264b Linux 4.6-rc4)
Merging mtd/master (20c07a5bf094 mtd: nand: Drop mtd.owner requirement in nand_scan)
Merging l2-mtd/master (abbbc60a0c69 mtd: pmc551: add __init attribute)
Merging nand/nand/next (4ab41e74ae5d mtd: brcmnand: respect ECC algorithm set by NAND subsystem)
Merging crypto/master (d1497977fecb crypto: s5p-sss - fix incorrect usage of scatterlists api)
Merging drm/drm-next (152ef5fa9e14 drm: Switch blobs to the new generic modeset obj refcounting)
Applying: drm/i915: fix up for edp_low_vswing change
Merging drm-panel/drm/panel/for-next (1ac3bac7c733 drm/panel: simple: Add support for Innolux AT070TN92)
Merging drm-intel/for-linux-next (5b4fd5b1111b drm/i915: Update DRIVER_DATE to 20160425)
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_ringbuffer.c
Merging drm-tegra/drm/tegra/for-next (3a9b33c6048a drm/tegra: Don't set a gamma table size)
Merging drm-misc/topic/drm-misc (36230cb5668c drm/dp: Allow signals to interrupt drm_aux-dev reads/writes)
Merging drm-exynos/exynos-drm/for-next (25364a9e54fb Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid)
Merging drm-msm/msm-next (fcda50c8f484 drm/msm: rename hdmi symbols)
Merging hdlcd/for-upstream/hdlcd (69c2565a3cca drm: ARM HDLCD - fix an error code)
Merging drm-vc4/drm-vc4-next (5883980313af drm/vc4: Fix NULL deref in HDMI init error path)
Merging kbuild/for-next (7eb09bb55394 Merge branch 'kbuild/kbuild' into kbuild/for-next)
Merging kconfig/for-next (5bcba792bb30 localmodconfig: Fix whitespace repeat count after "tristate")
Merging regmap/for-next (8eabbbb9c0c9 Merge remote-tracking branches 'regmap/topic/doc' and 'regmap/topic/flat' into regmap-next)
Merging sound/for-next (a33d59599653 Merge branch 'for-linus' into for-next)
Merging sound-asoc/for-next (428a3bb0133e Merge remote-tracking branches 'asoc/topic/tlv320aic31xx', 'asoc/topic/tlv320aic32x4', 'asoc/topic/topology', 'asoc/topic/wm8960' and 'asoc/topic/wm8962' into asoc-next)
Merging modules/modules-next (e2d1248432c4 module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled)
Merging input/next (9e4cc255e6e1 Input: twl6040-vibra - remove mutex)
Merging block/for-next (783f8d0af678 Merge branch 'for-4.7/drivers' into for-next)
Merging device-mapper/for-next (3ff6a535b994 dm mpath: eliminate use of spinlock in IO fast-paths)
Merging pcmcia/master (e8e68fd86d22 pcmcia: do not break rsrc_nonstatic when handling anonymous cards)
Merging mmc-uh/next (b941a0e9598e mmc: sdhci-of-arasan: fix set_clock when a phy is supported)
Merging md/for-next (9c573de3283a MD: make bio mergeable)
Merging mfd/for-mfd-next (ba5776ab6f09 mfd: cros_ec: Allow building for ARM64)
Merging backlight/for-backlight-next (60d613d6aef4 backlight: pwm_bl: Free PWM requested by legacy API on error path)
Merging battery/master (4a99fa06a8ca sbs-battery: fix power status when battery charging near dry)
Merging omap_dss2/for-next (32ad61951574 video: fbdev: sis: remove unused variable)
Merging regulator/for-next (aec879a0b98b Merge remote-tracking branches 'regulator/topic/tps6524x' and 'regulator/topic/twl' into regulator-next)
Merging security/next (da20dfe6b50e fs: fix over-zealous use of "const")
Merging integrity/next (f5f8f020b2da ima: add support for creating files using the mknodat syscall)
Merging keys/keys-next (1ea6102bba5f Merge branch 'keys-trust' into keys-next)
CONFLICT (content): Merge conflict in crypto/asymmetric_keys/pkcs7_parser.c
Merging selinux/next (c2316dbf1242 selinux: apply execstack check on thread stacks)
Merging tpmdd/next (c5f074b23a79 tpm: Fix IRQ unwind ordering in TIS)
Applying: tpm: fix for typo in tpm/tpm_ibmvtpm.c
Merging watchdog/master (d1ed3ba4e3d7 watchdog: Ensure that wdd is not dereferenced if NULL)
Merging iommu/next (1229bc9a9973 Merge branches 'iommu/fixes', 'arm/io-pgtable', 'arm/rockchip', 'arm/omap', 'x86/vt-d', 'ppc/pamu' and 'x86/amd' into next)
Merging dwmw2-iommu/master (22e2f9fa63b0 iommu/vt-d: Use per-cpu IOVA caching)
Merging vfio/next (5ed4aba1265f vfio_iommu_spapr_tce: Remove unneeded iommu_group_get_iommudata)
Merging jc_docs/docs-next (2fd872bd84b3 Doc: correct the location of sysrq.c)
Merging trivial/for-next (52bbe141f37f gitignore: fix wording)
Merging audit/next (188e3c5cd2b6 tty: provide tty_name() even without CONFIG_TTY)
Merging devicetree/devicetree/next (48a9b733e644 of/irq: Rename "intc_desc" to "of_intc_desc" to fix OF on sh)
Merging dt-rh/for-next (1c986e3643d2 of: document refcount incrementation of of_get_cpu_node())
CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
Merging mailbox/mailbox-for-next (dd28216528cf mailbox/omap: kill omap_mbox_{save/restore}_ctx() functions)
Merging spi/for-next (7136be37c1e4 Merge remote-tracking branches 'spi/topic/pic32-qspi', 'spi/topic/pxa2xx' and 'spi/topic/xlp' into spi-next)
Merging tip/auto-latest (fbd03a56586d Merge branch 'sched/core')
CONFLICT (content): Merge conflict in drivers/firmware/efi/arm-init.c
CONFLICT (content): Merge conflict in drivers/cpufreq/longhaul.c
Merging clockevents/clockevents/next (cee77c2c5b57 clocksource/drivers/tango-xtal: Fix incorrect test)
Merging edac/linux_next (12f0721c5a70 sb_edac: correctly fetch DIMM width on Ivy Bridge and Haswell)
Merging edac-amd/for-next (c5fb04cc96c1 ARM: socfpga: Initialize Arria10 OCRAM ECC on startup)
Merging irqchip/irqchip/for-next (a66ce4b7d9d2 Merge branch 'irqchip/mvebu' into irqchip/for-next)
Merging ftrace/for-next (4afe6495e5cb tracing: Don't use the address of the buffer array name in copy_from_user)
Merging rcu/rcu/next (ebcd2861ae27 arm: Whack an expected event-trace-from-idle mole)
Merging kvm/linux-next (05b1159e641f Merge tag 'kvms390-20160420' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into next)
Merging kvm-arm/next (02e0b7600f83 arm64: kvm: Add support for 16K pages)
Merging kvm-ppc/kvm-ppc-next (c63517c2e381 KVM: PPC: Book3S: correct width in XER handling)
Merging kvm-ppc-paulus/kvm-ppc-next (58ded4201ff0 KVM: PPC: Add support for 64bit TCE windows)
Merging kvms390/next (c87ff1433aca KVM: s390: add clear I/O irq operation for FLIC)
Merging xen-tip/linux-next (3a61cfdd47c4 xen/x86: don't lose event interrupts)
CONFLICT (content): Merge conflict in drivers/firmware/efi/arm-runtime.c
CONFLICT (content): Merge conflict in arch/arm64/kernel/setup.c
Merging percpu/for-next (18fc93fd6412 percpu: remove PERCPU_ENOUGH_ROOM which is stale definition)
Merging workqueues/for-next (e55c35cf41c9 Merge branch 'for-4.6-fixes' into for-next)
Merging drivers-x86/for-next (19d46ee1aec0 asus-laptop: correct error handling in sysfs_acpi_set)
Merging chrome-platform/for-next (1dc318166a9a platform/chrome: use to_platform_device())
Merging hsi/for-next (87d99063be01 HSI: ssi-protocol: Use handshake logic from n950)
Merging leds/for-next (f15c65afddbe leds: ss4200: add DMI data for FSC SCALEO Home Server)
Merging ipmi/for-next (a1b4e31bfabb IPMI: reserve memio regions separately)
Merging driver-core/driver-core-next (5614e7725856 Merge 4.6-rc4 into driver-core-next)
Merging tty/tty-next (5be605ac9af9 tty/serial: atmel: fix hardware handshake selection)
Merging usb/usb-next (ce15bda10121 Merge tag 'usb-for-v4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next)
Merging usb-gadget/next (2a58f9c12bb3 usb: dwc3: gadget: disable automatic calculation of ACK TP NUMP)
Merging usb-serial/usb-next (8c34d82e9dc6 USB: serial: use IS_ENABLED() instead of checking for FOO || FOO_MODULE)
Merging usb-chipidea-next/ci-for-usb-next (4e332df63487 usb: otg-fsm: support multiple instances)
Merging staging/staging-next (610cc3a49fdc Staging: lustre: Make lustre_profile_list static)
CONFLICT (content): Merge conflict in drivers/iio/magnetometer/ak8975.c
Merging char-misc/char-misc-next (9bf292bfca94 misc: mic: Fix for double fetch security bug in VOP driver)
Merging extcon/extcon-next (453fc627c7b5 extcon: usb-gpio: add support for ACPI gpio interface)
Merging cgroup/for-next (e0f00aff2dcc Merge branch 'for-4.6-fixes' into for-next)
Merging scsi/for-next (71d397581d52 MAINTAINERS: Update the file list for the NCR 5380 entry)
Merging target-updates/for-next (5e47f1985d71 target: Fix target_release_cmd_kref shutdown comp leak)
Merging target-merge/for-next-merge (2994a7518317 cxgb4: update Kconfig and Makefile)
Merging pinctrl/for-next (1f5d93d96b06 Merge branch 'devel' into for-next)
Merging vhost/linux-next (c00bbcf86289 virtio: add VIRTIO_CONFIG_S_NEEDS_RESET device status bit)
Merging remoteproc/for-next (7a6271a80cae remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export alias)
Merging rpmsg/for-next (9735a22799b9 Linux 4.6-rc2)
Merging gpio/for-next (fd4faea75ac3 Merge branch 'devel' into for-next)
Merging dma-mapping/dma-mapping-next (d770e558e219 Linux 4.2-rc1)
Merging pwm/for-next (f55532a0c0b8 Linux 4.6-rc1)
Merging dma-buf/for-next (12566cc35d0e Merge tag 'pci-v4.6-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci)
Merging userns/for-next (f2ca379642d7 namei: permit linking with CAP_FOWNER in userns)
Merging ktest/for-next (f55532a0c0b8 Linux 4.6-rc1)
Merging clk/clk-next (58657d189a2f Merge branch 'clk-hw-register' (early part) into clk-next)
Merging aio/master (b562e44f507e Linux 4.5)
Merging kselftest/next (f55532a0c0b8 Linux 4.6-rc1)
Merging y2038/y2038 (4b277763c5b3 vfs: Add support to document max and min inode times)
Merging luto-misc/next (afd2ff9b7e1b Linux 4.4)
Merging borntraeger/linux-next (36f90b0a2ddd Linux 4.5-rc2)
Merging livepatching/for-next (157fe3c875a3 Merge branch 'for-4.7/livepatching-doc' into for-next)
Merging coresight/next (620a7feb9b3c coresight: etb10: adjust read pointer only when needed)
Merging rtc/rtc-next (820c5327d631 rtc: ds3232: fix call trace when rtc->ops_lock is used as NULL)
Merging hwspinlock/for-next (bd5717a4632c hwspinlock: qcom: Correct msb in regmap_field)
Merging nvdimm/libnvdimm-for-next (a390180291dd libnvdimm, pfn: fix nvdimm_namespace_add_poison() vs section alignment)
Merging akpm-current/current (305dd3d200a6 ipc/msg.c: use freezable blocking call)
CONFLICT (content): Merge conflict in include/linux/efi.h
CONFLICT (content): Merge conflict in arch/tile/Kconfig
CONFLICT (content): Merge conflict in arch/mips/kernel/process.c
CONFLICT (content): Merge conflict in arch/mips/Kconfig
CONFLICT (content): Merge conflict in arch/cris/Kconfig
Applying: mm-rename-_count-field-of-the-struct-page-to-_refcount-fix6
$ git checkout -b akpm remotes/origin/akpm/master
Applying: drivers/net/wireless/intel/iwlwifi/dvm/calib.c: simplfy min() expression
Applying: mm: make mmap_sem for write waits killable for mm syscalls
Applying: mm: make vm_mmap killable
Applying: mm: make vm_munmap killable
Applying: mm, aout: handle vm_brk failures
Applying: mm, elf: handle vm_brk error
Applying: mm: make vm_brk killable
Applying: mm, proc: make clear_refs killable
Applying: mm, fork: make dup_mmap wait for mmap_sem for write killable
Applying: ipc, shm: make shmem attach/detach wait for mmap_sem killable
Applying: vdso: make arch_setup_additional_pages wait for mmap_sem for write killable
Applying: coredump: make coredump_wait wait for mmap_sem for write killable
Applying: aio: make aio_setup_ring killable
Applying: exec: make exec path waiting for mmap_sem killable
Applying: prctl: make PR_SET_THP_DISABLE wait for mmap_sem killable
Applying: uprobes: wait for mmap_sem for write killable
Applying: drm/i915: make i915_gem_mmap_ioctl wait for mmap_sem killable
Applying: drm/radeon: make radeon_mn_get wait for mmap_sem killable
Applying: drm/amdgpu: make amdgpu_mn_get wait for mmap_sem killable
Applying: drm/amdgpu: use ERR_PTR() to return from amdgpu_mn_get
Merging akpm/master (87a40221eb27 drm/amdgpu: use ERR_PTR() to return from amdgpu_mn_get)
Applying: Revert "byteswap: try to avoid __builtin_constant_p gcc bug"
^ permalink raw reply
* Re: linux-next: build warning after merge of the akpm-current tree
From: Stephen Rothwell @ 2016-04-29 6:55 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Arnd Bergmann, Josh Poimboeuf,
Quinn Tran
In-Reply-To: <20160429164543.039df436@canb.auug.org.au>
Hi All,
On Fri, 29 Apr 2016 16:45:43 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/scsi/ipr.c: In function 'ipr_show_device_id':
> drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
> len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
> ^
>
> Lots and lots like this :-(
>
> Introduced by commit
>
> eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
>
> I guess __builtin_bswap64() has type "unsigned long int" :-(
So, I have reverted that commit for today ... it produces too many
warnings :-(
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: build warning after merge of the akpm-current tree
From: Stephen Rothwell @ 2016-04-29 6:45 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Arnd Bergmann, Josh Poimboeuf,
Quinn Tran
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/scsi/ipr.c: In function 'ipr_show_device_id':
drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
^
Lots and lots like this :-(
Probably introduced by commit
eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
I guess __builtin_bswap64() has type "unsigned long int" :-(
--
Cheers,
Stephen Rothwell
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox