* Re: [PATCH v3 09/12] ppc64/kexec_file: setup backup region for kdump kernel
From: Thiago Jung Bauermann @ 2020-07-16 22:06 UTC (permalink / raw)
To: Hari Bathini
Cc: kernel test robot, Pingfan Liu, Petr Tesarik, Nayna Jain,
Kexec-ml, Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev,
Sourabh Jain, Andrew Morton, Dave Young, Vivek Goyal,
Eric Biederman
In-Reply-To: <bea19627-c6b7-5d59-e194-03038bb4d9f6@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 16/07/20 7:08 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>>> @@ -968,7 +1040,7 @@ int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>>>
>>> /*
>>> * Restrict memory usage for kdump kernel by setting up
>>> - * usable memory ranges.
>>> + * usable memory ranges and memory reserve map.
>>> */
>>> if (image->type == KEXEC_TYPE_CRASH) {
>>> ret = get_usable_memory_ranges(&umem);
>>> @@ -980,6 +1052,24 @@ int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>>> pr_err("Error setting up usable-memory property for kdump kernel\n");
>>> goto out;
>>> }
>>> +
>>> + ret = fdt_add_mem_rsv(fdt, BACKUP_SRC_START + BACKUP_SRC_SIZE,
>>> + crashk_res.start - BACKUP_SRC_SIZE);
>>
>> I believe this answers my question from the other email about how the
>> crashkernel is prevented from stomping in the crashed kernel's memory,
>> right? I needed to think for a bit to understand what the above
>> reservation was protecting. I think it's worth adding a comment.
>
> Right. The reason to add it in the first place is, prom presses the panic button if
> it can't find low memory. Marking it reserved seems to keep it quiet though. so..
>
> Will add comment mentioning that..
Ah, makes sense. Thanks for the explanation.
>>> +void purgatory(void)
>>> +{
>>> + void *dest, *src;
>>> +
>>> + src = (void *)BACKUP_SRC_START;
>>> + if (backup_start) {
>>> + dest = (void *)backup_start;
>>> + __memcpy(dest, src, BACKUP_SRC_SIZE);
>>> + }
>>> +}
>>
>> In general I'm in favor of using C code over assembly, but having to
>> bring in that relocation support just for the above makes me wonder if
>> it's worth it in this case.
>
> I am planning to build on purgatory later with "I'm in purgatory" print support
> for pseries at least and also, sha256 digest check.
Ok. In that case, my preference would be to convert both the powerpc and
x86 purgatories to PIE since this greatly reduces the types of
relocations that are emitted, but better ask Dave Young what he thinks
before going down that route.
--
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH][next] PCI: imx6: Use fallthrough pseudo-keyword
From: Bjorn Helgaas @ 2020-07-16 22:06 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Richard Zhu, Lucas Stach, Lorenzo Pieralisi, Rob Herring,
Bjorn Helgaas, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, linux-pci, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200716211052.GA16893@embeddedor>
On Thu, Jul 16, 2020 at 04:10:52PM -0500, Gustavo A. R. Silva wrote:
> Replace the existing /* fall through */ comments and its variants with
> the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
> fall-through markings when it is the case.
>
> [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Hi Gustavo,
I'm certainly fine with these patches, and thanks for doing them!
And thanks for providing a link to the rationale. But the URL
contains "latest", so I think it may break if deprecated.rst or the
section is ever renamed.
I think I would prefer if we could reference the current text, e.g.,
via
https://www.kernel.org/doc/html/v5.7-rc7/process/deprecated.html#implicit-switch-case-fall-through
(The v5.7 doc would be better but doesn't seem to be generated yet; I
pinged the helpdesk about that.)
Or we could refer to b9918bdcac1f ("Documentation/process: Add
fallthrough pseudo-keyword"), although it's not nearly as pretty as
the HTML.
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 4e5c379ae418..1119ded593d0 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -439,7 +439,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
> break;
> - case IMX6QP: /* FALLTHROUGH */
> + case IMX6QP:
> case IMX6Q:
> /* power up core phy and enable ref clock */
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> @@ -642,7 +642,7 @@ static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> IMX6SX_GPR12_PCIE_RX_EQ_MASK,
> IMX6SX_GPR12_PCIE_RX_EQ_2);
> - /* FALLTHROUGH */
> + fallthrough;
> default:
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
> @@ -1107,7 +1107,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> dev_err(dev, "pcie_aux clock source missing or invalid\n");
> return PTR_ERR(imx6_pcie->pcie_aux);
> }
> - /* fall through */
> + fallthrough;
> case IMX7D:
> if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> imx6_pcie->controller_id = 1;
> --
> 2.27.0
>
^ permalink raw reply
* Re: [PATCH v3 09/12] ppc64/kexec_file: setup backup region for kdump kernel
From: Thiago Jung Bauermann @ 2020-07-16 22:06 UTC (permalink / raw)
To: Hari Bathini
Cc: kernel test robot, Pingfan Liu, Nayna Jain, Kexec-ml,
Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
Petr Tesarik, Andrew Morton, Dave Young, Vivek Goyal,
Eric Biederman
In-Reply-To: <bea19627-c6b7-5d59-e194-03038bb4d9f6@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 16/07/20 7:08 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>>> @@ -968,7 +1040,7 @@ int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>>>
>>> /*
>>> * Restrict memory usage for kdump kernel by setting up
>>> - * usable memory ranges.
>>> + * usable memory ranges and memory reserve map.
>>> */
>>> if (image->type == KEXEC_TYPE_CRASH) {
>>> ret = get_usable_memory_ranges(&umem);
>>> @@ -980,6 +1052,24 @@ int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>>> pr_err("Error setting up usable-memory property for kdump kernel\n");
>>> goto out;
>>> }
>>> +
>>> + ret = fdt_add_mem_rsv(fdt, BACKUP_SRC_START + BACKUP_SRC_SIZE,
>>> + crashk_res.start - BACKUP_SRC_SIZE);
>>
>> I believe this answers my question from the other email about how the
>> crashkernel is prevented from stomping in the crashed kernel's memory,
>> right? I needed to think for a bit to understand what the above
>> reservation was protecting. I think it's worth adding a comment.
>
> Right. The reason to add it in the first place is, prom presses the panic button if
> it can't find low memory. Marking it reserved seems to keep it quiet though. so..
>
> Will add comment mentioning that..
Ah, makes sense. Thanks for the explanation.
>>> +void purgatory(void)
>>> +{
>>> + void *dest, *src;
>>> +
>>> + src = (void *)BACKUP_SRC_START;
>>> + if (backup_start) {
>>> + dest = (void *)backup_start;
>>> + __memcpy(dest, src, BACKUP_SRC_SIZE);
>>> + }
>>> +}
>>
>> In general I'm in favor of using C code over assembly, but having to
>> bring in that relocation support just for the above makes me wonder if
>> it's worth it in this case.
>
> I am planning to build on purgatory later with "I'm in purgatory" print support
> for pseries at least and also, sha256 digest check.
Ok. In that case, my preference would be to convert both the powerpc and
x86 purgatories to PIE since this greatly reduces the types of
relocations that are emitted, but better ask Dave Young what he thinks
before going down that route.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v3 06/12] ppc64/kexec_file: restrict memory usage of kdump kernel
From: Thiago Jung Bauermann @ 2020-07-16 22:03 UTC (permalink / raw)
To: Hari Bathini
Cc: Pingfan Liu, Petr Tesarik, Nayna Jain, Kexec-ml,
Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <baa29ea9-7698-a7e8-e5a4-c9f842e1fcc8@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 16/07/20 4:22 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>
> <snip>
>
>>> +/**
>>> + * get_node_path - Get the full path of the given node.
>>> + * @dn: Node.
>>> + * @path: Updated with the full path of the node.
>>> + *
>>> + * Returns nothing.
>>> + */
>>> +static void get_node_path(struct device_node *dn, char *path)
>>> +{
>>> + if (!dn)
>>> + return;
>>> +
>>> + get_node_path(dn->parent, path);
>>
>> Is it ok to do recursion in the kernel? In this case I believe it's not
>> problematic since the maximum call depth will be the maximum depth of a
>> device tree node which shouldn't be too much. Also, there are no local
>> variables in this function. But I thought it was worth mentioning.
>
> You are right. We are better off avoiding the recursion here. Will
> change it to an iterative version instead.
Ok.
>>> + * each representing a memory range.
>>> + */
>>> + ranges = (len >> 2) / (n_mem_addr_cells + n_mem_size_cells);
>>> +
>>> + for (i = 0; i < ranges; i++) {
>>> + base = of_read_number(prop, n_mem_addr_cells);
>>> + prop += n_mem_addr_cells;
>>> + end = base + of_read_number(prop, n_mem_size_cells) - 1;
>
> prop is not used after the above.
>
>> You need to `prop += n_mem_size_cells` here.
>
> But yeah, adding it would make it look complete in some sense..
Isn't it used in the next iteration of the loop?
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* [qemu-mainline test] 151934: regressions - FAIL
From: osstest service owner @ 2020-07-16 22:08 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 151934 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151934/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065
test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065
test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065
test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065
test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065
test-armhf-armhf-xl-vhd 18 leak-check/check fail REGR. vs. 151065
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065
test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065
test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065
test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065
test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151065
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151065
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151065
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass
test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
version targeted for testing:
qemuu 8746309137ba470d1b2e8f5ce86ac228625db940
baseline version:
qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a
Last test of basis 151065 2020-06-12 22:27:51 Z 33 days
Failing since 151101 2020-06-14 08:32:51 Z 32 days 44 attempts
Testing same since 151934 2020-07-16 04:14:44 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Aaron Lindsay <aaron@os.amperecomputing.com>
Ahmed Karaman <ahmedkhaledkaraman@gmail.com>
Alberto Garcia <berto@igalia.com>
Aleksandar Markovic <aleksandar.m.mail@gmail.com>
Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
Alex Bennée <alex.bennee@linaro.org>
Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
Alex Williamson <alex.williamson@redhat.com>
Alexander Boettcher <alexander.boettcher@genode-labs.com>
Alexander Bulekov <alxndr@bu.edu>
Alexandre Mergnat <amergnat@baylibre.com>
Alexey Krasikov <alex-krasikov@yandex-team.ru>
Alistair Francis <alistair.francis@wdc.com>
Allan Peramaki <aperamak@pp1.inet.fi>
Andrew Jones <drjones@redhat.com>
Ani Sinha <ani.sinha@nutanix.com>
Anthony PERARD <anthony.perard@citrix.com>
Ard Biesheuvel <ardb@kernel.org>
Artyom Tarasenko <atar4qemu@gmail.com>
Atish Patra <atish.patra@wdc.com>
Aurelien Jarno <aurelien@aurel32.net>
Babu Moger <babu.moger@amd.com>
BALATON Zoltan <balaton@eik.bme.hu>
Basil Salman <basil@daynix.com>
Basil Salman <bsalman@redhat.com>
Beata Michalska <beata.michalska@linaro.org>
Bin Meng <bin.meng@windriver.com>
Bin Meng <bmeng.cn@gmail.com>
Cameron Esfahani <dirty@apple.com>
Catherine A. Frederick <chocola@animebitch.es>
Cathy Zhang <cathy.zhang@intel.com>
Chen Gang <chengang@emindsoft.com.cn>
Christian Borntraeger <borntraeger@de.ibm.com>
Christian Ehrhardt <christian.ehrhardt@canonical.com>
Christophe de Dinechin <dinechin@redhat.com>
Chuan Zheng <zhengchuan@huawei.com>
Cindy Lu <lulu@redhat.com>
Claudio Fontana <cfontana@suse.de>
Cleber Rosa <crosa@redhat.com>
Colin Xu <colin.xu@intel.com>
Cornelia Huck <cohuck@redhat.com>
Cédric Le Goater <clg@kaod.org>
Daniel P. Berrangé <berrange@redhat.com>
Daniele Buono <dbuono@linux.vnet.ibm.com>
David Carlier <devnexen@gmail.com>
David Edmondson <david.edmondson@oracle.com>
David Gibson <david@gibson.dropbear.id.au>
David Hildenbrand <david@redhat.com>
Denis V. Lunev <den@openvz.org>
Derek Su <dereksu@qnap.com>
Dr. David Alan Gilbert <dgilbert@redhat.com>
Ed Robbins <E.J.C.Robbins@kent.ac.uk>
Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Eduardo Habkost <ehabkost@redhat.com>
Emilio G. Cota <cota@braap.org>
Eric Auger <eric.auger@redhat.com>
Eric Blake <eblake@redhat.com>
Eric Farman <farman@linux.ibm.com>
Erik Smit <erik.lucas.smit@gmail.com>
Evgeny Yakovlev <eyakovlev@virtuozzo.com>
fangying <fangying1@huawei.com>
Farhan Ali <alifm@linux.ibm.com>
Filip Bozuta <Filip.Bozuta@syrmia.com>
Finn Thain <fthain@telegraphics.com.au>
Frank Chang <frank.chang@sifive.com>
Geoffrey McRae <geoff@hostfission.com>
Gerd Hoffmann <kraxel@redhat.com>
Giuseppe Musacchio <thatlemon@gmail.com>
Greg Kurz <groug@kaod.org>
Guenter Roeck <linux@roeck-us.net>
Gustavo Romero <gromero@linux.ibm.com>
Halil Pasic <pasic@linux.ibm.com>
Havard Skinnemoen <hskinnemoen@google.com>
Helge Deller <deller@gmx.de>
Howard Spoelstra <hsp.cat7@gmail.com>
Huacai Chen <chenhc@lemote.com>
Huacai Chen <zltjiangshi@gmail.com>
Ian Jiang <ianjiang.ict@gmail.com>
Igor Mammedov <imammedo@redhat.com>
Jan Kiszka <jan.kiszka@siemens.com>
Janne Grunau <j@jannau.net>
Janosch Frank <frankja@linux.ibm.com>
Jason Andryuk <jandryuk@gmail.com>
Jason Wang <jasowang@redhat.com>
Jay Zhou <jianjay.zhou@huawei.com>
Jean-Christophe Dubois <jcd@tribudubois.net>
Jessica Clarke <jrtc27@jrtc27.com>
Jiaxun Yang <jiaxun.yang@flygoat.com>
Jingqi Liu <jingqi.liu@intel.com>
John Snow <jsnow@redhat.com>
Jon Doron <arilou@gmail.com>
Joseph Myers <joseph@codesourcery.com>
Josh Kunz <jkz@google.com>
Juan Quintela <quintela@redhat.com>
Julio Faracco <jcfaracco@gmail.com>
Keqian Zhu <zhukeqian1@huawei.com>
Kevin Wolf <kwolf@redhat.com>
Klaus Jensen <k.jensen@samsung.com>
Klaus Jensen <klaus.jensen@cnexlabs.com>
Laszlo Ersek <lersek@redhat.com>
Laurent Vivier <laurent@vivier.eu>
Laurent Vivier <lvivier@redhat.com>
Leif Lindholm <leif@nuviainc.com>
Leonid Bloch <lb.workbox@gmail.com>
Leonid Bloch <lbloch@janustech.com>
Li Feng <fengli@smartx.com>
Li Qiang <liq3ea@gmail.com>
Liao Pingfang <liao.pingfang@zte.com.cn>
lichun <lichun@ruijie.com.cn>
Lijun Pan <ljp@linux.ibm.com>
Like Xu <like.xu@linux.intel.com>
Lingfeng Yang <lfy@google.com>
Lingshan zhu <lingshan.zhu@intel.com>
Liran Alon <liran.alon@oracle.com>
LIU Zhiwei <zhiwei_liu@c-sky.com>
Lukas Straub <lukasstraub2@web.de>
Luwei Kang <luwei.kang@intel.com>
Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Magnus Damm <magnus.damm@gmail.com>
Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
Marc-André Lureau <marcandre.lureau@redhat.com>
Marcelo Tosatti <mtosatti@redhat.com>
Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Mario Smarduch <msmarduch@digitalocean.com>
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Markus Armbruster <armbru@redhat.com>
Masahiro Yamada <masahiroy@kernel.org>
Matus Kysel <mkysel@tachyum.com>
Max Filippov <jcmvbkbc@gmail.com>
Max Reitz <mreitz@redhat.com>
Maxim Levitsky <mlevitsk@redhat.com>
Maxime Coquelin <maxime.coquelin@redhat.com>
Menno Lageman <menno.lageman@oracle.com>
Michael Rolnik <mrolnik@gmail.com>
Michael Roth <mdroth@linux.vnet.ibm.com>
Michael S. Tsirkin <mst@redhat.com>
Michal Privoznik <mprivozn@redhat.com>
Michele Denber <denber@mindspring.com>
Niek Linnenbank <nieklinnenbank@gmail.com>
Nir Soffer <nsoffer@redhat.com>
Olaf Hering <olaf@aepfle.de>
Pan Nengyuan <pannengyuan@huawei.com>
Paolo Bonzini <pbonzini@redhat.com>
Paul Durrant <pdurrant@amazon.com>
Pavel Dovgalyuk <Pavel.Dovgaluk@gmail.com>
Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
Peter Maydell <peter.maydell@linaro.org>
Peter Xu <peterx@redhat.com>
Philippe Mathieu-Daude <philmd@redhat.com>
Philippe Mathieu-Daudé <f4bug@amsat.org>
Philippe Mathieu-Daudé <philmd@redhat.com>
Prasad J Pandit <pjp@fedoraproject.org>
Radoslaw Biernacki <rad@semihalf.com>
Raphael Norwitz <raphael.norwitz@nutanix.com>
Richard Henderson <richard.henderson@linaro.org>
Richard W.M. Jones <rjones@redhat.com>
Riku Voipio <riku.voipio@linaro.org>
Robert Foley <robert.foley@linaro.org>
Roman Bolshakov <r.bolshakov@yadro.com>
Roman Kagan <rkagan@virtuozzo.com>
Roman Kagan <rvkagan@yandex-team.ru>
Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
Sarah Harris <S.E.Harris@kent.ac.uk>
Sebastian Rasmussen <sebras@gmail.com>
Sergio Lopez <slp@redhat.com>
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Stefan Berger <stefanb@linux.ibm.com>
Stefan Berger <stefanb@linux.vnet.ibm.com>
Stefan Hajnoczi <stefanha@redhat.com>
Tao Xu <tao3.xu@intel.com>
Thomas Huth <huth@tuxfamily.org>
Thomas Huth <thuth@redhat.com>
Tiwei Bie <tiwei.bie@intel.com>
Tong Ho <tong.ho@xilinx.com>
Vivek Goyal <vgoyal@redhat.com>
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Volker Rümelin <vr_qemu@t-online.de>
WangBowen <bowen.wang@intel.com>
Wei Huang <wei.huang2@amd.com>
Wei Wang <wei.w.wang@intel.com>
Wentong Wu <wentong.wu@intel.com>
Xie Yongji <xieyongji@bytedance.com>
Yi Wang <wang.yi59@zte.com.cn>
Ying Fang <fangying1@huawei.com>
Yoshinori Sato <ysato@users.sourceforge.jp>
Yuri Benditovich <yuri.benditovich@daynix.com>
Zhang Chen <chen.zhang@intel.com>
Zheng Chuan <zhengchuan@huawei.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-coresched-amd64-xl pass
test-arm64-arm64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-coresched-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail
test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
test-amd64-i386-freebsd10-amd64 fail
test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
test-amd64-i386-xl-qemuu-ovmf-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-arm64-arm64-xl-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-freebsd10-i386 fail
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel fail
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds fail
test-arm64-arm64-xl-seattle pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-arm64-arm64-xl-thunderx pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd fail
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 28624 lines long.)
^ permalink raw reply
* Re: [PATCH v3 09/12] ppc64/kexec_file: setup backup region for kdump kernel
From: Thiago Jung Bauermann @ 2020-07-16 22:06 UTC (permalink / raw)
To: Hari Bathini
Cc: kernel test robot, Pingfan Liu, Petr Tesarik, Nayna Jain,
Kexec-ml, Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev,
Sourabh Jain, Andrew Morton, Dave Young, Vivek Goyal,
Eric Biederman
In-Reply-To: <bea19627-c6b7-5d59-e194-03038bb4d9f6@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 16/07/20 7:08 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>>> @@ -968,7 +1040,7 @@ int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>>>
>>> /*
>>> * Restrict memory usage for kdump kernel by setting up
>>> - * usable memory ranges.
>>> + * usable memory ranges and memory reserve map.
>>> */
>>> if (image->type == KEXEC_TYPE_CRASH) {
>>> ret = get_usable_memory_ranges(&umem);
>>> @@ -980,6 +1052,24 @@ int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>>> pr_err("Error setting up usable-memory property for kdump kernel\n");
>>> goto out;
>>> }
>>> +
>>> + ret = fdt_add_mem_rsv(fdt, BACKUP_SRC_START + BACKUP_SRC_SIZE,
>>> + crashk_res.start - BACKUP_SRC_SIZE);
>>
>> I believe this answers my question from the other email about how the
>> crashkernel is prevented from stomping in the crashed kernel's memory,
>> right? I needed to think for a bit to understand what the above
>> reservation was protecting. I think it's worth adding a comment.
>
> Right. The reason to add it in the first place is, prom presses the panic button if
> it can't find low memory. Marking it reserved seems to keep it quiet though. so..
>
> Will add comment mentioning that..
Ah, makes sense. Thanks for the explanation.
>>> +void purgatory(void)
>>> +{
>>> + void *dest, *src;
>>> +
>>> + src = (void *)BACKUP_SRC_START;
>>> + if (backup_start) {
>>> + dest = (void *)backup_start;
>>> + __memcpy(dest, src, BACKUP_SRC_SIZE);
>>> + }
>>> +}
>>
>> In general I'm in favor of using C code over assembly, but having to
>> bring in that relocation support just for the above makes me wonder if
>> it's worth it in this case.
>
> I am planning to build on purgatory later with "I'm in purgatory" print support
> for pseries at least and also, sha256 digest check.
Ok. In that case, my preference would be to convert both the powerpc and
x86 purgatories to PIE since this greatly reduces the types of
relocations that are emitted, but better ask Dave Young what he thinks
before going down that route.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH][next] PCI: imx6: Use fallthrough pseudo-keyword
From: Bjorn Helgaas @ 2020-07-16 22:06 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Rob Herring, Lorenzo Pieralisi, Richard Zhu, Fabio Estevam,
Sascha Hauer, linux-kernel, NXP Linux Team,
Pengutronix Kernel Team, linux-pci, Bjorn Helgaas, Shawn Guo,
linux-arm-kernel, Lucas Stach
In-Reply-To: <20200716211052.GA16893@embeddedor>
On Thu, Jul 16, 2020 at 04:10:52PM -0500, Gustavo A. R. Silva wrote:
> Replace the existing /* fall through */ comments and its variants with
> the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
> fall-through markings when it is the case.
>
> [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Hi Gustavo,
I'm certainly fine with these patches, and thanks for doing them!
And thanks for providing a link to the rationale. But the URL
contains "latest", so I think it may break if deprecated.rst or the
section is ever renamed.
I think I would prefer if we could reference the current text, e.g.,
via
https://www.kernel.org/doc/html/v5.7-rc7/process/deprecated.html#implicit-switch-case-fall-through
(The v5.7 doc would be better but doesn't seem to be generated yet; I
pinged the helpdesk about that.)
Or we could refer to b9918bdcac1f ("Documentation/process: Add
fallthrough pseudo-keyword"), although it's not nearly as pretty as
the HTML.
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 4e5c379ae418..1119ded593d0 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -439,7 +439,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
> break;
> - case IMX6QP: /* FALLTHROUGH */
> + case IMX6QP:
> case IMX6Q:
> /* power up core phy and enable ref clock */
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> @@ -642,7 +642,7 @@ static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> IMX6SX_GPR12_PCIE_RX_EQ_MASK,
> IMX6SX_GPR12_PCIE_RX_EQ_2);
> - /* FALLTHROUGH */
> + fallthrough;
> default:
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
> @@ -1107,7 +1107,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> dev_err(dev, "pcie_aux clock source missing or invalid\n");
> return PTR_ERR(imx6_pcie->pcie_aux);
> }
> - /* fall through */
> + fallthrough;
> case IMX7D:
> if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> imx6_pcie->controller_id = 1;
> --
> 2.27.0
>
_______________________________________________
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/2] net: dsa: qca8k: Add additional PORT0_PAD_CTRL options
From: Jakub Kicinski @ 2020-07-16 22:09 UTC (permalink / raw)
To: Matthew Hagan
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller,
linux, netdev, linux-kernel, John Crispin, Jonathan McDowell
In-Reply-To: <2e1776f997441792a44cd35a16f1e69f848816ce.1594668793.git.mnhagan88@gmail.com>
On Mon, 13 Jul 2020 21:50:25 +0100 Matthew Hagan wrote:
> + u32 val = qca8k_read(priv, QCA8K_REG_PORT0_PAD_CTRL);
> + val |= QCA8K_PORT0_PAD_CTRL_MAC06_EXCHG;
> + val |= QCA8K_PORT0_PAD_SGMII_RXCLK_FALLING_EDGE;
> + val |= QCA8K_PORT0_PAD_SGMII_TXCLK_FALLING_EDGE;
> + qca8k_write(priv, QCA8K_REG_PORT0_PAD_CTRL, val);
> + val = qca8k_read(priv, reg);
> + val |= QCA8K_PORT_PAD_RGMII_EN;
> + qca8k_write(priv, reg, val);
> + val |= QCA8K_PORT_PAD_RGMII_EN |
> + QCA8K_PORT_PAD_RGMII_TX_DELAY(QCA8K_MAX_DELAY) |
> + QCA8K_PORT_PAD_RGMII_RX_DELAY(QCA8K_MAX_DELAY);
> + qca8k_write(priv, reg, val);
> + val |= QCA8K_PORT_PAD_SGMII_EN;
> + qca8k_write(priv, reg, val);
Since throughout the patch you're only setting bits perhaps
qca8k_reg_set() would be a better choice than manually reading
and then writing?
^ permalink raw reply
* Re: [PATCH net-next 1/3] ptp: add ability to configure duty cycle for periodic output
From: Vladimir Oltean @ 2020-07-16 22:09 UTC (permalink / raw)
To: Jacob Keller
Cc: kuba, davem, netdev, richardcochran, yangbo.lu, xiaoliang.yang_1,
po.liu, UNGLinuxDriver
In-Reply-To: <20200716214927.s4uu36twwegarznm@skbuf>
On Fri, Jul 17, 2020 at 12:49:27AM +0300, Vladimir Oltean wrote:
> On Thu, Jul 16, 2020 at 02:36:45PM -0700, Jacob Keller wrote:
> >
> >
> > On 7/16/2020 2:20 PM, Vladimir Oltean wrote:
> > > There are external event timestampers (PHCs with support for
> > > PTP_EXTTS_REQUEST) that timestamp both event edges.
> > >
> > > When those edges are very close (such as in the case of a short pulse),
> > > there is a chance that the collected timestamp might be of the rising,
> > > or of the falling edge, we never know.
> > >
> > > There are also PHCs capable of generating periodic output with a
> > > configurable duty cycle. This is good news, because we can space the
> > > rising and falling edge out enough in time, that the risks to overrun
> > > the 1-entry timestamp FIFO of the extts PHC are lower (example: the
> > > perout PHC can be configured for a period of 1 second, and an "on" time
> > > of 0.5 seconds, resulting in a duty cycle of 50%).
> > >
> > > A flag is introduced for signaling that an on time is present in the
> > > perout request structure, for preserving compatibility. Logically
> > > speaking, the duty cycle cannot exceed 100% and the PTP core checks for
> > > this.
> >
> > I was thinking whether it made sense to support over 50% since in theory
> > you could change start time and the duty cycle to specify the shifted
> > wave over? but I guess it doesn't really make much of a difference to
> > support all the way up to 100%.
> >
>
> Only if you also support polarity, and we don't support polarity. It's
> always high first, then low.
>
Sorry for the imprecise statement.
If you look at things from the perspective of the signal itself, the
statement is correct.
If you look at them from the perspective of the imaginary grid drawn by
the integer multiples of the period, in the PHC's time (a digital
counter), the correct statement would be that "it's always rising edge
first, then falling edge". And then the phase is just the delta between
these 2 points of reference.
Let me annotate this:
t_on
<------>
t_period
<--------->
phase
<->
> +------+ +------+ +------+ +------+ +------+ +------+ +------+
> | | | | | | | | | | | | | |
> --+ +--+ +--+ +--+ +--+ +--+ +--+ +
>
> +---------+---------+---------+---------+---------+---------+--------->
t=1000 t=1010 t=1020 t=1030 t=1040 t=1050 t=1060
> period=10 time
> phase=2
> on = 7
>
> There's no other way to obtain this signal which has a duty cycle > 50%
> by specifying a duty cycle < 50%.
>
Thanks,
-Vladimir
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: net: dsa: qca8k: Add PORT0_PAD_CTRL properties
From: Jakub Kicinski @ 2020-07-16 22:09 UTC (permalink / raw)
To: Matthew Hagan, Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, linux, netdev,
linux-kernel, John Crispin, Jonathan McDowell, Rob Herring,
devicetree
In-Reply-To: <ea0a35ed686e6dace77e25cb70a8f39fdd1ea8ad.1594668793.git.mnhagan88@gmail.com>
On Mon, 13 Jul 2020 21:50:26 +0100 Matthew Hagan wrote:
> Add names and decriptions of additional PORT0_PAD_CTRL properties.
>
> Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>
> ---
> Documentation/devicetree/bindings/net/dsa/qca8k.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
> index ccbc6d89325d..3d34c4f2e891 100644
> --- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
> @@ -13,6 +13,14 @@ Optional properties:
>
> - reset-gpios: GPIO to be used to reset the whole device
>
> +Optional MAC configuration properties:
> +
> +- qca,exchange-mac0-mac6: If present, internally swaps MAC0 and MAC6.
Perhaps we can say a little more here?
> +- qca,sgmii-rxclk-falling-edge: If present, sets receive clock phase to
> + falling edge.
> +- qca,sgmii-txclk-falling-edge: If present, sets transmit clock phase to
> + falling edge.
These are not something that other vendors may implement and therefore
something we may want to make generic? Andrew?
> Subnodes:
>
> The integrated switch subnode should be specified according to the binding
^ permalink raw reply
* Re: [PATCH v3 0/3] Remove special casing for PSEUDOREF updates
From: Junio C Hamano @ 2020-07-16 22:09 UTC (permalink / raw)
To: Han-Wen Nienhuys via GitGitGadget; +Cc: git, Han-Wen Nienhuys
In-Reply-To: <pull.673.v3.git.1594925141.gitgitgadget@gmail.com>
"Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com> writes:
> This gets rid of the special casing code for pseudorefs in refs.c
>
> This is in preparation for reftable.
>
> v3
>
> * tweak git-update-ref.txt description for logAllRefUpdates
>
> Han-Wen Nienhuys (3):
> t1400: use git rev-parse for testing PSEUDOREF existence
> Modify pseudo refs through ref backend storage
> Make HEAD a PSEUDOREF rather than PER_WORKTREE.
I reviewed some codepaths that deal with FETCH_HEAD recently.
As the file is quite different from all the other pseudo references
in that it needs to store more than one object name and in that each
ref in it needs more than just the object name, I doubt that it
makes much sense to enhance the refs API so that its requirements
can be covered.
It would probably make sense for FETCH_HEAD to stay "a text file
directly underneath $GIT_DIR", but get_oid() needs to be able to
read it and return the first object name recorded in the file.
^ permalink raw reply
* Compressing packed-refs
From: Konstantin Ryabitsev @ 2020-07-16 22:10 UTC (permalink / raw)
To: git
Hi, all:
I know repos with too many refs is a corner-case for most people, but
it's looming large in my world, so I'm wondering if it makes sense to
compress the packed-refs file when "git pack-refs" is performed?
What would the implications be, other than minor performance degradation
when reading it?
-K
^ permalink raw reply
* Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
From: Karol Herbst @ 2020-07-16 22:10 UTC (permalink / raw)
To: Linux PCI, Mika Westerberg
Cc: Ben Skeggs, Bjorn Helgaas, Lyude Paul, nouveau, dri-devel
In-Reply-To: <CACO55tsAEa5GXw5oeJPG=mcn+qxNvspXreJYWDJGZBy5v82JDA@mail.gmail.com>
On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst <kherbst@redhat.com> wrote:
>
> Hi everybody,
>
> with the mentioned commit Nouveau isn't able to load firmware onto the
> GPU on one of my systems here. Even though the issue doesn't always
> happen I am quite confident this is the commit breaking it.
>
> I am still digging into the issue and trying to figure out what
> exactly breaks, but it shows up in different ways. Either we are not
> able to boot the engines on the GPU or the GPU becomes unresponsive.
> Btw, this is also a system where our runtime power management issue
> shows up, so maybe there is indeed something funky with the bridge
> controller.
>
> Just pinging you in case you have an idea on how this could break Nouveau
>
> most of the times it shows up like this:
> nouveau 0000:01:00.0: acr: AHESASC binary failed
>
> Sometimes it works at boot and fails at runtime resuming with random
> faults. So I will be investigating a bit more, but yeah... I am super
> sure the commit triggered this issue, no idea if it actually causes
> it.
>
so yeah.. I reverted that locally and never ran into issues again.
Still valid on latest 5.7. So can we get this reverted or properly
fixed? This breaks runtime pm for us on at least some hardware.
> git bisect log (had to do a second bisect, that's why the first bad
> and good commits appear a bit random):
>
> git bisect start
> # bad: [a92b984a110863b42a3abf32e3f049b02b19e350] clk: samsung:
> exynos5433: Add IGNORE_UNUSED flag to sclk_i2s1
> git bisect bad a92b984a110863b42a3abf32e3f049b02b19e350
> # good: [4da858c086433cd012c0bb16b5921f6fafe3f803] Merge branch
> 'linux-5.7' of git://github.com/skeggsb/linux into drm-fixes
> git bisect good 4da858c086433cd012c0bb16b5921f6fafe3f803
> # good: [d5dfe4f1b44ed532653c2335267ad9599c8a698e] Merge tag
> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
> git bisect good d5dfe4f1b44ed532653c2335267ad9599c8a698e
> # good: [b24e451cfb8c33ef5b8b4a80e232706b089914fb] ipv6: fix
> IPV6_ADDRFORM operation logic
> git bisect good b24e451cfb8c33ef5b8b4a80e232706b089914fb
> # good: [d843ffbce812742986293f974d55ba404e91872f] nvmet: fix memory
> leak when removing namespaces and controllers concurrently
> git bisect good d843ffbce812742986293f974d55ba404e91872f
> # good: [be66f10a60e3ec0b589898f78a428bcb34095730] staging: wfx: fix
> output of rx_stats on big endian hosts
> git bisect good be66f10a60e3ec0b589898f78a428bcb34095730
> # good: [a4482984c41f5cc1d217aa189fe51bbbc0500f98] s390/qdio:
> consistently restore the IRQ handler
> git bisect good a4482984c41f5cc1d217aa189fe51bbbc0500f98
> # good: [bec32a54a4de62b46466f4da1beb9ddd42db81b8] f2fs: fix potential
> use-after-free issue
> git bisect good bec32a54a4de62b46466f4da1beb9ddd42db81b8
> # bad: [044aaaa8b1b15adb397ce423a6d97920a46b3893] habanalabs: increase
> timeout during reset
> git bisect bad 044aaaa8b1b15adb397ce423a6d97920a46b3893
> # good: [6fe8ed270763a6a2e350bf37eee0f3857482ed48] arm64: dts: qcom:
> db820c: Fix invalid pm8994 supplies
> git bisect good 6fe8ed270763a6a2e350bf37eee0f3857482ed48
> # good: [363e8bfc96b4e9d9e0a885408cecaf23df468523] tty: n_gsm: Fix
> waking up upper tty layer when room available
> git bisect good 363e8bfc96b4e9d9e0a885408cecaf23df468523
> # bad: [afaff825e3a436f9d1e3986530133b1c91b54cd1] PCI/PM: Assume ports
> without DLL Link Active train links in 100 ms
> git bisect bad afaff825e3a436f9d1e3986530133b1c91b54cd1
> # good: [be0ed15d88c65de0e28ff37a3b242e65a782fd98] HID: Add quirks for
> Trust Panora Graphic Tablet
> git bisect good be0ed15d88c65de0e28ff37a3b242e65a782fd98
> # first bad commit: [afaff825e3a436f9d1e3986530133b1c91b54cd1] PCI/PM:
> Assume ports without DLL Link Active train links in 100 ms
^ permalink raw reply
* Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
From: Karol Herbst @ 2020-07-16 22:10 UTC (permalink / raw)
To: Linux PCI, Mika Westerberg; +Cc: Bjorn Helgaas, nouveau, Ben Skeggs, dri-devel
In-Reply-To: <CACO55tsAEa5GXw5oeJPG=mcn+qxNvspXreJYWDJGZBy5v82JDA@mail.gmail.com>
On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst <kherbst@redhat.com> wrote:
>
> Hi everybody,
>
> with the mentioned commit Nouveau isn't able to load firmware onto the
> GPU on one of my systems here. Even though the issue doesn't always
> happen I am quite confident this is the commit breaking it.
>
> I am still digging into the issue and trying to figure out what
> exactly breaks, but it shows up in different ways. Either we are not
> able to boot the engines on the GPU or the GPU becomes unresponsive.
> Btw, this is also a system where our runtime power management issue
> shows up, so maybe there is indeed something funky with the bridge
> controller.
>
> Just pinging you in case you have an idea on how this could break Nouveau
>
> most of the times it shows up like this:
> nouveau 0000:01:00.0: acr: AHESASC binary failed
>
> Sometimes it works at boot and fails at runtime resuming with random
> faults. So I will be investigating a bit more, but yeah... I am super
> sure the commit triggered this issue, no idea if it actually causes
> it.
>
so yeah.. I reverted that locally and never ran into issues again.
Still valid on latest 5.7. So can we get this reverted or properly
fixed? This breaks runtime pm for us on at least some hardware.
> git bisect log (had to do a second bisect, that's why the first bad
> and good commits appear a bit random):
>
> git bisect start
> # bad: [a92b984a110863b42a3abf32e3f049b02b19e350] clk: samsung:
> exynos5433: Add IGNORE_UNUSED flag to sclk_i2s1
> git bisect bad a92b984a110863b42a3abf32e3f049b02b19e350
> # good: [4da858c086433cd012c0bb16b5921f6fafe3f803] Merge branch
> 'linux-5.7' of git://github.com/skeggsb/linux into drm-fixes
> git bisect good 4da858c086433cd012c0bb16b5921f6fafe3f803
> # good: [d5dfe4f1b44ed532653c2335267ad9599c8a698e] Merge tag
> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
> git bisect good d5dfe4f1b44ed532653c2335267ad9599c8a698e
> # good: [b24e451cfb8c33ef5b8b4a80e232706b089914fb] ipv6: fix
> IPV6_ADDRFORM operation logic
> git bisect good b24e451cfb8c33ef5b8b4a80e232706b089914fb
> # good: [d843ffbce812742986293f974d55ba404e91872f] nvmet: fix memory
> leak when removing namespaces and controllers concurrently
> git bisect good d843ffbce812742986293f974d55ba404e91872f
> # good: [be66f10a60e3ec0b589898f78a428bcb34095730] staging: wfx: fix
> output of rx_stats on big endian hosts
> git bisect good be66f10a60e3ec0b589898f78a428bcb34095730
> # good: [a4482984c41f5cc1d217aa189fe51bbbc0500f98] s390/qdio:
> consistently restore the IRQ handler
> git bisect good a4482984c41f5cc1d217aa189fe51bbbc0500f98
> # good: [bec32a54a4de62b46466f4da1beb9ddd42db81b8] f2fs: fix potential
> use-after-free issue
> git bisect good bec32a54a4de62b46466f4da1beb9ddd42db81b8
> # bad: [044aaaa8b1b15adb397ce423a6d97920a46b3893] habanalabs: increase
> timeout during reset
> git bisect bad 044aaaa8b1b15adb397ce423a6d97920a46b3893
> # good: [6fe8ed270763a6a2e350bf37eee0f3857482ed48] arm64: dts: qcom:
> db820c: Fix invalid pm8994 supplies
> git bisect good 6fe8ed270763a6a2e350bf37eee0f3857482ed48
> # good: [363e8bfc96b4e9d9e0a885408cecaf23df468523] tty: n_gsm: Fix
> waking up upper tty layer when room available
> git bisect good 363e8bfc96b4e9d9e0a885408cecaf23df468523
> # bad: [afaff825e3a436f9d1e3986530133b1c91b54cd1] PCI/PM: Assume ports
> without DLL Link Active train links in 100 ms
> git bisect bad afaff825e3a436f9d1e3986530133b1c91b54cd1
> # good: [be0ed15d88c65de0e28ff37a3b242e65a782fd98] HID: Add quirks for
> Trust Panora Graphic Tablet
> git bisect good be0ed15d88c65de0e28ff37a3b242e65a782fd98
> # first bad commit: [afaff825e3a436f9d1e3986530133b1c91b54cd1] PCI/PM:
> Assume ports without DLL Link Active train links in 100 ms
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [meta-yocto][dunfell] poky: Add fedora32 as a supported distro
From: Steve Sakoman @ 2020-07-16 22:11 UTC (permalink / raw)
To: poky
In-Reply-To: <cover.1594937430.git.steve@sakoman.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
meta-poky/conf/distro/poky.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index 7c4a285..7f0a157 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -59,6 +59,7 @@ SANITY_TESTED_DISTROS ?= " \
ubuntu-20.04 \n \
fedora-30 \n \
fedora-31 \n \
+ fedora-32 \n \
centos-7 \n \
centos-8 \n \
debian-8 \n \
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 07/12] ppc64/kexec_file: add support to relocate purgatory
From: Thiago Jung Bauermann @ 2020-07-16 22:12 UTC (permalink / raw)
To: Hari Bathini
Cc: kernel test robot, Pingfan Liu, Petr Tesarik, Nayna Jain,
Kexec-ml, Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev,
Sourabh Jain, Andrew Morton, Dave Young, Vivek Goyal,
Eric Biederman
In-Reply-To: <6f64a18a-352e-fdec-c902-45aefc31cc0a@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 16/07/20 5:50 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>>> So, add support to relocate purgatory in kexec_file_load system call
>>> by setting up TOC pointer and applying RELA relocations as needed.
>>
>> If we do want to use a C purgatory, Michael Ellerman had suggested
>> building it as a Position Independent Executable, which greatly reduces
>> the number and types of relocations that are needed. See patches 4 and 9
>> here:
>>
>> https://lore.kernel.org/linuxppc-dev/1478748449-3894-1-git-send-email-bauerman@linux.vnet.ibm.com/
>>
>> In the series above I hadn't converted x86 to PIE. If I had done that,
>> possibly Dave Young's opinion would have been different. :-)
>>
>> If that's still not desirable, he suggested in that discussion lifting
>> some code from x86 to generic code, which I implemented and would
>> simplify this patch as well:
>>
>> https://lore.kernel.org/linuxppc-dev/5009580.5GxAkTrMYA@morokweng/
>>
>
> Agreed. But I prefer to work on PIE and/or moving common relocation_add code
> for x86 & s390 to generic code later when I try to build on these purgatory
> changes. So, a separate series later to rework purgatory with the things you
> mentioned above sounds ok?
Sounds ok to me. Let's see what the maintainers think, then.
--
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH v3 07/12] ppc64/kexec_file: add support to relocate purgatory
From: Thiago Jung Bauermann @ 2020-07-16 22:12 UTC (permalink / raw)
To: Hari Bathini
Cc: kernel test robot, Pingfan Liu, Nayna Jain, Kexec-ml,
Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
Petr Tesarik, Andrew Morton, Dave Young, Vivek Goyal,
Eric Biederman
In-Reply-To: <6f64a18a-352e-fdec-c902-45aefc31cc0a@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 16/07/20 5:50 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>>> So, add support to relocate purgatory in kexec_file_load system call
>>> by setting up TOC pointer and applying RELA relocations as needed.
>>
>> If we do want to use a C purgatory, Michael Ellerman had suggested
>> building it as a Position Independent Executable, which greatly reduces
>> the number and types of relocations that are needed. See patches 4 and 9
>> here:
>>
>> https://lore.kernel.org/linuxppc-dev/1478748449-3894-1-git-send-email-bauerman@linux.vnet.ibm.com/
>>
>> In the series above I hadn't converted x86 to PIE. If I had done that,
>> possibly Dave Young's opinion would have been different. :-)
>>
>> If that's still not desirable, he suggested in that discussion lifting
>> some code from x86 to generic code, which I implemented and would
>> simplify this patch as well:
>>
>> https://lore.kernel.org/linuxppc-dev/5009580.5GxAkTrMYA@morokweng/
>>
>
> Agreed. But I prefer to work on PIE and/or moving common relocation_add code
> for x86 & s390 to generic code later when I try to build on these purgatory
> changes. So, a separate series later to rework purgatory with the things you
> mentioned above sounds ok?
Sounds ok to me. Let's see what the maintainers think, then.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v2] driver core: Fix sleeping in invalid context during device link deletion
From: Marek Szyprowski @ 2020-07-16 22:13 UTC (permalink / raw)
To: Saravana Kannan, Greg Kroah-Hartman, Rafael J. Wysocki
Cc: Guenter Roeck, kernel-team, linux-kernel
In-Reply-To: <20200716214523.2924704-1-saravanak@google.com>
Hi Saravana,
On 16.07.2020 23:45, Saravana Kannan wrote:
> Marek and Guenter reported that commit 287905e68dd2 ("driver core:
> Expose device link details in sysfs") caused sleeping/scheduling while
> atomic warnings.
>
> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:935
> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 12, name: kworker/0:1
> 2 locks held by kworker/0:1/12:
> #0: ee8074a8 ((wq_completion)rcu_gp){+.+.}-{0:0}, at: process_one_work+0x174/0x7dc
> #1: ee921f20 ((work_completion)(&sdp->work)){+.+.}-{0:0}, at: process_one_work+0x174/0x7dc
> Preemption disabled at:
> [<c01b10f0>] srcu_invoke_callbacks+0xc0/0x154
> ----- 8< ----- SNIP
> [<c064590c>] (device_del) from [<c0645c9c>] (device_unregister+0x24/0x64)
> [<c0645c9c>] (device_unregister) from [<c01b10fc>] (srcu_invoke_callbacks+0xcc/0x154)
> [<c01b10fc>] (srcu_invoke_callbacks) from [<c01493c4>] (process_one_work+0x234/0x7dc)
> [<c01493c4>] (process_one_work) from [<c01499b0>] (worker_thread+0x44/0x51c)
> [<c01499b0>] (worker_thread) from [<c0150bf4>] (kthread+0x158/0x1a0)
> [<c0150bf4>] (kthread) from [<c0100114>] (ret_from_fork+0x14/0x20)
> Exception stack(0xee921fb0 to 0xee921ff8)
>
> This was caused by the device link device being released in the context
> of srcu_invoke_callbacks(). There is no need to wait till the RCU
> callback to release the device link device. So release the device
> earlier and move the call_srcu() into the device release code. That way,
> the memory will get freed only after the device is released AND the RCU
> callback is called.
>
> Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs")
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---
>
> v1->v2:
> - Better fix
> - Changed subject
> - v1 is this patch https://lore.kernel.org/lkml/20200716050846.2047110-1-saravanak@google.com/
>
> Marek and Guenter,
>
> I reproduced the original issue and tested this fix. Seems to work for
> me. Can you confirm?
Confirmed, this one fixes the issue! :)
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Thanks,
> Saravana
>
> drivers/base/core.c | 45 +++++++++++++++++++++++++++------------------
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 5373ddd029f6..ec16b97d45ed 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -306,10 +306,34 @@ static struct attribute *devlink_attrs[] = {
> };
> ATTRIBUTE_GROUPS(devlink);
>
> +static void device_link_free(struct device_link *link)
> +{
> + while (refcount_dec_not_one(&link->rpm_active))
> + pm_runtime_put(link->supplier);
> +
> + put_device(link->consumer);
> + put_device(link->supplier);
> + kfree(link);
> +}
> +
> +#ifdef CONFIG_SRCU
> +static void __device_link_free_srcu(struct rcu_head *rhead)
> +{
> + device_link_free(container_of(rhead, struct device_link, rcu_head));
> +}
> +
> static void devlink_dev_release(struct device *dev)
> {
> - kfree(to_devlink(dev));
> + struct device_link *link = to_devlink(dev);
> +
> + call_srcu(&device_links_srcu, &link->rcu_head, __device_link_free_srcu);
> }
> +#else
> +static void devlink_dev_release(struct device *dev)
> +{
> + device_link_free(to_devlink(dev));
> +}
> +#endif
>
> static struct class devlink_class = {
> .name = "devlink",
> @@ -730,22 +754,7 @@ static void device_link_add_missing_supplier_links(void)
> mutex_unlock(&wfs_lock);
> }
>
> -static void device_link_free(struct device_link *link)
> -{
> - while (refcount_dec_not_one(&link->rpm_active))
> - pm_runtime_put(link->supplier);
> -
> - put_device(link->consumer);
> - put_device(link->supplier);
> - device_unregister(&link->link_dev);
> -}
> -
> #ifdef CONFIG_SRCU
> -static void __device_link_free_srcu(struct rcu_head *rhead)
> -{
> - device_link_free(container_of(rhead, struct device_link, rcu_head));
> -}
> -
> static void __device_link_del(struct kref *kref)
> {
> struct device_link *link = container_of(kref, struct device_link, kref);
> @@ -758,7 +767,7 @@ static void __device_link_del(struct kref *kref)
>
> list_del_rcu(&link->s_node);
> list_del_rcu(&link->c_node);
> - call_srcu(&device_links_srcu, &link->rcu_head, __device_link_free_srcu);
> + device_unregister(&link->link_dev);
> }
> #else /* !CONFIG_SRCU */
> static void __device_link_del(struct kref *kref)
> @@ -773,7 +782,7 @@ static void __device_link_del(struct kref *kref)
>
> list_del(&link->s_node);
> list_del(&link->c_node);
> - device_link_free(link);
> + device_unregister(&link->link_dev);
> }
> #endif /* !CONFIG_SRCU */
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,01/11] HAX to make DSC work on the icelake test system (rev2)
From: Patchwork @ 2020-07-16 22:14 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
In-Reply-To: <20200715224222.7557-1-manasi.d.navare@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 8028 bytes --]
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake test system (rev2)
URL : https://patchwork.freedesktop.org/series/79534/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8758 -> Patchwork_18196
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/index.html
Known issues
------------
Here are the changes found in Patchwork_18196 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) +1 similar issue
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-tgl-u2/igt@gem_exec_suspend@basic-s3.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-tgl-u2/igt@gem_exec_suspend@basic-s3.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-tgl-y/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-tgl-y/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1.html
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
#### Possible fixes ####
* igt@i915_module_load@reload:
- fi-tgl-u2: [DMESG-WARN][9] ([i915#402]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-tgl-u2/igt@i915_module_load@reload.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-tgl-u2/igt@i915_module_load@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-tgl-y/igt@i915_pm_rpm@basic-pci-d3-state.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-tgl-y/igt@i915_pm_rpm@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6700k2: [INCOMPLETE][13] ([i915#151]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-skl-6700k2/igt@i915_pm_rpm@module-reload.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-skl-6700k2/igt@i915_pm_rpm@module-reload.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [DMESG-FAIL][15] ([i915#1233]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1 similar issue
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-tgl-y/igt@vgem_basic@setversion.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-tgl-y/igt@vgem_basic@setversion.html
* igt@vgem_basic@unload:
- fi-blb-e6850: [INCOMPLETE][21] -> [PASS][22]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-blb-e6850/igt@vgem_basic@unload.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-blb-e6850/igt@vgem_basic@unload.html
#### Warnings ####
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][23] ([fdo#109271]) -> [DMESG-FAIL][24] ([i915#62])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92]) -> [DMESG-WARN][26] ([i915#62] / [i915#92] / [i915#95]) +6 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-kbl-x1275/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-kbl-x1275/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
* igt@kms_flip@basic-flip-vs-dpms@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][27] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][28] ([i915#62] / [i915#92])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8758/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-dpms@a-dp1.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-dpms@a-dp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
[i915#1887]: https://gitlab.freedesktop.org/drm/intel/issues/1887
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#456]: https://gitlab.freedesktop.org/drm/intel/issues/456
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (45 -> 40)
------------------------------
Missing (5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper
Build changes
-------------
* Linux: CI_DRM_8758 -> Patchwork_18196
CI-20190529: 20190529
CI_DRM_8758: b6738761bde03de00a1c84c6a85f9379f53f585c @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5738: bc8b56fe177af34fbde7b96f1f66614a0014c6ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18196: f4de44a552c14b647651ed909c64dfdde6eaa525 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f4de44a552c1 drm/i915: Add debugfs dumping for bigjoiner, v3.
ce260481299f drm/i915: Add intel_update_bigjoiner handling.
81c299846f0d drm/i915: Add bigjoiner aware plane clipping checks
4f5779f44812 drm/i915: Link planes in a bigjoiner configuration, v3.
01023aaf7c78 drm/i915: Make hardware readout work on i915.
52facad4f0f8 drm/i915: Enable big joiner support in enable and disable sequences.
07b3d174ba99 drm/i915: Try to make bigjoiner work in atomic check
e1afb809eac2 drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
fb6b540c3882 drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split
42b7ec254efd drm/i915: Remove hw.mode
6756ad0df458 HAX to make DSC work on the icelake test system
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18196/index.html
[-- Attachment #1.2: Type: text/html, Size: 9765 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v3 07/12] ppc64/kexec_file: add support to relocate purgatory
From: Thiago Jung Bauermann @ 2020-07-16 22:12 UTC (permalink / raw)
To: Hari Bathini
Cc: kernel test robot, Pingfan Liu, Petr Tesarik, Nayna Jain,
Kexec-ml, Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev,
Sourabh Jain, Andrew Morton, Dave Young, Vivek Goyal,
Eric Biederman
In-Reply-To: <6f64a18a-352e-fdec-c902-45aefc31cc0a@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 16/07/20 5:50 am, Thiago Jung Bauermann wrote:
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>>> So, add support to relocate purgatory in kexec_file_load system call
>>> by setting up TOC pointer and applying RELA relocations as needed.
>>
>> If we do want to use a C purgatory, Michael Ellerman had suggested
>> building it as a Position Independent Executable, which greatly reduces
>> the number and types of relocations that are needed. See patches 4 and 9
>> here:
>>
>> https://lore.kernel.org/linuxppc-dev/1478748449-3894-1-git-send-email-bauerman@linux.vnet.ibm.com/
>>
>> In the series above I hadn't converted x86 to PIE. If I had done that,
>> possibly Dave Young's opinion would have been different. :-)
>>
>> If that's still not desirable, he suggested in that discussion lifting
>> some code from x86 to generic code, which I implemented and would
>> simplify this patch as well:
>>
>> https://lore.kernel.org/linuxppc-dev/5009580.5GxAkTrMYA@morokweng/
>>
>
> Agreed. But I prefer to work on PIE and/or moving common relocation_add code
> for x86 & s390 to generic code later when I try to build on these purgatory
> changes. So, a separate series later to rework purgatory with the things you
> mentioned above sounds ok?
Sounds ok to me. Let's see what the maintainers think, then.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* [PATCH][next] i2c: aspeed: Use fallthrough pseudo-keyword
From: Brendan Higgins @ 2020-07-16 22:16 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20200716215242.GA19193@embeddedor>
On Thu, Jul 16, 2020 at 2:47 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Replace the existing /* fall through */ comments and its variants with
> the new pseudo-keyword macro fallthrough[1].
>
> [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
^ permalink raw reply
* Re: [PATCH RFC leds + net-next 3/3] net: phy: marvell: add support for PHY LEDs via LED class
From: kernel test robot @ 2020-07-16 22:16 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20200716171730.13227-4-marek.behun@nic.cz>
[-- Attachment #1: Type: text/plain, Size: 3129 bytes --]
Hi "Marek,
[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Marek-Beh-n/Add-support-for-LEDs-on-Marvell-PHYs/20200717-012010
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 59632b220f2d61df274ed3a14a204e941051fdad
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=alpha
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
drivers/net/phy/marvell.c: In function 'marvell_led_set_regval':
>> drivers/net/phy/marvell.c:775:6: warning: variable 'reg' set but not used [-Wunused-but-set-variable]
775 | int reg;
| ^~~
drivers/net/phy/marvell.c: In function '_marvell_led_brightness_set':
>> drivers/net/phy/marvell.c:806:6: warning: variable 'led' set but not used [-Wunused-but-set-variable]
806 | int led;
| ^~~
vim +/reg +775 drivers/net/phy/marvell.c
771
772 static int marvell_led_set_regval(struct phy_device *phydev, int led, u16 val)
773 {
774 u16 mask;
> 775 int reg;
776
777 switch (led) {
778 case 0 ... 3:
779 reg = MII_PHY_LED_CTRL;
780 break;
781 case 4 ... 5:
782 reg = MII_PHY_LED45_CTRL;
783 break;
784 default:
785 return -EINVAL;
786 }
787
788 val <<= (led % 4) * 4;
789 mask = 0xf << ((led % 4) * 4);
790
791 return phy_modify_paged(phydev, MII_MARVELL_LED_PAGE, MII_PHY_LED_CTRL, mask, val);
792 }
793
794 static inline int marvell_led_index(struct led_classdev *cdev)
795 {
796 struct marvell_priv *priv = to_phy_device(cdev->dev->parent)->priv;
797
798 return cdev - &priv->leds[0];
799 }
800
801 static int _marvell_led_brightness_set(struct led_classdev *cdev, enum led_brightness brightness,
802 bool check_trigger)
803 {
804 struct phy_device *phydev = to_phy_device(cdev->dev->parent);
805 struct marvell_priv *priv = phydev->priv;
> 806 int led;
807 u8 val;
808
809 /* don't do anything if one of HW triggers is set */
810 if (check_trigger && &marvell_led_triggers[0] <= cdev->trigger &&
811 cdev->trigger < &marvell_led_triggers[ARRAY_SIZE(marvell_led_triggers)])
812 return 0;
813
814 led = cdev - &priv->leds[0];
815 val = brightness ? MII_PHY_LED_CTRL_FORCE_ON : MII_PHY_LED_CTRL_FORCE_OFF;
816
817 return marvell_led_set_regval(phydev, marvell_led_index(cdev), val);
818 }
819
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 65066 bytes --]
^ permalink raw reply
* Re: [PATCH][next] i2c: aspeed: Use fallthrough pseudo-keyword
From: Brendan Higgins @ 2020-07-16 22:16 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: linux-aspeed, Gustavo A. R. Silva, Andrew Jeffery,
Benjamin Herrenschmidt, OpenBMC Maillist,
Linux Kernel Mailing List, Joel Stanley, Linux ARM, linux-i2c
In-Reply-To: <20200716215242.GA19193@embeddedor>
On Thu, Jul 16, 2020 at 2:47 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Replace the existing /* fall through */ comments and its variants with
> the new pseudo-keyword macro fallthrough[1].
>
> [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
_______________________________________________
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 12/35] libmultipath: strlcpy()/strlcat(): use restrict qualifier
From: Benjamin Marzinski @ 2020-07-16 22:18 UTC (permalink / raw)
To: mwilck; +Cc: dm-devel
In-Reply-To: <20200709101620.6786-13-mwilck@suse.com>
On Thu, Jul 09, 2020 at 12:15:57PM +0200, mwilck@suse.com wrote:
> From: Martin Wilck <mwilck@suse.com>
>
> Also remove the redundant local variables. It's not necessary to
> make "restrict" work, but it makes the intention more clear.
>
> Signed-off-by: Martin Wilck <mwilck@suse.com>
> ---
> libmultipath/util.c | 28 ++++++++++++----------------
> libmultipath/util.h | 4 ++--
> 2 files changed, 14 insertions(+), 18 deletions(-)
>
> diff --git a/libmultipath/util.c b/libmultipath/util.c
> index 957fb97..f965094 100644
> --- a/libmultipath/util.c
> +++ b/libmultipath/util.c
> @@ -113,46 +113,42 @@ get_word (const char *sentence, char **word)
> return skip + len;
> }
>
> -size_t strlcpy(char *dst, const char *src, size_t size)
> +size_t strlcpy(char * restrict dst, const char * restrict src, size_t size)
> {
> size_t bytes = 0;
> - char *q = dst;
> - const char *p = src;
> char ch;
>
> - while ((ch = *p++)) {
> - if (bytes+1 < size)
> - *q++ = ch;
> + while ((ch = *src++)) {
> + if (bytes + 1 < size)
> + *dst++ = ch;
> bytes++;
> }
>
> /* If size == 0 there is no space for a final null... */
> if (size)
> - *q = '\0';
> + *dst = '\0';
> return bytes;
> }
>
> -size_t strlcat(char *dst, const char *src, size_t size)
> +size_t strlcat(char * restrict dst, const char * restrict src, size_t size)
> {
> size_t bytes = 0;
> - char *q = dst;
> - const char *p = src;
> char ch;
>
> - while (bytes < size && *q) {
> - q++;
> + while (bytes < size && *dst) {
> + dst++;
> bytes++;
> }
> if (bytes == size)
this should return the strlen(dst) + strlen(src). It wouldn't in the
admittedly weird case where size isn't large enough to fit dst.
> return (bytes + strlen(src));
>
> - while ((ch = *p++)) {
> - if (bytes+1 < size)
> - *q++ = ch;
> + while ((ch = *src++)) {
> + if (bytes + 1 < size)
> + *dst++ = ch;
> bytes++;
> }
>
> - *q = '\0';
> + *dst = '\0';
> return bytes;
> }
>
> diff --git a/libmultipath/util.h b/libmultipath/util.h
> index ae18d8b..7e29b26 100644
> --- a/libmultipath/util.h
> +++ b/libmultipath/util.h
> @@ -15,8 +15,8 @@ int basenamecpy (const char *src, char *dst, size_t size);
> int filepresent (const char *run);
> char *get_next_string(char **temp, const char *split_char);
> int get_word (const char * sentence, char ** word);
> -size_t strlcpy(char *dst, const char *src, size_t size);
> -size_t strlcat(char *dst, const char *src, size_t size);
> +size_t strlcpy(char * restrict dst, const char * restrict src, size_t size);
> +size_t strlcat(char * restrict dst, const char * restrict src, size_t size);
> int devt2devname (char *, int, const char *);
> dev_t parse_devt(const char *dev_t);
> char *convert_dev(char *dev, int is_path_device);
> --
> 2.26.2
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Remaining RKL patches (rev7)
From: Patchwork @ 2020-07-16 22:19 UTC (permalink / raw)
To: Matt Roper; +Cc: intel-gfx
In-Reply-To: <20200716220551.2730644-1-matthew.d.roper@intel.com>
== Series Details ==
Series: Remaining RKL patches (rev7)
URL : https://patchwork.freedesktop.org/series/77971/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ 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.