* [PATCH 6/6] ARM: imx_v6_v7_defconfig: Select CONFIG_DRM_PANEL_SEIKO_43WVF1G
From: Fabio Estevam @ 2018-07-23 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1532119161-16597-6-git-send-email-festevam@gmail.com>
Hi Shawn,
On Fri, Jul 20, 2018 at 5:39 PM, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> imx6sl-evk, imx6sll-evk and imx6sx-sdb boards use a Seiko 43WVF1G panel.
>
> Now that the DRM mxsfb driver is the one selected by default, let's
> also select CONFIG_DRM_PANEL_SEIKO_43WVF1G so that these boards continue
> to have a working display by default.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
I understand you have already submitted the imx 4.19 material to Olof
and he has already merged it.
Without this series we will have many NXP development boards without
functional display in 4.19 by default due to the drm mxsfb conversion
in defconfig, which would not be a very good user experience.
I would like to kindly ask you to consider applying this series to 4.19 as well.
Thanks
^ permalink raw reply
* Re: [EXT] Re: UBIFS file has zeroes at the end after an unclean reboot
From: Richard Weinberger @ 2018-07-23 13:57 UTC (permalink / raw)
To: Bean Huo (beanhuo); +Cc: linux-mtd@lists.infradead.org
In-Reply-To: <2d969635723b4aa3abf59b2d5da7ab3e@SIWEX5A.sing.micron.com>
Bean,
Am Montag, 23. Juli 2018, 15:25:49 CEST schrieb Bean Huo (beanhuo):
> Hi,Richard
> Thanks.
> it is Async mode ubifs mounted. After random powerloss testing, found that there is one file contains huge zeroes data.
> But UBIFS didn't crash and no ECC/CRC error.
Well, if the application changed the file while the power-cut happens, such situation can happen on all
kind of filesystems.
That's why I asked whether the application does the right thing. :)
Thanks,
//richard
^ permalink raw reply
* [meta-oe] [PATCH 1/7] python-isort: add native and nativesdk
From: Binghua Guan @ 2018-07-23 13:40 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Binghua Guan <freebendy@gmail.com>
---
meta-python/recipes-devtools/python/python-isort.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta-python/recipes-devtools/python/python-isort.inc b/meta-python/recipes-devtools/python/python-isort.inc
index 6d13e5f7c..359b18012 100644
--- a/meta-python/recipes-devtools/python/python-isort.inc
+++ b/meta-python/recipes-devtools/python/python-isort.inc
@@ -13,3 +13,5 @@ RDEPENDS_${PN} += "\
${PYTHON_PN}-datetime \
${PYTHON_PN}-shell \
"
+
+BBCLASSEXTEND = "native nativesdk"
--
2.11.0
^ permalink raw reply related
* [igt-dev] ✓ Fi.CI.IGT: success for series starting with [i-g-t,1/4] lib/igt_pm: Make exit handlers signal safe
From: Patchwork @ 2018-07-23 13:58 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: igt-dev
In-Reply-To: <20180723114658.13025-1-tvrtko.ursulin@linux.intel.com>
== Series Details ==
Series: series starting with [i-g-t,1/4] lib/igt_pm: Make exit handlers signal safe
URL : https://patchwork.freedesktop.org/series/47052/
State : success
== Summary ==
= CI Bug Log - changes from IGT_4570_full -> IGTPW_1627_full =
== Summary - WARNING ==
Minor unknown changes coming with IGTPW_1627_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_1627_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://patchwork.freedesktop.org/api/1.0/series/47052/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in IGTPW_1627_full:
=== IGT changes ===
==== Warnings ====
igt@gem_exec_schedule@deep-bsd2:
shard-kbl: PASS -> SKIP +3
igt@gem_mocs_settings@mocs-rc6-bsd1:
shard-kbl: SKIP -> PASS
igt@kms_atomic_interruptible@legacy-pageflip:
shard-snb: SKIP -> PASS +2
== Known issues ==
Here are the changes found in IGTPW_1627_full that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@gem_exec_schedule@pi-ringfull-vebox:
shard-glk: NOTRUN -> FAIL (fdo#103158)
igt@kms_cursor_legacy@cursora-vs-flipa-legacy:
shard-glk: PASS -> FAIL (fdo#106765)
igt@kms_flip@2x-plain-flip-ts-check-interruptible:
shard-glk: PASS -> FAIL (fdo#100368)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
shard-glk: PASS -> FAIL (fdo#103375) +1
==== Possible fixes ====
igt@gem_mmap_gtt@coherency:
shard-glk: FAIL (fdo#100587) -> SKIP +1
igt@gem_ppgtt@blt-vs-render-ctxn:
shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS
igt@kms_flip@plain-flip-ts-check-interruptible:
shard-glk: FAIL (fdo#100368) -> PASS +1
igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
shard-glk: FAIL (fdo#103167) -> PASS
igt@perf_pmu@multi-client-vcs1:
shard-snb: INCOMPLETE (fdo#105411) -> SKIP
igt@prime_vgem@coherency-gtt:
shard-apl: FAIL (fdo#100587) -> SKIP +1
igt@testdisplay:
shard-glk: INCOMPLETE (fdo#107093, k.org#198133, fdo#103359) -> PASS
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
fdo#106765 https://bugs.freedesktop.org/show_bug.cgi?id=106765
fdo#107093 https://bugs.freedesktop.org/show_bug.cgi?id=107093
k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133
== Participating hosts (5 -> 5) ==
No changes in participating hosts
== Build changes ==
* IGT: IGT_4570 -> IGTPW_1627
* Linux: CI_DRM_4519 -> CI_DRM_4521
CI_DRM_4519: f14c0ec8fe9acce6fd1be84766f854ab8874eb33 @ git://anongit.freedesktop.org/gfx-ci/linux
CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_1627: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1627/
IGT_4570: 65cdccdc7bcbb791d791aeeeecb784a382110a3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1627/shards.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* [U-Boot] [PATCH] spl: fpga: Implement fpga bistream loading with fpga_load
From: Michal Simek @ 2018-07-23 13:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <fd5bb0fe-173f-c0e7-696d-b9ca34a4b6be@denx.de>
On 19.7.2018 10:35, Marek Vasut wrote:
> On 07/19/2018 08:44 AM, Michal Simek wrote:
>> On 19.7.2018 08:36, Luis Araneda wrote:
>>> Hi,
>>>
>>> On Thu, Jul 19, 2018 at 1:58 AM Michal Simek <michal.simek@xilinx.com> wrote:
>>>> On 18.7.2018 22:11, Marek Vasut wrote:
>>>>> On 07/18/2018 04:57 PM, Michal Simek wrote:
>>>>>> On 18.7.2018 16:24, Marek Vasut wrote:
>>>>>>> On 07/18/2018 04:18 PM, Michal Simek wrote:
>>>>>>>> On 18.7.2018 16:15, Marek Vasut wrote:
>>>>>>>>> On 07/18/2018 04:00 PM, Michal Simek wrote:
>>>>>>>>>> On 18.7.2018 14:54, Marek Vasut wrote:
>>>>>>>>>>> This breaks Arria10, sorry. The private loading function is needed on
>>>>>>>>>>> Arria10 as the whole bitstream is not available in RAM and needs to be
>>>>>>>>>>> loaded piece by piece, see [1]
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=blobdiff;f=arch/arm/mach-socfpga/spl.c;h=82adb5dfb8de62e3d928f6f4405705f3f32a780c;hp=7ee988a2d59831ec6bff927b2a5fdad7f57da055;hb=21f835ebf2b40fc8a3e8b818c5c5ba2555dd7c65;hpb=bd198801cb95b5a8460c95a762cc4a9a44ca85ef
>>>>>>>
>>>>>>> [...]
>>>>>>>>>> The second solution is to check if load address is not 0 and call
>>>>>>>>>> fpga_load only for that. In this case there is a need to check size for SPL.
>>>>>>>>>
>>>>>>>>> 0 is a valid load address, so no.
>>>>>>>>
>>>>>>>> Then new Kconfig option is another way to go now.
>>>>>>>
>>>>>>> No, the firmware loader is a way to go. Sadly, it's still work in progress.
>>>>>>
>>>>>> I have looked at that series and it will take some time to get it done
>>>>>> but even that series has no user and also only support filesystems.
>>>>>> Which is fine but not enough and support for RAW mode is necessary too.
>>>>>
>>>>> It already took like a year and half I think ... well, better invest
>>>>> your resources in perfecting it for your usecase, for that's the way to go.
>>>>
>>>> I don't think so because for SPL boot we need support for a RAW mode.
>>>>
>>>>>
>>>>>> Anyway Luis sent series where this SPL fpga supported is requested to
>>>>>> add and I had this functionality in more raw state in Xilinx tree for
>>>>>> quite a long time and it is time to support it because on Zybo (because
>>>>>> of i2c eeprom) and also cc108 (because of uart routing via PL) fpga load
>>>>>> needs to be done in SPL and we need that support.
>>>>>
>>>>> Ha
>>>>>
>>>>>> I have not a problem to keep your code in SPL but I need a way to enable
>>>>>> fpga load directly with all that features like hashes which are already
>>>>>> available. GZIP can be added pretty easily too.
>>>>>> That's why please suggest a way what you are comfortable with not to
>>>>>> block functionality on these devices.
>>>>>
>>>>> Look at the A10 nand branch, it uses full fit with all the bells and
>>>>> whistles. Maybe that's the way to go if you have DRAM available.
>>>>
>>>> Enabling full fit should be possible but there is really no need to
>>>> enable more and more features for load something to fpga. SPL still
>>>> needs to fit to small space.
>>>
>>> I tested Michal's patch by replacing the fourth patch of my series [1]
>>> with his patch, and it worked fine on a Zybo Z7-20. I think that for
>>> devices with DRAM available is the way to go, but as Marek said, it
>>> will brake Arria10.
>>
>> It doesn't break anything in mainline because there is no support for
>> Arria10.
>
> You might want to git grep a bit ?
I meant arria10 spl fpga support not soc itself.
>
>> His patch for this interface shouldn't reach mainline like it
>> is normal style in Linux. No user, no interface. Also if there is
>> interface already but no user then interfaces are removed like happened
>> with SG_DMA.
>
> Uhh, that's some strong wording right there. We have many other __weak
> functions in U-Boot which are probably never implemented either. Why
> don't you clean those up too instead of focusing on one which enables
> competing platform to work and is protected by Kconfig option, so it
> doesn't change anything for the other platforms ?
I think all of them should be removed.
>>> I'd like to see the functionality merged, but waiting to firmware
>>> loader might delay it. So I propose the following:
>>> - Keep the spl_load_fpga_image() function for devices
>>> like the Arria10.
>>> - Apply the first three patches of my series [1],
>>> as they fix FPGA (Zynq) support on SPL.
>>
>> They are fine please send me as regular patches and I will take them.
>>
>>> - Apply a modified version of Michal's patch, adding
>>> a temporary Kconfig option, like he suggested,
>>> to choose between the two implementations:
>>> fpga_load() for devices with DRAM available, and
>>> spl_load_fpga_image() for devices like the Arria10.
>>> - Once firmware loader is ready, convert the code to
>>> use it and unify the functions if possible.
>>
>> Let's continue to talk with Marek on this. If there he is not open to
>> better solution we need to create new Kconfig property to cover it.
>
> Like CONFIG_SPL_FPGA_SUPPORT ?
One approach is to copy the whole image to DDR and use it.
The second copy it by chunks.
The first is what we need for Xilinx. The second what you need for
Altera because you don't have DDR up and running.
That's why there needs to be likely to Kconfig entries.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v7 2/2] hwmon: ibmpowernv: Add attributes to enable/disable sensor groups
From: Michael Ellerman @ 2018-07-23 13:59 UTC (permalink / raw)
To: Shilpasri G Bhat, linux
Cc: linuxppc-dev, linux-hwmon, linux-kernel, ego, stewart,
Shilpasri G Bhat
In-Reply-To: <1532067143-22022-3-git-send-email-shilpa.bhat@linux.vnet.ibm.com>
Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> writes:
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index f829dad..99afbf7 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -292,12 +344,126 @@ static u32 get_sensor_hwmon_index(struct sensor_data *sdata,
> return ++sensor_groups[sdata->type].hwmon_index;
> }
>
> +static int init_sensor_group_data(struct platform_device *pdev,
> + struct platform_data *pdata)
> +{
> + struct sensor_group_data *sgrp_data;
> + struct device_node *groups, *sgrp;
> + enum sensors type;
> + int count = 0, ret = 0;
> +
> + groups = of_find_compatible_node(NULL, NULL, "ibm,opal-sensor-group");
> + if (!groups)
> + return ret;
> +
> + for_each_child_of_node(groups, sgrp) {
> + type = get_sensor_type(sgrp);
> + if (type != MAX_SENSOR_TYPE)
> + pdata->nr_sensor_groups++;
> + }
> +
> + if (!pdata->nr_sensor_groups)
> + goto out;
> +
> + sgrp_data = devm_kcalloc(&pdev->dev, pdata->nr_sensor_groups,
> + sizeof(*sgrp_data), GFP_KERNEL);
> + if (!sgrp_data) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + for_each_child_of_node(groups, sgrp) {
> + const __be32 *phandles;
> + int len, gid;
> +
> + type = get_sensor_type(sgrp);
> + if (type == MAX_SENSOR_TYPE)
> + continue;
> +
> + if (of_property_read_u32(sgrp, "sensor-group-id", &gid))
> + continue;
> +
> + phandles = of_get_property(sgrp, "sensors", &len);
> + if (!phandles)
> + continue;
You should be able to use the more modern OF APIs, eg:
rc = of_count_phandle_with_args(sgrp, "sensors", NULL);
> + len /= sizeof(u32);
> + if (!len)
> + continue;
Which would make that check unnecessary.
> + sensor_groups[type].attr_count++;
> + sgrp_data[count].gid = gid;
> + mutex_init(&sgrp_data[count].mutex);
> + sgrp_data[count++].enable = false;
> + }
> +
> + pdata->sgrp_data = sgrp_data;
> +out:
> + of_node_put(groups);
> + return ret;
> +}
> +
> +static struct sensor_group_data *get_sensor_group(struct platform_data *pdata,
> + struct device_node *node,
> + enum sensors gtype)
> +{
> + struct sensor_group_data *sgrp_data = pdata->sgrp_data;
> + struct device_node *groups, *sgrp;
> +
> + groups = of_find_compatible_node(NULL, NULL, "ibm,opal-sensor-group");
> + if (!groups)
> + return NULL;
> +
> + for_each_child_of_node(groups, sgrp) {
> + const __be32 *phandles;
> + int len, gid, i;
> + enum sensors type;
> +
> + type = get_sensor_type(sgrp);
> + if (type != gtype)
> + continue;
> +
> + if (of_property_read_u32(sgrp, "sensor-group-id", &gid))
> + continue;
> +
> + phandles = of_get_property(sgrp, "sensors", &len);
> + if (!phandles)
> + continue;
> +
> + len /= sizeof(u32);
> + if (!len)
> + continue;
> +
> + while (--len >= 0)
> + if (be32_to_cpu(phandles[len]) == node->phandle)
> + break;
Likewise, here you could use of_for_each_phandle().
cheers
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for lib: Don't assert all KMS drivers support edid_override
From: Patchwork @ 2018-07-23 13:59 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20180723133613.6418-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: lib: Don't assert all KMS drivers support edid_override
URL : https://patchwork.freedesktop.org/series/47060/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4521 -> IGTPW_1630 =
== Summary - SUCCESS ==
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/47060/revisions/1/mbox/
== Known issues ==
Here are the changes found in IGTPW_1630 that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@drv_module_reload@basic-reload:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106725, fdo#106248)
igt@gem_workarounds@basic-read:
{fi-icl-u}: NOTRUN -> FAIL (fdo#107338)
igt@kms_flip@basic-flip-vs-modeset:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) +1
igt@kms_flip@basic-flip-vs-wf_vblank:
{fi-icl-u}: NOTRUN -> DMESG-WARN (fdo#107335) +42
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614, fdo#106103)
{igt@kms_psr@primary_page_flip}:
{fi-icl-u}: NOTRUN -> DMESG-FAIL (fdo#107335) +3
igt@prime_vgem@basic-fence-read:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719)
==== Possible fixes ====
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: FAIL (fdo#104008) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719
fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000
fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103
fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248
fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725
fdo#107335 https://bugs.freedesktop.org/show_bug.cgi?id=107335
fdo#107338 https://bugs.freedesktop.org/show_bug.cgi?id=107338
== Participating hosts (47 -> 42) ==
Additional (2): fi-bsw-kefka fi-icl-u
Missing (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-snb-2600
== Build changes ==
* IGT: IGT_4570 -> IGTPW_1630
CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_1630: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1630/
IGT_4570: 65cdccdc7bcbb791d791aeeeecb784a382110a3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1630/issues.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* [PATCH] drm/atomic: Initialize variables in drm_atomic_helper_async_check() to make gcc happy
From: Boris Brezillon @ 2018-07-23 13:59 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, dri-devel; +Cc: Boris Brezillon
drm_atomic_helper_async_check() declares the plane, old_plane_state and
new_plane_state variables to iterate over all planes of the atomic
state and make sure only one plane is enabled.
Unfortunately gcc is not smart enough to figure out that the check on
n_planes is enough to guarantee that plane, new_plane_state and
old_plane_state are initialized.
Explicitly initialized those variables to NULL to make gcc happy.
Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane update")
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index f7ccfebd3ca8..80be74df7ba6 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1538,8 +1538,9 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
{
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
- struct drm_plane *plane;
- struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct drm_plane *plane = NULL;
+ struct drm_plane_state *old_plane_state = NULL;
+ struct drm_plane_state *new_plane_state = NULL;
const struct drm_plane_helper_funcs *funcs;
int i, n_planes = 0;
--
2.14.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH 2/2] scsi: set timed out out mq requests to complete
From: Bart Van Assche @ 2018-07-23 13:59 UTC (permalink / raw)
To: hch@lst.de, keith.busch@linux.intel.com
Cc: linux-scsi@vger.kernel.org, keith.busch@intel.com,
linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
axboe@kernel.dk, jianchao.w.wang@oracle.com
In-Reply-To: <20180723081231.GB19247@lst.de>
On Mon, 2018-07-23 at 10:12 +0200, hch@lst.de wrote:
> Btw, one thing we should do in blk-mq and scsi is to make the time
> optional. If the blk_mq driver doesn't even have a timeout struc=
ture
> there is no point in timing out requests and enter the timeout handle=
r
> ever.
Are there any blk-mq drivers that do not define a timeout handler and that
use shared tags? I think such drivers need periodic calls to blk_mq_=
-tag_idle().
Do you perhaps want to happen these calls from another context?
Thanks,
Bart.=
^ permalink raw reply
* [PATCH 2/2] scsi: set timed out out mq requests to complete
From: Bart Van Assche @ 2018-07-23 13:59 UTC (permalink / raw)
In-Reply-To: <20180723081231.GB19247@lst.de>
On Mon, 2018-07-23@10:12 +0200, hch@lst.de wrote:
> Btw, one thing we should do in blk-mq and scsi is to make the time
> optional. If the blk_mq driver doesn't even have a timeout structure
> there is no point in timing out requests and enter the timeout handler
> ever.
Are there any blk-mq drivers that do not define a timeout handler and that
use shared tags? I think such drivers need periodic calls to blk_mq_tag_idle().
Do you perhaps want to happen these calls from another context?
Thanks,
Bart.
^ permalink raw reply
* [PATCH 10/10] NFC: st95hf: add of match table
From: Daniel Mack @ 2018-07-23 14:00 UTC (permalink / raw)
To: sameo-VuQAYsv1563Yd54FQh9/CA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
colin.king-Z7WLFzj8eWMS+FvcfC7Uqw, shikha.singh-qxv4g6HH51o,
Daniel Mack, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180723140015.11663-1-daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
Add a match table for device tree compatible strings. Interestingly, a
document describing the bindings already exists since a while, but users
currently reply on the implicit matching in the drivers core.
Signed-off-by: Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
drivers/nfc/st95hf/core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/nfc/st95hf/core.c b/drivers/nfc/st95hf/core.c
index 4db3c020921c..5a01b454fbc4 100644
--- a/drivers/nfc/st95hf/core.c
+++ b/drivers/nfc/st95hf/core.c
@@ -1012,6 +1012,12 @@ static const struct spi_device_id st95hf_id[] = {
};
MODULE_DEVICE_TABLE(spi, st95hf_id);
+static const struct of_device_id st95hf_of_match[] = {
+ { .compatible = "st,st95hf", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, st95hf_of_match);
+
static int st95hf_probe(struct spi_device *nfc_spi_dev)
{
int ret;
@@ -1189,6 +1195,7 @@ static struct spi_driver st95hf_driver = {
.driver = {
.name = "st95hf",
.owner = THIS_MODULE,
+ .of_match_table = st95hf_of_match,
},
.id_table = st95hf_id,
.probe = st95hf_probe,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Michael Ellerman @ 2018-07-23 14:00 UTC (permalink / raw)
To: Alex Ghiti, Michal Hocko
Cc: linux, catalin.marinas, will.deacon, tony.luck, fenghua.yu, ralf,
paul.burton, jhogan, jejb, deller, benh, paulus, ysato, dalias,
davem, tglx, mingo, hpa, x86, arnd, linux-arm-kernel,
linux-kernel, linux-ia64, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, linux-arch, Naoya Horiguchi, Mike Kravetz
In-Reply-To: <2173685f-7f85-7acb-4685-2383210c5fa2@ghiti.fr>
Alex Ghiti <alex@ghiti.fr> writes:
> Does anyone have any suggestion about those patches ?
Cross compiling it for some non-x86 arches would be a good start :)
There are cross compilers available here:
https://mirrors.edge.kernel.org/pub/tools/crosstool/
cheers
> On 07/09/2018 02:16 PM, Michal Hocko wrote:
>> [CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-alex@ghiti.fr]
>>
>> On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
>>> In order to reduce copy/paste of functions across architectures and then
>>> make riscv hugetlb port (and future ports) simpler and smaller, this
>>> patchset intends to factorize the numerous hugetlb primitives that are
>>> defined across all the architectures.
>>>
>>> Except for prepare_hugepage_range, this patchset moves the versions that
>>> are just pass-through to standard pte primitives into
>>> asm-generic/hugetlb.h by using the same #ifdef semantic that can be
>>> found in asm-generic/pgtable.h, i.e. __HAVE_ARCH_***.
>>>
>>> s390 architecture has not been tackled in this serie since it does not
>>> use asm-generic/hugetlb.h at all.
>>> powerpc could be factorized a bit more (cf huge_ptep_set_wrprotect).
>>>
>>> This patchset has been compiled on x86 only.
>>>
>>> Changelog:
>>>
>>> v4:
>>> Fix powerpc build error due to misplacing of #include
>>> <asm-generic/hugetlb.h> outside of #ifdef CONFIG_HUGETLB_PAGE, as
>>> pointed by Christophe Leroy.
>>>
>>> v1, v2, v3:
>>> Same version, just problems with email provider and misuse of
>>> --batch-size option of git send-email
>>>
>>> Alexandre Ghiti (11):
>>> hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h
>>> hugetlb: Introduce generic version of hugetlb_free_pgd_range
>>> hugetlb: Introduce generic version of set_huge_pte_at
>>> hugetlb: Introduce generic version of huge_ptep_get_and_clear
>>> hugetlb: Introduce generic version of huge_ptep_clear_flush
>>> hugetlb: Introduce generic version of huge_pte_none
>>> hugetlb: Introduce generic version of huge_pte_wrprotect
>>> hugetlb: Introduce generic version of prepare_hugepage_range
>>> hugetlb: Introduce generic version of huge_ptep_set_wrprotect
>>> hugetlb: Introduce generic version of huge_ptep_set_access_flags
>>> hugetlb: Introduce generic version of huge_ptep_get
>>>
>>> arch/arm/include/asm/hugetlb-3level.h | 32 +---------
>>> arch/arm/include/asm/hugetlb.h | 33 +----------
>>> arch/arm64/include/asm/hugetlb.h | 39 +++---------
>>> arch/ia64/include/asm/hugetlb.h | 47 ++-------------
>>> arch/mips/include/asm/hugetlb.h | 40 +++----------
>>> arch/parisc/include/asm/hugetlb.h | 33 +++--------
>>> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +
>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
>>> arch/powerpc/include/asm/hugetlb.h | 43 ++------------
>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
>>> arch/sh/include/asm/hugetlb.h | 54 ++---------------
>>> arch/sparc/include/asm/hugetlb.h | 40 +++----------
>>> arch/x86/include/asm/hugetlb.h | 72 +----------------------
>>> include/asm-generic/hugetlb.h | 88 +++++++++++++++++++++++++++-
>>> 15 files changed, 143 insertions(+), 384 deletions(-)
>>>
>>> --
>>> 2.16.2
^ permalink raw reply
* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Michael Ellerman @ 2018-07-23 14:00 UTC (permalink / raw)
To: Alex Ghiti, Michal Hocko
Cc: linux, catalin.marinas, will.deacon, tony.luck, fenghua.yu, ralf,
paul.burton, jhogan, jejb, deller, benh, paulus, ysato, dalias,
davem, tglx, mingo, hpa, x86, arnd, linux-arm-kernel,
linux-kernel, linux-ia64, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, linux-arch, Naoya Horiguchi, Mike Kravetz
In-Reply-To: <2173685f-7f85-7acb-4685-2383210c5fa2@ghiti.fr>
Alex Ghiti <alex@ghiti.fr> writes:
> Does anyone have any suggestion about those patches ?
Cross compiling it for some non-x86 arches would be a good start :)
There are cross compilers available here:
https://mirrors.edge.kernel.org/pub/tools/crosstool/
cheers
> On 07/09/2018 02:16 PM, Michal Hocko wrote:
>> [CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-alex@ghiti.fr]
>>
>> On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
>>> In order to reduce copy/paste of functions across architectures and then
>>> make riscv hugetlb port (and future ports) simpler and smaller, this
>>> patchset intends to factorize the numerous hugetlb primitives that are
>>> defined across all the architectures.
>>>
>>> Except for prepare_hugepage_range, this patchset moves the versions that
>>> are just pass-through to standard pte primitives into
>>> asm-generic/hugetlb.h by using the same #ifdef semantic that can be
>>> found in asm-generic/pgtable.h, i.e. __HAVE_ARCH_***.
>>>
>>> s390 architecture has not been tackled in this serie since it does not
>>> use asm-generic/hugetlb.h at all.
>>> powerpc could be factorized a bit more (cf huge_ptep_set_wrprotect).
>>>
>>> This patchset has been compiled on x86 only.
>>>
>>> Changelog:
>>>
>>> v4:
>>> Fix powerpc build error due to misplacing of #include
>>> <asm-generic/hugetlb.h> outside of #ifdef CONFIG_HUGETLB_PAGE, as
>>> pointed by Christophe Leroy.
>>>
>>> v1, v2, v3:
>>> Same version, just problems with email provider and misuse of
>>> --batch-size option of git send-email
>>>
>>> Alexandre Ghiti (11):
>>> hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h
>>> hugetlb: Introduce generic version of hugetlb_free_pgd_range
>>> hugetlb: Introduce generic version of set_huge_pte_at
>>> hugetlb: Introduce generic version of huge_ptep_get_and_clear
>>> hugetlb: Introduce generic version of huge_ptep_clear_flush
>>> hugetlb: Introduce generic version of huge_pte_none
>>> hugetlb: Introduce generic version of huge_pte_wrprotect
>>> hugetlb: Introduce generic version of prepare_hugepage_range
>>> hugetlb: Introduce generic version of huge_ptep_set_wrprotect
>>> hugetlb: Introduce generic version of huge_ptep_set_access_flags
>>> hugetlb: Introduce generic version of huge_ptep_get
>>>
>>> arch/arm/include/asm/hugetlb-3level.h | 32 +---------
>>> arch/arm/include/asm/hugetlb.h | 33 +----------
>>> arch/arm64/include/asm/hugetlb.h | 39 +++---------
>>> arch/ia64/include/asm/hugetlb.h | 47 ++-------------
>>> arch/mips/include/asm/hugetlb.h | 40 +++----------
>>> arch/parisc/include/asm/hugetlb.h | 33 +++--------
>>> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +
>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
>>> arch/powerpc/include/asm/hugetlb.h | 43 ++------------
>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
>>> arch/sh/include/asm/hugetlb.h | 54 ++---------------
>>> arch/sparc/include/asm/hugetlb.h | 40 +++----------
>>> arch/x86/include/asm/hugetlb.h | 72 +----------------------
>>> include/asm-generic/hugetlb.h | 88 +++++++++++++++++++++++++++-
>>> 15 files changed, 143 insertions(+), 384 deletions(-)
>>>
>>> --
>>> 2.16.2
^ permalink raw reply
* [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Michael Ellerman @ 2018-07-23 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2173685f-7f85-7acb-4685-2383210c5fa2@ghiti.fr>
Alex Ghiti <alex@ghiti.fr> writes:
> Does anyone have any suggestion about those patches ?
Cross compiling it for some non-x86 arches would be a good start :)
There are cross compilers available here:
https://mirrors.edge.kernel.org/pub/tools/crosstool/
cheers
> On 07/09/2018 02:16 PM, Michal Hocko wrote:
>> [CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-alex at ghiti.fr]
>>
>> On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
>>> In order to reduce copy/paste of functions across architectures and then
>>> make riscv hugetlb port (and future ports) simpler and smaller, this
>>> patchset intends to factorize the numerous hugetlb primitives that are
>>> defined across all the architectures.
>>>
>>> Except for prepare_hugepage_range, this patchset moves the versions that
>>> are just pass-through to standard pte primitives into
>>> asm-generic/hugetlb.h by using the same #ifdef semantic that can be
>>> found in asm-generic/pgtable.h, i.e. __HAVE_ARCH_***.
>>>
>>> s390 architecture has not been tackled in this serie since it does not
>>> use asm-generic/hugetlb.h at all.
>>> powerpc could be factorized a bit more (cf huge_ptep_set_wrprotect).
>>>
>>> This patchset has been compiled on x86 only.
>>>
>>> Changelog:
>>>
>>> v4:
>>> Fix powerpc build error due to misplacing of #include
>>> <asm-generic/hugetlb.h> outside of #ifdef CONFIG_HUGETLB_PAGE, as
>>> pointed by Christophe Leroy.
>>>
>>> v1, v2, v3:
>>> Same version, just problems with email provider and misuse of
>>> --batch-size option of git send-email
>>>
>>> Alexandre Ghiti (11):
>>> hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h
>>> hugetlb: Introduce generic version of hugetlb_free_pgd_range
>>> hugetlb: Introduce generic version of set_huge_pte_at
>>> hugetlb: Introduce generic version of huge_ptep_get_and_clear
>>> hugetlb: Introduce generic version of huge_ptep_clear_flush
>>> hugetlb: Introduce generic version of huge_pte_none
>>> hugetlb: Introduce generic version of huge_pte_wrprotect
>>> hugetlb: Introduce generic version of prepare_hugepage_range
>>> hugetlb: Introduce generic version of huge_ptep_set_wrprotect
>>> hugetlb: Introduce generic version of huge_ptep_set_access_flags
>>> hugetlb: Introduce generic version of huge_ptep_get
>>>
>>> arch/arm/include/asm/hugetlb-3level.h | 32 +---------
>>> arch/arm/include/asm/hugetlb.h | 33 +----------
>>> arch/arm64/include/asm/hugetlb.h | 39 +++---------
>>> arch/ia64/include/asm/hugetlb.h | 47 ++-------------
>>> arch/mips/include/asm/hugetlb.h | 40 +++----------
>>> arch/parisc/include/asm/hugetlb.h | 33 +++--------
>>> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +
>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
>>> arch/powerpc/include/asm/hugetlb.h | 43 ++------------
>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
>>> arch/sh/include/asm/hugetlb.h | 54 ++---------------
>>> arch/sparc/include/asm/hugetlb.h | 40 +++----------
>>> arch/x86/include/asm/hugetlb.h | 72 +----------------------
>>> include/asm-generic/hugetlb.h | 88 +++++++++++++++++++++++++++-
>>> 15 files changed, 143 insertions(+), 384 deletions(-)
>>>
>>> --
>>> 2.16.2
^ permalink raw reply
* [U-Boot] [PATCH] fpga: Kconfig: Replace spaces with tabs
From: Michal Simek @ 2018-07-23 14:00 UTC (permalink / raw)
To: u-boot
Trivial Kconfig cleanup. Use tabs instead of spaces.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/fpga/Kconfig | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index d36c4c5e2804..50e901973d13 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -46,15 +46,15 @@ config FPGA_ZYNQMPPL
on Xilinx Zynq UltraScale+ (ZynqMP) device.
config FPGA_SPARTAN3
- bool "Enable Spartan3 FPGA driver"
- help
- Enable Spartan3 FPGA driver for loading in BIT format.
+ bool "Enable Spartan3 FPGA driver"
+ help
+ Enable Spartan3 FPGA driver for loading in BIT format.
config FPGA_ZYNQPL
- bool "Enable Xilinx FPGA for Zynq"
- depends on ARCH_ZYNQ
- help
- Enable FPGA driver for loading bitstream in BIT and BIN format
- on Xilinx Zynq devices.
+ bool "Enable Xilinx FPGA for Zynq"
+ depends on ARCH_ZYNQ
+ help
+ Enable FPGA driver for loading bitstream in BIT and BIN format
+ on Xilinx Zynq devices.
endmenu
--
1.9.1
^ permalink raw reply related
* Re: Is thin provisioning still experimental?
From: Mike Snitzer @ 2018-07-23 14:00 UTC (permalink / raw)
To: Drew Hastings; +Cc: dm-devel
In-Reply-To: <CAN-y+EK612pGsJTH-zO=FU0DpcFJxKfEHuDNs+6ufE6we9aK+g@mail.gmail.com>
On Mon, Jul 23 2018 at 1:06am -0400,
Drew Hastings <dhastings@crucialwebhost.com> wrote:
> I love all of the work you guys do @dm-devel . Thanks for taking the time
> to read this.
> I would like to use thin provisioning targets in production, but it's hard
> to ignore the warning in the documentation. It seems like, with an
> understanding of how thin provisioning works, it should be safe to use.
It is stale. I just committed this update that'll go upstream for the
4.19 merge window, see:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.19&id=f88a3f746ff0047c92e8312646247b08264daf35
> If the metadata and data device for the thin pool have enough space and
> are both error free, the kernel has plenty of free RAM, block sizes are
> set large enough to never run into performance issues (64 MiB), all of the
> underlying hardware is redundant on high performance NVME (no worries of
> fragmentation of data volume)... is it still unsafe for production? If so,
> can you shed some light on why that is?
It is safe. You do just want to make sure to not run out of space. We
now handle that event favorably but it is best to tempt fate. No idea
what, if any, filesystem you intend to run but XFS has the ability to
discontinue retries for certain error conditions. I highly recommend
you enable that for ENOSPC, otherwise you _will_ see the kernel block
indefinitely in XFS if thinp runs out of space underneath XFS.
> Thin provisioning is so cool. It would be a shame to not use it!
> Thank you so much!
Enjoy.
Mike
^ permalink raw reply
* Re: [Qemu-arm] [RFC PATCH 5/6] virt-acpi-build: add PPTT table
From: Igor Mammedov @ 2018-07-23 14:00 UTC (permalink / raw)
To: Andrew Jones
Cc: peter.maydell, Michael S. Tsirkin, qemu-devel, eric.auger,
qemu-arm, Shannon Zhao
In-Reply-To: <20180704124923.32483-6-drjones@redhat.com>
On Wed, 4 Jul 2018 14:49:22 +0200
Andrew Jones <drjones@redhat.com> wrote:
> The ACPI PPTT table supports topology descriptions for ACPI
> guests. Note, while a DT boot Linux guest with a non-flat CPU
> topology will see socket and core IDs being sequential integers
> starting from zero, e.g. with -smp 4,sockets=2,cores=2,threads=1
>
> a DT boot produces
>
> cpu: 0 package_id: 0 core_id: 0
> cpu: 1 package_id: 0 core_id: 1
> cpu: 2 package_id: 1 core_id: 0
> cpu: 3 package_id: 1 core_id: 1
>
> an ACPI boot produces
>
> cpu: 0 package_id: 36 core_id: 0
> cpu: 1 package_id: 36 core_id: 1
> cpu: 2 package_id: 96 core_id: 2
> cpu: 3 package_id: 96 core_id: 3
>
> This is due to several reasons:
>
> 1) DT cpu nodes do not have an equivalent field to what the PPTT
> ACPI Processor ID must be, i.e. something equal to the MADT CPU
> UID or equal to the UID of an ACPI processor container. In both
> ACPI cases those are platform dependant IDs assigned by the
> vendor.
>
> 2) While QEMU is the vendor for a guest, if the topology specifies
> SMT (> 1 thread), then, with ACPI, it is impossible to assign a
> core-id the same value as a package-id, thus it is not possible
> to have package-id=0 and core-id=0. This is because package and
> core containers must be in the same ACPI namespace and therefore
> must have unique UIDs.
>
> 3) ACPI processor containers are not required for PPTT tables to
> be used and, due to the limitations of which IDs are selected
> described above in (2), they are not helpful for QEMU, so we
> don't build them with this patch. In the absence of them, Linux
> assigns its own unique IDs. The maintainers have chosen not to use
> counters from zero, but rather ACPI table offsets, which explains
> why the numbers are so much larger than with DT.
>
> 4) When there is no SMT (threads=1) the core IDs for ACPI boot guests
> match the logical CPU IDs, because these IDs must be equal to the
> MADT CPU UID (as no processor containers are present), and QEMU
> uses the logical CPU ID for these MADT IDs.
>
> Cc: Igor Mammedov <imammedo@redhat.com>
> Cc: Shannon Zhao <zhaoshenglong@huawei.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> hw/acpi/aml-build.c | 50 +++++++++++++++++++++++++++++++++++++
> hw/arm/virt-acpi-build.c | 5 ++++
> include/hw/acpi/aml-build.h | 2 ++
> 3 files changed, 57 insertions(+)
>
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index 1e43cd736de9..37e8f5182ae9 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -24,6 +24,7 @@
> #include "hw/acpi/aml-build.h"
> #include "qemu/bswap.h"
> #include "qemu/bitops.h"
> +#include "sysemu/cpus.h"
> #include "sysemu/numa.h"
>
> static GArray *build_alloc_array(void)
> @@ -1679,6 +1680,55 @@ void build_slit(GArray *table_data, BIOSLinker *linker)
> table_data->len - slit_start, 1, NULL, NULL);
> }
>
> +/*
> + * ACPI 6.2 Processor Properties Topology Table (PPTT)
ACPI 6.2: 5.2.29.1 Processor hierarchy node structure (Type 0)
> + */
> +static void build_cpu_hierarchy(GArray *tbl, uint32_t flags,
> + uint32_t parent, uint32_t id)
build_processor_hierarchy_node()
> +{
> + build_append_byte(tbl, 0); /* Type 0 - processor */
> + build_append_byte(tbl, 20); /* Length, no private resources */
> + build_append_int_noprefix(tbl, 0, 2); /* Reserved */
> + build_append_int_noprefix(tbl, flags, 4);
just being pedantic, even for obvious fields add a comment that matches
field name in spec, like:
build_append_int_noprefix(tbl, flags, 4); /* Parent */
> + build_append_int_noprefix(tbl, parent, 4);
> + build_append_int_noprefix(tbl, id, 4);
> + build_append_int_noprefix(tbl, 0, 4); /* Num private resources */
put comment on new line if it doesn't fit into 80limit but use full
field name from spec
> +}
> +
> +void build_pptt(GArray *table_data, BIOSLinker *linker, int possible_cpus)
> +{
> + int pptt_start = table_data->len;
> + int uid = 0, cpus = 0, socket;
> +
> + acpi_data_push(table_data, sizeof(AcpiTableHeader));
> +
> + for (socket = 0; cpus < possible_cpus; socket++) {
probably should use possible_cpus->cpus[] here to iterate over
cpus and maybe socket_id... from there as well
> + uint32_t socket_offset = table_data->len - pptt_start;
> + int core;
> +
> + build_cpu_hierarchy(table_data, 1, 0, socket);
build_cpu_hierarchy(table_data, ACPI_PROC_HEIRARHY_PACKAGE, 0 /* no parent */ , socket);
> +
> + for (core = 0; core < smp_cores; core++) {
> + uint32_t core_offset = table_data->len - pptt_start;
> + int thread;
> +
> + if (smp_threads > 1) {
> + build_cpu_hierarchy(table_data, 0, socket_offset, core);
> + for (thread = 0; thread < smp_threads; thread++) {
maybe set/use core_id and thread_id from possible_cpus instead of
making up ID numbers here?
> + build_cpu_hierarchy(table_data, 2, core_offset, uid++);
> + }
> + } else {
> + build_cpu_hierarchy(table_data, 2, socket_offset, uid++);
> + }
> + }
> + cpus += smp_cores * smp_threads;
> + }
> +
> + build_header(linker, table_data,
> + (void *)(table_data->data + pptt_start), "PPTT",
> + table_data->len - pptt_start, 1, NULL, NULL);
> +}
> +
> /* build rev1/rev3/rev5.1 FADT */
> void build_fadt(GArray *tbl, BIOSLinker *linker, const AcpiFadtData *f,
> const char *oem_id, const char *oem_table_id)
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 1d1fc824da6f..aa77e1f018d9 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -832,6 +832,11 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> acpi_add_table(table_offsets, tables_blob);
> build_madt(tables_blob, tables->linker, vms);
>
> + if (!vmc->ignore_cpu_topology) {
> + acpi_add_table(table_offsets, tables_blob);
> + build_pptt(tables_blob, tables->linker, possible_cpus(vms));
> + }
> +
> acpi_add_table(table_offsets, tables_blob);
> build_gtdt(tables_blob, tables->linker, vms);
>
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index 6c36903c0a5d..2b0fde6bd417 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -414,6 +414,8 @@ void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
>
> void build_slit(GArray *table_data, BIOSLinker *linker);
>
> +void build_pptt(GArray *table_data, BIOSLinker *linker, int possible_cpus);
> +
> void build_fadt(GArray *tbl, BIOSLinker *linker, const AcpiFadtData *f,
> const char *oem_id, const char *oem_table_id);
> #endif
^ permalink raw reply
* Re: [Qemu-devel] [RFC PATCH 5/6] virt-acpi-build: add PPTT table
From: Igor Mammedov @ 2018-07-23 14:00 UTC (permalink / raw)
To: Andrew Jones
Cc: qemu-devel, qemu-arm, peter.maydell, eric.auger, wei,
Shannon Zhao, Michael S. Tsirkin
In-Reply-To: <20180704124923.32483-6-drjones@redhat.com>
On Wed, 4 Jul 2018 14:49:22 +0200
Andrew Jones <drjones@redhat.com> wrote:
> The ACPI PPTT table supports topology descriptions for ACPI
> guests. Note, while a DT boot Linux guest with a non-flat CPU
> topology will see socket and core IDs being sequential integers
> starting from zero, e.g. with -smp 4,sockets=2,cores=2,threads=1
>
> a DT boot produces
>
> cpu: 0 package_id: 0 core_id: 0
> cpu: 1 package_id: 0 core_id: 1
> cpu: 2 package_id: 1 core_id: 0
> cpu: 3 package_id: 1 core_id: 1
>
> an ACPI boot produces
>
> cpu: 0 package_id: 36 core_id: 0
> cpu: 1 package_id: 36 core_id: 1
> cpu: 2 package_id: 96 core_id: 2
> cpu: 3 package_id: 96 core_id: 3
>
> This is due to several reasons:
>
> 1) DT cpu nodes do not have an equivalent field to what the PPTT
> ACPI Processor ID must be, i.e. something equal to the MADT CPU
> UID or equal to the UID of an ACPI processor container. In both
> ACPI cases those are platform dependant IDs assigned by the
> vendor.
>
> 2) While QEMU is the vendor for a guest, if the topology specifies
> SMT (> 1 thread), then, with ACPI, it is impossible to assign a
> core-id the same value as a package-id, thus it is not possible
> to have package-id=0 and core-id=0. This is because package and
> core containers must be in the same ACPI namespace and therefore
> must have unique UIDs.
>
> 3) ACPI processor containers are not required for PPTT tables to
> be used and, due to the limitations of which IDs are selected
> described above in (2), they are not helpful for QEMU, so we
> don't build them with this patch. In the absence of them, Linux
> assigns its own unique IDs. The maintainers have chosen not to use
> counters from zero, but rather ACPI table offsets, which explains
> why the numbers are so much larger than with DT.
>
> 4) When there is no SMT (threads=1) the core IDs for ACPI boot guests
> match the logical CPU IDs, because these IDs must be equal to the
> MADT CPU UID (as no processor containers are present), and QEMU
> uses the logical CPU ID for these MADT IDs.
>
> Cc: Igor Mammedov <imammedo@redhat.com>
> Cc: Shannon Zhao <zhaoshenglong@huawei.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> hw/acpi/aml-build.c | 50 +++++++++++++++++++++++++++++++++++++
> hw/arm/virt-acpi-build.c | 5 ++++
> include/hw/acpi/aml-build.h | 2 ++
> 3 files changed, 57 insertions(+)
>
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index 1e43cd736de9..37e8f5182ae9 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -24,6 +24,7 @@
> #include "hw/acpi/aml-build.h"
> #include "qemu/bswap.h"
> #include "qemu/bitops.h"
> +#include "sysemu/cpus.h"
> #include "sysemu/numa.h"
>
> static GArray *build_alloc_array(void)
> @@ -1679,6 +1680,55 @@ void build_slit(GArray *table_data, BIOSLinker *linker)
> table_data->len - slit_start, 1, NULL, NULL);
> }
>
> +/*
> + * ACPI 6.2 Processor Properties Topology Table (PPTT)
ACPI 6.2: 5.2.29.1 Processor hierarchy node structure (Type 0)
> + */
> +static void build_cpu_hierarchy(GArray *tbl, uint32_t flags,
> + uint32_t parent, uint32_t id)
build_processor_hierarchy_node()
> +{
> + build_append_byte(tbl, 0); /* Type 0 - processor */
> + build_append_byte(tbl, 20); /* Length, no private resources */
> + build_append_int_noprefix(tbl, 0, 2); /* Reserved */
> + build_append_int_noprefix(tbl, flags, 4);
just being pedantic, even for obvious fields add a comment that matches
field name in spec, like:
build_append_int_noprefix(tbl, flags, 4); /* Parent */
> + build_append_int_noprefix(tbl, parent, 4);
> + build_append_int_noprefix(tbl, id, 4);
> + build_append_int_noprefix(tbl, 0, 4); /* Num private resources */
put comment on new line if it doesn't fit into 80limit but use full
field name from spec
> +}
> +
> +void build_pptt(GArray *table_data, BIOSLinker *linker, int possible_cpus)
> +{
> + int pptt_start = table_data->len;
> + int uid = 0, cpus = 0, socket;
> +
> + acpi_data_push(table_data, sizeof(AcpiTableHeader));
> +
> + for (socket = 0; cpus < possible_cpus; socket++) {
probably should use possible_cpus->cpus[] here to iterate over
cpus and maybe socket_id... from there as well
> + uint32_t socket_offset = table_data->len - pptt_start;
> + int core;
> +
> + build_cpu_hierarchy(table_data, 1, 0, socket);
build_cpu_hierarchy(table_data, ACPI_PROC_HEIRARHY_PACKAGE, 0 /* no parent */ , socket);
> +
> + for (core = 0; core < smp_cores; core++) {
> + uint32_t core_offset = table_data->len - pptt_start;
> + int thread;
> +
> + if (smp_threads > 1) {
> + build_cpu_hierarchy(table_data, 0, socket_offset, core);
> + for (thread = 0; thread < smp_threads; thread++) {
maybe set/use core_id and thread_id from possible_cpus instead of
making up ID numbers here?
> + build_cpu_hierarchy(table_data, 2, core_offset, uid++);
> + }
> + } else {
> + build_cpu_hierarchy(table_data, 2, socket_offset, uid++);
> + }
> + }
> + cpus += smp_cores * smp_threads;
> + }
> +
> + build_header(linker, table_data,
> + (void *)(table_data->data + pptt_start), "PPTT",
> + table_data->len - pptt_start, 1, NULL, NULL);
> +}
> +
> /* build rev1/rev3/rev5.1 FADT */
> void build_fadt(GArray *tbl, BIOSLinker *linker, const AcpiFadtData *f,
> const char *oem_id, const char *oem_table_id)
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 1d1fc824da6f..aa77e1f018d9 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -832,6 +832,11 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> acpi_add_table(table_offsets, tables_blob);
> build_madt(tables_blob, tables->linker, vms);
>
> + if (!vmc->ignore_cpu_topology) {
> + acpi_add_table(table_offsets, tables_blob);
> + build_pptt(tables_blob, tables->linker, possible_cpus(vms));
> + }
> +
> acpi_add_table(table_offsets, tables_blob);
> build_gtdt(tables_blob, tables->linker, vms);
>
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index 6c36903c0a5d..2b0fde6bd417 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -414,6 +414,8 @@ void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
>
> void build_slit(GArray *table_data, BIOSLinker *linker);
>
> +void build_pptt(GArray *table_data, BIOSLinker *linker, int possible_cpus);
> +
> void build_fadt(GArray *tbl, BIOSLinker *linker, const AcpiFadtData *f,
> const char *oem_id, const char *oem_table_id);
> #endif
^ permalink raw reply
* Re: [PATCH v2 4/8] NTB: ntb_pingpong: Choose doorbells based on port number
From: Allen Hubbe @ 2018-07-23 14:01 UTC (permalink / raw)
To: logang
Cc: linux-kernel, linux-ntb, Jon Mason, fancer.lancer,
Shyam-sundar.S-k, shuah, dmeyer
In-Reply-To: <20180720180034.3964-5-logang@deltatee.com>
On Fri, Jul 20, 2018 at 2:00 PM Logan Gunthorpe <logang@deltatee.com> wrote:
>
> This commit fixes pingpong support for existing drivers that do not
> implement ntb_default_port_number() and ntb_default_peer_port_number().
> This is required for hardware (like the crosslink topology of
> switchtec) which cannot assign reasonable port numbers to each port due
> to its perfect symmetry.
>
> Instead of picking the doorbell to use based on the the index of the
> peer, we use the peer's port number. This is a bit clearer and easier
> to understand.
Does this solve the issue where two of the the port numbers are the
same, because of symmetry over a crosslink? I think the two ports
with the "same" number should be identified as different peer index,
even if the port numbers are the same.
Maybe the port of any peer connected over the crosslink should be the
local switch's crosslink port. The local port number might be needed
to configure translation tables in the local switch. If a globally
unique port number is needed, maybe encode a chip number in some high
bits of the port number? If a locally unique port number is needed,
maybe encode a path, that could be useful for configuring address
translations across multiple crosslinks. Encoding a path, then each
port will have a different number, depending on the perspective of the
source port, which could be confusing (already, peer index is local
perspective, so can cause the same kind of confusion). IMO port
number can be anything useful for specific ntb driver and devices, or
maybe just be informative, but peer index should be useful for ntb
client drivers.
> Fixes: c7aeb0afdcc2 ("NTB: ntb_pp: Add full multi-port NTB API support")
> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
> ---
> drivers/ntb/test/ntb_pingpong.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/ntb/test/ntb_pingpong.c b/drivers/ntb/test/ntb_pingpong.c
> index 65865e460ab8..18d00eec7b02 100644
> --- a/drivers/ntb/test/ntb_pingpong.c
> +++ b/drivers/ntb/test/ntb_pingpong.c
> @@ -121,15 +121,14 @@ static int pp_find_next_peer(struct pp_ctx *pp)
> link = ntb_link_is_up(pp->ntb, NULL, NULL);
>
> /* Find next available peer */
> - if (link & pp->nmask) {
> + if (link & pp->nmask)
> pidx = __ffs64(link & pp->nmask);
> - out_db = BIT_ULL(pidx + 1);
Without +1 here, does this ring the same bell again?
> - } else if (link & pp->pmask) {
> + else if (link & pp->pmask)
> pidx = __ffs64(link & pp->pmask);
> - out_db = BIT_ULL(pidx);
> - } else {
> + else
> return -ENODEV;
> - }
> +
> + out_db = BIT_ULL(ntb_peer_port_number(pp->ntb, pidx));
Can it not be made to work with peer index?
>
> spin_lock(&pp->lock);
> pp->out_pidx = pidx;
> @@ -303,7 +302,7 @@ static void pp_init_flds(struct pp_ctx *pp)
> break;
> }
>
> - pp->in_db = BIT_ULL(pidx);
> + pp->in_db = BIT_ULL(lport);
> pp->pmask = GENMASK_ULL(pidx, 0) >> 1;
> pp->nmask = GENMASK_ULL(pcnt - 1, pidx);
>
> @@ -435,4 +434,3 @@ static void __exit pp_exit(void)
> debugfs_remove_recursive(pp_dbgfs_topdir);
> }
> module_exit(pp_exit);
> -
> --
> 2.11.0
^ permalink raw reply
* Re: kernel BUG at mm/shmem.c:LINE!
From: Matthew Wilcox @ 2018-07-23 14:01 UTC (permalink / raw)
To: Hugh Dickins
Cc: syzbot, Kirill A. Shutemov, Andrew Morton, linux-kernel, linux-mm,
syzkaller-bugs
In-Reply-To: <alpine.LSU.2.11.1807221856350.5536@eggly.anvils>
On Sun, Jul 22, 2018 at 07:28:01PM -0700, Hugh Dickins wrote:
> Whether or not that fixed syzbot's kernel BUG at mm/shmem.c:815!
> I don't know, but I'm afraid it has not fixed linux-next breakage of
> huge tmpfs: I get a similar page_to_pgoff BUG at mm/filemap.c:1466!
>
> Please try something like
> mount -o remount,huge=always /dev/shm
> cp /dev/zero /dev/shm
>
> Writing soon crashes in find_lock_entry(), looking up offset 0x201
> but getting the page for offset 0x3c1 instead.
Hmm. I don't see a crash while running that command, but I do see an RCU
stall in find_get_entries() called from shmem_undo_range() when running
'cp' the second time -- ie while truncating the /dev/shm/zero file.
Maybe I'm seeing the same bug as you, and maybe I'm seeing a different
one. Do we have a shmem test suite somewhere?
> I've spent a while on it, but better turn over to you, Matthew:
> my guess is that xas_create_range() does not create the layout
> you expect from it.
I've dumped the XArray tree on my machine and it actually looks fine
*except* that the pages pointed to are free! That indicates to me I
screwed up somebody's reference count somewhere.
^ permalink raw reply
* option: Do not try to bind to ADB interfaces
From: Romain Izard @ 2018-07-23 14:02 UTC (permalink / raw)
To: Johan Hovold, Greg Kroah-Hartman
Cc: linux-usb, linux-kernel, Romain Izard, stable
Some modems now use the Android Debug Bridge to provide a debugging
interface, and some phones can also export serial ports managed by the
"option" driver.
The ADB daemon running in userspace tries to use USB interfaces with
bDeviceClass=0xFF, bDeviceSubClass=0x42, bDeviceProtocol=1
Prevent the option driver from binding to those interfaces, as they
will not be serial ports.
This can fix issues like:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781256
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Cc: stable <stable@vger.kernel.org>
---
drivers/usb/serial/option.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 664e61f16b6a..f98943a57ff0 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1987,6 +1987,12 @@ static int option_probe(struct usb_serial *serial,
if (iface_desc->bInterfaceClass == USB_CLASS_MASS_STORAGE)
return -ENODEV;
+ /* Do not bind Android Debug Bridge interfaces */
+ if (iface_desc->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
+ iface_desc->bInterfaceSubClass == 0x42 &&
+ iface_desc->bInterfaceProtocol == 1)
+ return -ENODEV;
+
/*
* Don't bind reserved interfaces (like network ones) which often have
* the same class/subclass/protocol as the serial interfaces. Look at
^ permalink raw reply related
* [PATCH] option: Do not try to bind to ADB interfaces
From: Romain Izard @ 2018-07-23 14:02 UTC (permalink / raw)
To: Johan Hovold, Greg Kroah-Hartman
Cc: linux-usb, linux-kernel, Romain Izard, stable
Some modems now use the Android Debug Bridge to provide a debugging
interface, and some phones can also export serial ports managed by the
"option" driver.
The ADB daemon running in userspace tries to use USB interfaces with
bDeviceClass=0xFF, bDeviceSubClass=0x42, bDeviceProtocol=1
Prevent the option driver from binding to those interfaces, as they
will not be serial ports.
This can fix issues like:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781256
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Cc: stable <stable@vger.kernel.org>
---
drivers/usb/serial/option.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 664e61f16b6a..f98943a57ff0 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1987,6 +1987,12 @@ static int option_probe(struct usb_serial *serial,
if (iface_desc->bInterfaceClass == USB_CLASS_MASS_STORAGE)
return -ENODEV;
+ /* Do not bind Android Debug Bridge interfaces */
+ if (iface_desc->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
+ iface_desc->bInterfaceSubClass == 0x42 &&
+ iface_desc->bInterfaceProtocol == 1)
+ return -ENODEV;
+
/*
* Don't bind reserved interfaces (like network ones) which often have
* the same class/subclass/protocol as the serial interfaces. Look at
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 1/2] block: move dif_prepare/dif_complete functions to block layer
From: Keith Busch @ 2018-07-23 14:02 UTC (permalink / raw)
To: Max Gurtovoy
Cc: martin.petersen, linux-block, axboe, keith.busch, linux-nvme,
sagi, hch
In-Reply-To: <1532252998-2375-1-git-send-email-maxg@mellanox.com>
On Sun, Jul 22, 2018 at 12:49:57PM +0300, Max Gurtovoy wrote:
> +void blk_integrity_dif_prepare(struct request *rq, u8 protection_type,
> + u32 ref_tag)
> +{
> + const int tuple_sz = sizeof(struct t10_pi_tuple);
> + struct bio *bio;
> + struct t10_pi_tuple *pi;
> + u32 phys, virt;
> +
> + if (protection_type == T10_PI_TYPE3_PROTECTION)
> + return;
> +
> + phys = ref_tag;
> +
> + __rq_for_each_bio(bio, rq) {
> + struct bio_integrity_payload *bip = bio_integrity(bio);
> + struct bio_vec iv;
> + struct bvec_iter iter;
> + unsigned int j;
> +
> + /* Already remapped? */
> + if (bip->bip_flags & BIP_MAPPED_INTEGRITY)
> + break;
> +
> + virt = bip_get_seed(bip) & 0xffffffff;
> +
> + bip_for_each_vec(iv, bip, iter) {
> + pi = kmap_atomic(iv.bv_page) + iv.bv_offset;
> +
> + for (j = 0; j < iv.bv_len; j += tuple_sz, pi++) {
nvme's data integrity buffer can actually have more space between each
PI field, so we just need to account for that when iterating instead of
assuming each element is the size of a T10 PI tuple.
Otherwise, great idea.
^ permalink raw reply
* [PATCH 1/2] block: move dif_prepare/dif_complete functions to block layer
From: Keith Busch @ 2018-07-23 14:02 UTC (permalink / raw)
In-Reply-To: <1532252998-2375-1-git-send-email-maxg@mellanox.com>
On Sun, Jul 22, 2018@12:49:57PM +0300, Max Gurtovoy wrote:
> +void blk_integrity_dif_prepare(struct request *rq, u8 protection_type,
> + u32 ref_tag)
> +{
> + const int tuple_sz = sizeof(struct t10_pi_tuple);
> + struct bio *bio;
> + struct t10_pi_tuple *pi;
> + u32 phys, virt;
> +
> + if (protection_type == T10_PI_TYPE3_PROTECTION)
> + return;
> +
> + phys = ref_tag;
> +
> + __rq_for_each_bio(bio, rq) {
> + struct bio_integrity_payload *bip = bio_integrity(bio);
> + struct bio_vec iv;
> + struct bvec_iter iter;
> + unsigned int j;
> +
> + /* Already remapped? */
> + if (bip->bip_flags & BIP_MAPPED_INTEGRITY)
> + break;
> +
> + virt = bip_get_seed(bip) & 0xffffffff;
> +
> + bip_for_each_vec(iv, bip, iter) {
> + pi = kmap_atomic(iv.bv_page) + iv.bv_offset;
> +
> + for (j = 0; j < iv.bv_len; j += tuple_sz, pi++) {
nvme's data integrity buffer can actually have more space between each
PI field, so we just need to account for that when iterating instead of
assuming each element is the size of a T10 PI tuple.
Otherwise, great idea.
^ permalink raw reply
* ✗ patchtest: failure for iputils: upgrade to s20190629 (rev2)
From: Patchwork @ 2018-07-23 14:02 UTC (permalink / raw)
To: Ross Burton; +Cc: openembedded-core
In-Reply-To: <20180723134848.3698-1-ross.burton@intel.com>
== Series Details ==
Series: iputils: upgrade to s20190629 (rev2)
Revision: 2
URL : https://patchwork.openembedded.org/series/13153/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:
* Issue Upstream-Status is Inappropriate, but no reason was provided [test_upstream_status_presence_format]
Suggested fix Include a brief reason why install.patch is inappropriate
Current Upstream-Status: Inappropriate
Standard format Upstream-Status: Inappropriate [reason]
If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).
---
Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
^ 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.