All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 04/16] ARM: realview: use generic API for enabling SCU
From: Arnd Bergmann @ 2016-11-14 14:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <95b10b29-2d51-9e96-c628-232f081e09f4@samsung.com>

On Monday, November 14, 2016 5:36:43 PM CET pankaj.dubey wrote:
> On Monday 14 November 2016 05:26 PM, Arnd Bergmann wrote:
> > On Monday, November 14, 2016 10:31:59 AM CET Pankaj Dubey wrote:
> > 
> > The only difference here seems to be that realview also needs to handle
> > "arm,arm11mp-scu". Why not move that into the generic implementation?
> > 
> 
> Do you mean "arm,arm11mp-scu" this is generic SCU specific to ARM?

Yes.

> If it's generic then it can be moved on the same line I moved a5-scu and
> a9-scu.
> 
> I left it here in same file, as I understood it might be related with
> very specific to realview platform.

The reason why only realview has it is that this is currently the
only platform we support that uses SMP on an ARM11MPcore.

cns3xxx in is also SMP hardware, but we only support the first core.

	ARnd

^ permalink raw reply
* Re: [PATCH] [STYLE]staging:braille:braille_console.c [1/2]
From: Greg KH @ 2016-11-14 14:29 UTC (permalink / raw)
  To: Walt Feasel; +Cc: devel, linux-kernel
In-Reply-To: <1478826727-14635-1-git-send-email-waltfeasel@gmail.com>

On Thu, Nov 10, 2016 at 08:12:07PM -0500, Walt Feasel wrote:
> Made suggested modifications from checkpatch in reference
> to ERROR: Use 4 digit octal (0777) not decimal permissions
> 
> Signed-off-by: Walt Feasel <waltfeasel@gmail.com>
> ---
>  drivers/accessibility/braille/braille_console.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

{sigh}

Ok, I count over a hundred different patches from you in my inbox for
review.  That's great, but you need to redo them so that I can review
them.

First off, your Subject: lines are a bit odd.  You don't need the
"[STYLE]" portion, and you move around the [1/2] from the front to the
end.  Also, you aren't using git to number them, so they go from 9/12 to
10/12, which does not sort (it should be 09/12).

So please, use git to create the patch series.

Look at other patches sent to the lists for how to get good subjects,
don't use the same subject for multiple patches, that is an easy grounds
for rejection, and please put space characters after ':'.

Also say what you are doing in the subject, you don't do that here at
all.

So, for example, this Subject should be:
  [PATCH] staging: speakup: braille_console.c: use octal mode values

Read the file, Documentation/SubmittingPatches for a good description of
how to make a good subject.


Second, your patches are not threaded at all.  If you use 'git
send-email' they will all be linked up properly, making it much easier
for me to apply them, and for others to just delete them when they don't
care about the patch series.

So use 'git send-email' please.

And when using git send-email, send out patches in batches for a
specific driver, don't send out multiple series for the same driver, as
then I don't know which to accept or not.

Thirdly, please properly cc: the maintainers and developers of the
drivers you are modifying.  Use 'scripts/get_maintainers.pl' to do this.
You seem to do it in some places, but not all, so it's hard to know what
is going on there.

And lastly, slow down a bit.  Try all of this out on a single patch
series first.  Once you get them accepted, then keep going, and work on
more.  I don't want to see you waste energy on things that don't get
accepted (like all of these patches).

Does this help?

Right now I'm going to drop all of the patches you sent me, so please,
work on the above things and start to slowly resend them, in the proper
format, so that I can accept them and merge them to the kernel tree,
which is what we both want to see happen.

thanks,

greg k-h

^ permalink raw reply
* Re: [PATCH 1/6] mm: khugepaged: fix radix tree node leak in shmem collapse error path
From: Kirill A. Shutemov @ 2016-11-14 14:29 UTC (permalink / raw)
  To: Jan Kara
  Cc: Johannes Weiner, Andrew Morton, Linus Torvalds, linux-mm,
	linux-kernel, kernel-team
In-Reply-To: <20161114080744.GA2524@quack2.suse.cz>

