* Re: [GIT PULL] rockchip clock changes for 4.12 part1
From: Stephen Boyd @ 2017-04-05 20:05 UTC (permalink / raw)
To: Heiko Stuebner; +Cc: mturquette, linux-clk, linux-rockchip
In-Reply-To: <5160508.89PunkDez8@phil>
On 03/28, Heiko Stuebner wrote:
> Hi Mike, Stephen,
>
> Please find below rockchip clock changes for 4.12. As the tag states,
> I've included the rk1108 -> rv1108 clock rename in here. Pinctrl changes
> go through the pinctrl tree and once everything is in mainline I'll put
> the actual devicetree on top. That way we keep cross-tree changes to a
> minimum while keeping everything error-free and bisectable.
>
> So please pull if nothing stands out.
>
>
Thanks. Pulled into clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 1/2] x86/mce/AMD: Redo use of SMCA MCA_DE{STAT,ADDR} registers
From: Borislav Petkov @ 2017-04-05 20:04 UTC (permalink / raw)
To: Ghannam, Yazen
Cc: linux-edac@vger.kernel.org, Tony Luck, x86@kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <BN6PR1201MB0131E84344E19543CCB2C086F80A0@BN6PR1201MB0131.namprd12.prod.outlook.com>
On Wed, Apr 05, 2017 at 07:29:48PM +0000, Ghannam, Yazen wrote:
> If it's set, then I expect a Deferred error in MCA_STATUS since any Correctable
> Errors will be overwritten. Multiple bank types can generate Deferred errors
> so there may also be cases where for some types a valid Uncorrectable error
> happens and overwrites the Deferred error before we can handle it. In which
> case we lose the Deferred error if we don't check MCA_DESTAT.
So if we have an UE, wouldn't that raise an #MC? I guess in such cases
we should concentrate only on the deferred errors and let the #MC
handler deal with them. As we do now.
> If it's not set, then it's possible to have a valid Correctable error in MCA_STATUS
> while the valid Deferred error is in MCA_DESTAT.
What's logging the CE? We probably should log it too before something
overwrites it.
Anyway, ok, I think I know what needs to happen now:
amd_deferred_error_interrupt:
if (__log_error_deferred(bank))
return;
This one read MC?_STATUS and does the logging for when the deferred
error is in the normal MSRs. It returns true if it succeeded. It reads
and hands down both MC?_STATUS and MC?_ADDR to __log_error() so that it
doesn't have to read MC?_STATUS twice.
If __log_error_deferred() has read a different type of error, we still
log it? I'm not sure about this. I guess we can ignore that case for
now.
Then:
if (mca_flags.smca)
__log_error_deferred_smca(bank));
which handles the SMCA case. It too reads MSR_AMD64_SMCA_MCx_DESTAT
and MSR_AMD64_SMCA_MCx_DEADDR and hands them down to __log_error() for
logging.
For the __log_error() call in amd_threshold_interrupt(), you define a
log_error() wrapper which reads the default MSRs and hands them down to
__log_error().
So __log_error() always gets STATUS and ADDR MSR values and it doesn't
need to read them from the MSRs but only log them.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH nf-next 1/1] netfilter: Remove useless variable timeouts in init_conntrack
From: kbuild test robot @ 2017-04-05 20:01 UTC (permalink / raw)
To: gfree.wind; +Cc: kbuild-all, pablo, netfilter-devel, Gao Feng
In-Reply-To: <1491367754-16976-1-git-send-email-gfree.wind@foxmail.com>
[-- Attachment #1: Type: text/plain, Size: 3996 bytes --]
Hi Gao,
[auto build test ERROR on nf-next/master]
url: https://github.com/0day-ci/linux/commits/gfree-wind-foxmail-com/netfilter-Remove-useless-variable-timeouts-in-init_conntrack/20170406-031517
base: https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c:377:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.new = icmpv6_new,
^~~~~~~~~~
net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c:377:11: note: (near initialization for 'nf_conntrack_l4proto_icmpv6.new')
cc1: some warnings being treated as errors
--
>> net/netfilter/nf_conntrack_proto_generic.c:196:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.new = generic_new,
^~~~~~~~~~~
net/netfilter/nf_conntrack_proto_generic.c:196:11: note: (near initialization for 'nf_conntrack_l4proto_generic.new')
cc1: some warnings being treated as errors
--
>> net/netfilter/nf_conntrack_proto_gre.c:374:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.new = gre_new,
^~~~~~~
net/netfilter/nf_conntrack_proto_gre.c:374:11: note: (near initialization for 'nf_conntrack_l4proto_gre4.new')
cc1: some warnings being treated as errors
vim +377 net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
8fc027816 Gao feng 2012-06-21 361
08911475d Pablo Neira Ayuso 2012-06-29 362 static struct nf_proto_net *icmpv6_get_net_proto(struct net *net)
08911475d Pablo Neira Ayuso 2012-06-29 363 {
08911475d Pablo Neira Ayuso 2012-06-29 364 return &net->ct.nf_ct_proto.icmpv6.pn;
08911475d Pablo Neira Ayuso 2012-06-29 365 }
08911475d Pablo Neira Ayuso 2012-06-29 366
61075af51 Patrick McHardy 2007-07-14 367 struct nf_conntrack_l4proto nf_conntrack_l4proto_icmpv6 __read_mostly =
9fb9cbb10 Yasuyuki Kozakai 2005-11-09 368 {
9fb9cbb10 Yasuyuki Kozakai 2005-11-09 369 .l3proto = PF_INET6,
605dcad6c Martin Josefsson 2006-11-29 370 .l4proto = IPPROTO_ICMPV6,
9fb9cbb10 Yasuyuki Kozakai 2005-11-09 371 .name = "icmpv6",
9fb9cbb10 Yasuyuki Kozakai 2005-11-09 372 .pkt_to_tuple = icmpv6_pkt_to_tuple,
9fb9cbb10 Yasuyuki Kozakai 2005-11-09 373 .invert_tuple = icmpv6_invert_tuple,
9fb9cbb10 Yasuyuki Kozakai 2005-11-09 374 .print_tuple = icmpv6_print_tuple,
9fb9cbb10 Yasuyuki Kozakai 2005-11-09 375 .packet = icmpv6_packet,
2c8503f55 Pablo Neira Ayuso 2012-02-28 376 .get_timeouts = icmpv6_get_timeouts,
9fb9cbb10 Yasuyuki Kozakai 2005-11-09 @377 .new = icmpv6_new,
9fb9cbb10 Yasuyuki Kozakai 2005-11-09 378 .error = icmpv6_error,
07a936260 Amerigo Wang 2012-10-29 379 #if IS_ENABLED(CONFIG_NF_CT_NETLINK)
fdf708322 Patrick McHardy 2007-09-28 380 .tuple_to_nlattr = icmpv6_tuple_to_nlattr,
a400c30ed Holger Eitzenberger 2009-03-25 381 .nlattr_tuple_size = icmpv6_nlattr_tuple_size,
fdf708322 Patrick McHardy 2007-09-28 382 .nlattr_to_tuple = icmpv6_nlattr_to_tuple,
f73e924cd Patrick McHardy 2007-09-28 383 .nla_policy = icmpv6_nla_policy,
c1d10adb4 Pablo Neira Ayuso 2006-01-05 384 #endif
509784623 Pablo Neira Ayuso 2012-02-28 385 #if IS_ENABLED(CONFIG_NF_CT_NETLINK_TIMEOUT)
:::::: The code at line 377 was first introduced by commit
:::::: 9fb9cbb1082d6b31fb45aa1a14432449a0df6cf1 [NETFILTER]: Add nf_conntrack subsystem.
:::::: TO: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 59066 bytes --]
^ permalink raw reply
* [PATCH] nvme: avoid NULL pointer dereference in error recovery path
From: Guilherme G. Piccoli @ 2017-04-05 20:01 UTC (permalink / raw)
In-Reply-To: <20170405194357.GA11705@lst.de>
On 04/05/2017 04:43 PM, Christoph Hellwig wrote:
> On Wed, Apr 05, 2017@04:40:37PM -0300, Guilherme G. Piccoli wrote:
>> It's possible that driver fails to recover from a PCI error and the
>> PCI core (or arch PCI specifics, like EEH in PowerPC) starts a process
>> of device removal. While this removal process is happening, if another
>> PCI error is triggered, we might have a NULL address for
>> "struct *nvme_dev", pointed by "pci_dev *driver_data" - for example this
>> happens if nvme_remove() already have set that pci_dev struct's field
>> to NULL.
>>
>> In this case, the driver error handler functions will dereferece a NULL
>> pointer, causing a kernel oops. This patch checks for NULL pointer on
>> error handlers and in case "driver_data" points to NULL, it aborts the
>> error recovery path and return a fail error value to PCI core.
>
> I think this needs to be fixed at a higher level, that is the PCI
> core. Once you have the callbacks run in parallel a simple null check
> isn't going to fix this but every single access to the structure
> is a possible use after free.
>
Christoph, your point makes sense.
It's possible (I guess not expected, but at least feasible) to have a
2nd PCI error being triggered while a 1st error is in
recovery/removal-on-failure process, after the slot_reset() step of the
1st error specifically.
Many drivers around do these NULL pointer checks - solving this in EEH
core would mean having a way to every driver communicate the error
recovery process is completed and the next error could be "issued".
Like PCI core would "stack" the next error.
But...what if the device has really a severe issue in its slot, and it's
unable to recover at all? So, it'll trigger another error and naturally
the callbacks are going to be called, expecting to drop recoveries and
signal to PCI core something went real bad.
So, I believe these NULL checks will avoid at least this dereference
case and enforce signaling to PCI core to remove the device if this
"racy" error sequence happens after a device recovery failure is in process.
If you see another paths that multiple PCI errors happening in sequence
might cause trouble to nvme driver that I'm not aware, please let me
know and we can think a better solution. Also, if you have ideas on how
to address this in a more elegant/generic way, let me know too, I really
appreciate. Guess this patch is the most simplistic approach, at least
the one I could think of.
Thanks for the quick review!
Cheers,
Guilherme
^ permalink raw reply
* Re: [PATCH v1 1/2] string-list: use ALLOC_GROW macro when reallocing string_list
From: Stefan Beller @ 2017-04-05 20:00 UTC (permalink / raw)
To: Jeff Hostetler
Cc: git@vger.kernel.org, Junio C Hamano, Jeff King, Jeff Hostetler
In-Reply-To: <20170405195600.54801-2-git@jeffhostetler.com>
On Wed, Apr 5, 2017 at 12:55 PM, <git@jeffhostetler.com> wrote:
> + if (list->nr + 1 >= list->alloc)
> + ALLOC_GROW(list->items, list->nr+1, list->alloc);
No need for the condition here as it is part of the macro as well.
Thanks for spotting this fix!
Stefan
^ permalink raw reply
* [maintainer-tools PATCH v2] dim: Add examples section to dim.rst
From: Sean Paul @ 2017-04-05 19:59 UTC (permalink / raw)
To: daniel, intel-gfx
In-Reply-To: <20170404062326.6pw56w4a3zk37hij@phenom.ffwll.local>
Along with a recipe for creating a topic branch and sending a pull
request from it.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
---
Changes in v2:
- Address danvet's comments
- added paragraph about selecting a baseline
- s_origin/master_*baseline*_
- s/build test/test/
- add breadcrumb in drm-misc docs
dim.rst | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drm-misc.rst | 3 ++-
2 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/dim.rst b/dim.rst
index b99248e..3dd19f9 100644
--- a/dim.rst
+++ b/dim.rst
@@ -472,6 +472,63 @@ listed using the **list-aliases** subcommand.
The alias functionality requires **bash(1)** version 4.3 or later to work.
+EXAMPLES
+========
+
+Cross-subsystem topic branches
+------------------------------
+So you want to send a pull request to another subsystem? Maintainers will likely
+get cranky if you ask them to pull a swath of unrelated drm patches, so we'll
+use a topic branch based upon Linus' tree with only the relevant patches.
+
+First select a suitable *baseline* for your topic branch. For topic
+branches shared within the gpu/drm subsystem, base it on the latest
+drm-next branch. For anything else, base it on the latest -rc tag from
+Upstream (not just any random position). In very rare cases you might need
+to apply topic branch pull requests from other maintainers before you can
+apply patches to construct a suitable baseline first.
+
+Next, create the topic branch using dim. Use whichever dim remote is most
+applicable, and name the branch in a manner that describes the set of patches
+you want pulled. The upstream will be Linus' tree.
+
+ $ dim create-branch *dim-remote*/topic/*topic-branch* *baseline*
+
+Once the branch is created, you can apply the patches to be pulled.
+
+ $ dim apply-branch topic/*topic-branch*
+
+Test your new topic branch and push it.
+
+ $ dim push-branch topic/*topic-branch*
+
+Ensure that your topic branch was merged into drm-tip. The drm-tip tree is
+located in $DIM_PREFIX/drm-tip, test it to ensure the new topic branch
+didn't break anything.
+
+Once you're satisfied that nothing is broken, create the pull request.
+
+ $ dim pull-request topic/*topic-branch* *baseline*
+
+You'll be prompted to enter a tag description and your mail user agent will open
+with the pull request email. Change names and emails as appropriate to reflect
+who the sender and recipient of the pull is, and send it.
+
+Once the pull has been acked by your maintainer counterpart, you can pull it
+into the appropriate local dim branch.
+
+ $ dim apply-pull *dim-branch*
+
+Perform a final test, and push *dim-branch* to *dim-remote*.
+
+ $ dim push-branch *dim-branch*
+
+You can now remove the topic branch, as it is no longer useful (you could remove
+it any time after the pull request, since it creates a tag, but this is as good
+a place as any).
+
+ $ dim remove-branch topic/*topic-branch*
+
CONTRIBUTING
============
diff --git a/drm-misc.rst b/drm-misc.rst
index 8c6e4bf..45ea795 100644
--- a/drm-misc.rst
+++ b/drm-misc.rst
@@ -86,7 +86,8 @@ Right now the only hard merge criteria are:
* Any non-linear actions (backmerges, merging topic branches and sending out
pull requests) are only done by the official drm-misc maintainers (currently
- Daniel, Jani and Sean, see MAINTAINERS), and not by committers.
+ Daniel, Jani and Sean, see MAINTAINERS), and not by committers. See the
+ `examples section in dim <dim.html#examples>`_ for more info
* All the x86, arm and arm64 DRM drivers need to still compile. To simplify this
we track defconfigs for all three platforms in the `drm-intel-rerere` branch.
--
2.12.2.715.g7642488e1d-goog
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [obsolete] linux-next-git-rejects.patch removed from -mm tree
From: akpm @ 2017-04-05 19:58 UTC (permalink / raw)
To: akpm, mm-commits
The patch titled
Subject: linux-next-git-rejects
has been removed from the -mm tree. Its filename was
linux-next-git-rejects.patch
This patch was dropped because it is obsolete
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: linux-next-git-rejects
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ----
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 12 ------------
2 files changed, 16 deletions(-)
diff -puN drivers/gpu/drm/msm/adreno/adreno_gpu.c~linux-next-git-rejects drivers/gpu/drm/msm/adreno/adreno_gpu.c
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c~linux-next-git-rejects
+++ a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -440,10 +440,6 @@ void adreno_gpu_cleanup(struct adreno_gp
if (gpu->aspace) {
gpu->aspace->mmu->funcs->detach(gpu->aspace->mmu,
iommu_ports, ARRAY_SIZE(iommu_ports));
-<<<<<<< HEAD
- msm_gem_address_space_destroy(gpu->aspace);
-=======
msm_gem_address_space_put(gpu->aspace);
->>>>>>> linux-next/akpm-base
}
}
diff -puN drivers/gpu/drm/vmwgfx/vmwgfx_fence.c~linux-next-git-rejects drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c~linux-next-git-rejects
+++ a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -761,18 +761,12 @@ int vmw_fence_obj_wait_ioctl(struct drm_
arg->kernel_cookie = jiffies + wait_timeout;
}
-<<<<<<< HEAD
- base = vmw_fence_obj_lookup(tfile, arg->handle);
- if (IS_ERR(base))
- return PTR_ERR(base);
-=======
base = ttm_base_object_lookup(tfile, arg->handle);
if (unlikely(base == NULL)) {
pr_err("Wait invalid fence object handle 0x%08lx\n",
(unsigned long)arg->handle);
return -EINVAL;
}
->>>>>>> linux-next/akpm-base
fence = &(container_of(base, struct vmw_user_fence, base)->fence);
@@ -811,18 +805,12 @@ int vmw_fence_obj_signaled_ioctl(struct
struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
struct vmw_private *dev_priv = vmw_priv(dev);
-<<<<<<< HEAD
- base = vmw_fence_obj_lookup(tfile, arg->handle);
- if (IS_ERR(base))
- return PTR_ERR(base);
-=======
base = ttm_base_object_lookup(tfile, arg->handle);
if (unlikely(base == NULL)) {
pr_err("Fence signaled invalid fence object handle 0x%08lx\n",
(unsigned long)arg->handle);
return -EINVAL;
}
->>>>>>> linux-next/akpm-base
fence = &(container_of(base, struct vmw_user_fence, base)->fence);
fman = fman_from_fence(fence);
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
i-need-old-gcc.patch
ptrace-fix-ptrace_listen-race-corrupting-task-state-checkpatch-fixes.patch
arm-arch-arm-include-asm-pageh-needs-personalityh.patch
ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called-fix.patch
ocfs2-dlm-optimization-of-code-while-free-dead-node-locks-checkpatch-fixes.patch
mm.patch
mm-move-madv_free-pages-into-lru_inactive_file-list-checkpatch-fixes.patch
mm-use-is_migrate_highatomic-to-simplify-the-code-fix.patch
mm-introduce-memalloc_nofs_saverestore-api-fix.patch
jbd2-mark-the-transaction-context-with-the-scope-gfp_nofs-context-fix.patch
jbd2-make-the-whole-kjournald2-kthread-nofs-safe-checkpatch-fixes.patch
mm-page_alloc-count-movable-pages-when-stealing-from-pageblock-fix.patch
swap-add-warning-if-swap-slots-cache-failed-to-initialize-fix.patch
checkpatch-add-ability-to-find-bad-uses-of-vsprintf-%pfoo-extensions-fix.patch
checkpatch-add-ability-to-find-bad-uses-of-vsprintf-%pfoo-extensions-fix-fix.patch
taskstats-add-e-u-stime-for-tgid-command-fix.patch
taskstats-add-e-u-stime-for-tgid-command-fix-fix.patch
kernel-reboot-add-devm_register_reboot_notifier-fix.patch
fault-inject-support-systematic-fault-injection-fix.patch
linux-next-rejects.patch
drm-use-set_memoryh-header-fix.patch
drivers-staging-media-atomisp-pci-atomisp2-use-set_memoryh.patch
kernel-forkc-export-kernel_thread-to-modules.patch
slab-leaks3-default-y.patch
^ permalink raw reply
* Re: [PATCH 00/24] Kernel lockdown
From: David Howells @ 2017-04-05 19:57 UTC (permalink / raw)
To: linux-kernel
Cc: dhowells, gnomes, linux-efi, matthew.garrett, gregkh,
linux-security-module, keyrings
In-Reply-To: <149141219387.31282.6648284836568938717.stgit@warthog.procyon.org.uk>
Let me try sending this again again. Lee, Chun-Yi as a name causes the mail
dispatcher to break :-/
David
^ permalink raw reply
* [PATCH 00/24] Kernel lockdown
From: David Howells @ 2017-04-05 19:57 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <149141219387.31282.6648284836568938717.stgit@warthog.procyon.org.uk>
Let me try sending this again again. Lee, Chun-Yi as a name causes the mail
dispatcher to break :-/
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/24] Kernel lockdown
From: David Howells @ 2017-04-05 19:57 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA,
gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
keyrings-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <149141219387.31282.6648284836568938717.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
Let me try sending this again again. Lee, Chun-Yi as a name causes the mail
dispatcher to break :-/
David
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 03/13] s390x: Drop useless casts
From: Philippe Mathieu-Daudé @ 2017-04-05 19:57 UTC (permalink / raw)
To: Eric Blake, qemu-devel; +Cc: Alexander Graf, armbru, Richard Henderson
In-Reply-To: <20170405194741.18956-4-eblake@redhat.com>
On 04/05/2017 04:47 PM, Eric Blake wrote:
> An upcoming Coccinelle cleanup script wanted to reformat the casts
> present in this file - but on closer look, we don't need the casts
> at all because C automatically converts void* to any other pointer.
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> target/s390x/cpu_models.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index 1434d15..ce461cc 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -376,12 +376,12 @@ static void cpu_model_from_info(S390CPUModel *model, const CpuModelInfo *info,
>
> static void qdict_add_disabled_feat(const char *name, void *opaque)
> {
> - qdict_put((QDict *) opaque, name, qbool_from_bool(false));
> + qdict_put(opaque, name, qbool_from_bool(false));
> }
>
> static void qdict_add_enabled_feat(const char *name, void *opaque)
> {
> - qdict_put((QDict *) opaque, name, qbool_from_bool(true));
> + qdict_put(opaque, name, qbool_from_bool(true));
> }
>
> /* convert S390CPUDef into a static CpuModelInfo */
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 02/13] pci: Reduce scope of error injection
From: Philippe Mathieu-Daudé @ 2017-04-05 19:57 UTC (permalink / raw)
To: Eric Blake, qemu-devel; +Cc: Marcel Apfelbaum, armbru, Michael S. Tsirkin
In-Reply-To: <20170405194741.18956-3-eblake@redhat.com>
On 04/05/2017 04:47 PM, Eric Blake wrote:
> No one outside of pcie_aer.h was using error injection; mark them
> static for internal use.
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>
> ---
> v3: new patch, suggested by Markus
> ---
> include/hw/pci/pcie_aer.h | 4 ----
> hw/pci/pcie_aer.c | 4 ++--
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/include/hw/pci/pcie_aer.h b/include/hw/pci/pcie_aer.h
> index 526802b..729a943 100644
> --- a/include/hw/pci/pcie_aer.h
> +++ b/include/hw/pci/pcie_aer.h
> @@ -100,8 +100,4 @@ void pcie_aer_root_write_config(PCIDevice *dev,
> uint32_t addr, uint32_t val, int len,
> uint32_t root_cmd_prev);
>
> -/* error injection */
> -int pcie_aer_inject_error(PCIDevice *dev, const PCIEAERErr *err);
> -void pcie_aer_msg(PCIDevice *dev, const PCIEAERMsg *msg);
> -
> #endif /* QEMU_PCIE_AER_H */
> diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
> index 653af86..828052b 100644
> --- a/hw/pci/pcie_aer.c
> +++ b/hw/pci/pcie_aer.c
> @@ -376,7 +376,7 @@ static void pcie_aer_msg_root_port(PCIDevice *dev, const PCIEAERMsg *msg)
> *
> * Walk up the bus tree from the device, propagate the error message.
> */
> -void pcie_aer_msg(PCIDevice *dev, const PCIEAERMsg *msg)
> +static void pcie_aer_msg(PCIDevice *dev, const PCIEAERMsg *msg)
> {
> uint8_t type;
>
> @@ -631,7 +631,7 @@ static bool pcie_aer_inject_uncor_error(PCIEAERInject *inj, bool is_fatal)
> * Figure 6-2: Flowchart Showing Sequence of Device Error Signaling and Logging
> * Operations
> */
> -int pcie_aer_inject_error(PCIDevice *dev, const PCIEAERErr *err)
> +static int pcie_aer_inject_error(PCIDevice *dev, const PCIEAERErr *err)
> {
> uint8_t *aer_cap = NULL;
> uint16_t devctl = 0;
>
^ permalink raw reply
* [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support
From: Stefan Agner @ 2017-04-05 19:56 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20170405191023.GG19897@bill-the-cat>
On 2017-04-05 12:10, Tom Rini wrote:
> On Wed, Apr 05, 2017 at 11:20:43AM -0700, Stefan Agner wrote:
>> On 2017-04-05 08:15, Lukasz Majewski wrote:
>> > Hi Stefan,
>> >
>> >> On 2017-04-04 01:23, Lukasz Majewski wrote:
>> >> > Hi Stefan,
>> >> >
>> >> >> Hi Lukasz,
>> >> >>
>> >> >> On 2017-04-03 04:20, Lukasz Majewski wrote:
>> >> >> > Hi Stefan,
>> >> >> >
>> >> >> > Thanks for your patch. Please allow me to share some ideas for
>> >> >> > improvements.
>> >> >> >
>> >> >> >> From: Stefan Agner <stefan.agner@toradex.com>
>> >> >> >>
>> >> >> >> This patchset enables to boot elf binaries on secondary Cortex-M
>> >> >> >> class cores available on i.MX 6SoloX/7Solo/7Dual. This makes
>> >> >> >> handling and loading firmwares much more convinient since all
>> >> >> >> information where the firmware has to be loaded to is contained
>> >> >> >> in the elf headers. A typical usage looks like this:
>> >> >> >>
>> >> >> >> Colibri iMX7 # tftp ${loadaddr} firmware.elf && bootaux
>> >> >> >> ${loadaddr} Using FEC0 device
>> >> >> >> TFTP from server 192.168.10.1; our IP address is 192.168.10.2
>> >> >> >> Filename 'firmware.elf'.
>> >> >> >> Load address: 0x80800000
>> >> >> >> Loading: ##################################################
>> >> >> >> 88.3 KiB 5.4 MiB/s
>> >> >> >> done
>> >> >> >> Bytes transferred = 90424 (16138 hex)
>> >> >> >> ## Starting auxiliary core at 0x1FFF8311 ...
>> >> >> >> Colibri iMX7 #
>> >> >> >
>> >> >> > I can find some other platforms (not only IMX), which would
>> >> >> > benefit from this code - the generic 'bootaux' command.
>> >> >> >
>> >> >> > One good example would to allow multiple binaries for different
>> >> >> > SoC Cores (e.g. 2x Cortex-A8) to be loaded and started by u-boot.
>> >> >> >
>> >> >> > Hence, I'm wondering if you could make those patches usable for
>> >> >> > other platforms as well?
>> >> >>
>> >> >> I don't think that this is a good idea. bootaux is meant for
>> >> >> auxiliary cores, which often use a different architecture and are
>> >> >> not cache coherent (hence the cache flushes).
>> >> >
>> >> > I do remember, that I saw similar "tiny" patch to add "just one"
>> >> > ad-hoc command to do the same (conceptually) for TI SoC floating on
>> >> > the u-boot mailing list.
>> >> >
>> >> > Please correct me if I'm wrong, but bootaux is IMX specific and does
>> >> > work, which very likely, will be also required by other SoC vendors
>> >> > (TI's Sitara is also equipped with Cortex-M4 and PRUSS).
>> >>
>> >> bootaux is currently IMX specific, and its currently supported binary
>> >> format is M-class specific.
>> >>
>> >> >
>> >> > Unification of such effort can save us all a lot of trouble in a
>> >> > very near future.
>> >>
>> >> In OSS, you do not develop for the future. It gets developed when its
>> >> here.
>> >
>> > I cannot agree here. When you perceive threat then you prepare for it.
>> >
>> >>
>> >> >
>> >> >>
>> >> >> On SMP systems the main operating system normally starts the
>> >> >> secondary core.
>> >> >
>> >> > I think that there are some conceptual similarities between loading
>> >> > code to SMP core and Cortex M3. Of course some "tweaks" would be
>> >> > needed.
>> >> >
>> >>
>> >> There are conceptual similarities between a car and a truck, still,
>> >> they are likely manufactured in a different assembly line, probably
>> >> by a different producer.
>> >>
>> >> I guess in the end it really depends on where you draw the line: There
>> >> are differences between loading code which will get executed by the
>> >> primary code, loading code to execute explicitly on a SMP core, and
>> >> loading code to execute on a remote processor.
>> >>
>> >> The first case is already well supported, and we need to keep support
>> >> backward compatibility.
>> >>
>> >> The second case, IMHO, is a somewhat silly case: A SMP system usually
>> >> gets driven by a single OS image, and that OS makes sure to initialize
>> >> the cores (maybe with the help of firmware, such as the PSCI interface
>> >> on ARM). There is no need for a boot loader command to execute a image
>> >> on a secondary core explicitly...
>> >
>> > I do understand (and agree) with your point with SMP.
>> >
>> > But, I do know at least one use case when somebody would like to start
>> > two binaries (those are bare metal programs, taking care of SoC setup,
>> > IPC, etc).
>> >
>> > And maybe Linux with some FPGA based IP block already configured in
>> > u-boot.
>> >
>> >>
>> >> The third case is probably a case where we could start think about
>> >> unification efforts.
>> >>
>> >>
>> >> >> Otherwise, if you want to run them separately using U-Boot,
>> >> >> maybe a new command such as bootsmp would be more suited.
>> >> >
>> >> > Hmm - I do think that it would be too much:
>> >> >
>> >> > - bootm for generic single core
>> >> > - bootaux for IMX
>> >> > - bootsmp for SMP (on IMX/TI/RK?)
>> >> > - boot?? for ??
>> >>
>> >> There is at least also bootz and bootelf.
>> >
>> > I will reply to the other thread regarding bootelf.
>> >
>> >>
>> >> >
>> >> > I would like to avoid adding new commands for doing conceptually the
>> >> > same work.
>> >> >
>> >> > Even better, we could extend bootm to support the "multi binary"
>> >> > case too, but IMHO it would be also correct to have "bootaux" to
>> >> > handle generic binaries loading.
>> >> >
>> >> >>
>> >> >> >
>> >> >> >>
>> >> >> >> Note that the bootaux command retrieved the entry point (PC)
>> >> >> >> from the elf binary.
>> >> >> >
>> >> >> > Could you make this code flexible enough to handle not only elf
>> >> >> > binaries, but also other data (e.g. FPGA bitstreams)?
>> >> >>
>> >> >> The code of bootaux is rather small, I don't see much value into
>> >> >> stuff boot code for other peripherals into it.
>> >> >
>> >> > But I'm not asking to write support for other vendor's SoC/use
>> >> > cases.
>> >> >
>> >> > I'm just wondering if you could write generic command (framework) to
>> >> > support this use case and as an example add support for your IMX's
>> >> > Cortex-M3/4.
>> >> >
>> >>
>> >> Sure, mv arch/arm/imx-common/imx_bootaux.c cmd/, there is the
>> >> framework :-)
>> >>
>> >> But this promotes the M class specific binary format to a generic
>> >> format supported for all cores.
>> >>
>> >> > We would kill two birds with one stone - IMX is supported from the
>> >> > very beginning and we do have generic code to extend it by other
>> >> > vendors.
>> >> >
>> >> >> I don't know how FPGA
>> >> >> bistream loading typically works, but I guess it is quite different
>> >> >> from loading a firmware into RAM/SRAM and flush caches...
>> >> >
>> >> > FPGA quirks would be handled in arch/SoC specific code.
>> >> >
>> >> >>
>> >> >> I am not against reuse and unification, I just feel that this is
>> >> >> not really a case where we gain much.
>> >> >
>> >> > With generic "bootaux/bootm" command we can point other developers
>> >> > who would like to add such booting code to the already available
>> >> > framework.
>> >> >
>> >> > Also, we would prevent other "ad-hoc" commands adding to u-boot.
>> >> >
>> >>
>> >> Extending bootm does not seem like a good idea. bootm is already
>> >> rather complex, making it even more complex by supporting the
>> >> auxiliary core case seems really not work well.
>> >>
>> >> Also, bootm supports lots of features which you probably never would
>> >> use or test on a remote core (e.g. initramfs etc...)
>> >>
>> >> >>
>> >> >> >
>> >> >> > Maybe it would better to:
>> >> >> > -------------------------
>> >> >> >
>> >> >> > Embrace those binaries into FIT file (*.itb)? And allow multiple
>> >> >> > binaries loading? I'm thinking of work similar to one already
>> >> >> > did by Andre Przywara for SPL:
>> >> >> >
>> >> >> > "[PATCH v3 00/19] SPL: extend FIT loading support" posted on
>> >> >> > 31.03.2017?
>> >> >> >
>> >> >> > In that way we would "open" many new use cases, and other
>> >> >> > platforms (e.g. FPGA's, TI, etc) could benefit from it.
>> >> >> > One solid use case is to load different Linux binaries (or/and
>> >> >> > bare metal programs) to different SoC cores.
>> >> >> >
>> >> >> > The "meta data" (i.e. load address, data type, description),
>> >> >> > could be extracted from the FIT format (the code is already in
>> >> >> > u-boot).
>> >> >> >
>> >> >> > IMHO, this is very generic approach.
>> >> >>
>> >> >> I did some experiments with using FIT images for auxiliary core
>> >> >> firmware, however, it did not add a lot of advantage over using
>> >> >> elf:
>> >> >> http://git.toradex.com/cgit/u-boot-toradex.git/commit/?h=2015.04-toradex-next&id=d1d416f272e840e8139aec911f89a70fe5523eb2
>> >> >
>> >> > Unfortunately, not all use cases allow using ELF format. FIT gives
>> >> > more flexibility:
>> >> >
>> >> > - ./doc/README.dfutftp -> different images loading
>> >> >
>> >> > - Andre's patch to load multiple binaries in SPL - [PATCH v3 00/19]
>> >> > SPL: extend FIT loading support"
>> >> >
>> >>
>> >> Are flexible, but very much U-Boot specific. And much more complex to
>> >> support.
>> >>
>> >> >>
>> >> >> Firmwares are already built and available in the elf file format.
>> >> >> The Linux remoteproc framework, which is meant to handle this kind
>> >> >> of cores too, supports elf firmware loading too, so supporting elf
>> >> >> in U-Boot too is a nice alignment. Also using FIT adds an
>> >> >> additional step when building firm wares...
>> >> >
>> >> > But this is all OK.
>> >> >
>> >> > The ELF binary would be wrapped in FIT (with e.g. "elf" property,
>> >> > even 1 to 1 mapping). Then the 'bootaux/bootm' could parse ELF
>> >> > (which is also generic). And then some "IMX specific" (arch/SoC)
>> >> > code would be executed.
>> >> >
>> >>
>> >> So we go from a nacked binary loaded directly to the place it has been
>> >> linked to, to a double wrapped firmware file...?
>> >
>> > We would have elf binary file embedded into FIT file, these would bring
>> > flexibility.
>> >
>> > FIT support is in place (u-boot/spl).
>> >
>> > In such a way you can use any binary in any format.
>> >
>> > But I must admit that we are going off-topic here.....
>> >
>> >>
>> >> Not sure if user will appriciate that extra work and boot time. And
>> >> developers the extra code.
>> >>
>> >> Maybe in a perfect world that just works, because you know, FIT is
>> >> generic, and elf is generic... But that is just not how it works in
>> >> practice. The existing FIT code is rather complex, supports lots of
>> >> corner cases. The elf code supports different header types... Loading
>> >> the elf sections (which use M4 specific addressing) needs address
>> >> translation to get to suitable host addresses...
>> >
>> > Maybe I'm an idealist :-)
>> >
>> > One analogy comes to my mind between linux and u-boot.
>> >
>> > The proliferation of u-boot commands and linux board files. Why Linux
>> > spend tremendous resources to remove board files and switch to device
>> > tree?
>> >
>>
>> I argue that is the right way of doing it: Do ad-hoc solutions, whatever
>> makes sense, and once you understand the full breath of design space it
>> is much easier to build a suitable framework. At that point, do the
>> refactoring and build that suitable framework.
>>
>> If you design a framework without the understanding of the whole design
>> space, you will end up with something which does not work well and needs
>> lots of work-arounds etc...
>>
>> Of course, it is a bit different since both examples have outside facing
>> impact (change to device tree as well as changes to U-Boot commands).
>
> To ask the silly question, isn't cmd/remoteproc.c part of the proper
> framework for a solution here?
Oh wow, wasn't aware of that.
Interestingly, this even got merged before bootaux! (remoteproc has been
added September 2015, bootaux January 2016)...
The framework seems somewhat TI specific, e.g. there is no notion of
load address. Not sure how well that will fit with the NXP requirements,
but I will give it a shot.
--
Stefan
^ permalink raw reply
* [PATCH v1 2/2] p0005-status: time status on very large repo
From: git @ 2017-04-05 19:56 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Jeff Hostetler
In-Reply-To: <20170405195600.54801-1-git@jeffhostetler.com>
From: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
---
t/perf/p0005-status.sh | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
create mode 100644 t/perf/p0005-status.sh
diff --git a/t/perf/p0005-status.sh b/t/perf/p0005-status.sh
new file mode 100644
index 0000000..4a25ba0
--- /dev/null
+++ b/t/perf/p0005-status.sh
@@ -0,0 +1,70 @@
+#!/bin/sh
+
+test_description="Tests performance of read-tree"
+
+. ./perf-lib.sh
+
+test_perf_default_repo
+test_checkout_worktree
+
+## usage: dir depth width files
+make_paths () {
+ for f in $(seq $4)
+ do
+ echo $1/file$f
+ done;
+ if test $2 -gt 0;
+ then
+ for w in $(seq $3)
+ do
+ make_paths $1/dir$w $(($2 - 1)) $3 $4
+ done
+ fi
+ return 0
+}
+
+fill_index () {
+ make_paths $1 $2 $3 $4 |
+ sed "s/^/100644 $EMPTY_BLOB /" |
+ git update-index --index-info
+ return 0
+}
+
+br_work1=xxx_work1_xxx
+
+new_dir=xxx_dir_xxx
+
+## (5, 10, 9) will create 999,999 files.
+## (4, 10, 9) will create 99,999 files.
+depth=5
+width=10
+files=9
+
+export br_work1
+
+export new_dir
+
+export depth
+export width
+export files
+
+## Inflate the index with thousands of empty files and commit it.
+test_expect_success 'inflate the index' '
+ git reset --hard &&
+ git branch $br_work1 &&
+ git checkout $br_work1 &&
+ fill_index $new_dir $depth $width $files &&
+ git commit -m $br_work1 &&
+ git reset --hard
+'
+
+## The number of files in the xxx_work1_xxx branch.
+nr_work1=$(git ls-files | wc -l)
+export nr_work1
+
+test_perf "read-tree status work1 ($nr_work1)" '
+ git read-tree HEAD &&
+ git status
+'
+
+test_done
--
2.9.3
^ permalink raw reply related
* [PATCH v1 0/2] string-list: use ALLOC_GROW macro when reallocing
From: git @ 2017-04-05 19:55 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Jeff Hostetler
From: Jeff Hostetler <jeffhost@microsoft.com>
Use ALLOC_GROW() macro when reallocating a string_list array
rather than simply increasing it by 32. This helps performance
of status on very large repos on Windows.
Jeff Hostetler (2):
string-list: use ALLOC_GROW macro when reallocing string_list
p0005-status: time status on very large repo
string-list.c | 6 ++---
t/perf/p0005-status.sh | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+), 4 deletions(-)
create mode 100644 t/perf/p0005-status.sh
--
2.9.3
^ permalink raw reply
* [PATCH v1 1/2] string-list: use ALLOC_GROW macro when reallocing string_list
From: git @ 2017-04-05 19:55 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Jeff Hostetler
In-Reply-To: <20170405195600.54801-1-git@jeffhostetler.com>
From: Jeff Hostetler <jeffhost@microsoft.com>
Use ALLOC_GROW() macro when reallocing a string_list array
rather than simply increasing it by 32. This is a performance
optimization.
During status on a very large repo and there are many changes,
a significant percentage of the total run time was spent
reallocing the wt_status.changes array.
This change decreased the time in wt_status_collect_changes_worktree()
from 125 seconds to 45 seconds on my very large repository.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
---
string-list.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/string-list.c b/string-list.c
index 45016ad..cd4c4e0 100644
--- a/string-list.c
+++ b/string-list.c
@@ -41,10 +41,8 @@ static int add_entry(int insert_at, struct string_list *list, const char *string
if (exact_match)
return -1 - index;
- if (list->nr + 1 >= list->alloc) {
- list->alloc += 32;
- REALLOC_ARRAY(list->items, list->alloc);
- }
+ if (list->nr + 1 >= list->alloc)
+ ALLOC_GROW(list->items, list->nr+1, list->alloc);
if (index < list->nr)
memmove(list->items + index + 1, list->items + index,
(list->nr - index)
--
2.9.3
^ permalink raw reply related
* Re: [git pull] clk: renesas: Updates for v4.12 (take two)
From: Stephen Boyd @ 2017-04-05 19:56 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Michael Turquette, linux-clk, linux-renesas-soc
In-Reply-To: <1490952253-10963-1-git-send-email-geert+renesas@glider.be>
On 03/31, Geert Uytterhoeven wrote:
> Hi Mike, Stephen,
>
> The following changes since commit cecbe87d73006cb321dec79b349e3fefd1a80962:
>
> clk: renesas: rcar-gen3: Add workaround for PLL0/2/4 errata on H3 ES1.0 (2017-03-21 11:12:23 +0100)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git tags/clk-renesas-for-v4.12-tag2
>
> for you to fetch changes up to bb1953067c05be30a605ee1d5b05a2677735bb37:
>
> clk: renesas: rcar-gen3-cpg: Add support for RCLK on R-Car H3 ES2.0 (2017-03-30 13:26:02 +0200)
>
> ----------------------------------------------------------------
> clk: renesas: Updates for v4.12 (take two)
>
> - Add support for the Clock Pulse Generator / Module Standby and
> Software Reset module on revision ES2.0 of the R-Car H3 SoC, which
> differs from ES1.x in some areas.
>
> Note that this pull request is on top of my previous pull request for
> v4.12, which accidentally had a wrong version number in the subject
> line, and which I believe you haven't pulled yet.
Thanks. I pulled both by pulling this one tag.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 00/11] fujitsu-laptop: backlight cleanup
From: Michał Kępień @ 2017-04-05 19:55 UTC (permalink / raw)
To: Jonathan Woithe
Cc: Darren Hart, Andy Shevchenko, platform-driver-x86, linux-kernel
In-Reply-To: <20170405153600.GC27833@fury>
> On Wed, Apr 05, 2017 at 08:48:59AM +0200, Michał Kępień wrote:
> > This series introduces further changes to the way LCD backlight is
> > handled by fujitsu-laptop. These changes include fixing a bug in code
> > responsible for generating brightness-related input events, cleaning up
> > handling of module parameters, reducing code duplication, removing
> > superfluous debug messages and other fixes.
> >
> > This series was tested on a Lifebook S7020 and a Lifebook E744.
> >
> > This series is based on the testing branch as it requires earlier patch
> > series I submitted in order to apply cleanly.
> >
> > Changes from v1:
> >
> > - Update debug message logged by set_lcd_level() to reflect code flow
> > changes introduced by patch 04/11.
>
> Queued to testing, thanks!
Jonathan, I would still love to hear your opinion on this series. Take
your time, though, I do not see any reason to rush things. I will only
send the next series once you ack this one.
--
Best regards,
Michał Kępień
^ permalink raw reply
* [Buildroot] [PATCHv3 00/12] toolchain: improvements to copy_toolchain_sysroot and copy_toolchain_lib_root
From: Thomas Petazzoni @ 2017-04-05 19:54 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170207215649.364-1-patrickdepinguin@gmail.com>
Hello,
On Tue, 7 Feb 2017 22:56:37 +0100, Thomas De Schampheleire wrote:
> Thomas De Schampheleire (12):
> toolchain-external: reduce nesting in copy_toolchain_sysroot
> toolchain-external: fix broken handling of 'usr/lib/locale'
> toolchain-external: clarify rsync excludes in copy_toolchain_sysroot
> toolchain-external: handle ld.so fixups centrally
> toolchain helpers: introduce function relpath_prefix
> toolchain-external: cover multilib toolchains with lib/<variant>
> layout
> toolchain helpers: introduce simplify_symlink
> toolchain-external: simplify previously-broken symbolic links
> toolchain: copy_toolchain_lib_root: remove unused variable LIBDIR
> toolchain: copy_toolchain_lib_root: clarify logic
> toolchain: copy_toolchain_lib_root: clarify input parameter
> toolchain: copy_toolchain_lib_root: copy symlinks instead of
> recreating them
I've now applied the remainder of the series, patches 3 to 12. I still
find this quite complicated overall, but I couldn't find any other
solution and nobody else did, and the problem scope is complicated
anyway.
Let's see the feedback we get from users :)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support
From: Lukasz Majewski @ 2017-04-05 19:54 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20170405191023.GG19897@bill-the-cat>
On Wed, 5 Apr 2017 15:10:23 -0400
Tom Rini <trini@konsulko.com> wrote:
> On Wed, Apr 05, 2017 at 11:20:43AM -0700, Stefan Agner wrote:
> > On 2017-04-05 08:15, Lukasz Majewski wrote:
> > > Hi Stefan,
> > >
> > >> On 2017-04-04 01:23, Lukasz Majewski wrote:
> > >> > Hi Stefan,
> > >> >
> > >> >> Hi Lukasz,
> > >> >>
> > >> >> On 2017-04-03 04:20, Lukasz Majewski wrote:
> > >> >> > Hi Stefan,
> > >> >> >
> > >> >> > Thanks for your patch. Please allow me to share some ideas
> > >> >> > for improvements.
> > >> >> >
> > >> >> >> From: Stefan Agner <stefan.agner@toradex.com>
> > >> >> >>
> > >> >> >> This patchset enables to boot elf binaries on secondary
> > >> >> >> Cortex-M class cores available on i.MX 6SoloX/7Solo/7Dual.
> > >> >> >> This makes handling and loading firmwares much more
> > >> >> >> convinient since all information where the firmware has to
> > >> >> >> be loaded to is contained in the elf headers. A typical
> > >> >> >> usage looks like this:
> > >> >> >>
> > >> >> >> Colibri iMX7 # tftp ${loadaddr} firmware.elf && bootaux
> > >> >> >> ${loadaddr} Using FEC0 device
> > >> >> >> TFTP from server 192.168.10.1; our IP address is
> > >> >> >> 192.168.10.2 Filename 'firmware.elf'.
> > >> >> >> Load address: 0x80800000
> > >> >> >> Loading:
> > >> >> >> ################################################## 88.3
> > >> >> >> KiB 5.4 MiB/s done
> > >> >> >> Bytes transferred = 90424 (16138 hex)
> > >> >> >> ## Starting auxiliary core at 0x1FFF8311 ...
> > >> >> >> Colibri iMX7 #
> > >> >> >
> > >> >> > I can find some other platforms (not only IMX), which would
> > >> >> > benefit from this code - the generic 'bootaux' command.
> > >> >> >
> > >> >> > One good example would to allow multiple binaries for
> > >> >> > different SoC Cores (e.g. 2x Cortex-A8) to be loaded and
> > >> >> > started by u-boot.
> > >> >> >
> > >> >> > Hence, I'm wondering if you could make those patches usable
> > >> >> > for other platforms as well?
> > >> >>
> > >> >> I don't think that this is a good idea. bootaux is meant for
> > >> >> auxiliary cores, which often use a different architecture and
> > >> >> are not cache coherent (hence the cache flushes).
> > >> >
> > >> > I do remember, that I saw similar "tiny" patch to add "just
> > >> > one" ad-hoc command to do the same (conceptually) for TI SoC
> > >> > floating on the u-boot mailing list.
> > >> >
> > >> > Please correct me if I'm wrong, but bootaux is IMX specific
> > >> > and does work, which very likely, will be also required by
> > >> > other SoC vendors (TI's Sitara is also equipped with Cortex-M4
> > >> > and PRUSS).
> > >>
> > >> bootaux is currently IMX specific, and its currently supported
> > >> binary format is M-class specific.
> > >>
> > >> >
> > >> > Unification of such effort can save us all a lot of trouble in
> > >> > a very near future.
> > >>
> > >> In OSS, you do not develop for the future. It gets developed
> > >> when its here.
> > >
> > > I cannot agree here. When you perceive threat then you prepare
> > > for it.
> > >
> > >>
> > >> >
> > >> >>
> > >> >> On SMP systems the main operating system normally starts the
> > >> >> secondary core.
> > >> >
> > >> > I think that there are some conceptual similarities between
> > >> > loading code to SMP core and Cortex M3. Of course some
> > >> > "tweaks" would be needed.
> > >> >
> > >>
> > >> There are conceptual similarities between a car and a truck,
> > >> still, they are likely manufactured in a different assembly
> > >> line, probably by a different producer.
> > >>
> > >> I guess in the end it really depends on where you draw the line:
> > >> There are differences between loading code which will get
> > >> executed by the primary code, loading code to execute explicitly
> > >> on a SMP core, and loading code to execute on a remote processor.
> > >>
> > >> The first case is already well supported, and we need to keep
> > >> support backward compatibility.
> > >>
> > >> The second case, IMHO, is a somewhat silly case: A SMP system
> > >> usually gets driven by a single OS image, and that OS makes sure
> > >> to initialize the cores (maybe with the help of firmware, such
> > >> as the PSCI interface on ARM). There is no need for a boot
> > >> loader command to execute a image on a secondary core
> > >> explicitly...
> > >
> > > I do understand (and agree) with your point with SMP.
> > >
> > > But, I do know at least one use case when somebody would like to
> > > start two binaries (those are bare metal programs, taking care of
> > > SoC setup, IPC, etc).
> > >
> > > And maybe Linux with some FPGA based IP block already configured
> > > in u-boot.
> > >
> > >>
> > >> The third case is probably a case where we could start think
> > >> about unification efforts.
> > >>
> > >>
> > >> >> Otherwise, if you want to run them separately using U-Boot,
> > >> >> maybe a new command such as bootsmp would be more suited.
> > >> >
> > >> > Hmm - I do think that it would be too much:
> > >> >
> > >> > - bootm for generic single core
> > >> > - bootaux for IMX
> > >> > - bootsmp for SMP (on IMX/TI/RK?)
> > >> > - boot?? for ??
> > >>
> > >> There is at least also bootz and bootelf.
> > >
> > > I will reply to the other thread regarding bootelf.
> > >
> > >>
> > >> >
> > >> > I would like to avoid adding new commands for doing
> > >> > conceptually the same work.
> > >> >
> > >> > Even better, we could extend bootm to support the "multi
> > >> > binary" case too, but IMHO it would be also correct to have
> > >> > "bootaux" to handle generic binaries loading.
> > >> >
> > >> >>
> > >> >> >
> > >> >> >>
> > >> >> >> Note that the bootaux command retrieved the entry point
> > >> >> >> (PC) from the elf binary.
> > >> >> >
> > >> >> > Could you make this code flexible enough to handle not only
> > >> >> > elf binaries, but also other data (e.g. FPGA bitstreams)?
> > >> >>
> > >> >> The code of bootaux is rather small, I don't see much value
> > >> >> into stuff boot code for other peripherals into it.
> > >> >
> > >> > But I'm not asking to write support for other vendor's SoC/use
> > >> > cases.
> > >> >
> > >> > I'm just wondering if you could write generic command
> > >> > (framework) to support this use case and as an example add
> > >> > support for your IMX's Cortex-M3/4.
> > >> >
> > >>
> > >> Sure, mv arch/arm/imx-common/imx_bootaux.c cmd/, there is the
> > >> framework :-)
> > >>
> > >> But this promotes the M class specific binary format to a generic
> > >> format supported for all cores.
> > >>
> > >> > We would kill two birds with one stone - IMX is supported from
> > >> > the very beginning and we do have generic code to extend it by
> > >> > other vendors.
> > >> >
> > >> >> I don't know how FPGA
> > >> >> bistream loading typically works, but I guess it is quite
> > >> >> different from loading a firmware into RAM/SRAM and flush
> > >> >> caches...
> > >> >
> > >> > FPGA quirks would be handled in arch/SoC specific code.
> > >> >
> > >> >>
> > >> >> I am not against reuse and unification, I just feel that this
> > >> >> is not really a case where we gain much.
> > >> >
> > >> > With generic "bootaux/bootm" command we can point other
> > >> > developers who would like to add such booting code to the
> > >> > already available framework.
> > >> >
> > >> > Also, we would prevent other "ad-hoc" commands adding to
> > >> > u-boot.
> > >> >
> > >>
> > >> Extending bootm does not seem like a good idea. bootm is already
> > >> rather complex, making it even more complex by supporting the
> > >> auxiliary core case seems really not work well.
> > >>
> > >> Also, bootm supports lots of features which you probably never
> > >> would use or test on a remote core (e.g. initramfs etc...)
> > >>
> > >> >>
> > >> >> >
> > >> >> > Maybe it would better to:
> > >> >> > -------------------------
> > >> >> >
> > >> >> > Embrace those binaries into FIT file (*.itb)? And allow
> > >> >> > multiple binaries loading? I'm thinking of work similar to
> > >> >> > one already did by Andre Przywara for SPL:
> > >> >> >
> > >> >> > "[PATCH v3 00/19] SPL: extend FIT loading support" posted on
> > >> >> > 31.03.2017?
> > >> >> >
> > >> >> > In that way we would "open" many new use cases, and other
> > >> >> > platforms (e.g. FPGA's, TI, etc) could benefit from it.
> > >> >> > One solid use case is to load different Linux binaries
> > >> >> > (or/and bare metal programs) to different SoC cores.
> > >> >> >
> > >> >> > The "meta data" (i.e. load address, data type, description),
> > >> >> > could be extracted from the FIT format (the code is already
> > >> >> > in u-boot).
> > >> >> >
> > >> >> > IMHO, this is very generic approach.
> > >> >>
> > >> >> I did some experiments with using FIT images for auxiliary
> > >> >> core firmware, however, it did not add a lot of advantage
> > >> >> over using elf:
> > >> >> http://git.toradex.com/cgit/u-boot-toradex.git/commit/?h=2015.04-toradex-next&id=d1d416f272e840e8139aec911f89a70fe5523eb2
> > >> >
> > >> > Unfortunately, not all use cases allow using ELF format. FIT
> > >> > gives more flexibility:
> > >> >
> > >> > - ./doc/README.dfutftp -> different images loading
> > >> >
> > >> > - Andre's patch to load multiple binaries in SPL - [PATCH v3
> > >> > 00/19] SPL: extend FIT loading support"
> > >> >
> > >>
> > >> Are flexible, but very much U-Boot specific. And much more
> > >> complex to support.
> > >>
> > >> >>
> > >> >> Firmwares are already built and available in the elf file
> > >> >> format. The Linux remoteproc framework, which is meant to
> > >> >> handle this kind of cores too, supports elf firmware loading
> > >> >> too, so supporting elf in U-Boot too is a nice alignment.
> > >> >> Also using FIT adds an additional step when building firm
> > >> >> wares...
> > >> >
> > >> > But this is all OK.
> > >> >
> > >> > The ELF binary would be wrapped in FIT (with e.g. "elf"
> > >> > property, even 1 to 1 mapping). Then the 'bootaux/bootm' could
> > >> > parse ELF (which is also generic). And then some "IMX
> > >> > specific" (arch/SoC) code would be executed.
> > >> >
> > >>
> > >> So we go from a nacked binary loaded directly to the place it
> > >> has been linked to, to a double wrapped firmware file...?
> > >
> > > We would have elf binary file embedded into FIT file, these would
> > > bring flexibility.
> > >
> > > FIT support is in place (u-boot/spl).
> > >
> > > In such a way you can use any binary in any format.
> > >
> > > But I must admit that we are going off-topic here.....
> > >
> > >>
> > >> Not sure if user will appriciate that extra work and boot time.
> > >> And developers the extra code.
> > >>
> > >> Maybe in a perfect world that just works, because you know, FIT
> > >> is generic, and elf is generic... But that is just not how it
> > >> works in practice. The existing FIT code is rather complex,
> > >> supports lots of corner cases. The elf code supports different
> > >> header types... Loading the elf sections (which use M4 specific
> > >> addressing) needs address translation to get to suitable host
> > >> addresses...
> > >
> > > Maybe I'm an idealist :-)
> > >
> > > One analogy comes to my mind between linux and u-boot.
> > >
> > > The proliferation of u-boot commands and linux board files. Why
> > > Linux spend tremendous resources to remove board files and switch
> > > to device tree?
> > >
> >
> > I argue that is the right way of doing it: Do ad-hoc solutions,
> > whatever makes sense, and once you understand the full breath of
> > design space it is much easier to build a suitable framework. At
> > that point, do the refactoring and build that suitable framework.
> >
> > If you design a framework without the understanding of the whole
> > design space, you will end up with something which does not work
> > well and needs lots of work-arounds etc...
> >
> > Of course, it is a bit different since both examples have outside
> > facing impact (change to device tree as well as changes to U-Boot
> > commands).
>
> To ask the silly question, isn't cmd/remoteproc.c part of the proper
> framework for a solution here?
>
Yes, this seems like a solution :-). Thanks for pointing out.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170405/47b11407/attachment.sig>
^ permalink raw reply
* [PATCH] clk: iproc: Remove redundant check
From: Ray Jui @ 2017-04-05 19:53 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: David Binderman, linux-clk, linux-kernel,
bcm-kernel-feedback-list, Ray Jui
Remove the redundant check of 'rate' in the if statement of the
'pll_set_rate' function
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Fixes: 5fe225c105fd ("clk: iproc: add initial common clock support")
---
drivers/clk/bcm/clk-iproc-pll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/bcm/clk-iproc-pll.c b/drivers/clk/bcm/clk-iproc-pll.c
index e04634c..2d61893 100644
--- a/drivers/clk/bcm/clk-iproc-pll.c
+++ b/drivers/clk/bcm/clk-iproc-pll.c
@@ -277,7 +277,7 @@ static int pll_set_rate(struct iproc_clk *clk, unsigned int rate_index,
if (rate >= VCO_LOW && rate < VCO_HIGH) {
ki = 4;
kp_index = KP_BAND_MID;
- } else if (rate >= VCO_HIGH && rate && rate < VCO_HIGH_HIGH) {
+ } else if (rate >= VCO_HIGH && rate < VCO_HIGH_HIGH) {
ki = 3;
kp_index = KP_BAND_HIGH;
} else if (rate >= VCO_HIGH_HIGH && rate < VCO_MAX) {
--
2.1.4
^ permalink raw reply related
* Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt
From: Steven Rostedt @ 2017-04-05 19:52 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: LKML
In-Reply-To: <20170405193928.GM1600@linux.vnet.ibm.com>
On Wed, 5 Apr 2017 12:39:28 -0700
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > Here's the crucial part of that stack dump again:
> >
> > save_stack_trace+0x1b/0x1d
> > check_stack+0xec/0x24a
> > stack_trace_call+0x40/0x53
> > 0xffffffffa0026077
> > ? ftrace_graph_caller+0x78/0xa8
> > ? trace_hardirqs_off+0xd/0xf
> > ? rcu_eqs_enter_common.constprop.71+0x5/0x108
> > rcu_eqs_enter_common.constprop.71+0x5/0x108
> > rcu_idle_enter+0x51/0x72
> >
> >
> > The stack trace was called on rcu_eqs_enter_common() inside the
> > rcu_idle_enter() function call.
> >
> > Perhaps if I just let rcu disable stack tracing? Something like this:
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 50fee76..f894fc3 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -853,8 +853,10 @@ void rcu_idle_enter(void)
> > unsigned long flags;
> >
> > local_irq_save(flags);
> > + disable_stack_tracer();
> > rcu_eqs_enter(false);
> > rcu_sysidle_enter(0);
> > + enable_stack_tracer();
> > local_irq_restore(flags);
> > }
> > EXPORT_SYMBOL_GPL(rcu_idle_enter);
>
> That only covers one of two code paths, and still end up with the
> trace code thinking that RCU is paying attention to it when it really
> is not.
OK, that sounds like a separate bug to what I'm tracking.
>
> But if there is a disable_stack_tracer() and enable_stack_tracer(),
> I could use them as shown below. (Hand-edited patch, probably doesn't
> apply, let alone build.)
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit 1a11d6fd0ae344f7dccd57d3c587d9ef2a4bf08e
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date: Wed Apr 5 09:05:18 2017 -0700
>
> rcu: Fix dyntick-idle tracing
>
> The tracing subsystem started using rcu_irq_entry() and rcu_irq_exit()
> (with my blessing) to allow the current _rcuidle alternative tracepoint
> name to be dispensed with while still maintaining good performance.
> Unfortunately, this causes RCU's dyntick-idle entry code's tracing to
> appear to RCU like an interrupt that occurs where RCU is not designed
> to handle interrupts.
>
> This commit fixes this problem by moving the zeroing of ->dynticks_nesting
> after the offending trace_rcu_dyntick() statement, which narrows the
> window of vulnerability to a pair of adjacent statements that are now
> marked with comments to that effect.
>
> Reported-by: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 50fee7689e71..7308c88ee57a 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -771,25 +771,24 @@ cpu_needs_another_gp(struct rcu_state *rsp, struct rcu_data *rdp)
> }
>
> /*
> - * rcu_eqs_enter_common - current CPU is moving towards extended quiescent state
> + * rcu_eqs_enter_common - current CPU is entering an extended quiescent state
> *
> - * If the new value of the ->dynticks_nesting counter now is zero,
> - * we really have entered idle, and must do the appropriate accounting.
> - * The caller must have disabled interrupts.
> + * Enter idle, doing appropriate accounting. The caller must have
> + * disabled interrupts.
> */
> -static void rcu_eqs_enter_common(long long oldval, bool user)
> +static void rcu_eqs_enter_common(bool user)
> {
> struct rcu_state *rsp;
> struct rcu_data *rdp;
> - RCU_TRACE(struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);)
> + struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
>
> - trace_rcu_dyntick(TPS("Start"), oldval, rdtp->dynticks_nesting);
> + trace_rcu_dyntick(TPS("Start"), rdtp->dynticks_nesting, 0);
> if (IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> !user && !is_idle_task(current)) {
> struct task_struct *idle __maybe_unused =
> idle_task(smp_processor_id());
>
> - trace_rcu_dyntick(TPS("Error on entry: not idle task"), oldval, 0);
> + trace_rcu_dyntick(TPS("Error on entry: not idle task"), rdtp->dynticks_nesting, 0);
> rcu_ftrace_dump(DUMP_ORIG);
> WARN_ONCE(1, "Current pid: %d comm: %s / Idle pid: %d comm: %s",
> current->pid, current->comm,
> @@ -800,7 +799,8 @@ static void rcu_eqs_enter_common(long long oldval, bool user)
> do_nocb_deferred_wakeup(rdp);
> }
> rcu_prepare_for_idle();
> - rcu_dynticks_eqs_enter();
> + disable_stack_tracer();
> + rdtp->dynticks_nesting = 0; /* Breaks tracing momentarily. */
> + rcu_dynticks_eqs_enter(); /* After this, tracing works again. */
> + enable_stack_tracer();
OK, do you want me to send you a patch, or should I take your patch
into my tree and add this?
-- Steve
> rcu_dynticks_task_enter();
>
> /*
> @@ -821,19 +821,15 @@ static void rcu_eqs_enter_common(long long oldval, bool user)
> */
> static void rcu_eqs_enter(bool user)
> {
> - long long oldval;
> struct rcu_dynticks *rdtp;
>
> rdtp = this_cpu_ptr(&rcu_dynticks);
> - oldval = rdtp->dynticks_nesting;
> WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> - (oldval & DYNTICK_TASK_NEST_MASK) == 0);
> - if ((oldval & DYNTICK_TASK_NEST_MASK) == DYNTICK_TASK_NEST_VALUE) {
> - rdtp->dynticks_nesting = 0;
> - rcu_eqs_enter_common(oldval, user);
> - } else {
> + (rdtp->dynticks_nesting & DYNTICK_TASK_NEST_MASK) == 0);
> + if ((rdtp->dynticks_nesting & DYNTICK_TASK_NEST_MASK) == DYNTICK_TASK_NEST_VALUE)
> + rcu_eqs_enter_common(user);
> + else
> rdtp->dynticks_nesting -= DYNTICK_TASK_NEST_VALUE;
> - }
> }
>
> /**
> @@ -892,19 +888,18 @@ void rcu_user_enter(void)
> */
> void rcu_irq_exit(void)
> {
> - long long oldval;
> struct rcu_dynticks *rdtp;
>
> RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_irq_exit() invoked with irqs enabled!!!");
> rdtp = this_cpu_ptr(&rcu_dynticks);
> - oldval = rdtp->dynticks_nesting;
> - rdtp->dynticks_nesting--;
> WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> - rdtp->dynticks_nesting < 0);
> - if (rdtp->dynticks_nesting)
> - trace_rcu_dyntick(TPS("--="), oldval, rdtp->dynticks_nesting);
> - else
> - rcu_eqs_enter_common(oldval, true);
> + rdtp->dynticks_nesting < 1);
> + if (rdtp->dynticks_nesting <= 1) {
> + rcu_eqs_enter_common(true);
> + } else {
> + trace_rcu_dyntick(TPS("--="), rdtp->dynticks_nesting, rdtp->dynticks_nesting - 1);
> + rdtp->dynticks_nesting--;
> + }
> rcu_sysidle_enter(1);
> }
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 07/13] block: Use simpler QDict/QList scalar insertion macros
From: Richard W.M. Jones @ 2017-04-05 19:51 UTC (permalink / raw)
To: Eric Blake
Cc: qemu-devel, armbru, Kevin Wolf, Max Reitz, Stefan Hajnoczi,
Jeff Cody, Stefan Weil, Ronnie Sahlberg, Paolo Bonzini,
Peter Lieven, Fam Zheng, Alberto Garcia, Josh Durgin,
open list:blkdebug
In-Reply-To: <20170405194741.18956-8-eblake@redhat.com>
On Wed, Apr 05, 2017 at 02:47:35PM -0500, Eric Blake wrote:
> We now have macros in place to make it less verbose to add a scalar
> to QDict and QList, so use them.
>
> Patch created mechanically via:
> spatch --sp-file scripts/coccinelle/qobject.cocci \
> --macro-file scripts/cocci-macro-file.h --dir block --in-place
> then touched up manually to fix a couple of '?:' back to original spacing.
It seems a trivial change to me, ACK.
Rich.
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
> block/blkdebug.c | 6 +++---
> block/blkverify.c | 6 +++---
> block/curl.c | 2 +-
> block/file-posix.c | 8 ++++----
> block/file-win32.c | 4 ++--
> block/iscsi.c | 2 +-
> block/nbd.c | 41 ++++++++++++++++++++---------------------
> block/nfs.c | 43 +++++++++++++++++--------------------------
> block/null.c | 2 +-
> block/qcow2.c | 4 ++--
> block/quorum.c | 8 ++++----
> block/rbd.c | 16 ++++++++--------
> block/ssh.c | 16 +++++++---------
> block/vvfat.c | 10 +++++-----
> 14 files changed, 78 insertions(+), 90 deletions(-)
>
> diff --git a/block/blkdebug.c b/block/blkdebug.c
> index c5d4772..f69e136 100644
> --- a/block/blkdebug.c
> +++ b/block/blkdebug.c
> @@ -301,7 +301,7 @@ static void blkdebug_parse_filename(const char *filename, QDict *options,
> if (!strstart(filename, "blkdebug:", &filename)) {
> /* There was no prefix; therefore, all options have to be already
> present in the QDict (except for the filename) */
> - qdict_put(options, "x-image", qstring_from_str(filename));
> + qdict_put_str(options, "x-image", filename);
> return;
> }
>
> @@ -320,7 +320,7 @@ static void blkdebug_parse_filename(const char *filename, QDict *options,
>
> /* TODO Allow multi-level nesting and set file.filename here */
> filename = c + 1;
> - qdict_put(options, "x-image", qstring_from_str(filename));
> + qdict_put_str(options, "x-image", filename);
> }
>
> static QemuOptsList runtime_opts = {
> @@ -695,7 +695,7 @@ static void blkdebug_refresh_filename(BlockDriverState *bs, QDict *options)
> }
>
> opts = qdict_new();
> - qdict_put(opts, "driver", qstring_from_str("blkdebug"));
> + qdict_put_str(opts, "driver", "blkdebug");
>
> QINCREF(bs->file->bs->full_open_options);
> qdict_put(opts, "image", bs->file->bs->full_open_options);
> diff --git a/block/blkverify.c b/block/blkverify.c
> index 79c8914..5c7d506 100644
> --- a/block/blkverify.c
> +++ b/block/blkverify.c
> @@ -67,7 +67,7 @@ static void blkverify_parse_filename(const char *filename, QDict *options,
> if (!strstart(filename, "blkverify:", &filename)) {
> /* There was no prefix; therefore, all options have to be already
> present in the QDict (except for the filename) */
> - qdict_put(options, "x-image", qstring_from_str(filename));
> + qdict_put_str(options, "x-image", filename);
> return;
> }
>
> @@ -84,7 +84,7 @@ static void blkverify_parse_filename(const char *filename, QDict *options,
>
> /* TODO Allow multi-level nesting and set file.filename here */
> filename = c + 1;
> - qdict_put(options, "x-image", qstring_from_str(filename));
> + qdict_put_str(options, "x-image", filename);
> }
>
> static QemuOptsList runtime_opts = {
> @@ -291,7 +291,7 @@ static void blkverify_refresh_filename(BlockDriverState *bs, QDict *options)
> && s->test_file->bs->full_open_options)
> {
> QDict *opts = qdict_new();
> - qdict_put(opts, "driver", qstring_from_str("blkverify"));
> + qdict_put_str(opts, "driver", "blkverify");
>
> QINCREF(bs->file->bs->full_open_options);
> qdict_put(opts, "raw", bs->file->bs->full_open_options);
> diff --git a/block/curl.c b/block/curl.c
> index 2708d57..aa6e8cc 100644
> --- a/block/curl.c
> +++ b/block/curl.c
> @@ -548,7 +548,7 @@ static void curl_clean_state(CURLState *s)
> static void curl_parse_filename(const char *filename, QDict *options,
> Error **errp)
> {
> - qdict_put(options, CURL_BLOCK_OPT_URL, qstring_from_str(filename));
> + qdict_put_str(options, CURL_BLOCK_OPT_URL, filename);
> }
>
> static void curl_detach_aio_context(BlockDriverState *bs)
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 5370ba0..9431ad1 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -377,7 +377,7 @@ static void raw_parse_filename(const char *filename, QDict *options,
> * function call can be ignored. */
> strstart(filename, "file:", &filename);
>
> - qdict_put(options, "filename", qstring_from_str(filename));
> + qdict_put_str(options, "filename", filename);
> }
>
> static QemuOptsList raw_runtime_opts = {
> @@ -2150,7 +2150,7 @@ static void hdev_parse_filename(const char *filename, QDict *options,
> /* The prefix is optional, just as for "file". */
> strstart(filename, "host_device:", &filename);
>
> - qdict_put(options, "filename", qstring_from_str(filename));
> + qdict_put_str(options, "filename", filename);
> }
>
> static bool hdev_is_sg(BlockDriverState *bs)
> @@ -2239,7 +2239,7 @@ static int hdev_open(BlockDriverState *bs, QDict *options, int flags,
> goto hdev_open_Mac_error;
> }
>
> - qdict_put(options, "filename", qstring_from_str(bsd_path));
> + qdict_put_str(options, "filename", bsd_path);
>
> hdev_open_Mac_error:
> g_free(mediaType);
> @@ -2449,7 +2449,7 @@ static void cdrom_parse_filename(const char *filename, QDict *options,
> /* The prefix is optional, just as for "file". */
> strstart(filename, "host_cdrom:", &filename);
>
> - qdict_put(options, "filename", qstring_from_str(filename));
> + qdict_put_str(options, "filename", filename);
> }
> #endif
>
> diff --git a/block/file-win32.c b/block/file-win32.c
> index 57c4a78..0d455d1 100644
> --- a/block/file-win32.c
> +++ b/block/file-win32.c
> @@ -282,7 +282,7 @@ static void raw_parse_filename(const char *filename, QDict *options,
> * function call can be ignored. */
> strstart(filename, "file:", &filename);
>
> - qdict_put(options, "filename", qstring_from_str(filename));
> + qdict_put_str(options, "filename", filename);
> }
>
> static QemuOptsList raw_runtime_opts = {
> @@ -669,7 +669,7 @@ static void hdev_parse_filename(const char *filename, QDict *options,
> /* The prefix is optional, just as for "file". */
> strstart(filename, "host_device:", &filename);
>
> - qdict_put(options, "filename", qstring_from_str(filename));
> + qdict_put_str(options, "filename", filename);
> }
>
> static int hdev_open(BlockDriverState *bs, QDict *options, int flags,
> diff --git a/block/iscsi.c b/block/iscsi.c
> index 716e74a..1534ab6 100644
> --- a/block/iscsi.c
> +++ b/block/iscsi.c
> @@ -2102,7 +2102,7 @@ static int iscsi_create(const char *filename, QemuOpts *opts, Error **errp)
> iscsilun = bs->opaque;
>
> bs_options = qdict_new();
> - qdict_put(bs_options, "filename", qstring_from_str(filename));
> + qdict_put_str(bs_options, "filename", filename);
> ret = iscsi_open(bs, bs_options, 0, NULL);
> QDECREF(bs_options);
>
> diff --git a/block/nbd.c b/block/nbd.c
> index 814ab26d..b3545f5 100644
> --- a/block/nbd.c
> +++ b/block/nbd.c
> @@ -79,7 +79,7 @@ static int nbd_parse_uri(const char *filename, QDict *options)
> p = uri->path ? uri->path : "/";
> p += strspn(p, "/");
> if (p[0]) {
> - qdict_put(options, "export", qstring_from_str(p));
> + qdict_put_str(options, "export", p);
> }
>
> qp = query_params_parse(uri->query);
> @@ -94,9 +94,8 @@ static int nbd_parse_uri(const char *filename, QDict *options)
> ret = -EINVAL;
> goto out;
> }
> - qdict_put(options, "server.type", qstring_from_str("unix"));
> - qdict_put(options, "server.path",
> - qstring_from_str(qp->p[0].value));
> + qdict_put_str(options, "server.type", "unix");
> + qdict_put_str(options, "server.path", qp->p[0].value);
> } else {
> QString *host;
> char *port_str;
> @@ -115,11 +114,11 @@ static int nbd_parse_uri(const char *filename, QDict *options)
> host = qstring_from_str(uri->server);
> }
>
> - qdict_put(options, "server.type", qstring_from_str("inet"));
> + qdict_put_str(options, "server.type", "inet");
> qdict_put(options, "server.host", host);
>
> port_str = g_strdup_printf("%d", uri->port ?: NBD_DEFAULT_PORT);
> - qdict_put(options, "server.port", qstring_from_str(port_str));
> + qdict_put_str(options, "server.port", port_str);
> g_free(port_str);
> }
>
> @@ -181,7 +180,7 @@ static void nbd_parse_filename(const char *filename, QDict *options,
> export_name[0] = 0; /* truncate 'file' */
> export_name += strlen(EN_OPTSTR);
>
> - qdict_put(options, "export", qstring_from_str(export_name));
> + qdict_put_str(options, "export", export_name);
> }
>
> /* extract the host_spec - fail if it's not nbd:... */
> @@ -196,8 +195,8 @@ static void nbd_parse_filename(const char *filename, QDict *options,
>
> /* are we a UNIX or TCP socket? */
> if (strstart(host_spec, "unix:", &unixpath)) {
> - qdict_put(options, "server.type", qstring_from_str("unix"));
> - qdict_put(options, "server.path", qstring_from_str(unixpath));
> + qdict_put_str(options, "server.type", "unix");
> + qdict_put_str(options, "server.path", unixpath);
> } else {
> InetSocketAddress *addr = NULL;
>
> @@ -206,9 +205,9 @@ static void nbd_parse_filename(const char *filename, QDict *options,
> goto out;
> }
>
> - qdict_put(options, "server.type", qstring_from_str("inet"));
> - qdict_put(options, "server.host", qstring_from_str(addr->host));
> - qdict_put(options, "server.port", qstring_from_str(addr->port));
> + qdict_put_str(options, "server.type", "inet");
> + qdict_put_str(options, "server.host", addr->host);
> + qdict_put_str(options, "server.port", addr->port);
> qapi_free_InetSocketAddress(addr);
> }
>
> @@ -247,13 +246,13 @@ static bool nbd_process_legacy_socket_options(QDict *output_options,
> return false;
> }
>
> - qdict_put(output_options, "server.type", qstring_from_str("unix"));
> - qdict_put(output_options, "server.path", qstring_from_str(path));
> + qdict_put_str(output_options, "server.type", "unix");
> + qdict_put_str(output_options, "server.path", path);
> } else if (host) {
> - qdict_put(output_options, "server.type", qstring_from_str("inet"));
> - qdict_put(output_options, "server.host", qstring_from_str(host));
> - qdict_put(output_options, "server.port",
> - qstring_from_str(port ?: stringify(NBD_DEFAULT_PORT)));
> + qdict_put_str(output_options, "server.type", "inet");
> + qdict_put_str(output_options, "server.host", host);
> + qdict_put_str(output_options, "server.port",
> + port ?: stringify(NBD_DEFAULT_PORT));
> }
>
> return true;
> @@ -528,7 +527,7 @@ static void nbd_refresh_filename(BlockDriverState *bs, QDict *options)
> path = s->saddr->u.q_unix.path;
> } /* else can't represent as pseudo-filename */
>
> - qdict_put(opts, "driver", qstring_from_str("nbd"));
> + qdict_put_str(opts, "driver", "nbd");
>
> if (path && s->export) {
> snprintf(bs->exact_filename, sizeof(bs->exact_filename),
> @@ -551,10 +550,10 @@ static void nbd_refresh_filename(BlockDriverState *bs, QDict *options)
> qdict_put_obj(opts, "server", saddr_qdict);
>
> if (s->export) {
> - qdict_put(opts, "export", qstring_from_str(s->export));
> + qdict_put_str(opts, "export", s->export);
> }
> if (s->tlscredsid) {
> - qdict_put(opts, "tls-creds", qstring_from_str(s->tlscredsid));
> + qdict_put_str(opts, "tls-creds", s->tlscredsid);
> }
>
> qdict_flatten(opts);
> diff --git a/block/nfs.c b/block/nfs.c
> index 0816678..bfeebc1 100644
> --- a/block/nfs.c
> +++ b/block/nfs.c
> @@ -104,9 +104,9 @@ static int nfs_parse_uri(const char *filename, QDict *options, Error **errp)
> goto out;
> }
>
> - qdict_put(options, "server.host", qstring_from_str(uri->server));
> - qdict_put(options, "server.type", qstring_from_str("inet"));
> - qdict_put(options, "path", qstring_from_str(uri->path));
> + qdict_put_str(options, "server.host", uri->server);
> + qdict_put_str(options, "server.type", "inet");
> + qdict_put_str(options, "path", uri->path);
>
> for (i = 0; i < qp->n; i++) {
> unsigned long long val;
> @@ -121,23 +121,17 @@ static int nfs_parse_uri(const char *filename, QDict *options, Error **errp)
> goto out;
> }
> if (!strcmp(qp->p[i].name, "uid")) {
> - qdict_put(options, "user",
> - qstring_from_str(qp->p[i].value));
> + qdict_put_str(options, "user", qp->p[i].value);
> } else if (!strcmp(qp->p[i].name, "gid")) {
> - qdict_put(options, "group",
> - qstring_from_str(qp->p[i].value));
> + qdict_put_str(options, "group", qp->p[i].value);
> } else if (!strcmp(qp->p[i].name, "tcp-syncnt")) {
> - qdict_put(options, "tcp-syn-count",
> - qstring_from_str(qp->p[i].value));
> + qdict_put_str(options, "tcp-syn-count", qp->p[i].value);
> } else if (!strcmp(qp->p[i].name, "readahead")) {
> - qdict_put(options, "readahead-size",
> - qstring_from_str(qp->p[i].value));
> + qdict_put_str(options, "readahead-size", qp->p[i].value);
> } else if (!strcmp(qp->p[i].name, "pagecache")) {
> - qdict_put(options, "page-cache-size",
> - qstring_from_str(qp->p[i].value));
> + qdict_put_str(options, "page-cache-size", qp->p[i].value);
> } else if (!strcmp(qp->p[i].name, "debug")) {
> - qdict_put(options, "debug",
> - qstring_from_str(qp->p[i].value));
> + qdict_put_str(options, "debug", qp->p[i].value);
> } else {
> error_setg(errp, "Unknown NFS parameter name: %s",
> qp->p[i].name);
> @@ -811,7 +805,7 @@ static void nfs_refresh_filename(BlockDriverState *bs, QDict *options)
> QObject *server_qdict;
> Visitor *ov;
>
> - qdict_put(opts, "driver", qstring_from_str("nfs"));
> + qdict_put_str(opts, "driver", "nfs");
>
> if (client->uid && !client->gid) {
> snprintf(bs->exact_filename, sizeof(bs->exact_filename),
> @@ -834,28 +828,25 @@ static void nfs_refresh_filename(BlockDriverState *bs, QDict *options)
> visit_type_NFSServer(ov, NULL, &client->server, &error_abort);
> visit_complete(ov, &server_qdict);
> qdict_put_obj(opts, "server", server_qdict);
> - qdict_put(opts, "path", qstring_from_str(client->path));
> + qdict_put_str(opts, "path", client->path);
>
> if (client->uid) {
> - qdict_put(opts, "user", qint_from_int(client->uid));
> + qdict_put_int(opts, "user", client->uid);
> }
> if (client->gid) {
> - qdict_put(opts, "group", qint_from_int(client->gid));
> + qdict_put_int(opts, "group", client->gid);
> }
> if (client->tcp_syncnt) {
> - qdict_put(opts, "tcp-syn-cnt",
> - qint_from_int(client->tcp_syncnt));
> + qdict_put_int(opts, "tcp-syn-cnt", client->tcp_syncnt);
> }
> if (client->readahead) {
> - qdict_put(opts, "readahead-size",
> - qint_from_int(client->readahead));
> + qdict_put_int(opts, "readahead-size", client->readahead);
> }
> if (client->pagecache) {
> - qdict_put(opts, "page-cache-size",
> - qint_from_int(client->pagecache));
> + qdict_put_int(opts, "page-cache-size", client->pagecache);
> }
> if (client->debug) {
> - qdict_put(opts, "debug", qint_from_int(client->debug));
> + qdict_put_int(opts, "debug", client->debug);
> }
>
> visit_free(ov);
> diff --git a/block/null.c b/block/null.c
> index b300390..876f909 100644
> --- a/block/null.c
> +++ b/block/null.c
> @@ -232,7 +232,7 @@ static void null_refresh_filename(BlockDriverState *bs, QDict *opts)
> bs->drv->format_name);
> }
>
> - qdict_put(opts, "driver", qstring_from_str(bs->drv->format_name));
> + qdict_put_str(opts, "driver", bs->drv->format_name);
> bs->full_open_options = opts;
> }
>
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 6a92d2e..49c737f 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -2265,7 +2265,7 @@ static int qcow2_create2(const char *filename, int64_t total_size,
> * table)
> */
> options = qdict_new();
> - qdict_put(options, "driver", qstring_from_str("qcow2"));
> + qdict_put_str(options, "driver", "qcow2");
> blk = blk_new_open(filename, NULL, options,
> BDRV_O_RDWR | BDRV_O_RESIZE | BDRV_O_NO_FLUSH,
> &local_err);
> @@ -2327,7 +2327,7 @@ static int qcow2_create2(const char *filename, int64_t total_size,
>
> /* Reopen the image without BDRV_O_NO_FLUSH to flush it before returning */
> options = qdict_new();
> - qdict_put(options, "driver", qstring_from_str("qcow2"));
> + qdict_put_str(options, "driver", "qcow2");
> blk = blk_new_open(filename, NULL, options,
> BDRV_O_RDWR | BDRV_O_NO_BACKING, &local_err);
> if (blk == NULL) {
> diff --git a/block/quorum.c b/block/quorum.c
> index f7949e2..1b2a8c3 100644
> --- a/block/quorum.c
> +++ b/block/quorum.c
> @@ -1100,10 +1100,10 @@ static void quorum_refresh_filename(BlockDriverState *bs, QDict *options)
> }
>
> opts = qdict_new();
> - qdict_put(opts, "driver", qstring_from_str("quorum"));
> - qdict_put(opts, QUORUM_OPT_VOTE_THRESHOLD, qint_from_int(s->threshold));
> - qdict_put(opts, QUORUM_OPT_BLKVERIFY, qbool_from_bool(s->is_blkverify));
> - qdict_put(opts, QUORUM_OPT_REWRITE, qbool_from_bool(s->rewrite_corrupted));
> + qdict_put_str(opts, "driver", "quorum");
> + qdict_put_int(opts, QUORUM_OPT_VOTE_THRESHOLD, s->threshold);
> + qdict_put_bool(opts, QUORUM_OPT_BLKVERIFY, s->is_blkverify);
> + qdict_put_bool(opts, QUORUM_OPT_REWRITE, s->rewrite_corrupted);
> qdict_put(opts, "children", children);
>
> bs->full_open_options = opts;
> diff --git a/block/rbd.c b/block/rbd.c
> index 1ceeeb5..2354ffc 100644
> --- a/block/rbd.c
> +++ b/block/rbd.c
> @@ -154,20 +154,20 @@ static void qemu_rbd_parse_filename(const char *filename, QDict *options,
> goto done;
> }
> qemu_rbd_unescape(found_str);
> - qdict_put(options, "pool", qstring_from_str(found_str));
> + qdict_put_str(options, "pool", found_str);
>
> if (strchr(p, '@')) {
> found_str = qemu_rbd_next_tok(p, '@', &p);
> qemu_rbd_unescape(found_str);
> - qdict_put(options, "image", qstring_from_str(found_str));
> + qdict_put_str(options, "image", found_str);
>
> found_str = qemu_rbd_next_tok(p, ':', &p);
> qemu_rbd_unescape(found_str);
> - qdict_put(options, "snapshot", qstring_from_str(found_str));
> + qdict_put_str(options, "snapshot", found_str);
> } else {
> found_str = qemu_rbd_next_tok(p, ':', &p);
> qemu_rbd_unescape(found_str);
> - qdict_put(options, "image", qstring_from_str(found_str));
> + qdict_put_str(options, "image", found_str);
> }
> if (!p) {
> goto done;
> @@ -189,9 +189,9 @@ static void qemu_rbd_parse_filename(const char *filename, QDict *options,
> qemu_rbd_unescape(value);
>
> if (!strcmp(name, "conf")) {
> - qdict_put(options, "conf", qstring_from_str(value));
> + qdict_put_str(options, "conf", value);
> } else if (!strcmp(name, "id")) {
> - qdict_put(options, "user" , qstring_from_str(value));
> + qdict_put_str(options, "user", value);
> } else {
> /*
> * We pass these internally to qemu_rbd_set_keypairs(), so
> @@ -204,8 +204,8 @@ static void qemu_rbd_parse_filename(const char *filename, QDict *options,
> if (!keypairs) {
> keypairs = qlist_new();
> }
> - qlist_append(keypairs, qstring_from_str(name));
> - qlist_append(keypairs, qstring_from_str(value));
> + qlist_append_str(keypairs, name);
> + qlist_append_str(keypairs, value);
> }
> }
>
> diff --git a/block/ssh.c b/block/ssh.c
> index 471ba8a..34a2f79 100644
> --- a/block/ssh.c
> +++ b/block/ssh.c
> @@ -227,24 +227,23 @@ static int parse_uri(const char *filename, QDict *options, Error **errp)
> }
>
> if(uri->user && strcmp(uri->user, "") != 0) {
> - qdict_put(options, "user", qstring_from_str(uri->user));
> + qdict_put_str(options, "user", uri->user);
> }
>
> - qdict_put(options, "server.host", qstring_from_str(uri->server));
> + qdict_put_str(options, "server.host", uri->server);
>
> port_str = g_strdup_printf("%d", uri->port ?: 22);
> - qdict_put(options, "server.port", qstring_from_str(port_str));
> + qdict_put_str(options, "server.port", port_str);
> g_free(port_str);
>
> - qdict_put(options, "path", qstring_from_str(uri->path));
> + qdict_put_str(options, "path", uri->path);
>
> /* Pick out any query parameters that we understand, and ignore
> * the rest.
> */
> for (i = 0; i < qp->n; ++i) {
> if (strcmp(qp->p[i].name, "host_key_check") == 0) {
> - qdict_put(options, "host_key_check",
> - qstring_from_str(qp->p[i].value));
> + qdict_put_str(options, "host_key_check", qp->p[i].value);
> }
> }
>
> @@ -574,9 +573,8 @@ static bool ssh_process_legacy_socket_options(QDict *output_opts,
> }
>
> if (host) {
> - qdict_put(output_opts, "server.host", qstring_from_str(host));
> - qdict_put(output_opts, "server.port",
> - qstring_from_str(port ?: stringify(22)));
> + qdict_put_str(output_opts, "server.host", host);
> + qdict_put_str(output_opts, "server.port", port ?: stringify(22));
> }
>
> return true;
> diff --git a/block/vvfat.c b/block/vvfat.c
> index af5153d..8b4e4eb 100644
> --- a/block/vvfat.c
> +++ b/block/vvfat.c
> @@ -1057,10 +1057,10 @@ static void vvfat_parse_filename(const char *filename, QDict *options,
> }
>
> /* Fill in the options QDict */
> - qdict_put(options, "dir", qstring_from_str(filename));
> - qdict_put(options, "fat-type", qint_from_int(fat_type));
> - qdict_put(options, "floppy", qbool_from_bool(floppy));
> - qdict_put(options, "rw", qbool_from_bool(rw));
> + qdict_put_str(options, "dir", filename);
> + qdict_put_int(options, "fat-type", fat_type);
> + qdict_put_bool(options, "floppy", floppy);
> + qdict_put_bool(options, "rw", rw);
> }
>
> static int vvfat_open(BlockDriverState *bs, QDict *options, int flags,
> @@ -3040,7 +3040,7 @@ static int enable_write_target(BlockDriverState *bs, Error **errp)
> }
>
> options = qdict_new();
> - qdict_put(options, "write-target.driver", qstring_from_str("qcow"));
> + qdict_put_str(options, "write-target.driver", "qcow");
> s->qcow = bdrv_open_child(s->qcow_filename, options, "write-target", bs,
> &child_vvfat_qcow, false, errp);
> QDECREF(options);
> --
> 2.9.3
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
^ permalink raw reply
* Re: [PATCH v3 2/2] ASoC: fsl_ssi: Use the tolower() function
From: Timur Tabi @ 2017-04-05 19:51 UTC (permalink / raw)
To: Fabio Estevam, broonie; +Cc: nicoleotsuka, Fabio Estevam, alsa-devel
In-Reply-To: <1491421446-13799-2-git-send-email-festevam@gmail.com>
On 04/05/2017 02:44 PM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Code can be simplified by using the standard tolower() funtion.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
ACK
^ permalink raw reply
* Re: [PATCH v3 1/2] ASoC: fsl_ssi: Remove FSLSSI_I2S_RATES definition
From: Timur Tabi @ 2017-04-05 19:51 UTC (permalink / raw)
To: Fabio Estevam, broonie; +Cc: nicoleotsuka, Fabio Estevam, alsa-devel
In-Reply-To: <1491421446-13799-1-git-send-email-festevam@gmail.com>
On 04/05/2017 02:44 PM, Fabio Estevam wrote:
>
> The comment for the FSLSSI_I2S_RATES definition states that the
> driver currently only supports I2S slave mode, which is no longer
> correct.
>
> As FSLSSI_I2S_RATES is the same as the standard SNDRV_PCM_RATE_CONTINUOUS,
> just remove its definition and its comments to make the code simpler.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
ACK
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.