* [PATCH] [media] v4l2-core: fix use-after-free error
From: Sumit Gupta @ 2019-04-10 14:28 UTC (permalink / raw)
To: mchehab, hverkuil-cisco, sakari.ailus, paul.kocialkowski, tfiga,
keiichiw, sumitg
Cc: linux-media, linux-kernel
From: sumitg <sumitg@nvidia.com>
Fixing use-after-free within __v4l2_ctrl_handler_setup().
Memory is being freed with kfree(new_ref) for duplicate
control reference entry but cluster is still referring
to the duplicate entry. Change done to point cluster to
original reference instead of duplicate which is freed.
==================================================================
BUG: KASAN: use-after-free in __v4l2_ctrl_handler_setup+0x388/0x428
Read of size 8 at addr ffffffc324e78618 by task systemd-udevd/312
Allocated by task 312:
Freed by task 312:
The buggy address belongs to the object at ffffffc324e78600
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 24 bytes inside of
64-byte region [ffffffc324e78600, ffffffc324e78640)
The buggy address belongs to the page:
page:ffffffbf0c939e00 count:1 mapcount:0 mapping:
(null) index:0xffffffc324e78f80
flags: 0x4000000000000100(slab)
raw: 4000000000000100 0000000000000000 ffffffc324e78f80 000000018020001a
raw: 0000000000000000 0000000100000001 ffffffc37040fb80 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffffc324e78500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffffffc324e78580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>ffffffc324e78600: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffffffc324e78680: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffffffc324e78700: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Signed-off-by: sumitg <sumitg@nvidia.com>
---
drivers/media/v4l2-core/v4l2-ctrls.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index 5e3806f..e971bab 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2182,6 +2182,7 @@ static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
continue;
/* Don't add duplicates */
if (ref->ctrl->id == id) {
+ ctrl->cluster = &ref->ctrl;
kfree(new_ref);
goto unlock;
}
--
2.7.4
^ permalink raw reply related
* [OSSTEST PATCH 62/62] Switch to Debian Stretch
From: Ian Jackson @ 2019-04-10 14:24 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson, Wei Liu
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
From: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Osstest.pm | 2 +-
production-config | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Osstest.pm b/Osstest.pm
index 92b1a0ea..7ce53fcb 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -87,7 +87,7 @@ our %c = qw(
Images images
- DebianSuite jessie
+ DebianSuite stretch
DebianMirrorSubpath debian
TestHostKeypairPath id_rsa_osstest
diff --git a/production-config b/production-config
index fadfe8b9..5b9f5c82 100644
--- a/production-config
+++ b/production-config
@@ -90,12 +90,14 @@ TftpNetbootGroup osstest
# Update with ./mg-debian-installer-update(-all)
TftpDiVersion_wheezy 2016-06-08
TftpDiVersion_jessie 2018-06-26
+TftpDiVersion_stretch 2018-11-27
DebianSnapshotBackports_jessie http://snapshot.debian.org/archive/debian/20190206T211314Z/
# For ISO installs
DebianImageVersion_wheezy 7.2.0
DebianImageVersion_jessie 8.2.0
+DebianImageVersion_stretch 9.4.0
# These should normally be the same.
# Update with ./mg-cpu-microcode-update
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH for-4.1] q35: acpi: do not create dummy MCFG table
From: Wei Yang @ 2019-04-10 14:27 UTC (permalink / raw)
To: Igor Mammedov; +Cc: qemu-devel, mst, marcel.apfelbaum, ehabkost, richardw.yang
In-Reply-To: <1554822037-329838-1-git-send-email-imammedo@redhat.com>
On Tue, Apr 09, 2019 at 05:00:37PM +0200, Igor Mammedov wrote:
>Dummy table (with signature "QEMU") creation came from original SeaBIOS
>codebase. And QEMU would have to keep it around if there were Q35 machine
>that depended on keeping ACPI tables blob constant size. Luckily there
>were no versioned Q35 machine types before commit:
> (since 2.3) a1666142db acpi-build: make ROMs RAM blocks resizeable
>which obsoleted need to keep ACPI tables blob the same size on source/destination.
I think we should keep table blob the same size on source/destination.
But with resizable MemoryRegion, we don't need to reserve some dummy space.
Because we can expand it later.
>
>Considering the 1st versioned machine is pc-q35-2.4, the dummy table
>is not really necessary and it's safe to drop it without breaking
>cross version migration in both directions unconditionally.
>
>Signed-off-by: Igor Mammedov <imammedo@redhat.com>
>---
> hw/i386/acpi-build.c | 18 ++++--------------
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
>diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>index 416da31..8671e25 100644
>--- a/hw/i386/acpi-build.c
>+++ b/hw/i386/acpi-build.c
>@@ -2401,7 +2401,6 @@ static void
> build_mcfg_q35(GArray *table_data, BIOSLinker *linker, AcpiMcfgInfo *info)
> {
> AcpiTableMcfg *mcfg;
>- const char *sig;
> int len = sizeof(*mcfg) + 1 * sizeof(mcfg->allocation[0]);
>
> mcfg = acpi_data_push(table_data, len);
>@@ -2411,19 +2410,7 @@ build_mcfg_q35(GArray *table_data, BIOSLinker *linker, AcpiMcfgInfo *info)
> mcfg->allocation[0].start_bus_number = 0;
> mcfg->allocation[0].end_bus_number = PCIE_MMCFG_BUS(info->mcfg_size - 1);
>
>- /* MCFG is used for ECAM which can be enabled or disabled by guest.
I want to cnfirm what is "enabled or disabled by guest" here.
If we don't reserve mcfg and "guest" enable mcfg during running, the ACPI
table size changed. But the destination still has the original table size,
since destination "guest" keep sleep during this period.
Now the migration would face table size difference and break migration?
>- * To avoid table size changes (which create migration issues),
>- * always create the table even if there are no allocations,
>- * but set the signature to a reserved value in this case.
>- * ACPI spec requires OSPMs to ignore such tables.
>- */
>- if (info->mcfg_base == PCIE_BASE_ADDR_UNMAPPED) {
>- /* Reserved signature: ignored by OSPM */
>- sig = "QEMU";
>- } else {
>- sig = "MCFG";
>- }
>- build_header(linker, table_data, (void *)mcfg, sig, len, 1, NULL, NULL);
>+ build_header(linker, table_data, (void *)mcfg, "MCFG", len, 1, NULL, NULL);
> }
>
> /*
>@@ -2592,6 +2579,9 @@ static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg)
> }
> mcfg->mcfg_base = qnum_get_uint(qobject_to(QNum, o));
> qobject_unref(o);
>+ if (mcfg->mcfg_base == PCIE_BASE_ADDR_UNMAPPED) {
>+ return false;
>+ }
>
> o = object_property_get_qobject(pci_host, PCIE_HOST_MCFG_SIZE, NULL);
> assert(o);
>--
>2.7.4
--
Wei Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH 3/3] drm/amdgpu: Avoid HW reset if guilty job already signaled.
From: Grodzovsky, Andrey @ 2019-04-10 14:28 UTC (permalink / raw)
To: Koenig, Christian, dri-devel@lists.freedesktop.org,
amd-gfx@lists.freedesktop.org, etnaviv@lists.freedesktop.org,
eric@anholt.net
In-Reply-To: <2e4a76c7-dcba-4c8f-359b-bd30c4cf048f@gmail.com>
On 4/10/19 10:06 AM, Christian König wrote:
> Am 09.04.19 um 18:42 schrieb Grodzovsky, Andrey:
>> On 4/9/19 10:50 AM, Christian König wrote:
>>> Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
>>>> Also reject TDRs if another one already running.
>>>>
>>>> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>>> ---
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 94
>>>> +++++++++++++++++++++---------
>>>> 1 file changed, 67 insertions(+), 27 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> index aabd043..4446892 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> @@ -3327,10 +3327,12 @@ bool amdgpu_device_should_recover_gpu(struct
>>>> amdgpu_device *adev)
>>>> static int amdgpu_device_pre_asic_reset(struct amdgpu_device
>>>> *adev,
>>>> struct amdgpu_job *job,
>>>> - bool *need_full_reset_arg)
>>>> + bool *need_full_reset_arg,
>>>> + bool *job_signaled)
>>>> {
>>>> int i, r = 0;
>>>> bool need_full_reset = *need_full_reset_arg;
>>>> + struct amdgpu_ring *job_ring = job ?
>>>> to_amdgpu_ring(job->base.sched) : NULL;
>>>> /* block all schedulers and reset given job's ring */
>>>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>>>> @@ -3341,6 +3343,17 @@ static int amdgpu_device_pre_asic_reset(struct
>>>> amdgpu_device *adev,
>>>> drm_sched_stop(&ring->sched, &job->base);
>>>> + /*
>>>> + * Must check guilty signal here since after this point
>>>> all old
>>>> + * HW fences are force signaled.
>>>> + *
>>>> + * job->base holds a reference to parent fence
>>>> + */
>>>> + if (job_signaled && job && ring == job_ring &&
>>>> + job->base.s_fence->parent &&
>>>> + dma_fence_is_signaled(job->base.s_fence->parent))
>>>> + *job_signaled = true;
>>>> +
>>> That won't work correctly. See when the guilty job is not on the first
>>> scheduler, you would already have force completed some before getting
>>> here.
>>>
>>> Better to stop all schedulers first and then do the check.
>>>
>>> Christian.
>>
>> What do you mean by first scheduler ? There is one scheduler object per
>> ring so I am not clear what 'first' means here.
>
> Well for example if the guilty job is from a compute ring the we have
> already force signaled the gfx ring here.
>
> Same is true for other devices in the same hive, so it would probably
> be a good idea to move the force signaling and the IP reset somewhere
> else and this check up a layer.
>
> Christian.
Let me see if I understand you correctly - you want to AVOID ANY force
signaling in case we are not going to HW reset and so you want to have
the check if guilty is signaled BEFORE any ring fences are force
signaled. Correct ?
Andrey
>
>>
>> Andrey
>>
>>
>>>> /* after all hw jobs are reset, hw fence is meaningless, so
>>>> force_completion */
>>>> amdgpu_fence_driver_force_completion(ring);
>>>> }
>>>> @@ -3358,7 +3371,8 @@ static int amdgpu_device_pre_asic_reset(struct
>>>> amdgpu_device *adev,
>>>> - if (!amdgpu_sriov_vf(adev)) {
>>>> + /* Don't suspend on bare metal if we are not going to HW reset
>>>> the ASIC */
>>>> + if (!amdgpu_sriov_vf(adev) && !(*job_signaled)) {
>>>> if (!need_full_reset)
>>>> need_full_reset =
>>>> amdgpu_device_ip_need_full_reset(adev);
>>>> @@ -3495,7 +3509,7 @@ static int amdgpu_do_asic_reset(struct
>>>> amdgpu_hive_info *hive,
>>>> return r;
>>>> }
>>>> -static void amdgpu_device_post_asic_reset(struct amdgpu_device
>>>> *adev)
>>>> +static void amdgpu_device_post_asic_reset(struct amdgpu_device
>>>> *adev, bool job_signaled)
>>>> {
>>>> int i;
>>>> @@ -3505,7 +3519,8 @@ static void
>>>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>>>> if (!ring || !ring->sched.thread)
>>>> continue;
>>>> - if (!adev->asic_reset_res)
>>>> + /* No point to resubmit jobs if we didn't HW reset*/
>>>> + if (!adev->asic_reset_res && !job_signaled)
>>>> drm_sched_resubmit_jobs(&ring->sched);
>>>> drm_sched_start(&ring->sched, !adev->asic_reset_res);
>>>> @@ -3518,14 +3533,21 @@ static void
>>>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>>>> adev->asic_reset_res = 0;
>>>> }
>>>> -static void amdgpu_device_lock_adev(struct amdgpu_device *adev)
>>>> +static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool
>>>> trylock)
>>>> {
>>>> - mutex_lock(&adev->lock_reset);
>>>> + if (trylock) {
>>>> + if (!mutex_trylock(&adev->lock_reset))
>>>> + return false;
>>>> + } else
>>>> + mutex_lock(&adev->lock_reset);
>>>> +
>>>> atomic_inc(&adev->gpu_reset_counter);
>>>> adev->in_gpu_reset = 1;
>>>> /* Block kfd: SRIOV would do it separately */
>>>> if (!amdgpu_sriov_vf(adev))
>>>> amdgpu_amdkfd_pre_reset(adev);
>>>> +
>>>> + return true;
>>>> }
>>>> static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
>>>> @@ -3555,29 +3577,44 @@ int amdgpu_device_gpu_recover(struct
>>>> amdgpu_device *adev,
>>>> {
>>>> int r;
>>>> struct amdgpu_hive_info *hive = NULL;
>>>> - bool need_full_reset = false;
>>>> struct amdgpu_device *tmp_adev = NULL;
>>>> struct list_head device_list, *device_list_handle = NULL;
>>>> + bool xgmi_topology_present, need_full_reset, job_signaled;
>>>> + need_full_reset = job_signaled = false;
>>>> INIT_LIST_HEAD(&device_list);
>>>> dev_info(adev->dev, "GPU reset begin!\n");
>>>> + hive = amdgpu_get_xgmi_hive(adev, 0);
>>>> + xgmi_topology_present = hive &&
>>>> adev->gmc.xgmi.num_physical_nodes > 1;
>>>> +
>>>> /*
>>>> - * In case of XGMI hive disallow concurrent resets to be
>>>> triggered
>>>> - * by different nodes. No point also since the one node already
>>>> executing
>>>> - * reset will also reset all the other nodes in the hive.
>>>> + * Here we trylock to avoid chain of resets executing from
>>>> + * either trigger by jobs on different adevs in XGMI hive or
>>>> jobs on
>>>> + * different schedulers for same device while this tdr is
>>>> running.
>>>> + * We always reset all schedulers for device and all devices for
>>>> XGMI
>>>> + * hive so that should take care of them too.
>>>> */
>>>> - hive = amdgpu_get_xgmi_hive(adev, 0);
>>>> - if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
>>>> - !mutex_trylock(&hive->reset_lock))
>>>> +
>>>> + if (xgmi_topology_present && !mutex_trylock(&hive->reset_lock)) {
>>>> + DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as
>>>> another already in progress",
>>>> + job->base.id, hive->hive_id);
>>>> return 0;
>>>> + }
>>>> /* Start with adev pre asic reset first for soft reset
>>>> check.*/
>>>> - amdgpu_device_lock_adev(adev);
>>>> + if (!amdgpu_device_lock_adev(adev, !xgmi_topology_present)) {
>>>> + DRM_INFO("Bailing on TDR for s_job:%llx, as another already
>>>> in progress",
>>>> + job->base.id);
>>>> + return 0;
>>>> + }
>>>> +
>>>> + /* Guilty job will be freed after this*/
>>>> r = amdgpu_device_pre_asic_reset(adev,
>>>> job,
>>>> - &need_full_reset);
>>>> + &need_full_reset,
>>>> + &job_signaled);
>>>> if (r) {
>>>> /*TODO Should we stop ?*/
>>>> DRM_ERROR("GPU pre asic reset failed with err, %d for drm
>>>> dev, %s ",
>>>> @@ -3609,10 +3646,11 @@ int amdgpu_device_gpu_recover(struct
>>>> amdgpu_device *adev,
>>>> if (tmp_adev == adev)
>>>> continue;
>>>> - amdgpu_device_lock_adev(tmp_adev);
>>>> + amdgpu_device_lock_adev(tmp_adev, false);
>>>> r = amdgpu_device_pre_asic_reset(tmp_adev,
>>>> NULL,
>>>> - &need_full_reset);
>>>> + &need_full_reset,
>>>> + &job_signaled);
>>>> /*TODO Should we stop ?*/
>>>> if (r) {
>>>> DRM_ERROR("GPU pre asic reset failed with err, %d for
>>>> drm dev, %s ",
>>>> @@ -3623,19 +3661,21 @@ int amdgpu_device_gpu_recover(struct
>>>> amdgpu_device *adev,
>>>> /* Actual ASIC resets if needed.*/
>>>> /* TODO Implement XGMI hive reset logic for SRIOV */
>>>> - if (amdgpu_sriov_vf(adev)) {
>>>> - r = amdgpu_device_reset_sriov(adev, job ? false : true);
>>>> - if (r)
>>>> - adev->asic_reset_res = r;
>>>> - } else {
>>>> - r = amdgpu_do_asic_reset(hive, device_list_handle,
>>>> &need_full_reset);
>>>> - if (r && r == -EAGAIN)
>>>> - goto retry;
>>>> + if (!job || !job_signaled) {
>>>> + if (amdgpu_sriov_vf(adev)) {
>>>> + r = amdgpu_device_reset_sriov(adev, job ? false : true);
>>>> + if (r)
>>>> + adev->asic_reset_res = r;
>>>> + } else {
>>>> + r = amdgpu_do_asic_reset(hive, device_list_handle,
>>>> &need_full_reset);
>>>> + if (r && r == -EAGAIN)
>>>> + goto retry;
>>>> + }
>>>> }
>>>> /* Post ASIC reset for all devs .*/
>>>> list_for_each_entry(tmp_adev, device_list_handle,
>>>> gmc.xgmi.head) {
>>>> - amdgpu_device_post_asic_reset(tmp_adev);
>>>> + amdgpu_device_post_asic_reset(tmp_adev, job_signaled);
>>>> if (r) {
>>>> /* bad news, how to tell it to userspace ? */
>>>> @@ -3648,7 +3688,7 @@ int amdgpu_device_gpu_recover(struct
>>>> amdgpu_device *adev,
>>>> amdgpu_device_unlock_adev(tmp_adev);
>>>> }
>>>> - if (hive && adev->gmc.xgmi.num_physical_nodes > 1)
>>>> + if (xgmi_topology_present)
>>>> mutex_unlock(&hive->reset_lock);
>>>> if (r)
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v4 2/4] ASoC: fsl_audmix: remove "model" attribute from DT document
From: Fabio Estevam @ 2019-04-10 14:26 UTC (permalink / raw)
To: Viorel Suman
Cc: Mark Rutland, Viorel Suman, alsa-devel@alsa-project.org,
linuxppc-dev@lists.ozlabs.org, Timur Tabi, Xiubo Li,
linux-kernel@vger.kernel.org, Sascha Hauer, Takashi Iwai,
Liam Girdwood, Rob Herring, Jaroslav Kysela, Nicolin Chen,
Julia Lawall, devicetree@vger.kernel.org, Mark Brown,
dl-linux-imx, Pengutronix Kernel Team, Shawn Guo,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1554894380-25153-3-git-send-email-viorel.suman@nxp.com>
On Wed, Apr 10, 2019 at 8:06 AM Viorel Suman <viorel.suman@nxp.com> wrote:
>
> Remove "model" attribute from fsl_audmix DT document.
Please provide the reasoning.
^ permalink raw reply
* [PATCH v3] rcar-csi2: Move setting of Field Detection Control Register
From: Niklas Söderlund @ 2019-04-10 14:27 UTC (permalink / raw)
To: Hans Verkuil, Laurent Pinchart, linux-media
Cc: linux-renesas-soc, Niklas Söderlund, Ulrich Hecht,
Kieran Bingham
Later datasheet versions (rev 1.00) clarifies that the FLD register
should be set after LINKCNT.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/media/platform/rcar-vin/rcar-csi2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c b/drivers/media/platform/rcar-vin/rcar-csi2.c
index 73c51e9d4a1adcba..799e526fd3df5554 100644
--- a/drivers/media/platform/rcar-vin/rcar-csi2.c
+++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
@@ -519,8 +519,6 @@ static int rcsi2_start_receiver(struct rcar_csi2 *priv)
rcsi2_write(priv, PHTC_REG, 0);
/* Configure */
- rcsi2_write(priv, FLD_REG, FLD_FLD_NUM(2) | FLD_FLD_EN4 |
- FLD_FLD_EN3 | FLD_FLD_EN2 | FLD_FLD_EN);
rcsi2_write(priv, VCDT_REG, vcdt);
if (vcdt2)
rcsi2_write(priv, VCDT2_REG, vcdt2);
@@ -551,6 +549,8 @@ static int rcsi2_start_receiver(struct rcar_csi2 *priv)
rcsi2_write(priv, PHYCNT_REG, phycnt);
rcsi2_write(priv, LINKCNT_REG, LINKCNT_MONITOR_EN |
LINKCNT_REG_MONI_PACT_EN | LINKCNT_ICLK_NONSTOP);
+ rcsi2_write(priv, FLD_REG, FLD_FLD_NUM(2) | FLD_FLD_EN4 |
+ FLD_FLD_EN3 | FLD_FLD_EN2 | FLD_FLD_EN);
rcsi2_write(priv, PHYCNT_REG, phycnt | PHYCNT_SHUTDOWNZ);
rcsi2_write(priv, PHYCNT_REG, phycnt | PHYCNT_SHUTDOWNZ | PHYCNT_RSTZ);
--
2.21.0
^ permalink raw reply related
* RE: using phosphor-dbus-monitor
From: Wim Vervoorn @ 2019-04-10 14:27 UTC (permalink / raw)
To: Matthew Barth, Matt Spinler, Lei YU; +Cc: openbmc@lists.ozlabs.org
In-Reply-To: <cd7788f6-1f41-0ab7-aebf-fed6f2a675d7@linux.ibm.com>
Hello Matt,
I just found the reason why this wasn’t working. I overlooked a typo in the interface : Sensors instead of Sensor.
Best ergards,
Wim Vervoorn
-----Original Message-----
From: Matthew Barth [mailto:msbarth@linux.ibm.com]
Sent: Tuesday, April 9, 2019 4:12 PM
To: Matt Spinler <mspinler@linux.ibm.com>; Wim Vervoorn <wvervoorn@eltan.com>; Lei YU <mine260309@gmail.com>
Cc: openbmc@lists.ozlabs.org
Subject: Re: using phosphor-dbus-monitor
On 4/9/19 8:50 AM, Matt Spinler wrote:
> Hi Wim,
>
> If you could post your YAML somewhere, I could take a look for any
> obvious problems.
If you could also provide a little more details on the error your attempting to log would be helpful (i.e. is there a dbus interface?).
>
> On 4/9/2019 2:23 AM, Wim Vervoorn wrote:
>> Hello Lei,
>>
>> Thanks for your response. I know this example too and it helps a bit
>> but it doesn’t really clarify all issues.
>>
>> As you've worked with this as well. Do you understand the meta item?
>> The example indicates it has different meaning but doesn't provide
>> any pointers to what those meanings are. Have you been able to find out?
What meta item are you referring to?
>>
>> Best Regards,
>> Wim Vervoorn
>>
>> -----Original Message-----
>> From: Lei YU [mailto:mine260309@gmail.com]
>> Sent: Tuesday, April 9, 2019 5:44 AM
>> To: Wim Vervoorn <wvervoorn@eltan.com>; Matthew Barth
>> <msbarth@linux.ibm.com>
>> Cc: openbmc@lists.ozlabs.org
>> Subject: Re: using phosphor-dbus-monitor
>>
>>> I am trying to use phosphor-dbus-monitor to create logging of sensor
>>> exceptions like a Critical state on a specific sensor.
>>> I am able to create a solution with a building yaml but at the end
>>> it doesn’t deliver me the desired result.
>>> As there are very limited examples (on a few in the witherspoon) it
>>> is very hard to figure out where the mistake is.
>> There is an example yaml config in the repo:
>> https://github.com/openbmc/phosphor-dbus-monitor/blob/master/src/exam
>> ple/example.yaml
>>
>>
>> And I have the same feeling that it's hard to know what's wrong if
>> something is wrong.ei
>>
>>> Are there any tools that can be used to make this easier?
>> @Matthew Barth Could you kindly help to add some doc/tool to make it
>> easier to use?
Originally, the example yaml was meant to be the document which I understand is probably not the greatest form when it comes to this.
Unfortunately enhancing the documentation would be a low priority at this time but feel free to create/update the documentation from your findings and push them up for review if you'd like.
>>
>>> Additionally is this the correct method to achieve this goal or
>>> should I use something else to define conditions for logging?
>> I think so. This repo is intended to watch the dbus and do stuff as
>> yaml config.
Correct. This repo was intended to perform error logging and/or system level actions, such as a shutdown, based on object properties on dbus.
>>
>>
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 2/2] bpf: remove use of weak functions
From: Bruce Richardson @ 2019-04-10 14:27 UTC (permalink / raw)
To: Aaron Conole; +Cc: konstantin.ananyev, dev
In-Reply-To: <f7tpnpueyxm.fsf@dhcp-25.97.bos.redhat.com>
On Wed, Apr 10, 2019 at 10:07:33AM -0400, Aaron Conole wrote:
> Bruce Richardson <bruce.richardson@intel.com> writes:
>
> > Weak functions don't work well with static libraries and require the use of
> > "whole-archive" flag to ensure that the correct function is used when
> > linking. Since the weak function is only used as a placeholder within this
> > library alone, we can replace it with a non-weak version protected using
> > preprocessor ifdefs.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
>
> I agree with dropping the weak implementations.
>
> But, can't we adjust the order of objects when building with multiple
> strong definitions and the linker will choose the first? I know this
> works for the GNU linker.
>
> I do find this information to help support this statement:
>
> https://stackoverflow.com/questions/51656838/attribute-weak-and-static-libraries
>
> Unfortunately, I don't find anything in the C standard to govern entity
> precedence. This means it isn't something that works across linker
> implementations (but compatible implementations like clang will maintain
> that behavior).
>
It may be possible, but I'd be worried about the fragility of the support.
Is it a good idea to have multiple implementations of a function in a .a
file. Without running the resulting binary, we have no way of knowing the
correct function was picked up. At least with the weak versions, we can see
from nm what is used.
/Bruce
^ permalink raw reply
* [Xen-devel] [OSSTEST PATCH 47/62] Debian: Add reference to bug numbers for erase-other-disks
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Osstest/Debian.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 073b776c..79b7960d 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1171,6 +1171,7 @@ END2
chmod +x parted_devices
END
+ # Work around Debian bugs #601363 #687160
preseed_hook_installscript($ho, $sfx,
'/lib/partman/init.d', '25erase-other-disks', <<END, 1);
#!/bin/sh
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [Xen-devel] [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
From: Laszlo Ersek @ 2019-04-10 14:27 UTC (permalink / raw)
To: Jordan Justen, Anthony PERARD, devel
Cc: xen-devel, Julien Grall, Ard Biesheuvel
In-Reply-To: <155488970861.20447.12525571872411959890@jljusten-skl>
On 04/10/19 11:48, Jordan Justen wrote:
> On 2019-04-09 04:08:15, Anthony PERARD wrote:
>> This is a copy of OvmfX64, removing VirtIO and some SMM.
>>
>> This new platform will be changed to make it works on two types of Xen
>> guest: HVM and PVH.
>>
>> Compare to OvmfX64, this patch:
>>
>> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
>> - removed: VirtioLib class resolution
>> - removed: all UEFI_DRIVER modules for virtio devices
>> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
>> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
>> - removed: Everything related to SMM_REQUIRE==true
>> - removed: Everything related to SECURE_BOOT_ENABLE==true
>> - removed: Everything related to TPM2_ENABLE==true
>> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
>> - changed: default FD_SIZE_IN_KB to 2M.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
>
> I guess we all want our name to be first :), but OvmfXen seems more
> like the pattern that edk2 uses when making sub-platforms.
>
> Also, in some cases we've used !ifdef type things to keep dsc and fdf
> files common. Would that not be workable here? Maybe it would get too
> ugly. :\
I've been happy with a similar Xen<->QEMU split under ArmVirtPkg.
Duplications in updates are usually not a huge burden, and keeping the
files separate has proved very helpful for determining
maintainer/reviewer/tester responsibility.
> It could help to prevent having to sync dsc changes across, and
> prevent changes from being omitted for Xen on accident.
True, but in my experience that's been the smaller problem. The larger
problem has been modifying Xen stuff in unintended ways (= regressing
Xen), because we can't test (or don't even notice) the Xen-side
implications of changes made to common source.
Personally I prefer another (DSC + FDF) pair under OvmfPkg (beyond the
three we already have) to another layer of (conditional?) includes. The
!if's that are being eliminated in this Xen-customized copy (i.e., in
this patch) are complex enough already :)
... It's not that I *generally* prefer duplication; as you say, we do
have a number of !includes already. I do prefer duplication specifically
for Xen vs. QEMU however.
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [Xen-devel] [OSSTEST PATCH 36/62] TestSupport: target_somefile_leaf rename and change a variable
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
Rename this function. `getleaf' contains `get' which makes it sound
like the function copies something, or returns answers suitable for
getting, or something.
Also rename `$rdest' to `$rfile' since it might be a source too.
(Although we are not about to make it a source...)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Osstest/TestSupport.pm | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 4e2f120a..a5870e4d 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -504,10 +504,10 @@ sub remote_perl_script_done ($) {
!$? or die "$thing->{What} $?";
}
-sub target_somefile_getleaf ($$$) {
- my ($lleaf_ref, $rdest, $ho) = @_;
+sub target_somefile_leaf ($$$) {
+ my ($lleaf_ref, $rfile, $ho) = @_;
if (!defined $$lleaf_ref) {
- $$lleaf_ref= $rdest;
+ $$lleaf_ref= $rfile;
$$lleaf_ref =~ s,.*/,,;
}
$$lleaf_ref= hostnamepath($ho)."--$$lleaf_ref";
@@ -602,7 +602,7 @@ sub target_install_packages_norec ($@) {
sub tpfcs_core {
my ($tputfilef,$ho,$timeout,$filedata, $rdest,$lleaf) = @_;
- target_somefile_getleaf(\$lleaf,$rdest,$ho);
+ target_somefile_leaf(\$lleaf,$rdest,$ho);
my $h= new IO::File "$stash/$lleaf", 'w' or die "$lleaf $!";
print $h $filedata or die $!;
@@ -654,7 +654,7 @@ sub teditfileex {
if (!defined $rdest) {
$rdest= $rfile;
}
- target_somefile_getleaf(\$lleaf,$rdest,$ho);
+ target_somefile_leaf(\$lleaf,$rdest,$ho);
my $lfile;
for (;;) {
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [Xen-devel] [OSSTEST PATCH 39/62] preseed_base: chmod ssh host private keys to placate sshd
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
Otherwise:
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for '/etc/ssh/ssh_host_ed25519_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
key_load_private: bad permissions
Could not load host key: /etc/ssh/ssh_host_ed25519_key
This seems to start happening with stretch. Presumably stretch is
more annoyingly picky than jessie.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Osstest/Debian.pm | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index aff5acd5..d76dd03d 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -871,6 +871,14 @@ END
preseed_hook_overlay($ho, $sfx, $srcdir, $tfilename);
});
+ # Host private keys in the overlays have to be group-readable
+ # at least, or no-one can use them. But ssh is very fussy.
+ preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+chmod 600 /target/etc/ssh/ssh_host_*_key ||:
+END
+
my $preseed = <<"END";
d-i debian-installer/locale string en_GB
d-i console-keymaps-at/keymap select gb
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf
From: Laszlo Ersek @ 2019-04-10 14:27 UTC (permalink / raw)
To: Jordan Justen, Anthony PERARD, devel
Cc: xen-devel, Julien Grall, Ard Biesheuvel
In-Reply-To: <155488970861.20447.12525571872411959890@jljusten-skl>
On 04/10/19 11:48, Jordan Justen wrote:
> On 2019-04-09 04:08:15, Anthony PERARD wrote:
>> This is a copy of OvmfX64, removing VirtIO and some SMM.
>>
>> This new platform will be changed to make it works on two types of Xen
>> guest: HVM and PVH.
>>
>> Compare to OvmfX64, this patch:
>>
>> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
>> - removed: VirtioLib class resolution
>> - removed: all UEFI_DRIVER modules for virtio devices
>> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
>> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
>> - removed: Everything related to SMM_REQUIRE==true
>> - removed: Everything related to SECURE_BOOT_ENABLE==true
>> - removed: Everything related to TPM2_ENABLE==true
>> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
>> - changed: default FD_SIZE_IN_KB to 2M.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>> OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +-------------------
>
> I guess we all want our name to be first :), but OvmfXen seems more
> like the pattern that edk2 uses when making sub-platforms.
>
> Also, in some cases we've used !ifdef type things to keep dsc and fdf
> files common. Would that not be workable here? Maybe it would get too
> ugly. :\
I've been happy with a similar Xen<->QEMU split under ArmVirtPkg.
Duplications in updates are usually not a huge burden, and keeping the
files separate has proved very helpful for determining
maintainer/reviewer/tester responsibility.
> It could help to prevent having to sync dsc changes across, and
> prevent changes from being omitted for Xen on accident.
True, but in my experience that's been the smaller problem. The larger
problem has been modifying Xen stuff in unintended ways (= regressing
Xen), because we can't test (or don't even notice) the Xen-side
implications of changes made to common source.
Personally I prefer another (DSC + FDF) pair under OvmfPkg (beyond the
three we already have) to another layer of (conditional?) includes. The
!if's that are being eliminated in this Xen-customized copy (i.e., in
this patch) are complex enough already :)
... It's not that I *generally* prefer duplication; as you say, we do
have a number of !includes already. I do prefer duplication specifically
for Xen vs. QEMU however.
Thanks
Laszlo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [OSSTEST PATCH 47/62] Debian: Add reference to bug numbers for erase-other-disks
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Osstest/Debian.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 073b776c..79b7960d 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1171,6 +1171,7 @@ END2
chmod +x parted_devices
END
+ # Work around Debian bugs #601363 #687160
preseed_hook_installscript($ho, $sfx,
'/lib/partman/init.d', '25erase-other-disks', <<END, 1);
#!/bin/sh
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [OSSTEST PATCH 36/62] TestSupport: target_somefile_leaf rename and change a variable
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
Rename this function. `getleaf' contains `get' which makes it sound
like the function copies something, or returns answers suitable for
getting, or something.
Also rename `$rdest' to `$rfile' since it might be a source too.
(Although we are not about to make it a source...)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Osstest/TestSupport.pm | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 4e2f120a..a5870e4d 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -504,10 +504,10 @@ sub remote_perl_script_done ($) {
!$? or die "$thing->{What} $?";
}
-sub target_somefile_getleaf ($$$) {
- my ($lleaf_ref, $rdest, $ho) = @_;
+sub target_somefile_leaf ($$$) {
+ my ($lleaf_ref, $rfile, $ho) = @_;
if (!defined $$lleaf_ref) {
- $$lleaf_ref= $rdest;
+ $$lleaf_ref= $rfile;
$$lleaf_ref =~ s,.*/,,;
}
$$lleaf_ref= hostnamepath($ho)."--$$lleaf_ref";
@@ -602,7 +602,7 @@ sub target_install_packages_norec ($@) {
sub tpfcs_core {
my ($tputfilef,$ho,$timeout,$filedata, $rdest,$lleaf) = @_;
- target_somefile_getleaf(\$lleaf,$rdest,$ho);
+ target_somefile_leaf(\$lleaf,$rdest,$ho);
my $h= new IO::File "$stash/$lleaf", 'w' or die "$lleaf $!";
print $h $filedata or die $!;
@@ -654,7 +654,7 @@ sub teditfileex {
if (!defined $rdest) {
$rdest= $rfile;
}
- target_somefile_getleaf(\$lleaf,$rdest,$ho);
+ target_somefile_leaf(\$lleaf,$rdest,$ho);
my $lfile;
for (;;) {
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [OSSTEST PATCH 39/62] preseed_base: chmod ssh host private keys to placate sshd
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
Otherwise:
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for '/etc/ssh/ssh_host_ed25519_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
key_load_private: bad permissions
Could not load host key: /etc/ssh/ssh_host_ed25519_key
This seems to start happening with stretch. Presumably stretch is
more annoyingly picky than jessie.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Osstest/Debian.pm | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index aff5acd5..d76dd03d 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -871,6 +871,14 @@ END
preseed_hook_overlay($ho, $sfx, $srcdir, $tfilename);
});
+ # Host private keys in the overlays have to be group-readable
+ # at least, or no-one can use them. But ssh is very fussy.
+ preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+chmod 600 /target/etc/ssh/ssh_host_*_key ||:
+END
+
my $preseed = <<"END";
d-i debian-installer/locale string en_GB
d-i console-keymaps-at/keymap select gb
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [PATCH 4/7] media: atmel: atmel-isc: add support for DO_WHITE_BALANCE
From: Hans Verkuil @ 2019-04-10 14:26 UTC (permalink / raw)
To: Eugen.Hristev, linux-media, Nicolas.Ferre, linux-arm-kernel,
linux-kernel, mchehab
Cc: ksloat
In-Reply-To: <1554807715-2353-5-git-send-email-eugen.hristev@microchip.com>
On 4/9/19 1:07 PM, Eugen.Hristev@microchip.com wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> This adds support for the 'button' control DO_WHITE_BALANCE
> This feature will enable the ISC to compute the white balance coefficients
> in a one time shot, at the user discretion.
> This can be used if a color chart/grey chart is present in front of the camera.
> The ISC will adjust the coefficients and have them fixed until next balance
> or until sensor mode is changed.
> This is particularly useful for white balance adjustment in different
> lighting scenarios, and then taking photos to similar scenery.
> The old auto white balance stays in place, where the ISC will adjust every
> 4 frames to the current scenery lighting, if the scenery is approximately
> grey in average, otherwise grey world algorithm fails.
> One time white balance adjustments needs streaming to be enabled, such that
> capture is enabled and the histogram has data to work with.
> Histogram without capture does not work in this hardware module.
>
> To disable auto white balance feature (first step)
> v4l2-ctl --set-ctrl=white_balance_automatic=0
>
> To start the one time white balance procedure:
> v4l2-ctl --set-ctrl=do_white_balance=1
>
> User controls now include the do_white_balance ctrl:
> User Controls
>
> brightness 0x00980900 (int) : min=-1024 max=1023 step=1 default=0 value=0 flags=slider
> contrast 0x00980901 (int) : min=-2048 max=2047 step=1 default=256 value=256 flags=slider
> white_balance_automatic 0x0098090c (bool) : default=1 value=1
> do_white_balance 0x0098090d (button) : flags=write-only, execute-on-write
> gamma 0x00980910 (int) : min=0 max=2 step=1 default=2 value=2 flags=slider
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
> drivers/media/platform/atmel/atmel-isc.c | 74 +++++++++++++++++++++++++++++---
> 1 file changed, 69 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
> index f6b8b00e..e516805 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -167,6 +167,9 @@ struct isc_ctrls {
> u32 brightness;
> u32 contrast;
> u8 gamma_index;
> +#define ISC_WB_NONE 0
> +#define ISC_WB_AUTO 1
> +#define ISC_WB_ONETIME 2
> u8 awb;
>
> /* one for each component : GR, R, GB, B */
> @@ -210,6 +213,7 @@ struct isc_device {
> struct fmt_config try_config;
>
> struct isc_ctrls ctrls;
> + struct v4l2_ctrl *do_wb_ctrl;
> struct work_struct awb_work;
>
> struct mutex lock;
> @@ -809,7 +813,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
>
> bay_cfg = isc->config.sd_format->cfa_baycfg;
>
> - if (!ctrls->awb)
> + if (ctrls->awb == ISC_WB_NONE)
> isc_reset_awb_ctrls(isc);
>
> regmap_write(regmap, ISC_WB_CFG, bay_cfg);
> @@ -1928,7 +1932,7 @@ static void isc_awb_work(struct work_struct *w)
> baysel = isc->config.sd_format->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
>
> /* if no more auto white balance, reset controls. */
> - if (!ctrls->awb)
> + if (ctrls->awb == ISC_WB_NONE)
> isc_reset_awb_ctrls(isc);
>
> pm_runtime_get_sync(isc->dev);
> @@ -1937,7 +1941,7 @@ static void isc_awb_work(struct work_struct *w)
> * only update if we have all the required histograms and controls
> * if awb has been disabled, we need to reset registers as well.
> */
> - if (hist_id == ISC_HIS_CFG_MODE_GR || !ctrls->awb) {
> + if (hist_id == ISC_HIS_CFG_MODE_GR || ctrls->awb == ISC_WB_NONE) {
> /*
> * It may happen that DMA Done IRQ will trigger while we are
> * updating white balance registers here.
> @@ -1947,6 +1951,16 @@ static void isc_awb_work(struct work_struct *w)
> spin_lock_irqsave(&isc->awb_lock, flags);
> isc_update_awb_ctrls(isc);
> spin_unlock_irqrestore(&isc->awb_lock, flags);
> +
> + /*
> + * if we are doing just the one time white balance adjustment,
> + * we are basically done.
> + */
> + if (ctrls->awb == ISC_WB_ONETIME) {
> + v4l2_info(&isc->v4l2_dev,
> + "Completed one time white-balance adjustment.\n");
> + ctrls->awb = ISC_WB_NONE;
> + }
> }
> regmap_write(regmap, ISC_HIS_CFG, hist_id | baysel | ISC_HIS_CFG_RAR);
> isc_update_profile(isc);
> @@ -1974,10 +1988,56 @@ static int isc_s_ctrl(struct v4l2_ctrl *ctrl)
> ctrls->gamma_index = ctrl->val;
> break;
> case V4L2_CID_AUTO_WHITE_BALANCE:
> - ctrls->awb = ctrl->val;
> + if (ctrl->val == 1) {
> + ctrls->awb = ISC_WB_AUTO;
> + v4l2_ctrl_activate(isc->do_wb_ctrl, false);
> + } else {
> + ctrls->awb = ISC_WB_NONE;
> + v4l2_ctrl_activate(isc->do_wb_ctrl, true);
> + }
> + /* we did not configure ISC yet */
> + if (!isc->config.sd_format)
> + break;
> +
> + if (!ISC_IS_FORMAT_RAW(isc->config.sd_format->mbus_code)) {
> + v4l2_err(&isc->v4l2_dev,
> + "White balance adjustments available only if sensor is in RAW mode.\n");
This isn't an error, instead if the format isn't raw, then deactivate
the control (see v4l2_ctrl_activate()). That way the control framework
will handle this.
> + return 0;
> + }
> +
> if (ctrls->hist_stat != HIST_ENABLED) {
> isc_reset_awb_ctrls(isc);
> }
> +
> + if (isc->ctrls.awb && vb2_is_streaming(&isc->vb2_vidq) &&
> + ISC_IS_FORMAT_RAW(isc->config.sd_format->mbus_code))
> + isc_set_histogram(isc, true);
> +
> + break;
> + case V4L2_CID_DO_WHITE_BALANCE:
> + /* we did not configure ISC yet */
> + if (!isc->config.sd_format)
> + break;
> +
> + if (ctrls->awb == ISC_WB_AUTO) {
> + v4l2_err(&isc->v4l2_dev,
> + "To use one time white-balance adjustment, disable auto white balance first.\n");
I'd do this differently: if auto whitebalance is already on, then just do
nothing for V4L2_CID_DO_WHITE_BALANCE.
> + return -EAGAIN;
> + }
> + if (!vb2_is_streaming(&isc->vb2_vidq)) {
> + v4l2_err(&isc->v4l2_dev,
> + "One time white-balance adjustment requires streaming to be enabled.\n");
This too should use v4l2_ctrl_activate(): activate the control in start_streaming,
deactivate in stop_streaming (and when the control is created).
> + return -EAGAIN;
> + }
> +
> + if (!ISC_IS_FORMAT_RAW(isc->config.sd_format->mbus_code)) {
> + v4l2_err(&isc->v4l2_dev,
> + "White balance adjustments available only if sensor is in RAW mode.\n");
Same note as above: use v4l2_ctrl_activate() for this.
> + return -EAGAIN;
> + }
> + ctrls->awb = ISC_WB_ONETIME;
> + isc_set_histogram(isc, true);
> + v4l2_info(&isc->v4l2_dev, "One time white-balance started.\n");
Make this v4l2_dbg.
> break;
> default:
> return -EINVAL;
> @@ -2000,7 +2060,7 @@ static int isc_ctrl_init(struct isc_device *isc)
> ctrls->hist_stat = HIST_INIT;
> isc_reset_awb_ctrls(isc);
>
> - ret = v4l2_ctrl_handler_init(hdl, 4);
> + ret = v4l2_ctrl_handler_init(hdl, 5);
> if (ret < 0)
> return ret;
>
> @@ -2012,6 +2072,10 @@ static int isc_ctrl_init(struct isc_device *isc)
> v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, GAMMA_MAX, 1, 2);
> v4l2_ctrl_new_std(hdl, ops, V4L2_CID_AUTO_WHITE_BALANCE, 0, 1, 1, 1);
>
> + /* do_white_balance is a button, so min,max,step,default are ignored */
> + isc->do_wb_ctrl = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_DO_WHITE_BALANCE,
> + 0, 0, 0, 0);
> +
> v4l2_ctrl_handler_setup(hdl);
>
> return 0;
>
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 4/7] media: atmel: atmel-isc: add support for DO_WHITE_BALANCE
From: Hans Verkuil @ 2019-04-10 14:26 UTC (permalink / raw)
To: Eugen.Hristev, linux-media, Nicolas.Ferre, linux-arm-kernel,
linux-kernel, mchehab
Cc: ksloat
In-Reply-To: <1554807715-2353-5-git-send-email-eugen.hristev@microchip.com>
On 4/9/19 1:07 PM, Eugen.Hristev@microchip.com wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> This adds support for the 'button' control DO_WHITE_BALANCE
> This feature will enable the ISC to compute the white balance coefficients
> in a one time shot, at the user discretion.
> This can be used if a color chart/grey chart is present in front of the camera.
> The ISC will adjust the coefficients and have them fixed until next balance
> or until sensor mode is changed.
> This is particularly useful for white balance adjustment in different
> lighting scenarios, and then taking photos to similar scenery.
> The old auto white balance stays in place, where the ISC will adjust every
> 4 frames to the current scenery lighting, if the scenery is approximately
> grey in average, otherwise grey world algorithm fails.
> One time white balance adjustments needs streaming to be enabled, such that
> capture is enabled and the histogram has data to work with.
> Histogram without capture does not work in this hardware module.
>
> To disable auto white balance feature (first step)
> v4l2-ctl --set-ctrl=white_balance_automatic=0
>
> To start the one time white balance procedure:
> v4l2-ctl --set-ctrl=do_white_balance=1
>
> User controls now include the do_white_balance ctrl:
> User Controls
>
> brightness 0x00980900 (int) : min=-1024 max=1023 step=1 default=0 value=0 flags=slider
> contrast 0x00980901 (int) : min=-2048 max=2047 step=1 default=256 value=256 flags=slider
> white_balance_automatic 0x0098090c (bool) : default=1 value=1
> do_white_balance 0x0098090d (button) : flags=write-only, execute-on-write
> gamma 0x00980910 (int) : min=0 max=2 step=1 default=2 value=2 flags=slider
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
> drivers/media/platform/atmel/atmel-isc.c | 74 +++++++++++++++++++++++++++++---
> 1 file changed, 69 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
> index f6b8b00e..e516805 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -167,6 +167,9 @@ struct isc_ctrls {
> u32 brightness;
> u32 contrast;
> u8 gamma_index;
> +#define ISC_WB_NONE 0
> +#define ISC_WB_AUTO 1
> +#define ISC_WB_ONETIME 2
> u8 awb;
>
> /* one for each component : GR, R, GB, B */
> @@ -210,6 +213,7 @@ struct isc_device {
> struct fmt_config try_config;
>
> struct isc_ctrls ctrls;
> + struct v4l2_ctrl *do_wb_ctrl;
> struct work_struct awb_work;
>
> struct mutex lock;
> @@ -809,7 +813,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
>
> bay_cfg = isc->config.sd_format->cfa_baycfg;
>
> - if (!ctrls->awb)
> + if (ctrls->awb == ISC_WB_NONE)
> isc_reset_awb_ctrls(isc);
>
> regmap_write(regmap, ISC_WB_CFG, bay_cfg);
> @@ -1928,7 +1932,7 @@ static void isc_awb_work(struct work_struct *w)
> baysel = isc->config.sd_format->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
>
> /* if no more auto white balance, reset controls. */
> - if (!ctrls->awb)
> + if (ctrls->awb == ISC_WB_NONE)
> isc_reset_awb_ctrls(isc);
>
> pm_runtime_get_sync(isc->dev);
> @@ -1937,7 +1941,7 @@ static void isc_awb_work(struct work_struct *w)
> * only update if we have all the required histograms and controls
> * if awb has been disabled, we need to reset registers as well.
> */
> - if (hist_id == ISC_HIS_CFG_MODE_GR || !ctrls->awb) {
> + if (hist_id == ISC_HIS_CFG_MODE_GR || ctrls->awb == ISC_WB_NONE) {
> /*
> * It may happen that DMA Done IRQ will trigger while we are
> * updating white balance registers here.
> @@ -1947,6 +1951,16 @@ static void isc_awb_work(struct work_struct *w)
> spin_lock_irqsave(&isc->awb_lock, flags);
> isc_update_awb_ctrls(isc);
> spin_unlock_irqrestore(&isc->awb_lock, flags);
> +
> + /*
> + * if we are doing just the one time white balance adjustment,
> + * we are basically done.
> + */
> + if (ctrls->awb == ISC_WB_ONETIME) {
> + v4l2_info(&isc->v4l2_dev,
> + "Completed one time white-balance adjustment.\n");
> + ctrls->awb = ISC_WB_NONE;
> + }
> }
> regmap_write(regmap, ISC_HIS_CFG, hist_id | baysel | ISC_HIS_CFG_RAR);
> isc_update_profile(isc);
> @@ -1974,10 +1988,56 @@ static int isc_s_ctrl(struct v4l2_ctrl *ctrl)
> ctrls->gamma_index = ctrl->val;
> break;
> case V4L2_CID_AUTO_WHITE_BALANCE:
> - ctrls->awb = ctrl->val;
> + if (ctrl->val == 1) {
> + ctrls->awb = ISC_WB_AUTO;
> + v4l2_ctrl_activate(isc->do_wb_ctrl, false);
> + } else {
> + ctrls->awb = ISC_WB_NONE;
> + v4l2_ctrl_activate(isc->do_wb_ctrl, true);
> + }
> + /* we did not configure ISC yet */
> + if (!isc->config.sd_format)
> + break;
> +
> + if (!ISC_IS_FORMAT_RAW(isc->config.sd_format->mbus_code)) {
> + v4l2_err(&isc->v4l2_dev,
> + "White balance adjustments available only if sensor is in RAW mode.\n");
This isn't an error, instead if the format isn't raw, then deactivate
the control (see v4l2_ctrl_activate()). That way the control framework
will handle this.
> + return 0;
> + }
> +
> if (ctrls->hist_stat != HIST_ENABLED) {
> isc_reset_awb_ctrls(isc);
> }
> +
> + if (isc->ctrls.awb && vb2_is_streaming(&isc->vb2_vidq) &&
> + ISC_IS_FORMAT_RAW(isc->config.sd_format->mbus_code))
> + isc_set_histogram(isc, true);
> +
> + break;
> + case V4L2_CID_DO_WHITE_BALANCE:
> + /* we did not configure ISC yet */
> + if (!isc->config.sd_format)
> + break;
> +
> + if (ctrls->awb == ISC_WB_AUTO) {
> + v4l2_err(&isc->v4l2_dev,
> + "To use one time white-balance adjustment, disable auto white balance first.\n");
I'd do this differently: if auto whitebalance is already on, then just do
nothing for V4L2_CID_DO_WHITE_BALANCE.
> + return -EAGAIN;
> + }
> + if (!vb2_is_streaming(&isc->vb2_vidq)) {
> + v4l2_err(&isc->v4l2_dev,
> + "One time white-balance adjustment requires streaming to be enabled.\n");
This too should use v4l2_ctrl_activate(): activate the control in start_streaming,
deactivate in stop_streaming (and when the control is created).
> + return -EAGAIN;
> + }
> +
> + if (!ISC_IS_FORMAT_RAW(isc->config.sd_format->mbus_code)) {
> + v4l2_err(&isc->v4l2_dev,
> + "White balance adjustments available only if sensor is in RAW mode.\n");
Same note as above: use v4l2_ctrl_activate() for this.
> + return -EAGAIN;
> + }
> + ctrls->awb = ISC_WB_ONETIME;
> + isc_set_histogram(isc, true);
> + v4l2_info(&isc->v4l2_dev, "One time white-balance started.\n");
Make this v4l2_dbg.
> break;
> default:
> return -EINVAL;
> @@ -2000,7 +2060,7 @@ static int isc_ctrl_init(struct isc_device *isc)
> ctrls->hist_stat = HIST_INIT;
> isc_reset_awb_ctrls(isc);
>
> - ret = v4l2_ctrl_handler_init(hdl, 4);
> + ret = v4l2_ctrl_handler_init(hdl, 5);
> if (ret < 0)
> return ret;
>
> @@ -2012,6 +2072,10 @@ static int isc_ctrl_init(struct isc_device *isc)
> v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, GAMMA_MAX, 1, 2);
> v4l2_ctrl_new_std(hdl, ops, V4L2_CID_AUTO_WHITE_BALANCE, 0, 1, 1, 1);
>
> + /* do_white_balance is a button, so min,max,step,default are ignored */
> + isc->do_wb_ctrl = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_DO_WHITE_BALANCE,
> + 0, 0, 0, 0);
> +
> v4l2_ctrl_handler_setup(hdl);
>
> return 0;
>
Regards,
Hans
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 1/1] x86/entry/64: randomize kernel stack offset upon syscall
From: Reshetova, Elena @ 2019-04-10 14:26 UTC (permalink / raw)
To: Ingo Molnar, Andy Lutomirski
Cc: luto@kernel.org, linux-kernel@vger.kernel.org,
luto@amacapital.net, jpoimboe@redhat.com, keescook@chromium.org,
jannh@google.com, Perla, Enrico, mingo@redhat.com, bp@alien8.de,
tglx@linutronix.de, peterz@infradead.org,
gregkh@linuxfoundation.org
In-Reply-To: <20190410114259.GB9293@gmail.com>
> * Elena Reshetova <elena.reshetova@intel.com> wrote:
>
> > 2) Andy's tests, misc-tests: ./timing_test_64 10M sys_enosys
> > base: 10000000 loops in 1.62224s = 162.22 nsec / loop
> > random_offset (prandom_u32() every syscall): 10000000 loops in 1.64660s =
> 166.26 nsec / loop
>
> Stupid question, how did you manage to buil timing_test_64? Here it fails
> with a bog standard gcc 7.3.0 x86-64 distro toolchain:
>
> dagon:~/luto-misc-tests.git> make timing_test_64
> g++ -m64 -o timing_test_64 -O2 -g -std=gnu++11 -pthread -Wall timing_test.cc -lrt -
> ldl
> /usr/bin/ld: /tmp/cc8VRkuV.o: relocation R_X86_64_32S against `.text.startup' can
> not be used when making a PIE object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on outputcollect2: error: ld
> returned 1 exit status
> Makefile:39: recipe for target 'timing_test_64' failed
I used -no-pie on CFLAGS/CCFLAGS for the whole set of tools.
Unfortunately, this was only the first problem. After it complains about
rdwrgsbase asm case... That one I didn't quite understand, but because I could see that
this case wasn't used for particular measurements I was doing, I just commented that particular
case out.
>
>
> I'm using cb7f9f0592f8, which is like 1.5 years old - is this still the
> latest and greatest:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/luto/misc-tests.git
Yes, same for me.
Best Regards,
Elena.
^ permalink raw reply
* Re: [PATCH v4 3/4] ASoC: imx-audmix: fix object reference leaks in probe
From: Fabio Estevam @ 2019-04-10 14:26 UTC (permalink / raw)
To: Viorel Suman
Cc: Mark Rutland, Viorel Suman, alsa-devel@alsa-project.org,
linuxppc-dev@lists.ozlabs.org, Timur Tabi, Xiubo Li,
linux-kernel@vger.kernel.org, Sascha Hauer, Takashi Iwai,
Liam Girdwood, Rob Herring, Jaroslav Kysela, Nicolin Chen,
Julia Lawall, devicetree@vger.kernel.org, Mark Brown,
dl-linux-imx, Pengutronix Kernel Team, Shawn Guo,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1554894380-25153-4-git-send-email-viorel.suman@nxp.com>
On Wed, Apr 10, 2019 at 8:06 AM Viorel Suman <viorel.suman@nxp.com> wrote:
>
> Release the reference to the underlying device taken
> by of_find_device_by_node() call.
>
> Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
> Reported-by: Julia Lawall <Julia.Lawall@lip6.fr>
> Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Please provide a Fixes tag.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Xen-devel] [OSSTEST PATCH 21/62] ts-kernel-build: disable host1x, which doesn't build
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel
Cc: Thierry Reding, Julien Grall, Stefano Stabellini, Wei Liu,
dri-devel
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
From: Wei Liu <wei.liu2@citrix.com>
Empirically, on stretch armhf:
drivers/gpu/host1x/cdma.c: In function `host1x_pushbuffer_init':
drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of `dma_alloc_wc' from incompatible pointer type [-Werror=incompatible-pointer-types]
pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
^
etc.
This is blocking the upgrade of the Xen Project CI to Debian stretch
so disable it for now.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
CC: Julien Grall <julien.grall@arm.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Thierry Reding <thierry.reding@gmail.com>
CC: dri-devel@lists.freedesktop.org
---
ts-kernel-build | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ts-kernel-build b/ts-kernel-build
index 21b8f78a..0bc443de 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -594,6 +594,9 @@ case ${XEN_TARGET_ARCH} in
*) ;;
esac
+# Disable components that don't build
+setopt CONFIG_TEGRA_HOST1X n
+
exit 0
END
}
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [PATCH v4 3/4] ASoC: imx-audmix: fix object reference leaks in probe
From: Fabio Estevam @ 2019-04-10 14:26 UTC (permalink / raw)
To: Viorel Suman
Cc: Timur Tabi, Nicolin Chen, Xiubo Li, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Rob Herring, Mark Rutland, Takashi Iwai,
Shawn Guo, Sascha Hauer, Julia Lawall, Viorel Suman,
Pengutronix Kernel Team, dl-linux-imx,
alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1554894380-25153-4-git-send-email-viorel.suman@nxp.com>
On Wed, Apr 10, 2019 at 8:06 AM Viorel Suman <viorel.suman@nxp.com> wrote:
>
> Release the reference to the underlying device taken
> by of_find_device_by_node() call.
>
> Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
> Reported-by: Julia Lawall <Julia.Lawall@lip6.fr>
> Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Please provide a Fixes tag.
^ permalink raw reply
* [OSSTEST PATCH 21/62] ts-kernel-build: disable host1x, which doesn't build
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel
Cc: Thierry Reding, Julien Grall, Stefano Stabellini, Wei Liu,
dri-devel
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
From: Wei Liu <wei.liu2@citrix.com>
Empirically, on stretch armhf:
drivers/gpu/host1x/cdma.c: In function `host1x_pushbuffer_init':
drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of `dma_alloc_wc' from incompatible pointer type [-Werror=incompatible-pointer-types]
pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
^
etc.
This is blocking the upgrade of the Xen Project CI to Debian stretch
so disable it for now.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
CC: Julien Grall <julien.grall@arm.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Thierry Reding <thierry.reding@gmail.com>
CC: dri-devel@lists.freedesktop.org
---
ts-kernel-build | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ts-kernel-build b/ts-kernel-build
index 21b8f78a..0bc443de 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -594,6 +594,9 @@ case ${XEN_TARGET_ARCH} in
*) ;;
esac
+# Disable components that don't build
+setopt CONFIG_TEGRA_HOST1X n
+
exit 0
END
}
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [PATCH v4 3/4] ASoC: imx-audmix: fix object reference leaks in probe
From: Fabio Estevam @ 2019-04-10 14:26 UTC (permalink / raw)
To: Viorel Suman
Cc: Timur Tabi, Nicolin Chen, Xiubo Li, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Rob Herring, Mark Rutland, Takashi Iwai,
Shawn Guo, Sascha Hauer, Julia Lawall, Viorel Suman,
Pengutronix Kernel Team, dl-linux-imx,
alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1554894380-25153-4-git-send-email-viorel.suman@nxp.com>
On Wed, Apr 10, 2019 at 8:06 AM Viorel Suman <viorel.suman@nxp.com> wrote:
>
> Release the reference to the underlying device taken
> by of_find_device_by_node() call.
>
> Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
> Reported-by: Julia Lawall <Julia.Lawall@lip6.fr>
> Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Please provide a Fixes tag.
^ permalink raw reply
* [Xen-devel] [OSSTEST PATCH 07/62] ts-leak-check: suppress systemd-shim, which leaks in stretch
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Wei Liu
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
From: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
ts-leak-check | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-leak-check b/ts-leak-check
index 678d0696..41e6245d 100755
--- a/ts-leak-check
+++ b/ts-leak-check
@@ -202,6 +202,7 @@ xenstore /vm
xenstore /libxl
process .* udevd
+process .* /.+/systemd-shim
file /var/run/xenstored/db
file /var/run/xenstored/db.debug
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
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.