On Mon, Nov 14, 2016 at 09:07:44AM +0100, Jan Kara wrote:
> On Fri 11-11-16 19:37:53, Kirill A. Shutemov wrote:
> > On Fri, Nov 11, 2016 at 01:22:24PM +0100, Jan Kara wrote:
> > > On Fri 11-11-16 13:59:21, Kirill A. Shutemov wrote:
> > > > On Tue, Nov 08, 2016 at 11:12:45AM -0500, Johannes Weiner wrote:
> > > > > On Tue, Nov 08, 2016 at 10:53:52AM +0100, Jan Kara wrote:
> > > > > > On Mon 07-11-16 14:07:36, Johannes Weiner wrote:
> > > > > > > The radix tree counts valid entries in each tree node. Entries stored
> > > > > > > in the tree cannot be removed by simpling storing NULL in the slot or
> > > > > > > the internal counters will be off and the node never gets freed again.
> > > > > > > 
> > > > > > > When collapsing a shmem page fails, restore the holes that were filled
> > > > > > > with radix_tree_insert() with a proper radix tree deletion.
> > > > > > > 
> > > > > > > Fixes: f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages")
> > > > > > > Reported-by: Jan Kara <jack@suse.cz>
> > > > > > > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> > > > > > > ---
> > > > > > >  mm/khugepaged.c | 3 ++-
> > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > > > > > index 728d7790dc2d..eac6f0580e26 100644
> > > > > > > --- a/mm/khugepaged.c
> > > > > > > +++ b/mm/khugepaged.c
> > > > > > > @@ -1520,7 +1520,8 @@ static void collapse_shmem(struct mm_struct *mm,
> > > > > > >  				if (!nr_none)
> > > > > > >  					break;
> > > > > > >  				/* Put holes back where they were */
> > > > > > > -				radix_tree_replace_slot(slot, NULL);
> > > > > > > +				radix_tree_delete(&mapping->page_tree,
> > > > > > > +						  iter.index);
> > > > > > 
> > > > > > Hum, but this is inside radix_tree_for_each_slot() iteration. And
> > > > > > radix_tree_delete() may end up freeing nodes resulting in invalidating
> > > > > > current slot pointer and the iteration code will do use-after-free.
> > > > > 
> > > > > Good point, we need to do another tree lookup after the deletion.
> > > > > 
> > > > > But there are other instances in the code, where we drop the lock
> > > > > temporarily and somebody else could delete the node from under us.
> > > > > 
> > > > > In the main collapse path, I *think* this is prevented by the fact
> > > > > that when we drop the tree lock we still hold the page lock of the
> > > > > regular page that's in the tree while we isolate and unmap it, thus
> > > > > pin the node. Even so, it would seem a little hairy to rely on that.
> > > > > 
> > > > > Kirill?
> > > > 
> > > > [ sorry for delay ]
> > > > 
> > > > Yes, we make sure that locked page still belong to the radix tree and fall
> > > > off if it's not. Locked page cannot be removed from radix-tree, so we
> > > > should be fine.
> > > 
> > > Well, it cannot be removed from the radix tree but radix tree code is still
> > > free to collapse / expand the tree nodes as it sees fit (currently the only
> > > real case is when changing direct page pointer in the tree root to a node
> > > pointer or vice versa but still...). So code should not really assume that
> > > the node page is referenced from does not change once tree_lock is dropped.
> > > It leads to subtle bugs...
> > 
> > Hm. Okay.
> > 
> > What is the right way re-validate that slot is still valid? Do I need full
> > look up again? Can I pin node explicitly?
> 
> Full lookup is the only way to re-validate the slot. There is no way to pin
> a radix tree node.

I guess this should be enough:

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 728d7790dc2d..c5ef73588676 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1400,7 +1400,9 @@ static void collapse_shmem(struct mm_struct *mm,
 					PAGE_SIZE, 0);
 
 		spin_lock_irq(&mapping->tree_lock);
-
+		slot = radix_tree_lookup_slot(&mapping->page_tree, index);
+		VM_BUG_ON_PAGE(page != radix_tree_deref_slot_protected(slot,
+					&mapping->tree_lock), page);
 		VM_BUG_ON_PAGE(page_mapped(page), page);
 
 		/*
-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related
* Re: [PATCH 1/6] mm: khugepaged: fix radix tree node leak in shmem collapse error path
From: Kirill A. Shutemov @ 2016-11-14 14:29 UTC (permalink / raw)
  To: Jan Kara
  Cc: Johannes Weiner, Andrew Morton, Linus Torvalds, linux-mm,
	linux-kernel, kernel-team
In-Reply-To: <20161114080744.GA2524@quack2.suse.cz>

On Mon, Nov 14, 2016 at 09:07:44AM +0100, Jan Kara wrote:
> On Fri 11-11-16 19:37:53, Kirill A. Shutemov wrote:
> > On Fri, Nov 11, 2016 at 01:22:24PM +0100, Jan Kara wrote:
> > > On Fri 11-11-16 13:59:21, Kirill A. Shutemov wrote:
> > > > On Tue, Nov 08, 2016 at 11:12:45AM -0500, Johannes Weiner wrote:
> > > > > On Tue, Nov 08, 2016 at 10:53:52AM +0100, Jan Kara wrote:
> > > > > > On Mon 07-11-16 14:07:36, Johannes Weiner wrote:
> > > > > > > The radix tree counts valid entries in each tree node. Entries stored
> > > > > > > in the tree cannot be removed by simpling storing NULL in the slot or
> > > > > > > the internal counters will be off and the node never gets freed again.
> > > > > > > 
> > > > > > > When collapsing a shmem page fails, restore the holes that were filled
> > > > > > > with radix_tree_insert() with a proper radix tree deletion.
> > > > > > > 
> > > > > > > Fixes: f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages")
> > > > > > > Reported-by: Jan Kara <jack@suse.cz>
> > > > > > > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> > > > > > > ---
> > > > > > >  mm/khugepaged.c | 3 ++-
> > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > > > > > index 728d7790dc2d..eac6f0580e26 100644
> > > > > > > --- a/mm/khugepaged.c
> > > > > > > +++ b/mm/khugepaged.c
> > > > > > > @@ -1520,7 +1520,8 @@ static void collapse_shmem(struct mm_struct *mm,
> > > > > > >  				if (!nr_none)
> > > > > > >  					break;
> > > > > > >  				/* Put holes back where they were */
> > > > > > > -				radix_tree_replace_slot(slot, NULL);
> > > > > > > +				radix_tree_delete(&mapping->page_tree,
> > > > > > > +						  iter.index);
> > > > > > 
> > > > > > Hum, but this is inside radix_tree_for_each_slot() iteration. And
> > > > > > radix_tree_delete() may end up freeing nodes resulting in invalidating
> > > > > > current slot pointer and the iteration code will do use-after-free.
> > > > > 
> > > > > Good point, we need to do another tree lookup after the deletion.
> > > > > 
> > > > > But there are other instances in the code, where we drop the lock
> > > > > temporarily and somebody else could delete the node from under us.
> > > > > 
> > > > > In the main collapse path, I *think* this is prevented by the fact
> > > > > that when we drop the tree lock we still hold the page lock of the
> > > > > regular page that's in the tree while we isolate and unmap it, thus
> > > > > pin the node. Even so, it would seem a little hairy to rely on that.
> > > > > 
> > > > > Kirill?
> > > > 
> > > > [ sorry for delay ]
> > > > 
> > > > Yes, we make sure that locked page still belong to the radix tree and fall
> > > > off if it's not. Locked page cannot be removed from radix-tree, so we
> > > > should be fine.
> > > 
> > > Well, it cannot be removed from the radix tree but radix tree code is still
> > > free to collapse / expand the tree nodes as it sees fit (currently the only
> > > real case is when changing direct page pointer in the tree root to a node
> > > pointer or vice versa but still...). So code should not really assume that
> > > the node page is referenced from does not change once tree_lock is dropped.
> > > It leads to subtle bugs...
> > 
> > Hm. Okay.
> > 
> > What is the right way re-validate that slot is still valid? Do I need full
> > look up again? Can I pin node explicitly?
> 
> Full lookup is the only way to re-validate the slot. There is no way to pin
> a radix tree node.

I guess this should be enough:

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 728d7790dc2d..c5ef73588676 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1400,7 +1400,9 @@ static void collapse_shmem(struct mm_struct *mm,
 					PAGE_SIZE, 0);
 
 		spin_lock_irq(&mapping->tree_lock);
-
+		slot = radix_tree_lookup_slot(&mapping->page_tree, index);
+		VM_BUG_ON_PAGE(page != radix_tree_deref_slot_protected(slot,
+					&mapping->tree_lock), page);
 		VM_BUG_ON_PAGE(page_mapped(page), page);
 
 		/*
-- 
 Kirill A. Shutemov

^ permalink raw reply related
* [ovmf test] 102220: all pass - PUSHED
From: osstest service owner @ 2016-11-14 14:29 UTC (permalink / raw)
  To: xen-devel, osstest-admin

flight 102220 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102220/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 bab82372a9e6ce066fa725a792e71d07191046ca
baseline version:
 ovmf                 b17d5507cfdfd10c4f1f5911ffe75fdc49fafa37

Last test of basis   102214  2016-11-14 09:26:44 Z    0 days
Testing same since   102220  2016-11-14 12:26:52 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Hao Wu <hao.a.wu@intel.com>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=bab82372a9e6ce066fa725a792e71d07191046ca
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf bab82372a9e6ce066fa725a792e71d07191046ca
+ branch=ovmf
+ revision=bab82372a9e6ce066fa725a792e71d07191046ca
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xbab82372a9e6ce066fa725a792e71d07191046ca = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osstest@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"OsstestUpstream"} or die $!;
        '
++ :
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osstest@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/qemu-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
++ : daily-cron.ovmf
++ : git://xenbits.xen.org/qemu-xen.git
++ : git://git.qemu.org/qemu.git
+ TREE_LINUX=osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
+ TREE_XEN=osstest@xenbits.xen.org:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xen.org:/home/xen/git/libvirt.git
+ TREE_RUMPRUN=osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
+ TREE_SEABIOS=osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
+ TREE_OVMF=osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
+ TREE_XTF=osstest@xenbits.xen.org:/home/xen/git/xtf.git
+ info_linux_tree ovmf
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /home/osstest/repos/ovmf
+ git push osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git bab82372a9e6ce066fa725a792e71d07191046ca:refs/heads/xen-tested-master
To osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   b17d550..bab8237  bab82372a9e6ce066fa725a792e71d07191046ca -> xen-tested-master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply
* Re: [PATCH v2 01/13] drm/i915/glk: Add Geminilake PCI IDs
From: Ander Conselvan De Oliveira @ 2016-11-14 14:29 UTC (permalink / raw)
  To: intel-gfx
In-Reply-To: <1479133477-32288-1-git-send-email-ander.conselvan.de.oliveira@intel.com>

I forgot to pass -1 to git send-email, that's why this patch ended up here.
Please ignore.

On Mon, 2016-11-14 at 16:24 +0200, Ander Conselvan de Oliveira wrote:
> v2: Add new 0x3185 ID. (Joonas)
> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.
> com>
> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 1 +
>  include/drm/i915_pciids.h       | 4 ++++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 2c9645f..e03f558 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -436,6 +436,7 @@ static const struct pci_device_id pciidlist[] = {
>  	INTEL_SKL_GT3_IDS(&intel_skylake_gt3_info),
>  	INTEL_SKL_GT4_IDS(&intel_skylake_gt3_info),
>  	INTEL_BXT_IDS(&intel_broxton_info),
> +	INTEL_GLK_IDS(&intel_geminilake_info),
>  	INTEL_KBL_GT1_IDS(&intel_kabylake_info),
>  	INTEL_KBL_GT2_IDS(&intel_kabylake_info),
>  	INTEL_KBL_GT3_IDS(&intel_kabylake_gt3_info),
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 0d5f426..540be9f 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -292,6 +292,10 @@
>  	INTEL_VGA_DEVICE(0x5A84, info), /* APL HD Graphics 505 */ \
>  	INTEL_VGA_DEVICE(0x5A85, info)  /* APL HD Graphics 500 */
>  
> +#define INTEL_GLK_IDS(info) \
> +	INTEL_VGA_DEVICE(0x3184, info), \
> +	INTEL_VGA_DEVICE(0x3185, info)
> +
>  #define INTEL_KBL_GT1_IDS(info)	\
>  	INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
>  	INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply
* Re: [PATCH 04/16] ARM: realview: use generic API for enabling SCU
From: Arnd Bergmann @ 2016-11-14 14:28 UTC (permalink / raw)
  To: pankaj.dubey
  Cc: linux-arm-kernel, linux-kernel, rmk+kernel, horms, magnus.damm,
	geert+renesas, vireshk, shiraz.linux.kernel, krzk, thomas.ab,
	Russell King
In-Reply-To: <95b10b29-2d51-9e96-c628-232f081e09f4@samsung.com>

On Monday, November 14, 2016 5:36:43 PM CET pankaj.dubey wrote:
> On Monday 14 November 2016 05:26 PM, Arnd Bergmann wrote:
> > On Monday, November 14, 2016 10:31:59 AM CET Pankaj Dubey wrote:
> > 
> > The only difference here seems to be that realview also needs to handle
> > "arm,arm11mp-scu". Why not move that into the generic implementation?
> > 
> 
> Do you mean "arm,arm11mp-scu" this is generic SCU specific to ARM?

Yes.

> If it's generic then it can be moved on the same line I moved a5-scu and
> a9-scu.
> 
> I left it here in same file, as I understood it might be related with
> very specific to realview platform.

The reason why only realview has it is that this is currently the
only platform we support that uses SMP on an ARM11MPcore.

cns3xxx in is also SMP hardware, but we only support the first core.

	ARnd

^ permalink raw reply
* Re: [PATCH v3] soc: qcom: Add SoC info driver
From: Imran Khan @ 2016-11-14 14:30 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: andy.gross, lee.jones, David Brown, open list,
	open list:ARM/QUALCOMM SUPPORT, open list:ARM/QUALCOMM SUPPORT
In-Reply-To: <20161107193514.GC25787@tuxbot>

On 11/8/2016 1:05 AM, Bjorn Andersson wrote:
> On Mon 07 Nov 06:35 PST 2016, Imran Khan wrote:
> 
> 
> 
> [..]
> 
>>>> +static void socinfo_populate(struct soc_device_attribute *soc_dev_attr)
>>>> +{
>>>> +	u32 soc_version = socinfo_get_version();
>>>> +
>>>> +	soc_dev_attr->soc_id   = kasprintf(GFP_KERNEL, "%d", socinfo_get_id());
>>>
>>> I believe soc_id is supposed to be a human readable name; e.g. "MSM8996"
>>> not "246".
>>>
>>
>> I am not sure about this. I see other vendors also exposing soc_id as numeric value
>> and machine is perhaps used for a human readable name. Please let me if I 
>> am getting something wrong here.
>>
> 
> I'm slightly confused to what these various properties are supposed to
> contain, according to Documentation/ABI/testing/sysfs-devices-soc soc_id
> should contain the SoC serial number, while most implementations does
> like you and put something telling which SoC it is.
> 
> 246 is however not a useful number, as everyone reading it - be it human
> or computer - will have to carry the translation table to figure out
> what it actually says.
>

Yeah. I agree on this point. I was just following the lead of other SoCs here.
Just worried if having a string here breaks the convention. At least having
a numeric number is more in line with the documentation which expects a 
serial number. May be here by serial number the documentation means numeric
id itself. Can someone please provide some feedback? 
 
>>>> +	soc_dev_attr->family  =  "Snapdragon";
> 
> I think family should be e.g. "MSM8996" and then machine should be e.g.
> "MSM8996AU".
> 

I think here family should be Snapdragon.The following site also mentions
the SoCs as Snapdragon family of processors.

https://www.qualcomm.com/products/snapdragon/processors/comparison

Could you please confirm if it's okay?

<snip>

>>
>> As such this funtion does not serve any overly important purpose. It just prints
>> socinfo related stuff in one line in boot logs which sometimes helps in identification
>> of the platform while doing a debugging from dumps. 
>> So I intend to keep it but if you see some issues please let me know, I can try to
>> modify it.
>>
> 
> I presumed this was used for post mortem purposes. But how useful is
> this? Doesn't the dump file come with enough information to identify the
> platform you collected the dump on?
> 
> And when we enter download mode the SMEM items should be intact, so the
> raw information should be available already - verbatim.
> 
> 
> The kernel log is for human consumption, first and foremost, so if
> you're printing anything it must make sense to humans.
> 
>>>> +	u32 f_maj = SOCINFO_VERSION_MAJOR(socinfo_format);
>>>> +	u32 f_min = SOCINFO_VERSION_MINOR(socinfo_format);
>>>> +	u32 v_maj = SOCINFO_VERSION_MAJOR(socinfo->v0_1.version);
>>>> +	u32 v_min = SOCINFO_VERSION_MINOR(socinfo->v0_1.version);
>>>> +
>>>> +	switch (socinfo_format) {
>>>> +	case SOCINFO_VERSION(0, 1):
>>>> +		pr_info("v%u.%u, id=%u, ver=%u.%u\n",
>>>> +			f_maj, f_min, socinfo->v0_1.id, v_maj, v_min);
> 
> This is neither nicely formatted (info logs should not be based on
> __func__) nor useful to the average developer.
> 
> The reason why I'm objecting is that booting a CAF kernel gives me pages
> and pages of cryptic debug messages, warning and error messages. But due
> to the amount of logs no-one will actually read through the log and
> correct things - and when you're actually looking for an error the
> scroll-back buffer is too short.
> 
> So I object to this, based on the broken window theory.
> 
> [..]

Okay. I will remove this function in next patch set.

>> Thanks and Regards,
> 
> Thank you Imran, looking forward to the next version.
> 
> Regards,
> Bjorn
> 

Thanks Bjorn, Looking forward for your answers about the queries, so that
I can float the next patch set.

Best Regards,
Imran


-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply
* Re: [PATCH] i2c: mux: fix up dependencies
From: Linus Walleij @ 2016-11-14 14:30 UTC (permalink / raw)
  To: Peter Rosin
  Cc: Wolfram Sang, linux-i2c@vger.kernel.org, stable, Jonathan Cameron
In-Reply-To: <3ba9773a-b32b-1be3-cf27-2c4e7842197f@axentia.se>

On Mon, Nov 14, 2016 at 2:59 PM, Peter Rosin <peda@axentia.se> wrote:

> It is not obvious to me that the i2c mux is dependent on
> CONFIG_OF. Sure, there are unconditional calls to things like
> of_property_read_u32 etc, but those are meant to be compiled
> away for the !CONFIG_OF case. I think. The code predates me,
> but that's how I read it...
(...)
> But don't add "depends on OF", or am I missing something?

Yeah that's right I guess. It can also use ACPI.

I'll update.

Yours,
Linus Walleij

^ permalink raw reply
* Re: [PATCH v4 0/6] perf report: Show branch flags/cycles in --branch-history callgraph view
From: Arnaldo Carvalho de Melo @ 2016-11-14 14:30 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Jin Yao, jolsa, Linux-kernel, ak, kan.liang
In-Reply-To: <1477876794-30749-1-git-send-email-yao.jin@linux.intel.com>

Em Mon, Oct 31, 2016 at 09:19:48AM +0800, Jin Yao escreveu:
> v4: Update according to Andi's comments. The requirement is not displaying
>     the number of removed loops. It needs to display the average number of
>     iterations. It computes out the number of iterations by counting
>     the removed loops. 
> 
> v3: 1. Display the count for tsx abort, remove the abort percentage.
> 
>     2. Since the branch history code has a loop detection that removes
>        small loops in util/machine.c:remove_loops(). It would be nice to
>        note how many loops were removed. So it adds the note on some
>        callchain entries.
> 
> v2: Just a rebase to Arnaldo's perf/core branch, no functional changes.

Andi, are you ok with this now? Can I have your Acked-by or Tested-by?

Thanks,

- Arnaldo
 
> Initial post
> 
> perf record -g -b ...
> perf report --branch-history
> 
> Currently it only shows the branches from the LBR in the callgraph view.
> It would be useful to annotate branch predictions and TSX aborts and
> also timed LBR cycles also in the callgraph view.
> 
> This would allow a quick overview where branch predictions are and how
> costly basic blocks are.
> 
> For example:
> 
> # Overhead  Source:Line                  Symbol                       Shared Object      Predicted  Abort  Cycles
> # ........  ...........................  ...........................  .................  .........  .....  ......
> #
>     38.25%  div.c:45                     [.] main                     div                97.6%      0      3
>             |
>             ---main div.c:42 (cycles:2)
>                compute_flag div.c:28 (cycles:2)
>                compute_flag div.c:27 (cycles:1)
>                rand rand.c:28 (cycles:1)
>                rand rand.c:28 (cycles:1)
>                __random random.c:298 (cycles:1)
>                __random random.c:297 (cycles:1)
>                __random random.c:295 (cycles:1)
>                __random random.c:295 (cycles:1)
>                __random random.c:295 (cycles:1)
>                __random random.c:295 (cycles:9)
>                |
>                |--36.73%--__random_r random_r.c:392 (cycles:9)
>                |          __random_r random_r.c:357 (cycles:1)
>                |          __random random.c:293 (cycles:1)
>                |          __random random.c:293 (cycles:1)
>                |          __random random.c:291 (cycles:1)
>                |          __random random.c:291 (cycles:1)
>                |          __random random.c:291 (cycles:1)
>                |          __random random.c:288 (cycles:1)
>                |          rand rand.c:27 (cycles:1)
>                |          rand rand.c:26 (cycles:1)
>                |          rand@plt +4194304 (cycles:1)
>                |          rand@plt +4194304 (cycles:1)
>                |          compute_flag div.c:25 (cycles:1)
>                |          compute_flag div.c:22 (cycles:1)
>                |          main div.c:40 (cycles:1)
>                |          main div.c:40 (cycles:16)
>                |          main div.c:39 (cycles:16)
>                |          |
>                |          |--29.93%--main div.c:39 (predicted:50.6%, cycles:1, iterations:18)
>                |          |          main div.c:44 (predicted:50.6%, cycles:1)
>                |          |          |
>                |          |           --22.69%--main div.c:42 (cycles:2, iterations:17)
>                |          |                     compute_flag div.c:28 (cycles:2)
>                |          |                     |
>                |          |                      --10.52%--compute_flag div.c:27 (cycles:1)
>                |          |                                rand rand.c:28 (cycles:1)
> 
> Jin Yao (6):
>   perf report: Add branch flag to callchain cursor node
>   perf report: Create a symbol_conf flag for showing branch flag
>     counting
>   perf report: Caculate and return the branch flag counting
>   perf report: Show branch info in callchain entry for stdio mode
>   perf report: Show branch info in callchain entry for browser mode
>   perf report: Display columns Predicted/Abort/Cycles in
>     --branch-history
> 
>  tools/perf/Documentation/perf-report.txt |   9 ++
>  tools/perf/builtin-report.c              |   9 +-
>  tools/perf/ui/browsers/hists.c           |  20 ++-
>  tools/perf/ui/stdio/hist.c               |  35 +++++-
>  tools/perf/util/callchain.c              | 203 ++++++++++++++++++++++++++++++-
>  tools/perf/util/callchain.h              |  22 +++-
>  tools/perf/util/hist.c                   |   3 +
>  tools/perf/util/hist.h                   |   3 +
>  tools/perf/util/machine.c                |  82 ++++++++++---
>  tools/perf/util/sort.c                   | 113 ++++++++++++++++-
>  tools/perf/util/sort.h                   |   3 +
>  tools/perf/util/symbol.h                 |   1 +
>  12 files changed, 476 insertions(+), 27 deletions(-)
> 
> -- 
> 2.7.4

^ permalink raw reply
* [U-Boot] [PATCH] socfpga: add support for Terasic DE1-SoC board
From: Marek Vasut @ 2016-11-14 14:31 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20161114151748.1e3faf3b@crub>

On 11/14/2016 03:17 PM, Anatolij Gustschin wrote:
> Hi,
> 
> On Mon, 14 Nov 2016 15:07:31 +0100
> Marek Vasut marex at denx.de wrote:
> ...
>>> +#undef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
>>> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION	2  
>>
>> Why is this needed ? Just start U-Boot from partition 1 as all the other
>> SoCFPGAs do , esp. since this is a devkit, please keep it consistent.
> 
> It is not really needed. I used the original Terasic SD-Card,
> its raw partition is 2. OK, will remove it.

Thanks!

>> Looks great otherwise :)
> 
> Thanks for review!

I'll pick V2 for the next release then. Thanks!

-- 
Best regards,
Marek Vasut

^ permalink raw reply
* Re: [PATCH] [STYLE]staging:skein:threefish_block.c remove blank lines
From: Greg KH @ 2016-11-14 14:31 UTC (permalink / raw)
  To: Dan Carpenter; +Cc: Jason Cooper, devel, Walt Feasel, linux-kernel
In-Reply-To: <20161114102301.GM28701@mwanda>

On Mon, Nov 14, 2016 at 01:34:15PM +0300, Dan Carpenter wrote:
> Please just delete the blank lines.  You aren't that special like a snow
> flake.

I agree, they need to be removed so that we don't have people waste time
on this, and the code gets closer to the correct kernel style rules.

thanks,

greg k-h

^ permalink raw reply
* [WireGuard] RFE: A notion of VERSION (was: Debugging AllowedIps)
From: Kalin KOZHUHAROV @ 2016-11-14 14:34 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list

Hi Jason,

On Mon, Nov 14, 2016 at 11:28 AM, John Huttley <john@mib-infotech.co.nz> wrote:
> RFE: when the module loads and prints its test at startup, please print its
> version and compile flags as well.
>

I second that! There is not (yet) a notion of VERSION in the code,
better not wait till 1.0 to put it :-)

One can use the commit from git, but that assumes always build from git sources.
Examples:
GIT_COMMIT := $(shell git log -n 1 --pretty=format:"%h" HEAD 2>/dev/null)
GIT_TAG := $(shell git tag --points HEAD 2>/dev/null)

( NOTE: GIT_TAG is only available if we have a tag defined at current HEAD, e.g.

$ git checkout bebcae1
HEAD is now at bebcae1... chacha20poly1305: cleanup magic constants

$ git tag --points HEAD
experimental-0.0.20161105
)

I'd rather see a VERSION.txt file, or a `VERSION := 0.0.something`
inside Makefile.

Or even directly hardcoded in main.c:

diff --git a/src/main.c b/src/main.c
index e381d09..4991812 100644
--- a/src/main.c
+++ b/src/main.c
@@ -13,6 +13,9 @@
 #include <linux/module.h>
 #include <net/rtnetlink.h>

+#define DRV_VERSION "0.0.20161105"
+const char wireguard_driver_version[] = DRV_VERSION;
+
 static int __init mod_init(void)
 {
        int ret = 0;
@@ -29,25 +32,31 @@ static int __init mod_init(void)
        chacha20poly1305_init();
        noise_init();

+#ifdef CONFIG_WIREGUARD_PARALLEL
        ret = packet_init_data_caches();
        if (ret < 0)
                return ret;
+#endif

        ret = device_init();
        if (ret < 0) {
+#ifdef CONFIG_WIREGUARD_PARALLEL
                packet_deinit_data_caches();
+#endif
                return ret;
        }

-       pr_info("WireGuard loaded. See www.wireguard.io for information.\n");
-       pr_info("(C) Copyright 2015-2016 Jason A. Donenfeld
<Jason@zx2c4.com>. All Rights Reserved.\n");
+       pr_info("WireGuard %s loaded. See www.wireguard.io for
information.\n", wireguard_driver_version);
+       pr_info("Copyright (c) 2015-2016 Jason A. Donenfeld
<Jason@zx2c4.com>. All rights reserved.\n");
        return ret;
 }

 static void __exit mod_exit(void)
 {
        device_uninit();
+#ifdef CONFIG_WIREGUARD_PARALLEL
        packet_deinit_data_caches();
+#endif
        pr_debug("WireGuard has been unloaded\n");
 }

@@ -57,3 +66,4 @@ MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("Simple, secure, and speedy VPN tunnel");
 MODULE_AUTHOR("Jason A. Donenfeld <Jason@zx2c4.com>");
 MODULE_ALIAS_RTNL_LINK(KBUILD_MODNAME);
+MODULE_VERSION(DRV_VERSION);


Not sure if const char casting is needed (was copying from e1000e driver) ;-/

I changed slightly the Copyright pr_info, actually I guess you should
remove "All  rights reserved." altogether from it (but keep it in the
source).

Cheers,
Kalin.

^ permalink raw reply related
* [PATCH RFC v2 0/2] Enable cp15 timers with user space gic & kvm
From: Alexander Graf @ 2016-11-14 14:32 UTC (permalink / raw)
  To: QEMU Developers; +Cc: Peter Maydell, Paolo Bonzini, kvm-devel, qemu-arm

When running with KVM enabled, you can choose between emulating the
gic in kernel or user space. If the kernel supports in-kernel virtualization
of the interrupt controller, it will default to that. If not, if will
default to user space emulation.

Unfortunately when running in user mode gic emulation, we miss out on
timer events which are only available from kernel space.

This patch set leverages the new kernel/user space pending line synchronization
for those timer events.

rfc1 -> rfc2:

  - use local variable for ARM_CPU
  - remove bear trap
  - move timer warning to gic device

Alexander Graf (2):
  linux-headers: update
  ARM: KVM: Enable in-kernel timers with user space gic

 hw/intc/arm_gic.c             |  7 +++++++
 include/sysemu/kvm.h          | 11 +++++++++++
 kvm-all.c                     |  5 +++++
 kvm-stub.c                    |  5 +++++
 linux-headers/asm-arm/kvm.h   |  1 +
 linux-headers/asm-arm64/kvm.h |  1 +
 linux-headers/linux/kvm.h     |  6 ++++++
 target-arm/cpu.h              |  3 +++
 target-arm/kvm.c              | 20 ++++++++++++++++++++
 9 files changed, 59 insertions(+)

-- 
1.8.5.6


^ permalink raw reply
* [PATCH RFC v2 1/2] linux-headers: update
From: Alexander Graf @ 2016-11-14 14:32 UTC (permalink / raw)
  To: QEMU Developers; +Cc: Peter Maydell, Paolo Bonzini, kvm-devel, qemu-arm
In-Reply-To: <1479133935-63848-1-git-send-email-agraf@suse.de>

This patch updates the Linux headers to include the in-progress user
space ARM timer patches. It is explicitly RFC, as the patches are not
merged yet.
---
 linux-headers/asm-arm/kvm.h   | 1 +
 linux-headers/asm-arm64/kvm.h | 1 +
 linux-headers/linux/kvm.h     | 6 ++++++
 3 files changed, 8 insertions(+)

diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index 541268c..5d58ec2 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -105,6 +105,7 @@ struct kvm_debug_exit_arch {
 };
 
 struct kvm_sync_regs {
+	__u8 timer_irq_level;
 };
 
 struct kvm_arch_memory_slot {
diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index fd5a276..0e1cbd1 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b/linux-headers/asm-arm64/kvm.h
@@ -143,6 +143,7 @@ struct kvm_debug_exit_arch {
 #define KVM_GUESTDBG_USE_HW		(1 << 17)
 
 struct kvm_sync_regs {
+	__u8 timer_irq_level;
 };
 
 struct kvm_arch_memory_slot {
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 4806e06..737113c 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -870,6 +870,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_S390_USER_INSTR0 130
 #define KVM_CAP_MSI_DEVID 131
 #define KVM_CAP_PPC_HTM 132
+#define KVM_CAP_ARM_TIMER 133
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -1327,4 +1328,9 @@ struct kvm_assigned_msix_entry {
 #define KVM_X2APIC_API_USE_32BIT_IDS            (1ULL << 0)
 #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK  (1ULL << 1)
 
+/* Available with KVM_CAP_ARM_TIMER */
+
+/* Bits for run->arm_timer.timesource */
+#define KVM_ARM_TIMER_VTIMER           (1 << 0)
+
 #endif /* __LINUX_KVM_H */
-- 
1.8.5.6


^ permalink raw reply related
* [PATCH RFC v2 2/2] ARM: KVM: Enable in-kernel timers with user space gic
From: Alexander Graf @ 2016-11-14 14:32 UTC (permalink / raw)
  To: QEMU Developers; +Cc: Peter Maydell, Paolo Bonzini, kvm-devel, qemu-arm
In-Reply-To: <1479133935-63848-1-git-send-email-agraf@suse.de>

When running with KVM enabled, you can choose between emulating the
gic in kernel or user space. If the kernel supports in-kernel virtualization
of the interrupt controller, it will default to that. If not, if will
default to user space emulation.

Unfortunately when running in user mode gic emulation, we miss out on
timer events which are only available from kernel space. This patch leverages
the new kernel/user space pending line synchronization for those timer events.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

rfc1 -> rfc2:

  - use local variable for ARM_CPU
  - remove bear trap
  - move timer warning to gic device
---
 hw/intc/arm_gic.c    |  7 +++++++
 include/sysemu/kvm.h | 11 +++++++++++
 kvm-all.c            |  5 +++++
 kvm-stub.c           |  5 +++++
 target-arm/cpu.h     |  3 +++
 target-arm/kvm.c     | 20 ++++++++++++++++++++
 6 files changed, 51 insertions(+)

diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index 521aac3..1f3aacf 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -25,6 +25,7 @@
 #include "qom/cpu.h"
 #include "qemu/log.h"
 #include "trace.h"
+#include "sysemu/kvm.h"
 
 //#define DEBUG_GIC
 
@@ -1428,6 +1429,12 @@ static void arm_gic_realize(DeviceState *dev, Error **errp)
         return;
     }
 
+    if (kvm_enabled() && !kvm_arm_supports_timer()) {
+            error_setg(errp, "KVM with user space irqchip only works when the "
+                             "host kernel supports KVM_CAP_ARM_TIMER");
+            return;
+    }
+
     /* This creates distributor and main CPU interface (s->cpuiomem[0]) */
     gic_init_irqs_and_mmio(s, gic_set_irq, gic_ops);
 
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index df67cc0..9715fee 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -227,6 +227,17 @@ int kvm_init_vcpu(CPUState *cpu);
 int kvm_cpu_exec(CPUState *cpu);
 int kvm_destroy_vcpu(CPUState *cpu);
 
+/**
+ * kvm_arm_supports_timer
+ *
+ * Not all KVM implementations support notifications for the CP15 timers to
+ * user space. This function indicates whether the current KVM implementation
+ * does support them.
+ *
+ * Returns: true if KVM supports using ARM core timers from user space
+ */
+bool kvm_arm_supports_timer(void);
+
 #ifdef NEED_CPU_H
 #include "cpu.h"
 
diff --git a/kvm-all.c b/kvm-all.c
index 330219e..8d4696c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -2194,6 +2194,11 @@ int kvm_has_intx_set_mask(void)
     return kvm_state->intx_set_mask;
 }
 
+bool kvm_arm_supports_timer(void)
+{
+    return kvm_check_extension(kvm_state, KVM_CAP_ARM_TIMER);
+}
+
 #ifdef KVM_CAP_SET_GUEST_DEBUG
 struct kvm_sw_breakpoint *kvm_find_sw_breakpoint(CPUState *cpu,
                                                  target_ulong pc)
diff --git a/kvm-stub.c b/kvm-stub.c
index b1b6b96..a4d408b 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -157,4 +157,9 @@ bool kvm_has_free_slot(MachineState *ms)
 {
     return false;
 }
+
+bool kvm_arm_supports_timer(void)
+{
+    return false;
+}
 #endif
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index ca5c849..2c379a3 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -659,6 +659,9 @@ struct ARMCPU {
 
     ARMELChangeHook *el_change_hook;
     void *el_change_hook_opaque;
+
+    /* Used to synchronize KVM and QEMU timer levels */
+    uint8_t timer_irq_level;
 };
 
 static inline ARMCPU *arm_env_get_cpu(CPUARMState *env)
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index c00b94e..c5f0d37 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -527,6 +527,26 @@ void kvm_arch_pre_run(CPUState *cs, struct kvm_run *run)
 
 MemTxAttrs kvm_arch_post_run(CPUState *cs, struct kvm_run *run)
 {
+    ARMCPU *cpu;
+    bool vtimer_high;
+
+    if (kvm_irqchip_in_kernel()) {
+        /*
+         * We only need to sync timer states with user-space interrupt
+         * controllers, so return early and save cycles if we don't.
+         */
+        return MEMTXATTRS_UNSPECIFIED;
+    }
+
+    cpu = ARM_CPU(cs);
+
+    /* Synchronize our internal vtimer irq line with the kvm one */
+    if (run->s.regs.timer_irq_level != cpu->timer_irq_level) {
+        vtimer_high = run->s.regs.timer_irq_level & KVM_ARM_TIMER_VTIMER;
+        qemu_set_irq(cpu->gt_timer_outputs[GTIMER_VIRT], vtimer_high ? 1 : 0);
+        cpu->timer_irq_level = run->s.regs.timer_irq_level;
+    }
+
     return MEMTXATTRS_UNSPECIFIED;
 }
 
-- 
1.8.5.6


^ permalink raw reply related
* [Qemu-devel] [PATCH RFC v2 1/2] linux-headers: update
From: Alexander Graf @ 2016-11-14 14:32 UTC (permalink / raw)
  To: QEMU Developers; +Cc: Peter Maydell, Paolo Bonzini, kvm-devel, qemu-arm
In-Reply-To: <1479133935-63848-1-git-send-email-agraf@suse.de>

This patch updates the Linux headers to include the in-progress user
space ARM timer patches. It is explicitly RFC, as the patches are not
merged yet.
---
 linux-headers/asm-arm/kvm.h   | 1 +
 linux-headers/asm-arm64/kvm.h | 1 +
 linux-headers/linux/kvm.h     | 6 ++++++
 3 files changed, 8 insertions(+)

diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index 541268c..5d58ec2 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -105,6 +105,7 @@ struct kvm_debug_exit_arch {
 };
 
 struct kvm_sync_regs {
+	__u8 timer_irq_level;
 };
 
 struct kvm_arch_memory_slot {
diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index fd5a276..0e1cbd1 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b/linux-headers/asm-arm64/kvm.h
@@ -143,6 +143,7 @@ struct kvm_debug_exit_arch {
 #define KVM_GUESTDBG_USE_HW		(1 << 17)
 
 struct kvm_sync_regs {
+	__u8 timer_irq_level;
 };
 
 struct kvm_arch_memory_slot {
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 4806e06..737113c 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -870,6 +870,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_S390_USER_INSTR0 130
 #define KVM_CAP_MSI_DEVID 131
 #define KVM_CAP_PPC_HTM 132
+#define KVM_CAP_ARM_TIMER 133
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -1327,4 +1328,9 @@ struct kvm_assigned_msix_entry {
 #define KVM_X2APIC_API_USE_32BIT_IDS            (1ULL << 0)
 #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK  (1ULL << 1)
 
+/* Available with KVM_CAP_ARM_TIMER */
+
+/* Bits for run->arm_timer.timesource */
+#define KVM_ARM_TIMER_VTIMER           (1 << 0)
+
 #endif /* __LINUX_KVM_H */
-- 
1.8.5.6

^ permalink raw reply related
* [Qemu-devel] [PATCH RFC v2 2/2] ARM: KVM: Enable in-kernel timers with user space gic
From: Alexander Graf @ 2016-11-14 14:32 UTC (permalink / raw)
  To: QEMU Developers; +Cc: Peter Maydell, Paolo Bonzini, kvm-devel, qemu-arm
In-Reply-To: <1479133935-63848-1-git-send-email-agraf@suse.de>

When running with KVM enabled, you can choose between emulating the
gic in kernel or user space. If the kernel supports in-kernel virtualization
of the interrupt controller, it will default to that. If not, if will
default to user space emulation.

Unfortunately when running in user mode gic emulation, we miss out on
timer events which are only available from kernel space. This patch leverages
the new kernel/user space pending line synchronization for those timer events.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

rfc1 -> rfc2:

  - use local variable for ARM_CPU
  - remove bear trap
  - move timer warning to gic device
---
 hw/intc/arm_gic.c    |  7 +++++++
 include/sysemu/kvm.h | 11 +++++++++++
 kvm-all.c            |  5 +++++
 kvm-stub.c           |  5 +++++
 target-arm/cpu.h     |  3 +++
 target-arm/kvm.c     | 20 ++++++++++++++++++++
 6 files changed, 51 insertions(+)

diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index 521aac3..1f3aacf 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -25,6 +25,7 @@
 #include "qom/cpu.h"
 #include "qemu/log.h"
 #include "trace.h"
+#include "sysemu/kvm.h"
 
 //#define DEBUG_GIC
 
@@ -1428,6 +1429,12 @@ static void arm_gic_realize(DeviceState *dev, Error **errp)
         return;
     }
 
+    if (kvm_enabled() && !kvm_arm_supports_timer()) {
+            error_setg(errp, "KVM with user space irqchip only works when the "
+                             "host kernel supports KVM_CAP_ARM_TIMER");
+            return;
+    }
+
     /* This creates distributor and main CPU interface (s->cpuiomem[0]) */
     gic_init_irqs_and_mmio(s, gic_set_irq, gic_ops);
 
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index df67cc0..9715fee 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -227,6 +227,17 @@ int kvm_init_vcpu(CPUState *cpu);
 int kvm_cpu_exec(CPUState *cpu);
 int kvm_destroy_vcpu(CPUState *cpu);
 
+/**
+ * kvm_arm_supports_timer
+ *
+ * Not all KVM implementations support notifications for the CP15 timers to
+ * user space. This function indicates whether the current KVM implementation
+ * does support them.
+ *
+ * Returns: true if KVM supports using ARM core timers from user space
+ */
+bool kvm_arm_supports_timer(void);
+
 #ifdef NEED_CPU_H
 #include "cpu.h"
 
diff --git a/kvm-all.c b/kvm-all.c
index 330219e..8d4696c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -2194,6 +2194,11 @@ int kvm_has_intx_set_mask(void)
     return kvm_state->intx_set_mask;
 }
 
+bool kvm_arm_supports_timer(void)
+{
+    return kvm_check_extension(kvm_state, KVM_CAP_ARM_TIMER);
+}
+
 #ifdef KVM_CAP_SET_GUEST_DEBUG
 struct kvm_sw_breakpoint *kvm_find_sw_breakpoint(CPUState *cpu,
                                                  target_ulong pc)
diff --git a/kvm-stub.c b/kvm-stub.c
index b1b6b96..a4d408b 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -157,4 +157,9 @@ bool kvm_has_free_slot(MachineState *ms)
 {
     return false;
 }
+
+bool kvm_arm_supports_timer(void)
+{
+    return false;
+}
 #endif
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index ca5c849..2c379a3 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -659,6 +659,9 @@ struct ARMCPU {
 
     ARMELChangeHook *el_change_hook;
     void *el_change_hook_opaque;
+
+    /* Used to synchronize KVM and QEMU timer levels */
+    uint8_t timer_irq_level;
 };
 
 static inline ARMCPU *arm_env_get_cpu(CPUARMState *env)
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index c00b94e..c5f0d37 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -527,6 +527,26 @@ void kvm_arch_pre_run(CPUState *cs, struct kvm_run *run)
 
 MemTxAttrs kvm_arch_post_run(CPUState *cs, struct kvm_run *run)
 {
+    ARMCPU *cpu;
+    bool vtimer_high;
+
+    if (kvm_irqchip_in_kernel()) {
+        /*
+         * We only need to sync timer states with user-space interrupt
+         * controllers, so return early and save cycles if we don't.
+         */
+        return MEMTXATTRS_UNSPECIFIED;
+    }
+
+    cpu = ARM_CPU(cs);
+
+    /* Synchronize our internal vtimer irq line with the kvm one */
+    if (run->s.regs.timer_irq_level != cpu->timer_irq_level) {
+        vtimer_high = run->s.regs.timer_irq_level & KVM_ARM_TIMER_VTIMER;
+        qemu_set_irq(cpu->gt_timer_outputs[GTIMER_VIRT], vtimer_high ? 1 : 0);
+        cpu->timer_irq_level = run->s.regs.timer_irq_level;
+    }
+
     return MEMTXATTRS_UNSPECIFIED;
 }
 
-- 
1.8.5.6

^ permalink raw reply related
* [Qemu-devel] [PATCH RFC v2 0/2] Enable cp15 timers with user space gic & kvm
From: Alexander Graf @ 2016-11-14 14:32 UTC (permalink / raw)
  To: QEMU Developers; +Cc: Peter Maydell, Paolo Bonzini, kvm-devel, qemu-arm

When running with KVM enabled, you can choose between emulating the
gic in kernel or user space. If the kernel supports in-kernel virtualization
of the interrupt controller, it will default to that. If not, if will
default to user space emulation.

Unfortunately when running in user mode gic emulation, we miss out on
timer events which are only available from kernel space.

This patch set leverages the new kernel/user space pending line synchronization
for those timer events.

rfc1 -> rfc2:

  - use local variable for ARM_CPU
  - remove bear trap
  - move timer warning to gic device

Alexander Graf (2):
  linux-headers: update
  ARM: KVM: Enable in-kernel timers with user space gic

 hw/intc/arm_gic.c             |  7 +++++++
 include/sysemu/kvm.h          | 11 +++++++++++
 kvm-all.c                     |  5 +++++
 kvm-stub.c                    |  5 +++++
 linux-headers/asm-arm/kvm.h   |  1 +
 linux-headers/asm-arm64/kvm.h |  1 +
 linux-headers/linux/kvm.h     |  6 ++++++
 target-arm/cpu.h              |  3 +++
 target-arm/kvm.c              | 20 ++++++++++++++++++++
 9 files changed, 59 insertions(+)

-- 
1.8.5.6

^ permalink raw reply
* [PATCH 2/4] fpga mgr: Expose FPGA capabilities to userland via sysfs
From: atull @ 2016-11-14 14:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161107001326.7395-3-moritz.fischer@ettus.com>

On Mon, 7 Nov 2016, Moritz Fischer wrote:

Hi Moritz,

One nit below.  Otherwise,

    Acked-by: Alan Tull <atull@opensource.altera.com>

Alan


> Expose FPGA capabilities to userland via sysfs.
> 
> Add Documentation for currently supported capabilities
> that get exported via sysfs.
> 
> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> Cc: Alan Tull <atull@opensource.altera.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  Documentation/ABI/testing/sysfs-class-fpga-manager | 16 ++++++++++++++++
>  drivers/fpga/fpga-mgr.c                            | 20 ++++++++++++++++++++
>  include/linux/fpga/fpga-mgr.h                      |  2 ++
>  3 files changed, 38 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-fpga-manager b/Documentation/ABI/testing/sysfs-class-fpga-manager
> index 23056c5..d9aee21 100644
> --- a/Documentation/ABI/testing/sysfs-class-fpga-manager
> +++ b/Documentation/ABI/testing/sysfs-class-fpga-manager
> @@ -35,3 +35,19 @@ Description:	Read fpga manager state as a string.
>  		* write complete	= Doing post programming steps
>  		* write complete error	= Error while doing post programming
>  		* operating		= FPGA is programmed and operating
> +
> +What: 		/sys/class/fpga_manager/fpga/capabilities
> +Date:		November 2016
> +KernelVersion:	4.9
> +Contact:	Moritz Fischer <moritz.fischer@ettus.com>
> +Description:	Read fpga manager capabilities as a string.
> +		The intent is to provide userspace with information on what
> +		operations the particular instance can execute.
> +
> +		Each line expresses a capability that is available on the
> +		particular instance of an fpga manager.
> +		Supported so far:
> +
> +		* Full reconfiguration
> +		* Partial reconfiguration
> +		* Decrypt bitstream on the fly

Decrypt gets added in a later patch.

> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index ed57c17..98230b7 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -167,6 +167,11 @@ static const char * const state_str[] = {
>  	[FPGA_MGR_STATE_OPERATING] =		"operating",
>  };
>  
> +static const char * const cap_str[] = {
> +	[FPGA_MGR_CAP_FULL_RECONF] = "Full reconfiguration",
> +	[FPGA_MGR_CAP_PARTIAL_RECONF] = "Partial reconfiguration",
> +};
> +
>  static ssize_t name_show(struct device *dev,
>  			 struct device_attribute *attr, char *buf)
>  {
> @@ -183,10 +188,25 @@ static ssize_t state_show(struct device *dev,
>  	return sprintf(buf, "%s\n", state_str[mgr->state]);
>  }
>  
> +static ssize_t capabilities_show(struct device *dev,
> +				 struct device_attribute *attr, char *buf)
> +{
> +	struct fpga_manager *mgr = to_fpga_manager(dev);
> +	char *start = buf;
> +	enum fpga_mgr_capability cap;
> +
> +	for_each_fpga_mgr_cap_mask(cap, mgr->caps)
> +		buf += sprintf(buf, "%s\n", cap_str[cap]);
> +
> +	return buf - start;
> +}
> +
> +static DEVICE_ATTR_RO(capabilities);
>  static DEVICE_ATTR_RO(name);
>  static DEVICE_ATTR_RO(state);
>  
>  static struct attribute *fpga_mgr_attrs[] = {
> +	&dev_attr_capabilities.attr,
>  	&dev_attr_name.attr,
>  	&dev_attr_state.attr,
>  	NULL,
> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> index e73429c..9bb96a5 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -108,6 +108,8 @@ static inline void __fpga_mgr_cap_set(enum fpga_mgr_capability cap,
>  	set_bit(cap, mask->bits);
>  }
>  
> +#define for_each_fpga_mgr_cap_mask(cap, mask) \
> +	for_each_set_bit(cap, mask.bits, FPGA_MGR_CAP_END)
>  
>  /**
>   * struct fpga_manager_ops - ops for low level fpga manager drivers
> -- 
> 2.10.0
> 
> 

^ permalink raw reply
* Re: [PATCH] x86: re-add stack alignment check
From: Jan Beulich @ 2016-11-14 14:33 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: xen-devel, Wei Liu
In-Reply-To: <5829D720020000780011E730@prv-mh.provo.novell.com>

>>> On 14.11.16 at 15:24, <JBeulich@suse.com> wrote:
>>>> On 14.11.16 at 14:45, <andrew.cooper3@citrix.com> wrote:
>> The BUILD_BUG_ON() is useful to retain, but I would suggest making
>> get_stack_bottom() a static inline and putting the BUILD_BUG_ON() there.
> 
> I would agree if we were to not add back the BUG_ON(), but as
> per above I'm not convinced yet.

Actually no - the 16-byte alignment requirement exists only here,
not for every caller of this function.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply
* Re: [PATCH 2/4] fpga mgr: Expose FPGA capabilities to userland via sysfs
From: atull @ 2016-11-14 14:33 UTC (permalink / raw)
  To: Moritz Fischer
  Cc: linux-kernel, moritz.fischer.private, michal.simek,
	soren.brinkmann, linux-arm-kernel, julia
In-Reply-To: <20161107001326.7395-3-moritz.fischer@ettus.com>

[-- Attachment #1: Type: text/plain, Size: 3776 bytes --]

On Mon, 7 Nov 2016, Moritz Fischer wrote:

Hi Moritz,

One nit below.  Otherwise,

    Acked-by: Alan Tull <atull@opensource.altera.com>

Alan


> Expose FPGA capabilities to userland via sysfs.
> 
> Add Documentation for currently supported capabilities
> that get exported via sysfs.
> 
> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> Cc: Alan Tull <atull@opensource.altera.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> ---
>  Documentation/ABI/testing/sysfs-class-fpga-manager | 16 ++++++++++++++++
>  drivers/fpga/fpga-mgr.c                            | 20 ++++++++++++++++++++
>  include/linux/fpga/fpga-mgr.h                      |  2 ++
>  3 files changed, 38 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-fpga-manager b/Documentation/ABI/testing/sysfs-class-fpga-manager
> index 23056c5..d9aee21 100644
> --- a/Documentation/ABI/testing/sysfs-class-fpga-manager
> +++ b/Documentation/ABI/testing/sysfs-class-fpga-manager
> @@ -35,3 +35,19 @@ Description:	Read fpga manager state as a string.
>  		* write complete	= Doing post programming steps
>  		* write complete error	= Error while doing post programming
>  		* operating		= FPGA is programmed and operating
> +
> +What: 		/sys/class/fpga_manager/fpga/capabilities
> +Date:		November 2016
> +KernelVersion:	4.9
> +Contact:	Moritz Fischer <moritz.fischer@ettus.com>
> +Description:	Read fpga manager capabilities as a string.
> +		The intent is to provide userspace with information on what
> +		operations the particular instance can execute.
> +
> +		Each line expresses a capability that is available on the
> +		particular instance of an fpga manager.
> +		Supported so far:
> +
> +		* Full reconfiguration
> +		* Partial reconfiguration
> +		* Decrypt bitstream on the fly

Decrypt gets added in a later patch.

> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index ed57c17..98230b7 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -167,6 +167,11 @@ static const char * const state_str[] = {
>  	[FPGA_MGR_STATE_OPERATING] =		"operating",
>  };
>  
> +static const char * const cap_str[] = {
> +	[FPGA_MGR_CAP_FULL_RECONF] = "Full reconfiguration",
> +	[FPGA_MGR_CAP_PARTIAL_RECONF] = "Partial reconfiguration",
> +};
> +
>  static ssize_t name_show(struct device *dev,
>  			 struct device_attribute *attr, char *buf)
>  {
> @@ -183,10 +188,25 @@ static ssize_t state_show(struct device *dev,
>  	return sprintf(buf, "%s\n", state_str[mgr->state]);
>  }
>  
> +static ssize_t capabilities_show(struct device *dev,
> +				 struct device_attribute *attr, char *buf)
> +{
> +	struct fpga_manager *mgr = to_fpga_manager(dev);
> +	char *start = buf;
> +	enum fpga_mgr_capability cap;
> +
> +	for_each_fpga_mgr_cap_mask(cap, mgr->caps)
> +		buf += sprintf(buf, "%s\n", cap_str[cap]);
> +
> +	return buf - start;
> +}
> +
> +static DEVICE_ATTR_RO(capabilities);
>  static DEVICE_ATTR_RO(name);
>  static DEVICE_ATTR_RO(state);
>  
>  static struct attribute *fpga_mgr_attrs[] = {
> +	&dev_attr_capabilities.attr,
>  	&dev_attr_name.attr,
>  	&dev_attr_state.attr,
>  	NULL,
> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> index e73429c..9bb96a5 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -108,6 +108,8 @@ static inline void __fpga_mgr_cap_set(enum fpga_mgr_capability cap,
>  	set_bit(cap, mask->bits);
>  }
>  
> +#define for_each_fpga_mgr_cap_mask(cap, mask) \
> +	for_each_set_bit(cap, mask.bits, FPGA_MGR_CAP_END)
>  
>  /**
>   * struct fpga_manager_ops - ops for low level fpga manager drivers
> -- 
> 2.10.0
> 
> 

^ permalink raw reply
* [Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs
From: Alexey Brodkin @ 2016-11-14 14:34 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20161114150740.394bdd02@free-electrons.com>

Hi Thomas,

On Mon, 2016-11-14 at 15:07 +0100, Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 14 Nov 2016 12:32:29 +0000, Vlad Zakharov wrote:
> 
> > 
> > We apologize for coming late with that update.
> > But could you please apply it on master as it is important for us to come up with latest kernel in upcoming
> > Buildroot release.
> > Updated configs were build- and run tested on corresponding platforms, so there shouldn't be any regressions there.
> 
> Once -rc1 has passed, we don't apply version bumps (be it to packages
> or defconfigs), unless they fix a specific issue.
> 
> What is the issue with having this update part of 2017.02 ?

Obviously since we live in upstream everything that could not be applied to
stable branches (i.e. is not a trivial fix and longer than 200 lines) get
merged in newer kernels.

In particular following commit was not accepted in
backports:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=840c054fd0efb048df6fceb0c46385ec5b66dfe6

See discussion here?http://www.spinics.net/lists/stable/msg143544.html

The problem is in GCC v6.x newer ABI is used for ARCv2 and so only kernels v4.8+
will work. I.e. existing 4.7 will fail to run user-space apps built with GCC 6.x.

Indeed we may add mentioned off-the-tree patch in BR for 4.7 but I'd rather bump
kernel version here with which we get more fixes across the tree for our users.

-Alexey

^ permalink raw reply
* [PATCH 0/4] Fixes for sanity.bbclass and sdk
From: Robert Yang @ 2016-11-14 14:34 UTC (permalink / raw)
  To: openembedded-core

The following changes since commit 9303d8055c45a0f6af295d70a6f6a8b9d8d8a7c9:

  devtool: add "rename" subcommand (2016-11-07 11:04:17 +0000)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/4fixes
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/4fixes

Robert Yang (4):
  populate_sdk_ext.bbclass: use weak assignment for
    TOOLCHAINEXT_OUTPUTNAME
  testsdk.bbclass: print which file is not found
  sanity.bbclass:check_connectivity(): print more error messages
  sanity.bbclass: fix check_connectivity() for BB_NO_NETWORK = "0"

 meta/classes/populate_sdk_ext.bbclass |  2 +-
 meta/classes/sanity.bbclass           | 19 +++++++++++++------
 meta/classes/testsdk.bbclass          |  6 +++---
 3 files changed, 17 insertions(+), 10 deletions(-)

-- 
2.10.2



^ permalink raw reply
* [PATCH 1/4] populate_sdk_ext.bbclass: use weak assignment for TOOLCHAINEXT_OUTPUTNAME
From: Robert Yang @ 2016-11-14 14:34 UTC (permalink / raw)
  To: openembedded-core
In-Reply-To: <cover.1479133967.git.liezhi.yang@windriver.com>

The TOOLCHAINEXT_OUTPUTNAME is different from TOOLCHAIN_OUTPUTNAME, it
is used for eSDK only, so that it doesn't mix with SDK, use "?=" for it
so that other conf file can define it.

If we don't use "?=" here, then we need use forcevariable to redfine it:
TOOLCHAINEXT_OUTPUTNAME_forcevariable = "foo"

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/classes/populate_sdk_ext.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass
index a0856d4..2c9def6 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -77,7 +77,7 @@ COREBASE_FILES ?= " \
 
 SDK_DIR_task-populate-sdk-ext = "${WORKDIR}/sdk-ext"
 B_task-populate-sdk-ext = "${SDK_DIR}"
-TOOLCHAINEXT_OUTPUTNAME = "${SDK_NAME}-toolchain-ext-${SDK_VERSION}"
+TOOLCHAINEXT_OUTPUTNAME ?= "${SDK_NAME}-toolchain-ext-${SDK_VERSION}"
 TOOLCHAIN_OUTPUTNAME_task-populate-sdk-ext = "${TOOLCHAINEXT_OUTPUTNAME}"
 
 SDK_EXT_TARGET_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAINEXT_OUTPUTNAME}.target.manifest"
-- 
2.10.2



^ permalink raw reply related
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.