* Re: mesh-cfgclient Node is not attached
From: Gix, Brian @ 2020-02-20 19:00 UTC (permalink / raw)
To: nazeer.m@phytec.in, linux-bluetooth@vger.kernel.org
In-Reply-To: <OF2849A126.CB6B1F2C-ONC1258514.0028F058-C1258514.0028F05A@phytec.de>
Hi Mr Nazeer,
On Thu, 2020-02-20 at 08:27 +0100, Mahaboob Nazeer SK wrote:
> Hi,
>
> I was trying to provision a node using a mesh-cfgclient.
>
> I have successfully ran create and i was able to get configuration
> files in the .config.
>
> [mesh-cfgclient]# create
> Mesh network configuration exists (/home/nazeer/.config/meshcfg/config_db.json)
>
> After that i have tried to discover the unprovisioned node but i get
> Node is not attached message.
>
> [mesh-cfgclient]# discover-unprovisioned on
> Node is not attached
> [mesh-cfgclient]#
The problem you describe is probably due to the daemon not finding an appropriate BT controller to attach to.
This led to the "Attach" failing after the "Create", and then none of the commands to the node are able to be
sent.
There are a couple of options here:
1. If you have a single BT Controller (v4 or newer) you will need to disable the main bluetooth daemon so that
the bluetooth-meshd daemon has access to it:
$ sudo systemctl disable bluetooth
$ sudo systemctl stop bluetooth
2. If you have *multiple* BT controllers, make sure the bluetooth daemon hasn't automatically claimed them all:
In /etc/bluetooth/main.conf, make sure AutoEnable=false (reboot may then be required)
In the future, we will be doing work to enable co-existance and controller sharing for single controller
systems. However, this will require some changes in the kernel.
>
> Could you please let me know if weather there are some
> more steps involved to discover and provision a node or if am missing somethings.
>
> Thank you.
Regards,
--Brian Gix
^ permalink raw reply
* Re: [PATCH v3 2/8] remoteproc: qcom: Introduce driver to store pil info in IMEM
From: Mathieu Poirier @ 2020-02-20 19:01 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Ohad Ben-Cohen, Andy Gross, Rob Herring, Mark Rutland,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Sibi Sankar, Rishabh Bhatnagar
In-Reply-To: <20200211005059.1377279-3-bjorn.andersson@linaro.org>
On Mon, Feb 10, 2020 at 04:50:53PM -0800, Bjorn Andersson wrote:
> A region in IMEM is used to communicate load addresses of remoteproc to
> post mortem debug tools. Implement a driver that can be used to store
> this information in order to enable these tools to process collected
> ramdumps.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v2:
> - Sorted includes
> - Replace use of stracpy (still not landed upstream)
> - Fixed error handling in probe
> - Return error from store, to allow clients to decide action
> - Replace hard coded size with value read from reg property
>
> drivers/remoteproc/Kconfig | 3 +
> drivers/remoteproc/Makefile | 1 +
> drivers/remoteproc/qcom_pil_info.c | 168 +++++++++++++++++++++++++++++
> drivers/remoteproc/qcom_pil_info.h | 8 ++
> 4 files changed, 180 insertions(+)
> create mode 100644 drivers/remoteproc/qcom_pil_info.c
> create mode 100644 drivers/remoteproc/qcom_pil_info.h
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index de3862c15fcc..20c8194e610e 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -95,6 +95,9 @@ config KEYSTONE_REMOTEPROC
> It's safe to say N here if you're not interested in the Keystone
> DSPs or just want to use a bare minimum kernel.
>
> +config QCOM_PIL_INFO
> + tristate
> +
> config QCOM_RPROC_COMMON
> tristate
>
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index e30a1b15fbac..2ab32bd41b44 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
> obj-$(CONFIG_WKUP_M3_RPROC) += wkup_m3_rproc.o
> obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
> obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
> +obj-$(CONFIG_QCOM_PIL_INFO) += qcom_pil_info.o
> obj-$(CONFIG_QCOM_RPROC_COMMON) += qcom_common.o
> obj-$(CONFIG_QCOM_Q6V5_COMMON) += qcom_q6v5.o
> obj-$(CONFIG_QCOM_Q6V5_ADSP) += qcom_q6v5_adsp.o
> diff --git a/drivers/remoteproc/qcom_pil_info.c b/drivers/remoteproc/qcom_pil_info.c
> new file mode 100644
> index 000000000000..398aeb957f3c
> --- /dev/null
> +++ b/drivers/remoteproc/qcom_pil_info.c
> @@ -0,0 +1,168 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2019-2020 Linaro Ltd.
> + */
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +#define PIL_RELOC_NAME_LEN 8
> +
> +struct pil_reloc_entry {
> + char name[PIL_RELOC_NAME_LEN];
> + __le64 base;
> + __le32 size;
> +} __packed;
> +
> +struct pil_reloc {
> + struct device *dev;
> + struct regmap *map;
> + size_t offset;
> + size_t num_entries;
> + int val_bytes;
> +
> + struct pil_reloc_entry entries[];
> +};
> +
> +static struct pil_reloc *_reloc;
> +static DEFINE_MUTEX(reloc_mutex);
> +
> +/**
> + * qcom_pil_info_store() - store PIL information of image in IMEM
> + * @image: name of the image
> + * @base: base address of the loaded image
> + * @size: size of the loaded image
> + *
> + * Return: 0 on success, negative errno on failure
> + */
> +int qcom_pil_info_store(const char *image, phys_addr_t base, size_t size)
> +{
> + struct pil_reloc_entry *entry;
> + int idx = -1;
> + int ret;
> + int i;
> +
> + mutex_lock(&reloc_mutex);
> + for (i = 0; i < _reloc->num_entries; i++) {
> + if (!_reloc->entries[i].name[0]) {
> + if (idx == -1)
> + idx = i;
> + continue;
> + }
> +
> + if (!strncmp(_reloc->entries[i].name, image, 8)) {
s/8/PIL_RELOC_NAME_LEN
> + idx = i;
> + goto found;
> + }
> + }
> +
> + if (idx == -1) {
> + dev_warn(_reloc->dev, "insufficient PIL info slots\n");
> + ret = -ENOMEM;
> + goto unlock;
> + }
> +
> +found:
> + entry = &_reloc->entries[idx];
> + strscpy(entry->name, image, ARRAY_SIZE(entry->name));
> + entry->base = base;
> + entry->size = size;
> +
> + ret = regmap_bulk_write(_reloc->map,
> + _reloc->offset + idx * sizeof(*entry),
> + entry, sizeof(*entry) / _reloc->val_bytes);
> +unlock:
> + mutex_unlock(&reloc_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(qcom_pil_info_store);
> +
> +/**
> + * qcom_pil_info_available() - query if the pil info is probed
> + *
> + * Return: boolean indicating if the pil info device is probed
> + */
> +bool qcom_pil_info_available(void)
> +{
> + return !!_reloc;
> +}
> +EXPORT_SYMBOL_GPL(qcom_pil_info_available);
> +
> +static int pil_reloc_probe(struct platform_device *pdev)
> +{
> + unsigned int num_entries;
> + struct pil_reloc *reloc;
> + struct resource *res;
> + int ret;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -EINVAL;
> +
> + num_entries = resource_size(res) / sizeof(struct pil_reloc_entry);
> +
> + reloc = devm_kzalloc(&pdev->dev,
> + struct_size(reloc, entries, num_entries),
> + GFP_KERNEL);
> + if (!reloc)
> + return -ENOMEM;
> +
> + reloc->dev = &pdev->dev;
> + reloc->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
> + if (IS_ERR(reloc->map))
> + return PTR_ERR(reloc->map);
> +
> + reloc->offset = res->start;
> + reloc->num_entries = num_entries;
> +
> + reloc->val_bytes = regmap_get_val_bytes(reloc->map);
> + if (reloc->val_bytes < 0)
> + return -EINVAL;
> +
> + ret = regmap_bulk_write(reloc->map, reloc->offset, reloc->entries,
> + reloc->num_entries *
> + sizeof(struct pil_reloc_entry) /
> + reloc->val_bytes);
> + if (ret < 0)
> + return ret;
> +
> + mutex_lock(&reloc_mutex);
> + _reloc = reloc;
> + mutex_unlock(&reloc_mutex);
> +
> + return 0;
> +}
> +
> +static int pil_reloc_remove(struct platform_device *pdev)
> +{
> + mutex_lock(&reloc_mutex);
> + _reloc = NULL;
> + mutex_unlock(&reloc_mutex);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id pil_reloc_of_match[] = {
> + { .compatible = "qcom,pil-reloc-info" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, pil_reloc_of_match);
> +
> +static struct platform_driver pil_reloc_driver = {
> + .probe = pil_reloc_probe,
> + .remove = pil_reloc_remove,
> + .driver = {
> + .name = "qcom-pil-reloc-info",
> + .of_match_table = pil_reloc_of_match,
> + },
> +};
> +module_platform_driver(pil_reloc_driver);
> +
> +MODULE_DESCRIPTION("Qualcomm PIL relocation info");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/remoteproc/qcom_pil_info.h b/drivers/remoteproc/qcom_pil_info.h
> new file mode 100644
> index 000000000000..93aaaca8aed2
> --- /dev/null
> +++ b/drivers/remoteproc/qcom_pil_info.h
> @@ -0,0 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __QCOM_PIL_INFO_H__
> +#define __QCOM_PIL_INFO_H__
> +
> +int qcom_pil_info_store(const char *image, phys_addr_t base, size_t size);
> +bool qcom_pil_info_available(void);
> +
> +#endif
> --
> 2.24.0
>
^ permalink raw reply
* Re: [PATCH v1 1/4] Acceptance test: add address as param
From: Wainer dos Santos Moschetta @ 2020-02-20 18:54 UTC (permalink / raw)
To: Oksana Vohchana, qemu-devel; +Cc: philmd, crosa
In-Reply-To: <20200214145235.4378-2-ovoshcha@redhat.com>
Hi Oksana,
On 2/14/20 12:52 PM, Oksana Vohchana wrote:
> Provides param address in _get_free_port()
> because by default it takes free port only on the localhost
>
> Signed-off-by: Oksana Vohchana <ovoshcha@redhat.com>
> ---
> tests/acceptance/migration.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/acceptance/migration.py b/tests/acceptance/migration.py
> index a8367ca023..e4c39b85a1 100644
> --- a/tests/acceptance/migration.py
> +++ b/tests/acceptance/migration.py
> @@ -52,8 +52,8 @@ class Migration(Test):
> source_vm.qmp('migrate', uri=src_uri)
> self.assert_migration(source_vm, dest_vm)
>
> - def _get_free_port(self):
> - port = network.find_free_port()
> + def _get_free_port(self, address='localhost'):
> + port = network.find_free_port(address=address)
Looks good to me, but:
- This patch is out of order, it should be followed by patches 03 and 04.
- You could have described in the cover letter (or in the commit) your
intention with this change.
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Thanks!
- Wainer
> if port is None:
> self.cancel('Failed to find a free port')
> return port
^ permalink raw reply
* RE: [External] Re: [PATCH] thinkpad_acpi: Add sysfs entry for lcdshadow feature
From: Mark Pearson @ 2020-02-20 19:03 UTC (permalink / raw)
To: Rajat Jain
Cc: Andy Shevchenko, Nitin Joshi, Mat King, Jani Nikula,
Daniel Thompson, Jingoo Han, Henrique de Moraes Holschuh,
Darren Hart, Andy Shevchenko, Thinkpad-acpi devel ML,
Platform Driver, Nitin Joshi1, Benjamin Berg,
Linux Kernel Mailing List, dri-devel, Greg Kroah-Hartman
In-Reply-To: <CACK8Z6GwuOnJUUscriGwKWGBp5PFKyuqUkFYC8tEXa0UEuEZww@mail.gmail.com>
Hi Rajat,
> -----Original Message-----
> From: Rajat Jain <rajatja@google.com>
> Sent: Thursday, February 20, 2020 1:39 PM
> >
> > For this particular issue what is the best way to contribute and get
> > involved? We'd like to make it so ePrivacy can be used more easily from
> > Linux. I agree a more generic way of controlling it would be good.
> > I looked at the proposed patch from Rajat
> > (https://lkml.org/lkml/2019/10/22/967) - it seems like a good solution to me.
> > We can help with testing that on our platforms if that would be useful.
>
> Thanks you, just so that you know, the latest patchset is at:
> https://lkml.org/lkml/2019/12/20/794
>
> It would be great to get some additional testing if possible. I can
> send a sample ACPI (for our platform) in case it helps.
>
Sounds good - we'll definitely try this out and see how it goes. I suspect we'll have some questions once we try it out and get more familiar.
> >
> > I need to understand how we connect that implementation with the ACPI
> > controls we have (as I believe what we have are thinkpad specific and not to
> > a drm spec; we need to confirm that). We also have the ACPI events that
> > notify if ePrivacy was changed by the hotkeys and that seems like something
> > that should be done in thinkpad_acpi.c and not the drm code.
> >
> > Not sure if the two need to be connected somehow (or if handling the
> > event is actually not important and polling is acceptable)?
>
> So there was some brief discussion about this on my patches - but
> atleast on the platforms I have seen, there was no way to change the
> privacy screen out of software / kernel control. Essentially, if there
> are hotkeys, they would send an input event to the kernel, who'd send
> them to userspace, who'd use the DRM method to toggle the privacy
> screen. Thus the current version of the patch only supports
> controlling the privacy screen via set() method. The get() method just
> returns the cached value.I hope that works for you.
>
OK - on the thinkpads we have function+D as a 'hotkey' to control the feature...and my understanding is that bypasses everything and goes straight to the firmware.
The changes Nitin had been working on in thinkpad_acpi.c was to make this more Linux and friendly - provide a sysfs hook for user space to connect to with the aim of allowing it to be configured from user space and have on screen display when it was triggered etc.
I'm personally not sure yet how this ties up with the DRM method - more digging required. I'm intrigued to see if it works on our systems (sadly I don't have anything with that feature available on my desk right now...I need to get my hands on one)
Thanks
Mark
^ permalink raw reply
* Re: [cip-dev] [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU
From: Chris Paterson @ 2020-02-20 14:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux ARM, Michal Hocko, Rik van Riel, Catalin Marinas,
Santosh Shilimkar, Dave Chinner, Russell King - ARM Linux admin,
Linux Kernel Mailing List, Linux-MM, Yafang Shao,
Geert Uytterhoeven, Al Viro, cip-dev@lists.cip-project.org,
Johannes Weiner, linux-fsdevel, kernel-team@fb.com,
Kishon Vijay Abraham I, Linus Torvalds, Andrew Morton,
Roman Gushchin
In-Reply-To: <CAK8P3a3Za8dthPE7czQs+rK+xUq+ZZC4Sbj8QF5YjXvtfzop4Q@mail.gmail.com>
Hello,
> From: Arnd Bergmann <arnd@arndb.de>
> Sent: 16 February 2020 20:38
>
> On Sun, Feb 16, 2020 at 8:54 PM Chris Paterson
> <Chris.Paterson2@renesas.com> wrote:
> >
> > Hello Arnd, Geert,
> >
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Sent: 16 February 2020 09:45
> > > To: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Hi Arnd,
> > >
> > > On Sat, Feb 15, 2020 at 5:59 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Sat, Feb 15, 2020 at 12:25 PM Geert Uytterhoeven
> > > > <geert@linux-m68k.org> wrote:
> > > > > On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann <arnd@arndb.de>
> > > wrote:
> > > > > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin
> > > > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split
> (even
> > > > > for 1 GiB or 2 GiB configurations) in two parts, one below and one
> above
> > > > > the 32-bit physical limit.
> >
> > Yep. One example is r8a7743-iwg20m.dtsi.
>
> This one has 2x512MB, with half above the 4GiB limit. This means it needs
> LPAE to address high physical addresses (which is fine), but it does not need
> highmem if one uses an appropriate CONFIG_VMSPLIT_* option.
>
> > > > Good to know. I think there are several other chips that have dual-
> channel
> > > > DDR3 and thus /can/ support this configuration, but this rarely happens.
> > > > Are you aware of commercial products that use a 4GB configuration,
> aside
> > > from
> > > > the reference board?
> >
> > iWave Systems make a range of SOM modules using the RZ/G1 SoCs.
> > I believe there are options for some of these to use 4 GB, although 1 or 2
> GB is
> > used in the boards we've upstreamed support for.
> >
> > There are also other SOM vendors (e.g. Emtrion) and end users of RZ/G1,
> > but I'm not sure of the details.
>
> Both iWave and Emtrion only seem to list boards with 2GB or less on their
> websites today (with up to 15 year availability). My guess is that they had
> the same problem as everyone else in finding the right memory chips in
> the required quantities and/or long-term availability. iWave lists "By default
> 1GB DDR3 and 4GB eMMC only supported. Contact iWave for memory
> expansion support." on some boards, but that doesn't mean they ever
> shipped a 4GB configuration.
I probably should have been clearer before - I actually have a couple of iWave RZ/G1M SOM modules with 4GB DDR on them.
However I've never booted them nor do I know what the memory mapping is.
Kind regards, Chris
>
> Arnd
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
^ permalink raw reply
* Re: [PATCH v2 2/2] lib: make a test module with set/clear bit
From: Jesse Brandeburg @ 2020-02-20 19:03 UTC (permalink / raw)
To: Peter Zijlstra
Cc: tglx, mingo, bp, x86, linux-kernel, linux, andriy.shevchenko,
dan.j.williams
In-Reply-To: <20200220181033.GW14897@hirez.programming.kicks-ass.net>
On Thu, 20 Feb 2020 19:10:33 +0100 Peter wrote:
> On Thu, Feb 20, 2020 at 09:37:22AM -0800, Jesse Brandeburg wrote:
> > Test some bit clears/sets to make sure assembly doesn't change.
> > Instruct Kbuild to build this file with extra warning level -Wextra,
> > to catch new issues, and also doesn't hurt to build with C=1.
> >
> > This was used to test changes to arch/x86/include/asm/bitops.h.
> >
> > Recommended usage:
> > make defconfig
> > scripts/config -m CONFIG_TEST_BITOPS
> > make modules_prepare
> > make C=1 W=1 lib/test_bitops.ko
> > objdump -S -d lib/test_bitops.ko
>
> I only applied this second patch:
>
> # sparse --version
> 0.6.0 (Debian: 0.6.0-3+b1)
Thanks for the review! The module was created to verify assembly didn't
change before/after, but it's not a reproducer. Let me fix that (I had
skipped that step as I originally didn't plan to upstream the
test-patch).
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Remove require_force_probe protection
From: Patchwork @ 2020-02-20 19:03 UTC (permalink / raw)
To: Souza, Jose; +Cc: intel-gfx
In-Reply-To: <20200218230822.66801-1-jose.souza@intel.com>
== Series Details ==
Series: drm/i915/tgl: Remove require_force_probe protection
URL : https://patchwork.freedesktop.org/series/73613/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16613_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_16613_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16613_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_16613_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_exec_balancer@hang:
- shard-tglb: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb2/igt@gem_exec_balancer@hang.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-tglb1/igt@gem_exec_balancer@hang.html
New tests
---------
New tests have been introduced between CI_DRM_7963_full and Patchwork_16613_full:
### New IGT tests (54) ###
* igt@i915_pm_backlight@bad-brightness:
- Statuses : 3 pass(s) 4 skip(s)
- Exec time: [0.0, 0.03] s
* igt@i915_pm_backlight@fade:
- Statuses : 3 pass(s) 4 skip(s)
- Exec time: [0.0, 2.60] s
* igt@i915_pm_backlight@fade_with_dpms:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 5.00] s
* igt@i915_pm_backlight@fade_with_suspend:
- Statuses : 3 pass(s) 4 skip(s)
- Exec time: [0.0, 4.50] s
* igt@i915_pm_lpsp@edp-native:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.04] s
* igt@i915_pm_lpsp@edp-panel-fitter:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.05] s
* igt@i915_pm_lpsp@non-edp:
- Statuses : 1 pass(s) 7 skip(s)
- Exec time: [0.0, 0.12] s
* igt@i915_pm_lpsp@screens-disabled:
- Statuses : 1 pass(s) 7 skip(s)
- Exec time: [0.0, 0.04] s
* igt@i915_pm_rc6_residency@media-rc6-accuracy:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rc6_residency@rc6-accuracy:
- Statuses : 8 pass(s)
- Exec time: [3.00] s
* igt@i915_pm_rpm@cursor:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 45.52] s
* igt@i915_pm_rpm@cursor-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 36.78] s
* igt@i915_pm_rpm@debugfs-forcewake-user:
- Statuses : 7 pass(s)
- Exec time: [10.41, 14.24] s
* igt@i915_pm_rpm@debugfs-read:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 80.93] s
* igt@i915_pm_rpm@dpms-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 0.81] s
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- Statuses : 3 pass(s) 4 skip(s)
- Exec time: [0.0, 9.74] s
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 4.13] s
* igt@i915_pm_rpm@dpms-non-lpsp:
- Statuses : 4 pass(s) 3 skip(s)
- Exec time: [0.0, 0.16] s
* igt@i915_pm_rpm@drm-resources-equal:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.64] s
* igt@i915_pm_rpm@fences:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 14.70] s
* igt@i915_pm_rpm@fences-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 12.82] s
* igt@i915_pm_rpm@gem-evict-pwrite:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 3.96] s
* igt@i915_pm_rpm@gem-execbuf:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 15.30] s
* igt@i915_pm_rpm@gem-execbuf-stress:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 42.82] s
* igt@i915_pm_rpm@gem-execbuf-stress-pc8:
- Statuses : 1 incomplete(s) 7 skip(s)
- Exec time: [0.0, 0.00] s
* igt@i915_pm_rpm@gem-idle:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.09] s
* igt@i915_pm_rpm@gem-pread:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 6.33] s
* igt@i915_pm_rpm@i2c:
- Statuses : 7 pass(s)
- Exec time: [0.95, 11.18] s
* igt@i915_pm_rpm@legacy-planes:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 169.80] s
* igt@i915_pm_rpm@legacy-planes-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 146.58] s
* igt@i915_pm_rpm@modeset-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.93] s
* igt@i915_pm_rpm@modeset-lpsp-stress:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 49.59] s
* igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 18.02] s
* igt@i915_pm_rpm@modeset-non-lpsp:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 3.93] s
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 7.29] s
* igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 5.43] s
* igt@i915_pm_rpm@modeset-pc8-residency-stress:
- Statuses : 8 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rpm@modeset-stress-extra-wait:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 73.83] s
* igt@i915_pm_rpm@pc8-residency:
- Statuses : 8 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rpm@pm-caching:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 19.89] s
* igt@i915_pm_rpm@pm-tiling:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 16.86] s
* igt@i915_pm_rpm@reg-read-ioctl:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 7.98] s
* igt@i915_pm_rpm@sysfs-read:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 3.87] s
* igt@i915_pm_rpm@system-suspend:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.06] s
* igt@i915_pm_rpm@system-suspend-devices:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 13.38] s
* igt@i915_pm_rpm@system-suspend-execbuf:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 86.04] s
* igt@i915_pm_rpm@system-suspend-modeset:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 13.66] s
* igt@i915_pm_rpm@universal-planes:
- Statuses : 7 pass(s)
- Exec time: [2.94, 226.06] s
* igt@i915_pm_rpm@universal-planes-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 195.48] s
* igt@i915_pm_rps@min-max-config-idle:
- Statuses : 8 pass(s)
- Exec time: [0.11, 0.66] s
* igt@i915_pm_rps@min-max-config-loaded:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [0.32, 3.02] s
* igt@i915_pm_rps@reset:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [3.52, 3.67] s
* igt@i915_pm_rps@waitboost:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [2.52, 2.65] s
* igt@i915_pm_sseu@full-enable:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 0.01] s
Known issues
------------
Here are the changes found in Patchwork_16613_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_schedule@preempt-queue-bsd1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +11 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_exec_schedule@preempt-queue-bsd1.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb5/igt@gem_exec_schedule@preempt-queue-bsd1.html
* igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb3/igt@gem_exec_schedule@reorder-wide-bsd.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb1/igt@gem_exec_schedule@reorder-wide-bsd.html
* igt@gem_partial_pwrite_pread@write-snoop:
- shard-hsw: [PASS][7] -> [FAIL][8] ([i915#694]) +2 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw6/igt@gem_partial_pwrite_pread@write-snoop.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-hsw4/igt@gem_partial_pwrite_pread@write-snoop.html
* igt@gem_vm_create@isolation:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#314])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk6/igt@gem_vm_create@isolation.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-glk3/igt@gem_vm_create@isolation.html
* igt@gem_workarounds@suspend-resume-context:
- shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +2 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl2/igt@gem_workarounds@suspend-resume-context.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-apl4/igt@gem_workarounds@suspend-resume-context.html
* igt@i915_pm_dc@dc5-dpms:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#447])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@i915_pm_dc@dc5-dpms.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb3/igt@i915_pm_dc@dc5-dpms.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#454])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@i915_pm_dc@dc6-psr.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb4/igt@i915_pm_dc@dc6-psr.html
* igt@i915_pm_rpm@gem-execbuf-stress-pc8 (NEW):
- shard-snb: [SKIP][17] ([fdo#109271]) -> [INCOMPLETE][18] ([i915#82])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-snb5/igt@i915_pm_rpm@gem-execbuf-stress-pc8.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-snb6/igt@i915_pm_rpm@gem-execbuf-stress-pc8.html
* igt@i915_selftest@live_gtt:
- shard-kbl: [PASS][19] -> [TIMEOUT][20] ([fdo#112271])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl7/igt@i915_selftest@live_gtt.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-kbl4/igt@i915_selftest@live_gtt.html
* igt@kms_flip@flip-vs-absolute-wf_vblank:
- shard-tglb: [PASS][21] -> [FAIL][22] ([i915#488])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-tglb3/igt@kms_flip@flip-vs-absolute-wf_vblank.html
* igt@kms_flip@flip-vs-suspend:
- shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([i915#180])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl3/igt@kms_flip@flip-vs-suspend.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-kbl7/igt@kms_flip@flip-vs-suspend.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-skl: [PASS][25] -> [FAIL][26] ([i915#49])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-skl5/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][27] -> [FAIL][28] ([fdo#108145])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-skl5/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][29] -> [FAIL][30] ([fdo#108145] / [i915#265])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-skl1/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_plane_lowres@pipe-a-tiling-y:
- shard-glk: [PASS][31] -> [FAIL][32] ([i915#899])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk9/igt@kms_plane_lowres@pipe-a-tiling-y.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-glk4/igt@kms_plane_lowres@pipe-a-tiling-y.html
* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][33] -> [SKIP][34] ([fdo#109441]) +1 similar issue
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb4/igt@kms_psr@psr2_cursor_mmap_cpu.html
* igt@perf_pmu@init-busy-vcs1:
- shard-iclb: [PASS][35] -> [SKIP][36] ([fdo#112080]) +4 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@perf_pmu@init-busy-vcs1.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb7/igt@perf_pmu@init-busy-vcs1.html
#### Possible fixes ####
* {igt@gem_ctx_persistence@close-replace-race}:
- shard-iclb: [FAIL][37] ([i915#1241]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_ctx_persistence@close-replace-race.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb3/igt@gem_ctx_persistence@close-replace-race.html
- shard-apl: [FAIL][39] ([i915#1241]) -> [PASS][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl4/igt@gem_ctx_persistence@close-replace-race.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-apl1/igt@gem_ctx_persistence@close-replace-race.html
* {igt@gem_exec_schedule@implicit-both-bsd2}:
- shard-iclb: [SKIP][41] ([fdo#109276] / [i915#677]) -> [PASS][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb8/igt@gem_exec_schedule@implicit-both-bsd2.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb2/igt@gem_exec_schedule@implicit-both-bsd2.html
* igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [SKIP][43] ([i915#677]) -> [PASS][44] +1 similar issue
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb3/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
* igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [SKIP][45] ([fdo#112146]) -> [PASS][46] +1 similar issue
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_exec_schedule@preemptive-hang-bsd.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb7/igt@gem_exec_schedule@preemptive-hang-bsd.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk: [FAIL][47] ([i915#644]) -> [PASS][48]
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk8/igt@gem_ppgtt@flink-and-close-vma-leak.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-glk7/igt@gem_ppgtt@flink-and-close-vma-leak.html
- shard-apl: [FAIL][49] ([i915#644]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@gem_ppgtt@flink-and-close-vma-leak.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-apl6/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@gem_wait@write-busy-vcs1:
- shard-iclb: [SKIP][51] ([fdo#112080]) -> [PASS][52] +4 similar issues
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb8/igt@gem_wait@write-busy-vcs1.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb2/igt@gem_wait@write-busy-vcs1.html
* igt@kms_cursor_crc@pipe-a-cursor-size-change:
- shard-snb: [SKIP][53] ([fdo#109271]) -> [PASS][54] +1 similar issue
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-snb4/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-snb6/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [FAIL][55] ([i915#96]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw8/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-hsw6/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [DMESG-WARN][57] ([i915#180]) -> [PASS][58]
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-kbl6/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: [FAIL][59] ([i915#79]) -> [PASS][60]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw: [INCOMPLETE][61] ([i915#61]) -> [PASS][62]
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@kms_flip@flip-vs-suspend-interruptible.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-hsw1/igt@kms_flip@flip-vs-suspend-interruptible.html
* igt@kms_frontbuffer_tracking@psr-1p-rte:
- shard-tglb: [SKIP][63] ([i915#668]) -> [PASS][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_frontbuffer_tracking@psr-1p-rte.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-tglb3/igt@kms_frontbuffer_tracking@psr-1p-rte.html
* {igt@kms_hdr@bpc-switch-dpms}:
- shard-skl: [FAIL][65] ([i915#1188]) -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl2/igt@kms_hdr@bpc-switch-dpms.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-skl1/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [DMESG-WARN][67] ([i915#180]) -> [PASS][68] +2 similar issues
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-apl3/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [FAIL][69] ([fdo#108145] / [i915#265]) -> [PASS][70]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [SKIP][71] ([fdo#109642] / [fdo#111068]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@kms_psr2_su@frontbuffer.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
* igt@kms_psr@no_drrs:
- shard-iclb: [FAIL][73] ([i915#173]) -> [PASS][74]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@kms_psr@no_drrs.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb7/igt@kms_psr@no_drrs.html
* igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-iclb: [SKIP][75] ([fdo#109441]) -> [PASS][76] +2 similar issues
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@kms_psr@psr2_sprite_mmap_gtt.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
* igt@kms_setmode@basic:
- shard-apl: [FAIL][77] ([i915#31]) -> [PASS][78]
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl2/igt@kms_setmode@basic.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-apl7/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-skl: [INCOMPLETE][79] ([i915#69]) -> [PASS][80]
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-skl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@perf@short-reads:
- shard-kbl: [TIMEOUT][81] ([fdo#112271] / [i915#51]) -> [PASS][82]
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@perf@short-reads.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-kbl1/igt@perf@short-reads.html
* igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: [SKIP][83] ([fdo#109276]) -> [PASS][84] +8 similar issues
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb8/igt@prime_vgem@fence-wait-bsd2.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-iclb2/igt@prime_vgem@fence-wait-bsd2.html
#### Warnings ####
* igt@gem_eio@in-flight-suspend:
- shard-kbl: [INCOMPLETE][85] ([fdo#103665]) -> [DMESG-WARN][86] ([i915#180])
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@gem_eio@in-flight-suspend.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-kbl1/igt@gem_eio@in-flight-suspend.html
* igt@gem_tiled_blits@interruptible:
- shard-hsw: [FAIL][87] ([i915#818]) -> [FAIL][88] ([i915#694])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw1/igt@gem_tiled_blits@interruptible.html
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-hsw8/igt@gem_tiled_blits@interruptible.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1197]: https://gitlab.freedesktop.org/drm/intel/issues/1197
[i915#1239]: https://gitlab.freedesktop.org/drm/intel/issues/1239
[i915#1241]: https://gitlab.freedesktop.org/drm/intel/issues/1241
[i915#173]: https://gitlab.freedesktop.org/drm/intel/issues/173
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
[i915#314]: https://gitlab.freedesktop.org/drm/intel/issues/314
[i915#447]: https://gitlab.freedesktop.org/drm/intel/issues/447
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#488]: https://gitlab.freedesktop.org/drm/intel/issues/488
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#51]: https://gitlab.freedesktop.org/drm/intel/issues/51
[i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
[i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
[i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#818]: https://gitlab.freedesktop.org/drm/intel/issues/818
[i915#82]: https://gitlab.freedesktop.org/drm/intel/issues/82
[i915#899]: https://gitlab.freedesktop.org/drm/intel/issues/899
[i915#96]: https://gitlab.freedesktop.org/drm/intel/issues/96
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7963 -> Patchwork_16613
CI-20190529: 20190529
CI_DRM_7963: e0d737598eb749378a5dc4ed3dfafc6f79d512cb @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5448: 116020b1f83c1b3994c76882df7f77b6731d78ba @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16613: e94302377fad504b417c64381216bf424da11f5e @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v8 02/15] help: add shell-path to --build-options
From: Junio C Hamano @ 2020-02-20 19:03 UTC (permalink / raw)
To: Emily Shaffer; +Cc: git
In-Reply-To: <20200220015858.181086-3-emilyshaffer@google.com>
Emily Shaffer <emilyshaffer@google.com> writes:
> It may be useful to know which shell Git was built to try to point to,
> in the event that shell-based Git commands are failing. $SHELL_PATH is
> set during the build and used to launch the manpage viewer, as well as
> by git-compat-util.h, and it's used during tests. 'git version
> --build-options' is encouraged for use in bug reports, so it makes sense
> to include this information there.
It probably makes sense to capture PERL_PATH, PYTHON_PATH,
TCLTK_PATH, and TCL_PATH, as they fall into exactly the same
category as this one.
> Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
> ---
> help.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/help.c b/help.c
> index a21487db77..190722fb0a 100644
> --- a/help.c
> +++ b/help.c
> @@ -654,6 +654,7 @@ int cmd_version(int argc, const char **argv, const char *prefix)
> printf("no commit associated with this build\n");
> printf("sizeof-long: %d\n", (int)sizeof(long));
> printf("sizeof-size_t: %d\n", (int)sizeof(size_t));
> + printf("shell-path: %s\n", SHELL_PATH);
> /* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
> }
> return 0;
^ permalink raw reply
* Re: [PATCH] block: Prevent hung_check firing during long sync IO
From: Salman Qazi @ 2020-02-20 19:04 UTC (permalink / raw)
To: Jesse Barnes; +Cc: Ming Lei, Jens Axboe, linux-block, Bart Van Assche
In-Reply-To: <CAJmaN=kZrE7FNPd3Fv4nxc1qYhGo=V3uZA-zyPxzqRYq6KABrg@mail.gmail.com>
Thank you for doing this. The fix will help, but it is not a complete solution.
+1 to Jesse's comment about putting into a descriptive helper. This
functionality might be useful elsewhere.
I'd like to reiterate that the problem is broader. For instance, if I
hack the IOCTL path to be immune from the hung task watchdog from
firing there, the problem simply moves to another I/O that is behind
the IOCTL. For instance if I have a dd command doing direct I/O
against the same device that has the IOCTL pending, the dd will hang
in uninterruptible sleep and eventually the hung task timer will fire.
[ 5645.712955] dd D 634a749ef8dd8750 0 5126 4978
0x00000000 last_sleep: 5568344242277. last_runnable: 5568342587878
[ 5645.712965] ffff88005cfb2c00 ffff88007ab14940 ffff88007a6df080
ffff8800614a4b00
[ 5645.712973] 0000000000014940 ffff880076f77a00 ffffffffb1076a57
ffff880000000000
[ 5645.712981] ffff8800614a4b00 7fffffffffffffff ffff880075402940
ffff880076f77a38
[ 5645.712988] Call Trace:
[ 5645.713000] [<ffffffffb1076a57>] ? __schedule+0x37a/0x7a2
[ 5645.713005] [<ffffffffb10766a7>] schedule+0x3f/0x75
[ 5645.713009] [<ffffffffb1079410>] schedule_timeout+0x53/0x6af
[ 5645.713015] [<ffffffffb1077425>] io_schedule_timeout+0x6b/0x91
[ 5645.713021] [<ffffffffb09dd66a>] dio_await_one+0x94/0xdb
[ 5645.713025] [<ffffffffb09dc668>] __blockdev_direct_IO+0x6d5/0x763
[ 5645.713029] [<ffffffffb09dbde9>] ? blkdev_direct_IO+0x3b/0x3b
[ 5645.713034] [<ffffffffb09dbde9>] ? blkdev_direct_IO+0x3b/0x3b
[ 5645.713039] [<ffffffffb09dbde3>] blkdev_direct_IO+0x35/0x3b
[ 5645.713044] [<ffffffffb095bf30>]
generic_file_direct_write+0xfb/0x16d
[ 5645.713050] [<ffffffffb098c661>]
__generic_file_write_iter+0x2b0/0x3c1
[ 5645.713056] [<ffffffffb0bffe9d>] ? write_port+0xdc/0xdc
[ 5645.713061] [<ffffffffb0b506de>] ? __clear_user+0x41/0x66
[ 5645.713065] [<ffffffffb09db78f>] blkdev_write_iter+0xd1/0x13e
[ 5645.713072] [<ffffffffb0a66977>] SyS_write+0x22d/0x431
[ 5645.713077] [<ffffffffb107b163>] entry_SYSCALL_64_fastpath+0x31/0xab
Similarly, I am sure there are filesystem specific paths that can
potentially hang. I suspect that the flushing code in ext4 might be
one such path. These are just examples.
Also, my worry persists that we are creating more places for bugs to
hide by blanket immunizing I/O paths from the hung task timer. Having
said all of that, I don't really have a significantly better in-kernel
solution.
Reviewed-by: Salman Qazi <sqazi@google.com>
On Thu, Feb 20, 2020 at 6:43 AM Jesse Barnes <jsbarnes@google.com> wrote:
>
> Yeah looks good.
>
> Reviewed-by: Jesse Barnes <jsbarnes@google.com>
>
> A further change (just for readability) might be to factor out these
> "don't trigger hangcheck" waits from here and blk_execute_rq() into a
> small helper with a descriptive name.
>
> Thanks,
> Jesse
>
> On Thu, Feb 20, 2020 at 5:05 AM Ming Lei <ming.lei@redhat.com> wrote:
> >
> > submit_bio_wait() can be called from ioctl(BLKSECDISCARD), which
> > may take long time to complete, as Salman mentioned, 4K BLKSECDISCARD
> > takes up to 100 second on some devices. Also any block I/O operation
> > that occurs after the BLKSECDISCARD is submitted will also potentially
> > be affected by the hung task timeouts.
> >
> > So prevent hung_check from firing by taking same approach used
> > in blk_execute_rq(), and the wake-up interval is set as half the
> > hung_check timer period, which keeps overhead low enough.
> >
> > Cc: Salman Qazi <sqazi@google.com>
> > Cc: Jesse Barnes <jsbarnes@google.com>
> > Cc: Bart Van Assche <bvanassche@acm.org>
> > Link: https://lkml.org/lkml/2020/2/12/1193
> > Reported-by: Salman Qazi <sqazi@google.com>
> > Signed-off-by: Ming Lei <ming.lei@redhat.com>
> > ---
> > block/bio.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/block/bio.c b/block/bio.c
> > index 94d697217887..c9ce19a86de7 100644
> > --- a/block/bio.c
> > +++ b/block/bio.c
> > @@ -17,6 +17,7 @@
> > #include <linux/cgroup.h>
> > #include <linux/blk-cgroup.h>
> > #include <linux/highmem.h>
> > +#include <linux/sched/sysctl.h>
> >
> > #include <trace/events/block.h>
> > #include "blk.h"
> > @@ -1019,12 +1020,19 @@ static void submit_bio_wait_endio(struct bio *bio)
> > int submit_bio_wait(struct bio *bio)
> > {
> > DECLARE_COMPLETION_ONSTACK_MAP(done, bio->bi_disk->lockdep_map);
> > + unsigned long hang_check;
> >
> > bio->bi_private = &done;
> > bio->bi_end_io = submit_bio_wait_endio;
> > bio->bi_opf |= REQ_SYNC;
> > submit_bio(bio);
> > - wait_for_completion_io(&done);
> > +
> > + /* Prevent hang_check timer from firing at us during very long I/O */
> > + hang_check = sysctl_hung_task_timeout_secs;
> > + if (hang_check)
> > + while (!wait_for_completion_io_timeout(&done, hang_check * (HZ/2)));
> > + else
> > + wait_for_completion_io(&done);
> >
> > return blk_status_to_errno(bio->bi_status);
> > }
> > --
> > 2.20.1
> >
^ permalink raw reply
* Re: [PATCH] rtw88: disable TX-AMSDU on 2.4G band
From: Brian Norris @ 2020-02-20 19:04 UTC (permalink / raw)
To: Tony Chuang; +Cc: Justin Capella, Kalle Valo, Chris Chiu, linux-wireless
In-Reply-To: <2c91e4e7b36d42a8abad6ae356c2869c@realtek.com>
On Tue, Feb 11, 2020 at 6:56 PM Tony Chuang <yhchuang@realtek.com> wrote:
> Module parameters are really good for me, too. But we've had discussion
> before with Kalle and Brian, they both were trying hard to avoid module
> parameters.
My personal preference is to avoid module parameters when you can fix
the defaults, and that module parameters should never be a workaround
for fixing the default behavior.
I don't think my above preference precludes module parameters: they
can be useful as "extra debug knobs."
But Kalle had a little more nuanced opinion here -- he didn't even
want "debug knobs" for core 802.11 functionality, because (I may be
paraphrasing) one person's "debug knob" easily becomes the next
person's "required knob." Additionally, a mess of disorganized knobs
can make maintenance difficult -- one can't really expect the average
distribution to make a good selection on 100 different parameters; and
for those that do tweak the parameters, it now creates a combinatoric
mess to debug and triage user reports of "it's broken". I can respect
all of those reasons too.
Regards,
Brian
^ permalink raw reply
* Re: [PATCH] staging: Replace zero-length array with flexible-array member
From: Adham.Abozaeid @ 2020-02-20 19:04 UTC (permalink / raw)
To: gustavo, gregkh, vaibhav.sr, mgreer, johan, elder, m.tretter,
kernel, mchehab, Larry.Finger, florian.c.schilhabel, Ajay.Kathat
Cc: devel, linux-kernel, greybus-dev, linux-media, linux-wireless
In-Reply-To: <20200220132908.GA30501@embeddedor>
Hi Gustavo
On 2/20/20 6:29 AM, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on.
>
> Also, notice that, dynamic memory allocations won't be affected by
> this change:
>
> "Flexible array members have incomplete type, and so the sizeof operator
> may not be applied. As a quirk of the original implementation of
> zero-length arrays, sizeof evaluates to zero."[1]
>
> This issue was found with the help of Coccinelle.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>
> static void cfg_scan_result(enum scan_event scan_event,
> diff --git a/drivers/staging/wilc1000/spi.c b/drivers/staging/wilc1000/spi.c
> index 44f7d48851b5..11653ac118cd 100644
> --- a/drivers/staging/wilc1000/spi.c
> +++ b/drivers/staging/wilc1000/spi.c
> @@ -139,7 +139,7 @@ struct wilc_spi_read_rsp_data {
> u8 status;
> u8 resp_header;
> u8 resp_data[4];
> - u8 crc[0];
> + u8 crc[];
> } __packed;
more zero-length arrays in wilc1000, spi.c, struct wilc_spi_cmd, and in fw.h
^ permalink raw reply
* Re: [PATCH bpf-next] libbpf: relax check whether BTF is mandatory
From: Alexei Starovoitov @ 2020-02-20 19:05 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, Network Development, Alexei Starovoitov, Daniel Borkmann,
Julia Kartseva, Andrii Nakryiko, Kernel Team
In-Reply-To: <20200220062635.1497872-1-andriin@fb.com>
On Wed, Feb 19, 2020 at 10:27 PM Andrii Nakryiko <andriin@fb.com> wrote:
>
> If BPF program is using BTF-defined maps, BTF is required only for
> libbpf itself to process map definitions. If after that BTF fails to
> be loaded into kernel (e.g., if it doesn't support BTF at all), this
> shouldn't prevent valid BPF program from loading. Existing
> retry-without-BTF logic for creating maps will succeed to create such
> maps without any problems. So, presence of .maps section shouldn't make
> BTF required for kernel. Update the check accordingly.
>
> Validated by ensuring simple BPF program with BTF-defined maps is still
> loaded on old kernel without BTF support and map is correctly parsed and
> created.
>
> Fixes: abd29c931459 ("libbpf: allow specifying map definitions using BTF")
> Reported-by: Julia Kartseva <hex@fb.com>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Applied. Thanks
^ permalink raw reply
* [PATCH] net: bcmgenet: Don't set ID_MODE_DIS when not using RGMII
From: Florian Fainelli @ 2020-02-20 19:05 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200220163630.29806-1-nsaenzjulienne@suse.de>
On 2/20/20 8:36 AM, Nicolas Saenz Julienne wrote:
> As per Linux's driver, ID_MODE_DIS is only set when the PHY interface is
> RGMII. Don't enable it for the rest of setups.
>
> This has been seen to misconfigure RPi4's PHY when booting Linux.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Does the failure look like the following: you have a driver for the
Broadcom PHY used on the Pi4 in u-boot, and the phy_dev->interface value
is being used to configure the Ethernet PHY chip in a certain way.
Later when you boot Linux, you do not have CONFIG_BROADCOM_PHY enabled
so the Generic PHY driver gets used instead, and there is a disagreement
between the AMAC and PHY as to whom should be adding the delays?
At any rate:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/bcmgenet.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
> index 8f4848aec6..e971b556ac 100644
> --- a/drivers/net/bcmgenet.c
> +++ b/drivers/net/bcmgenet.c
> @@ -448,7 +448,10 @@ static int bcmgenet_adjust_link(struct bcmgenet_eth_priv *priv)
> }
>
> clrsetbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, OOB_DISABLE,
> - RGMII_LINK | RGMII_MODE_EN | ID_MODE_DIS);
> + RGMII_LINK | RGMII_MODE_EN);
> +
> + if (phy_dev->interface == PHY_INTERFACE_MODE_RGMII)
> + setbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, ID_MODE_DIS);
>
> writel(speed << CMD_SPEED_SHIFT, (priv->mac_reg + UMAC_CMD));
>
>
--
Florian
^ permalink raw reply
* [PATCH v2 05/21] arm: socfpga: Override 'lowlevel_init' to support ATF
From: Ang, Chee Hong @ 2020-02-20 19:05 UTC (permalink / raw)
To: u-boot
In-Reply-To: <9e7b3553-f60a-4217-c270-cd3292cc7629@denx.de>
> On 2/20/20 3:27 AM, Ang, Chee Hong wrote:
> >> On 2/19/20 1:25 PM, chee.hong.ang at intel.com wrote:
> >> [...]
> >>> diff --git a/arch/arm/mach-socfpga/lowlevel_init.S
> >>> b/arch/arm/mach-socfpga/lowlevel_init.S
> >>> new file mode 100644
> >>> index 0000000..68053a0
> >>> --- /dev/null
> >>> +++ b/arch/arm/mach-socfpga/lowlevel_init.S
> >>
> >> This should be some lowlevel_init_64.S to make it clear it's only for
> >> arm64 platforms.
> > OK. It makes sense. Thanks.
> >>
> >>> @@ -0,0 +1,85 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0 */
> >>> +/*
> >>> + * Copyright (C) 2019, Intel Corporation */
> >>> +
> >>> +#include <asm-offsets.h>
> >>> +#include <config.h>
> >>> +#include <linux/linkage.h>
> >>> +#include <asm/macro.h>
> >>> +
> >>> +ENTRY(lowlevel_init)
> >>> + mov x29, lr /* Save LR */
> >>> +
> >>> +#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) #ifdef
> >>> +CONFIG_SPL_ATF
> >>> + branch_if_slave x0, 2f
> >>> +#else
> >>> + branch_if_slave x0, 1f
> >>> +#endif
> >>> +
> >>> + ldr x0, =GICD_BASE
> >>> + bl gic_init_secure
> >>> +#ifdef CONFIG_SPL_BUILD
> >>> + b 2f
> >>> +#else
> >>> + b 3f
> >>> +#endif
> >>
> >> Can't this be done in C code ? Can we reduce the ifdeffery ?
> > This lowlevel_init function is shared by SPL and U-Boot and they run
> > in slightly different flow.
>
> What does this 'different flow' mean ?
This has something to with multi-cores CPU such as A53.
For SPL, we need to make sure the slave CPUs (CPU1/2/3) trapped in a 'place'
Where they could be 'activated' by kernel for multi-processor environment.
It means the kernel get to 'activate' the slave CPUs from master CPU (CPU0)
U-Boot proper only run on master CPU (CPU0). The rest of slave CPUs
are trapped in the beginning of SPL waiting to be 'activated'
by kernel.
In U-Boot proper, only master CPU gets to run this code and it will just
do the basic GIC setup and skip the 'trap'. The 'trap' is to prevent the slave
CPUs from running the same SPL, ATF and U-Boot code as the master CPU in
parallel. Only single core (maser CPU) is needed for bootloaders and firmware.
>
> > I don't think this can be done in C code but let me see what I can do
> > to further optimize the flow to reduce the ifdeffery.
>
> That would be nice, thanks.
^ permalink raw reply
* Re: [PATCH 2/4] ceph: consider file's last read/write when calculating wanted caps
From: Jeff Layton @ 2020-02-20 19:06 UTC (permalink / raw)
To: Yan, Zheng, ceph-devel
In-Reply-To: <20200220122630.63170-2-zyan@redhat.com>
On Thu, 2020-02-20 at 20:26 +0800, Yan, Zheng wrote:
> When getting caps for read/write, update corresponding file's last
> read/write. If a file hasn't been read/write for 'caps_wanted_delay_max'
> seconds, ignore the file when calculating wanted caps.
>
> Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
> ---
> fs/ceph/caps.c | 149 ++++++++++++++++++++++++-----------
> fs/ceph/file.c | 23 +++---
> fs/ceph/inode.c | 15 +++-
> fs/ceph/ioctl.c | 4 +-
> fs/ceph/super.h | 16 +++-
> include/linux/ceph/ceph_fs.h | 1 +
> 6 files changed, 145 insertions(+), 63 deletions(-)
>
> diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> index 293920d013ff..ccdc47bd7cf0 100644
> --- a/fs/ceph/caps.c
> +++ b/fs/ceph/caps.c
> @@ -971,18 +971,44 @@ int __ceph_caps_used(struct ceph_inode_info *ci)
> return used;
> }
>
> +#define FMODE_WAIT_BIAS 1000
> +
> /*
> * wanted, by virtue of open file modes
> */
> int __ceph_caps_file_wanted(struct ceph_inode_info *ci)
> {
> + struct ceph_mount_options *opt =
> + ceph_inode_to_client(&ci->vfs_inode)->mount_options;
> + unsigned long used_cutoff =
> + round_jiffies(jiffies - opt->caps_wanted_delay_max * HZ);
> + unsigned long idle_cutoff =
> + round_jiffies(jiffies - opt->caps_wanted_delay_min * HZ);
> int i, bits = 0;
> +
> for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
> - if (ci->i_nr_by_mode[i])
> + if (ci->i_file_by_mode[i].nr >= FMODE_WAIT_BIAS) {
> + /* there are cap waiters or lots of open files */
> bits |= 1 << i;
> + } else if (ci->i_file_by_mode[i].nr > 0) {
> + if (i == CEPH_FILE_MODE_PIN ||
> + time_after(ci->i_file_by_mode[i].last_used,
> + used_cutoff))
> + bits |= 1 << i;
Ok, so in the case where we have active references give it up if
last_used is after the max delay.
> + } else if ((ci->i_file_by_mode[i].last_used & 1)) {
> + if (time_after(ci->i_file_by_mode[i].last_used,
> + idle_cutoff)) {
> + bits |= 1 << i;
> + } else {
> + ci->i_file_by_mode[i].last_used &= ~1UL;
> + }
> + }
What's the need for the trickery with the bottom bit here? It seems
simpler (and about as fast) to just do a time_after check every time.
> }
> if (bits == 0)
> return 0;
> + if (bits == 1 && !S_ISDIR(ci->vfs_inode.i_mode))
> + return 0;
> +
> return ceph_caps_for_mode(bits >> 1);
> }
>
> @@ -1021,14 +1047,6 @@ int __ceph_caps_mds_wanted(struct ceph_inode_info *ci, bool check)
> return mds_wanted;
> }
>
> -/*
> - * called under i_ceph_lock
> - */
> -static int __ceph_is_single_caps(struct ceph_inode_info *ci)
> -{
> - return rb_first(&ci->i_caps) == rb_last(&ci->i_caps);
> -}
> -
> int ceph_is_any_caps(struct inode *inode)
> {
> struct ceph_inode_info *ci = ceph_inode(inode);
> @@ -1856,10 +1874,6 @@ void ceph_check_caps(struct ceph_inode_info *ci, int flags,
> if (ci->i_ceph_flags & CEPH_I_FLUSH)
> flags |= CHECK_CAPS_FLUSH;
>
> - if (!(flags & CHECK_CAPS_AUTHONLY) ||
> - (ci->i_auth_cap && __ceph_is_single_caps(ci)))
> - __cap_delay_cancel(mdsc, ci);
> -
> goto retry_locked;
> retry:
> spin_lock(&ci->i_ceph_lock);
> @@ -2081,9 +2095,16 @@ void ceph_check_caps(struct ceph_inode_info *ci, int flags,
> goto retry; /* retake i_ceph_lock and restart our cap scan. */
> }
>
> - /* Reschedule delayed caps release if we delayed anything */
> - if (delayed)
> - __cap_delay_requeue(mdsc, ci, false);
> + if (list_empty(&ci->i_cap_delay_list)) {
> + if (delayed) {
> + /* Reschedule delayed caps release if we delayed anything */
> + __cap_delay_requeue(mdsc, ci, false);
> + } else if ((file_wanted & ~CEPH_CAP_PIN) &&
> + !(used & (CEPH_CAP_FILE_RD | CEPH_CAP_ANY_FILE_WR))) {
> + /* periodically re-calculate caps wanted by open files */
> + __cap_delay_requeue(mdsc, ci, true);
> + }
> + }
>
> spin_unlock(&ci->i_ceph_lock);
>
> @@ -2549,8 +2570,9 @@ static void __take_cap_refs(struct ceph_inode_info *ci, int got,
> * FIXME: how does a 0 return differ from -EAGAIN?
> */
> enum {
> - NON_BLOCKING = 1,
> - CHECK_FILELOCK = 2,
> + /* first 8 bits are reserved for CEPH_FILE_MODE_FOO */
> + NON_BLOCKING = (1 << 8),
> + CHECK_FILELOCK = (1 << 9),
> };
>
> static int try_get_cap_refs(struct inode *inode, int need, int want,
> @@ -2560,7 +2582,6 @@ static int try_get_cap_refs(struct inode *inode, int need, int want,
> struct ceph_mds_client *mdsc = ceph_inode_to_client(inode)->mdsc;
> int ret = 0;
> int have, implemented;
> - int file_wanted;
> bool snap_rwsem_locked = false;
>
> dout("get_cap_refs %p need %s want %s\n", inode,
> @@ -2576,15 +2597,6 @@ static int try_get_cap_refs(struct inode *inode, int need, int want,
> goto out_unlock;
> }
>
> - /* make sure file is actually open */
> - file_wanted = __ceph_caps_file_wanted(ci);
> - if ((file_wanted & need) != need) {
> - dout("try_get_cap_refs need %s file_wanted %s, EBADF\n",
> - ceph_cap_string(need), ceph_cap_string(file_wanted));
> - ret = -EBADF;
> - goto out_unlock;
> - }
> -
> /* finish pending truncate */
> while (ci->i_truncate_pending) {
> spin_unlock(&ci->i_ceph_lock);
> @@ -2692,6 +2704,9 @@ static int try_get_cap_refs(struct inode *inode, int need, int want,
> ceph_cap_string(have), ceph_cap_string(need));
> }
> out_unlock:
> +
> + __ceph_touch_fmode(ci, mdsc, flags);
> +
> spin_unlock(&ci->i_ceph_lock);
> if (snap_rwsem_locked)
> up_read(&mdsc->snap_rwsem);
> @@ -2729,10 +2744,22 @@ static void check_max_size(struct inode *inode, loff_t endoff)
> ceph_check_caps(ci, CHECK_CAPS_AUTHONLY, NULL);
> }
>
> +static inline int get_used_file_mode(int need, int want)
> +{
> + int fmode = 0;
> + if (need & CEPH_CAP_FILE_RD)
> + fmode |= CEPH_FILE_MODE_RD;
> + if (need & CEPH_CAP_FILE_WR)
> + fmode |= CEPH_FILE_MODE_WR;
> + if (want & CEPH_CAP_FILE_LAZYIO)
> + fmode |= CEPH_FILE_MODE_LAZY;
> + return fmode;
> +}
> +
> int ceph_try_get_caps(struct inode *inode, int need, int want,
> bool nonblock, int *got)
> {
> - int ret;
> + int ret, flags;
>
> BUG_ON(need & ~CEPH_CAP_FILE_RD);
> BUG_ON(want & ~(CEPH_CAP_FILE_CACHE|CEPH_CAP_FILE_LAZYIO|CEPH_CAP_FILE_SHARED));
> @@ -2740,8 +2767,11 @@ int ceph_try_get_caps(struct inode *inode, int need, int want,
> if (ret < 0)
> return ret;
>
> - ret = try_get_cap_refs(inode, need, want, 0,
> - (nonblock ? NON_BLOCKING : 0), got);
> + flags = get_used_file_mode(need, want);
> + if (nonblock)
> + flags |= NON_BLOCKING;
> +
> + ret = try_get_cap_refs(inode, need, want, 0, flags, got);
> return ret == -EAGAIN ? 0 : ret;
> }
>
> @@ -2767,11 +2797,15 @@ int ceph_get_caps(struct file *filp, int need, int want,
> fi->filp_gen != READ_ONCE(fsc->filp_gen))
> return -EBADF;
>
> + flags = get_used_file_mode(need, want);
> +
> while (true) {
> if (endoff > 0)
> check_max_size(inode, endoff);
>
> - flags = atomic_read(&fi->num_locks) ? CHECK_FILELOCK : 0;
> + flags &= CEPH_FILE_MODE_MASK;
> + if (atomic_read(&fi->num_locks))
> + flags |= CHECK_FILELOCK;
> _got = 0;
> ret = try_get_cap_refs(inode, need, want, endoff,
> flags, &_got);
> @@ -2791,6 +2825,8 @@ int ceph_get_caps(struct file *filp, int need, int want,
> list_add(&cw.list, &mdsc->cap_wait_list);
> spin_unlock(&mdsc->caps_list_lock);
>
> + /* make sure used fmode not timeout */
> + ceph_get_fmode(ci, flags, FMODE_WAIT_BIAS);
> add_wait_queue(&ci->i_cap_wq, &wait);
>
> flags |= NON_BLOCKING;
> @@ -2804,6 +2840,7 @@ int ceph_get_caps(struct file *filp, int need, int want,
> }
>
> remove_wait_queue(&ci->i_cap_wq, &wait);
> + ceph_put_fmode(ci, flags, FMODE_WAIT_BIAS);
>
> spin_lock(&mdsc->caps_list_lock);
> list_del(&cw.list);
> @@ -2823,7 +2860,7 @@ int ceph_get_caps(struct file *filp, int need, int want,
> if (ret < 0) {
> if (ret == -ESTALE) {
> /* session was killed, try renew caps */
> - ret = ceph_renew_caps(inode);
> + ret = ceph_renew_caps(inode, flags);
> if (ret == 0)
> continue;
> }
> @@ -4121,13 +4158,41 @@ void ceph_flush_dirty_caps(struct ceph_mds_client *mdsc)
> dout("flush_dirty_caps done\n");
> }
>
> +void __ceph_touch_fmode(struct ceph_inode_info *ci,
> + struct ceph_mds_client *mdsc, int fmode)
> +{
> + int i;
> + int bits = (fmode << 1);
> + unsigned long now = jiffies | 1;
> + for (i = 1; i < CEPH_FILE_MODE_BITS; i++) {
> + if (bits & (1 << i))
> + ci->i_file_by_mode[i].last_used = now;
> + }
> +
> + /* queue periodic check */
> + if (bits && list_empty(&ci->i_cap_delay_list))
> + __cap_delay_requeue(mdsc, ci, true);
> +}
> +
> +void ceph_get_fmode(struct ceph_inode_info *ci, int fmode, int count)
> +{
> + int i;
> + int bits = (fmode << 1) | 1;
> + spin_lock(&ci->i_ceph_lock);
> + for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
> + if (bits & (1 << i))
> + ci->i_file_by_mode[i].nr += count;
> + }
> + spin_unlock(&ci->i_ceph_lock);
> +}
> +
> void __ceph_get_fmode(struct ceph_inode_info *ci, int fmode)
> {
> int i;
> int bits = (fmode << 1) | 1;
> for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
> if (bits & (1 << i))
> - ci->i_nr_by_mode[i]++;
> + ci->i_file_by_mode[i].nr++;
> }
> }
>
> @@ -4136,26 +4201,18 @@ void __ceph_get_fmode(struct ceph_inode_info *ci, int fmode)
> * we may need to release capabilities to the MDS (or schedule
> * their delayed release).
> */
> -void ceph_put_fmode(struct ceph_inode_info *ci, int fmode)
> +void ceph_put_fmode(struct ceph_inode_info *ci, int fmode, int count)
> {
> - int i, last = 0;
> + int i;
> int bits = (fmode << 1) | 1;
> spin_lock(&ci->i_ceph_lock);
> for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
> if (bits & (1 << i)) {
> - BUG_ON(ci->i_nr_by_mode[i] == 0);
> - if (--ci->i_nr_by_mode[i] == 0)
> - last++;
> + BUG_ON(ci->i_file_by_mode[i].nr < count);
> + ci->i_file_by_mode[i].nr -= count;
> }
> }
> - dout("put_fmode %p fmode %d {%d,%d,%d,%d}\n",
> - &ci->vfs_inode, fmode,
> - ci->i_nr_by_mode[0], ci->i_nr_by_mode[1],
> - ci->i_nr_by_mode[2], ci->i_nr_by_mode[3]);
> spin_unlock(&ci->i_ceph_lock);
> -
> - if (last && ci->i_vino.snap == CEPH_NOSNAP)
> - ceph_check_caps(ci, 0, NULL);
> }
>
> /*
> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> index 7e0190b1f821..f28f420bad23 100644
> --- a/fs/ceph/file.c
> +++ b/fs/ceph/file.c
> @@ -213,7 +213,7 @@ static int ceph_init_file_info(struct inode *inode, struct file *file,
> struct ceph_dir_file_info *dfi =
> kmem_cache_zalloc(ceph_dir_file_cachep, GFP_KERNEL);
> if (!dfi) {
> - ceph_put_fmode(ci, fmode); /* clean up */
> + ceph_put_fmode(ci, fmode, 1); /* clean up */
> return -ENOMEM;
> }
>
> @@ -224,7 +224,7 @@ static int ceph_init_file_info(struct inode *inode, struct file *file,
> } else {
> fi = kmem_cache_zalloc(ceph_file_cachep, GFP_KERNEL);
> if (!fi) {
> - ceph_put_fmode(ci, fmode); /* clean up */
> + ceph_put_fmode(ci, fmode, 1); /* clean up */
> return -ENOMEM;
> }
>
> @@ -263,7 +263,7 @@ static int ceph_init_file(struct inode *inode, struct file *file, int fmode)
> case S_IFLNK:
> dout("init_file %p %p 0%o (symlink)\n", inode, file,
> inode->i_mode);
> - ceph_put_fmode(ceph_inode(inode), fmode); /* clean up */
> + ceph_put_fmode(ceph_inode(inode), fmode, 1); /* clean up */
> break;
>
> default:
> @@ -273,7 +273,7 @@ static int ceph_init_file(struct inode *inode, struct file *file, int fmode)
> * we need to drop the open ref now, since we don't
> * have .release set to ceph_release.
> */
> - ceph_put_fmode(ceph_inode(inode), fmode); /* clean up */
> + ceph_put_fmode(ceph_inode(inode), fmode, 1); /* clean up */
> BUG_ON(inode->i_fop->release == ceph_release);
>
> /* call the proper open fop */
> @@ -285,14 +285,15 @@ static int ceph_init_file(struct inode *inode, struct file *file, int fmode)
> /*
> * try renew caps after session gets killed.
> */
> -int ceph_renew_caps(struct inode *inode)
> +int ceph_renew_caps(struct inode *inode, int fmode)
> {
> - struct ceph_mds_client *mdsc = ceph_sb_to_client(inode->i_sb)->mdsc;
> + struct ceph_mds_client *mdsc = ceph_inode_to_client(inode)->mdsc;
> struct ceph_inode_info *ci = ceph_inode(inode);
> struct ceph_mds_request *req;
> int err, flags, wanted;
>
> spin_lock(&ci->i_ceph_lock);
> + __ceph_touch_fmode(ci, mdsc, fmode);
> wanted = __ceph_caps_file_wanted(ci);
> if (__ceph_is_any_real_caps(ci) &&
> (!(wanted & CEPH_CAP_ANY_WR) || ci->i_auth_cap)) {
> @@ -405,6 +406,7 @@ int ceph_open(struct inode *inode, struct file *file)
> } else if (ceph_snap(inode) != CEPH_NOSNAP &&
> (ci->i_snap_caps & wanted) == wanted) {
> __ceph_get_fmode(ci, fmode);
> + __ceph_touch_fmode(ci, mdsc, fmode);
> spin_unlock(&ci->i_ceph_lock);
> return ceph_init_file(inode, file, fmode);
> }
> @@ -525,7 +527,7 @@ int ceph_atomic_open(struct inode *dir, struct dentry *dentry,
> }
> out_req:
> if (!req->r_err && req->r_target_inode)
> - ceph_put_fmode(ceph_inode(req->r_target_inode), req->r_fmode);
> + ceph_put_fmode(ceph_inode(req->r_target_inode), req->r_fmode, 1);
> ceph_mdsc_put_request(req);
> out_ctx:
> ceph_release_acl_sec_ctx(&as_ctx);
> @@ -542,7 +544,7 @@ int ceph_release(struct inode *inode, struct file *file)
> dout("release inode %p dir file %p\n", inode, file);
> WARN_ON(!list_empty(&dfi->file_info.rw_contexts));
>
> - ceph_put_fmode(ci, dfi->file_info.fmode);
> + ceph_put_fmode(ci, dfi->file_info.fmode, 1);
>
> if (dfi->last_readdir)
> ceph_mdsc_put_request(dfi->last_readdir);
> @@ -554,7 +556,8 @@ int ceph_release(struct inode *inode, struct file *file)
> dout("release inode %p regular file %p\n", inode, file);
> WARN_ON(!list_empty(&fi->rw_contexts));
>
> - ceph_put_fmode(ci, fi->fmode);
> + ceph_put_fmode(ci, fi->fmode, 1);
> +
> kmem_cache_free(ceph_file_cachep, fi);
> }
>
> @@ -1560,7 +1563,7 @@ static ssize_t ceph_write_iter(struct kiocb *iocb, struct iov_iter *from)
> if (dirty)
> __mark_inode_dirty(inode, dirty);
> if (ceph_quota_is_max_bytes_approaching(inode, iocb->ki_pos))
> - ceph_check_caps(ci, CHECK_CAPS_NODELAY, NULL);
> + ceph_check_caps(ci, CHECK_CAPS_AUTHONLY, NULL);
NODELAY to AUTHONLY? Why? I guess if we're approaching quota we do want
to be talking to the authority, but I'm not sure that change belongs in
this patch.
> }
>
> dout("aio_write %p %llx.%llx %llu~%u dropping cap refs on %s\n",
> diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
> index 094b8fc37787..b279bd8e168e 100644
> --- a/fs/ceph/inode.c
> +++ b/fs/ceph/inode.c
> @@ -478,8 +478,10 @@ struct inode *ceph_alloc_inode(struct super_block *sb)
> ci->i_head_snapc = NULL;
> ci->i_snap_caps = 0;
>
> - for (i = 0; i < CEPH_FILE_MODE_BITS; i++)
> - ci->i_nr_by_mode[i] = 0;
> + for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
> + ci->i_file_by_mode[i].nr = 0;
> + ci->i_file_by_mode[i].last_used = 0;
> + }
>
> mutex_init(&ci->i_truncate_mutex);
> ci->i_truncate_seq = 0;
> @@ -637,7 +639,7 @@ int ceph_fill_file_size(struct inode *inode, int issued,
> if ((issued & (CEPH_CAP_FILE_CACHE|
> CEPH_CAP_FILE_BUFFER)) ||
> mapping_mapped(inode->i_mapping) ||
> - __ceph_caps_file_wanted(ci)) {
> + __ceph_is_file_opened(ci)) {
> ci->i_truncate_pending++;
> queue_trunc = 1;
> }
> @@ -1010,6 +1012,13 @@ static int fill_inode(struct inode *inode, struct page *locked_page,
> fill_inline = true;
> }
>
> + if (cap_fmode >= 0) {
> + if (!info_caps)
> + pr_warn("mds issued no caps on %llx.%llx\n",
> + ceph_vinop(inode));
> + __ceph_touch_fmode(ci, mdsc, cap_fmode);
> + }
> +
> spin_unlock(&ci->i_ceph_lock);
>
> if (fill_inline)
> diff --git a/fs/ceph/ioctl.c b/fs/ceph/ioctl.c
> index c90f03beb15d..da0ee54ae5bc 100644
> --- a/fs/ceph/ioctl.c
> +++ b/fs/ceph/ioctl.c
> @@ -243,11 +243,13 @@ static long ceph_ioctl_lazyio(struct file *file)
> struct ceph_file_info *fi = file->private_data;
> struct inode *inode = file_inode(file);
> struct ceph_inode_info *ci = ceph_inode(inode);
> + struct ceph_mds_client *mdsc = ceph_inode_to_client(inode)->mdsc;
>
> if ((fi->fmode & CEPH_FILE_MODE_LAZY) == 0) {
> spin_lock(&ci->i_ceph_lock);
> fi->fmode |= CEPH_FILE_MODE_LAZY;
> - ci->i_nr_by_mode[ffs(CEPH_FILE_MODE_LAZY)]++;
> + ci->i_file_by_mode[ffs(CEPH_FILE_MODE_LAZY)].nr++;
> + __ceph_touch_fmode(ci, mdsc, CEPH_FILE_MODE_LAZY);
> spin_unlock(&ci->i_ceph_lock);
> dout("ioctl_layzio: file %p marked lazy\n", file);
>
> diff --git a/fs/ceph/super.h b/fs/ceph/super.h
> index d370f89df358..029823643b8b 100644
> --- a/fs/ceph/super.h
> +++ b/fs/ceph/super.h
> @@ -361,7 +361,10 @@ struct ceph_inode_info {
> dirty|flushing caps */
> unsigned i_snap_caps; /* cap bits for snapped files */
>
> - int i_nr_by_mode[CEPH_FILE_MODE_BITS]; /* open file counts */
> + struct {
> + int nr;
> + unsigned long last_used;
> + } i_file_by_mode[CEPH_FILE_MODE_BITS]; /* open file counts */
>
> struct mutex i_truncate_mutex;
> u32 i_truncate_seq; /* last truncate to smaller size */
> @@ -673,6 +676,10 @@ extern int __ceph_caps_revoking_other(struct ceph_inode_info *ci,
> extern int ceph_caps_revoking(struct ceph_inode_info *ci, int mask);
> extern int __ceph_caps_used(struct ceph_inode_info *ci);
>
> +static inline bool __ceph_is_file_opened(struct ceph_inode_info *ci)
> +{
> + return ci->i_file_by_mode[0].nr;
> +}
> extern int __ceph_caps_file_wanted(struct ceph_inode_info *ci);
> extern int __ceph_caps_wanted(struct ceph_inode_info *ci);
>
> @@ -1074,7 +1081,10 @@ extern int ceph_try_get_caps(struct inode *inode,
>
> /* for counting open files by mode */
> extern void __ceph_get_fmode(struct ceph_inode_info *ci, int mode);
> -extern void ceph_put_fmode(struct ceph_inode_info *ci, int mode);
> +extern void ceph_get_fmode(struct ceph_inode_info *ci, int mode, int count);
> +extern void ceph_put_fmode(struct ceph_inode_info *ci, int mode, int count);
> +extern void __ceph_touch_fmode(struct ceph_inode_info *ci,
> + struct ceph_mds_client *mdsc, int fmode);
>
> /* addr.c */
> extern const struct address_space_operations ceph_aops;
> @@ -1086,7 +1096,7 @@ extern void ceph_pool_perm_destroy(struct ceph_mds_client* mdsc);
> /* file.c */
> extern const struct file_operations ceph_file_fops;
>
> -extern int ceph_renew_caps(struct inode *inode);
> +extern int ceph_renew_caps(struct inode *inode, int fmode);
> extern int ceph_open(struct inode *inode, struct file *file);
> extern int ceph_atomic_open(struct inode *dir, struct dentry *dentry,
> struct file *file, unsigned flags, umode_t mode);
> diff --git a/include/linux/ceph/ceph_fs.h b/include/linux/ceph/ceph_fs.h
> index cb21c5cf12c3..8017130a08a1 100644
> --- a/include/linux/ceph/ceph_fs.h
> +++ b/include/linux/ceph/ceph_fs.h
> @@ -564,6 +564,7 @@ struct ceph_filelock {
> #define CEPH_FILE_MODE_RDWR 3 /* RD | WR */
> #define CEPH_FILE_MODE_LAZY 4 /* lazy io */
> #define CEPH_FILE_MODE_BITS 4
> +#define CEPH_FILE_MODE_MASK ((1 << CEPH_FILE_MODE_BITS) - 1)
>
> int ceph_flags_to_mode(int flags);
>
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/2] objtool: clang-related fixes
From: Nick Desaulniers @ 2020-02-20 19:06 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov
Cc: maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), LKML,
Peter Zijlstra, Josh Poimboeuf
In-Reply-To: <cover.1581997059.git.jpoimboe@redhat.com>
Hello, can one of the x86 maintainers please pick up this series? Our
CI has been red *for days* now without it.
On Mon, Feb 17, 2020 at 7:42 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> Fix a couple of issues which were discovered after clang CI was broken
> by 644592d32837 ("objtool: Fail the kernel build on fatal errors").
>
> Josh Poimboeuf (2):
> objtool: Fix clang switch table edge case
> objtool: Improve call destination function detection
>
> tools/objtool/check.c | 38 +++++++++++++++++++++++++++-----------
> tools/objtool/elf.c | 14 ++++++++++++--
> tools/objtool/elf.h | 1 +
> 3 files changed, 40 insertions(+), 13 deletions(-)
>
> --
> 2.21.1
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [MODERATED] Re: [PATCH 2/2] more sampling fun 2
From: Ben Hutchings @ 2020-02-20 19:06 UTC (permalink / raw)
To: speck
In-Reply-To: <c5bae80efe4694c81d9cbbce633a2228086a330c.158215=?utf-8?q?2322?= .git.mgross@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]
On Thu, 2020-01-16 at 14:16 -0800, speck for mark gross wrote:
[...]
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
[...]
> +void srbds_configure_mitigation(void)
> +{
> + u64 mcu_ctrl;
> +
> + if (!boot_cpu_has_bug(X86_BUG_SRBDS) && !boot_cpu_has_bug(X86_BUG_SRBDS_TSX))
> + return;
> +
> + if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL))
> + return;
> +
> + rdmsrl(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
> + if (srbds_mitigation == SRBDS_MITIGATION_FULL)
> + mcu_ctrl &= ~SRBDS_MITG_DIS;
> + else if (srbds_mitigation == SRBDS_MITIGATION_OFF)
> + mcu_ctrl |= SRBDS_MITG_DIS;
> +
> + if (boot_cpu_has_bug(X86_BUG_SRBDS_TSX) && !boot_cpu_has(X86_FEATURE_RTM))
> + mcu_ctrl |= SRBDS_MITG_DIS;
In this case we will incorrectly report "Mitigation: bus lock when
using RDRAND or RDSEED" whereas the actual mitigation is that TSX is
disabled.
> + wrmsrl(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
> +}
[...]
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
[...]
> @@ -1042,6 +1047,19 @@ static const struct x86_cpu_id_ext cpu_vuln_whitelist[] __initconst = {
>
> VULNWL_INTEL(CORE_YONAH, NO_SSB),
>
> + VULNWL_INTEL(IVYBRIDGE, SRBDS), /*06_3A*/
> + VULNWL_INTEL(HASWELL, SRBDS), /*06_3C*/
> + VULNWL_INTEL(HASWELL_L, SRBDS), /*06_45*/
> + VULNWL_INTEL(HASWELL_G, SRBDS), /*06_46*/
> + VULNWL_INTEL(BROADWELL_G, SRBDS), /*06_47*/
> + VULNWL_INTEL(BROADWELL, SRBDS), /*06_3D*/
> + VULNWL_INTEL(SKYLAKE_L, SRBDS), /*06_4E*/
> + VULNWL_INTEL(SKYLAKE, SRBDS), /*06_5E*/
> + VULNWL_INTEL_STEPPING(KABYLAKE_L, (BIT(0xA)-1), SRBDS), /*06_8E steppings <=A*/
But this matches steppings 0-9.
> + VULNWL_INTEL_STEPPING(KABYLAKE_L, BIT(0xB)|BIT(0xC), SRBDS_TSX), /*06_8E stepping = 0xB if TSX enabled*/
> + VULNWL_INTEL_STEPPING(KABYLAKE, (BIT(0xB)-1), SRBDS), /*06_9E steppings <=B*/
And this matches steppings 0-A.
> + VULNWL_INTEL_STEPPING(KABYLAKE, BIT(0xC)|BIT(0xD), SRBDS_TSX), /*06_9E stepping = 0xC if TSX enabled*/
[...]
You should write the bit masks using GENMASK() instead of BIT().
Ben.
--
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [leon-rdma:ethtool 24/30] drivers/net//ethernet/cavium/liquidio/lio_main.c:1421:5: error: 'LIQUIDIO_VERSION' undeclared; did you mean 'LIQUIDIO_BASE_VERSION'?
From: kbuild test robot @ 2020-02-20 19:08 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 7430 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git ethtool
head: 7006debc75a8f4e071cc1ce1b6cdeef54446d00b
commit: b427bead3ee608b0da99b2c69abcb4ae3c4229ff [24/30] net/liquidio: Delete driver version assignment
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 7.5.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b427bead3ee608b0da99b2c69abcb4ae3c4229ff
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=alpha
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from include/linux/device.h:15:0,
from include/linux/pci.h:37,
from drivers/net//ethernet/cavium/liquidio/lio_main.c:20:
drivers/net//ethernet/cavium/liquidio/lio_main.c: In function 'octeon_chip_specific_setup':
>> drivers/net//ethernet/cavium/liquidio/lio_main.c:1421:5: error: 'LIQUIDIO_VERSION' undeclared (first use in this function); did you mean 'LIQUIDIO_BASE_VERSION'?
LIQUIDIO_VERSION);
^
include/linux/dev_printk.h:110:33: note: in definition of macro 'dev_info'
_dev_info(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~
drivers/net//ethernet/cavium/liquidio/lio_main.c:1421:5: note: each undeclared identifier is reported only once for each function it appears in
LIQUIDIO_VERSION);
^
include/linux/dev_printk.h:110:33: note: in definition of macro 'dev_info'
_dev_info(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~
--
In file included from include/linux/device.h:15:0,
from include/linux/pci.h:37,
from drivers/net//ethernet/cavium/liquidio/lio_vf_main.c:20:
drivers/net//ethernet/cavium/liquidio/lio_vf_main.c: In function 'octeon_device_init':
>> drivers/net//ethernet/cavium/liquidio/lio_vf_main.c:2355:4: error: 'LIQUIDIO_VERSION' undeclared (first use in this function); did you mean 'LIQUIDIO_BASE_VERSION'?
LIQUIDIO_VERSION, oct->sriov_info.rings_per_vf);
^
include/linux/dev_printk.h:110:33: note: in definition of macro 'dev_info'
_dev_info(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~
drivers/net//ethernet/cavium/liquidio/lio_vf_main.c:2355:4: note: each undeclared identifier is reported only once for each function it appears in
LIQUIDIO_VERSION, oct->sriov_info.rings_per_vf);
^
include/linux/dev_printk.h:110:33: note: in definition of macro 'dev_info'
_dev_info(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~
vim +1421 drivers/net//ethernet/cavium/liquidio/lio_main.c
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1369
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1370 /**
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1371 * \brief Identify the Octeon device and to map the BAR address space
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1372 * @param oct octeon device
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1373 */
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1374 static int octeon_chip_specific_setup(struct octeon_device *oct)
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1375 {
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1376 u32 dev_id, rev_id;
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1377 int ret = 1;
d3d7e6c65f75de Raghu Vatsavayi 2016-06-21 1378 char *s;
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1379
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1380 pci_read_config_dword(oct->pci_dev, 0, &dev_id);
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1381 pci_read_config_dword(oct->pci_dev, 8, &rev_id);
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1382 oct->rev_id = rev_id & 0xff;
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1383
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1384 switch (dev_id) {
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1385 case OCTEON_CN68XX_PCIID:
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1386 oct->chip_id = OCTEON_CN68XX;
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1387 ret = lio_setup_cn68xx_octeon_device(oct);
d3d7e6c65f75de Raghu Vatsavayi 2016-06-21 1388 s = "CN68XX";
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1389 break;
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1390
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1391 case OCTEON_CN66XX_PCIID:
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1392 oct->chip_id = OCTEON_CN66XX;
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1393 ret = lio_setup_cn66xx_octeon_device(oct);
d3d7e6c65f75de Raghu Vatsavayi 2016-06-21 1394 s = "CN66XX";
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1395 break;
d3d7e6c65f75de Raghu Vatsavayi 2016-06-21 1396
72c0091293c008 Raghu Vatsavayi 2016-08-31 1397 case OCTEON_CN23XX_PCIID_PF:
72c0091293c008 Raghu Vatsavayi 2016-08-31 1398 oct->chip_id = OCTEON_CN23XX_PF_VID;
72c0091293c008 Raghu Vatsavayi 2016-08-31 1399 ret = setup_cn23xx_octeon_pf_device(oct);
0c45d7fe12c7e1 Rick Farrington 2017-08-18 1400 if (ret)
0c45d7fe12c7e1 Rick Farrington 2017-08-18 1401 break;
cf19a8c3d515d8 Derek Chickles 2017-08-01 1402 #ifdef CONFIG_PCI_IOV
cf19a8c3d515d8 Derek Chickles 2017-08-01 1403 if (!ret)
cf19a8c3d515d8 Derek Chickles 2017-08-01 1404 pci_sriov_set_totalvfs(oct->pci_dev,
cf19a8c3d515d8 Derek Chickles 2017-08-01 1405 oct->sriov_info.max_vfs);
cf19a8c3d515d8 Derek Chickles 2017-08-01 1406 #endif
72c0091293c008 Raghu Vatsavayi 2016-08-31 1407 s = "CN23XX";
72c0091293c008 Raghu Vatsavayi 2016-08-31 1408 break;
72c0091293c008 Raghu Vatsavayi 2016-08-31 1409
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1410 default:
d3d7e6c65f75de Raghu Vatsavayi 2016-06-21 1411 s = "?";
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1412 dev_err(&oct->pci_dev->dev, "Unknown device found (dev_id: %x)\n",
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1413 dev_id);
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1414 }
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1415
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1416 if (!ret)
d3d7e6c65f75de Raghu Vatsavayi 2016-06-21 1417 dev_info(&oct->pci_dev->dev, "%s PASS%d.%d %s Version: %s\n", s,
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1418 OCTEON_MAJOR_REV(oct),
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1419 OCTEON_MINOR_REV(oct),
d3d7e6c65f75de Raghu Vatsavayi 2016-06-21 1420 octeon_get_conf(oct)->card_name,
d3d7e6c65f75de Raghu Vatsavayi 2016-06-21 @1421 LIQUIDIO_VERSION);
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1422
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1423 return ret;
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1424 }
f21fb3ed364bb8 Raghu Vatsavayi 2015-06-09 1425
:::::: The code at line 1421 was first introduced by commit
:::::: d3d7e6c65f75de18ced10a98595a847f9f95f0ce liquidio: Firmware image download
:::::: TO: Raghu Vatsavayi <rvatsavayi@caviumnetworks.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
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: 60189 bytes --]
^ permalink raw reply
* [zeus/master][PATCH 1/4] sgx-um, rogue-umlibs, gc320-libs: RRECOMMENDS on corresponding drivers
From: Denys Dmytriyenko @ 2020-02-20 18:47 UTC (permalink / raw)
To: meta-ti; +Cc: Denys Dmytriyenko
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
recipes-graphics/libgal/ti-gc320-libs_5.0.11.p7.bb | 2 ++
recipes-graphics/libgles/ti-img-rogue-umlibs_1.10.5371573.bb | 4 +++-
recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb | 2 ++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/recipes-graphics/libgal/ti-gc320-libs_5.0.11.p7.bb b/recipes-graphics/libgal/ti-gc320-libs_5.0.11.p7.bb
index e8c2f011..d6ecd229 100644
--- a/recipes-graphics/libgal/ti-gc320-libs_5.0.11.p7.bb
+++ b/recipes-graphics/libgal/ti-gc320-libs_5.0.11.p7.bb
@@ -12,6 +12,8 @@ BRANCH = "ti-${PV}"
SRC_URI = "git://git.ti.com/graphics/ti-gc320-libs.git;protocol=git;branch=${BRANCH}"
SRCREV = "c0afab259de59909cfe74c01f3f7fbaa147f94b5"
+RRECOMMENDS_${PN} = "ti-gc320-driver"
+
# There's only hardfp version available
python __anonymous() {
tunes = d.getVar("TUNE_FEATURES")
diff --git a/recipes-graphics/libgles/ti-img-rogue-umlibs_1.10.5371573.bb b/recipes-graphics/libgles/ti-img-rogue-umlibs_1.10.5371573.bb
index 9cb863a5..67290756 100644
--- a/recipes-graphics/libgles/ti-img-rogue-umlibs_1.10.5371573.bb
+++ b/recipes-graphics/libgles/ti-img-rogue-umlibs_1.10.5371573.bb
@@ -27,7 +27,7 @@ PROVIDES += "virtual/egl virtual/libgles1 virtual/libgles2 virtual/libgbm"
DEPENDS += "libdrm wayland expat"
RDEPENDS_${PN} += "bash"
RDEPENDS_${PN} += "python-core"
-RDEPENDS_${PN} += "ti-img-rogue-driver wayland expat"
+RDEPENDS_${PN} += "wayland expat"
RPROVIDES_${PN} = "libegl libgles1 libgles2 libgbm"
RPROVIDES_${PN}-dev = "libegl-dev libgles1-dev libgles2-dev libgbm-dev"
@@ -41,6 +41,8 @@ RCONFLICTS_${PN} = "libegl libgles1 libgles2 libgbm"
RCONFLICTS_${PN}-dev = "libegl-dev libgles1-dev libgles2-dev libgbm-dev"
RCONFLICTS_${PN}-dbg = "libegl-dbg libgles1-dbg libgles2-dbg"
+RRECOMMENDS_${PN} += "ti-img-rogue-driver"
+
S = "${WORKDIR}/git"
do_install () {
diff --git a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
index ecf3ffcc..8b0b3058 100644
--- a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
+++ b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
@@ -43,6 +43,8 @@ RCONFLICTS_${PN}-dbg = "libegl-dbg libgles1-dbg libgles2-dbg libgbm-dbg"
# The actual SONAME is libGLESv2.so.2, so need to explicitly specify RPROVIDES for .so.1 here
RPROVIDES_${PN} += "libGLESv2.so.1"
+RRECOMMENDS_${PN} += "ti-sgx-ddk-km"
+
S = "${WORKDIR}/git"
do_install () {
--
2.17.1
^ permalink raw reply related
* [zeus/master][PATCH 4/4] layer.conf: drop ti-ipc from SIGGEN_EXCLUDERECIPES_ABISAFE for now
From: Denys Dmytriyenko @ 2020-02-20 18:47 UTC (permalink / raw)
To: meta-ti; +Cc: Denys Dmytriyenko
In-Reply-To: <20200220184722.25828-1-denys@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
conf/layer.conf | 2 --
1 file changed, 2 deletions(-)
diff --git a/conf/layer.conf b/conf/layer.conf
index 824443d4..d82b2384 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -17,8 +17,6 @@ LAYERDEPENDS_meta-ti = "core"
SIGGEN_EXCLUDERECIPES_ABISAFE += " \
ti-sgx-ddk-km \
ti-sgx-ddk-um \
- ti-ipc \
- ti-ipc-rtos \
cmem-mod \
hplib-mod \
gdbserverproxy-module-drv \
--
2.17.1
^ permalink raw reply related
* [zeus/master][PATCH 3/4] vis: mark as compatible with dra7xx family
From: Denys Dmytriyenko @ 2020-02-20 18:47 UTC (permalink / raw)
To: meta-ti; +Cc: Denys Dmytriyenko
In-Reply-To: <20200220184722.25828-1-denys@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
recipes-bsp/vis-fw/vis_01.50.07.15.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-bsp/vis-fw/vis_01.50.07.15.bb b/recipes-bsp/vis-fw/vis_01.50.07.15.bb
index 5b9834c2..6eaf8de7 100644
--- a/recipes-bsp/vis-fw/vis_01.50.07.15.bb
+++ b/recipes-bsp/vis-fw/vis_01.50.07.15.bb
@@ -2,12 +2,12 @@ DESCRIPTION = "Radio Application Firmware"
LICENSE = "TI-TSPA"
LIC_FILES_CHKSUM = "file://${S}/J6_VIS_DEMO_LINUX_BINARY_01.50.07.15-Manifest.html;md5=a59aa54b9470f555cf086b91dca0afa3"
-COMPATIBLE_MACHINE = "dra7xx-evm"
+COMPATIBLE_MACHINE = "dra7xx"
PACKAGE_ARCH = "${MACHINE_ARCH}"
PR = "r1"
-SRC_URI = "http://downloads.ti.com/dsps/dsps_public_sw/glsdk/vis/01_50_07_15/exports/vis-${MACHINE}-01.50.07.15.tar.gz;protocol=http"
+SRC_URI = "http://downloads.ti.com/dsps/dsps_public_sw/glsdk/vis/01_50_07_15/exports/vis-dra7xx-evm-01.50.07.15.tar.gz;protocol=http"
SRC_URI[md5sum] = "fe8b00e398fb3b7ada0c15b601867acb"
SRC_URI[sha256sum] = "6e2aa47ae892910616ebdc96646af778af9a59ca0657716ab4fa4b24a9afae69"
--
2.17.1
^ permalink raw reply related
* [zeus/master][PATCH 2/4] omap-a15: add gc320 machine feature
From: Denys Dmytriyenko @ 2020-02-20 18:47 UTC (permalink / raw)
To: meta-ti; +Cc: Denys Dmytriyenko
In-Reply-To: <20200220184722.25828-1-denys@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
conf/machine/include/omap-a15.inc | 2 +-
recipes-graphics/libgal/ti-gc320-libs_5.0.11.p7.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/conf/machine/include/omap-a15.inc b/conf/machine/include/omap-a15.inc
index cc055365..a220828a 100644
--- a/conf/machine/include/omap-a15.inc
+++ b/conf/machine/include/omap-a15.inc
@@ -36,4 +36,4 @@ MACHINE_GUI_CLASS = "smallscreen"
UBI_VOLNAME = "rootfs"
# List common SoC features, may need to add touchscreen for specific machines
-MACHINE_FEATURES = "kernel26 apm usbgadget usbhost vfat ext2 screen alsa ethernet gpu mmip dsp"
+MACHINE_FEATURES = "kernel26 apm usbgadget usbhost vfat ext2 screen alsa ethernet gpu mmip dsp gc320"
diff --git a/recipes-graphics/libgal/ti-gc320-libs_5.0.11.p7.bb b/recipes-graphics/libgal/ti-gc320-libs_5.0.11.p7.bb
index d6ecd229..9487e724 100644
--- a/recipes-graphics/libgal/ti-gc320-libs_5.0.11.p7.bb
+++ b/recipes-graphics/libgal/ti-gc320-libs_5.0.11.p7.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "https://git.ti.com/graphics/ti-gc320-libs"
LICENSE = "TI-TSPA"
LIC_FILES_CHKSUM = "file://Manifest.html;md5=a9121e8936ace09820d23f7626daaca5"
-COMPATIBLE_MACHINE = "dra7xx"
+COMPATIBLE_MACHINE = "omap-a15"
CLEANBROKEN = "1"
--
2.17.1
^ permalink raw reply related
* [MODERATED] Re: [PATCH 1/2] more sampling fun 1
From: Ben Hutchings @ 2020-02-20 19:08 UTC (permalink / raw)
To: speck
In-Reply-To: <c79feecdb14c62e3dd8f2680bc68292f99882aeb.158215=?utf-8?q?2322?= .git.mgross@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
On Thu, 2020-02-06 at 14:11 -0800, speck for mark gross wrote:
> From: mark gross <mgross@linux.intel.com>
> Subject: [PATCH 1/2] Add capability to specify a range of steppings in the
[...]
> --- a/arch/x86/include/asm/cpu_device_id.h
> +++ b/arch/x86/include/asm/cpu_device_id.h
> @@ -35,7 +35,19 @@ struct x86_cpu_desc {
> .x86_microcode_rev = (revision), \
> }
>
> +/*
> + * Match a range of steppings
> + */
> +
> +struct x86_cpu_id_ext {
> + struct x86_cpu_id id;
> + __u16 steppings; /* bit map of steppings to match against */
> +};
> +
> +#define X86_STEPPING_ANY 0
[...]
Minor point, but wouldn't it make more sense to define X86_STEPPING_ANY
as GENMASK(15, 0)? Then it's no longer a special case.
Ben.
--
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/3] mtd: spi-nor: add 4bit block protection support
From: Michael Walle @ 2020-02-20 19:09 UTC (permalink / raw)
To: Jungseung Lee; +Cc: js07.lee, linux-mtd, vigneshr, Tudor.Ambarus
In-Reply-To: <ed9ae10ab3be4da90779cb6f8d6c6cf1e9fbc968.camel@samsung.com>
Am 2020-02-19 11:50, schrieb Jungseung Lee:
> Hi, Tudor and all
>
> 2020-02-10 (Mon), 11:26 +0000, Tudor.Ambarus@microchip.com:
>> On Monday, February 10, 2020 12:29:34 PM EET Michael Walle wrote:
>> > > It's bytes. Take a look at W25Q128JV. The sector size for this
>> > > flash is
>> > > 64KByte. The flash has 256 sectors. For this specific case:
>> > > bp_slots_available = 6;
>> > > bp_slots_needed = 8;
>> > >
>> > > The if condition is true, so
>> > > bp_slot_count = 6;
>> > > bp_min_slot_size = 64k << (8 - 6); //256k
>> >
>> > But nor->info->n_sectors is not 64k, its 256. Do you mean
>> > sector_size
>> > (like in
>> > my example below? Then we are on the same page
>>
>> Indeed, there is a typo in the pseudo code; I'm happy that the
>> example is
>> correct at least. I meant sector_size, not sectors. Now we should
>> exercise the
>> logic to all the known (corner) cases. Maybe Jungseung will tell us
>> if he
>> spots a flaw in the overall logic.
>>
>
> I didn't find any flaw in this logic. But IMHO for the pseudo code.
>
> bp_slots_available = (bp_mask >> shift) + 1 - 2;
> bp_slots_needed = ilog2(nor->info->n_sectors);
>
> if (bp_slots_needed > bp_slots_available) {
> bp_slot_count = bp_slots_available;
> bp_min_slot_size = nor->info->sector_size <<
> (bp_slots_needed - bp_slots_available);
> } else {
> bp_slot_count = bp_slots_needed;
> bp_min_slot_size = mtd->size >> bp_slot_count;
> }
>
> Probably we can use directly nor->info->sector_size for bp_min_slot_
> size.
>
> sector_size x n_sectors = mtd->size
> mtd->size / n_sectors = mtd->size >>
> ilog2(n_sectors) = sector_size
>
> bp_slot_count is equal to log2(n_sectors) now so if we can trust the
> value, we can also trust sector_size.
>
> After change it,
>
> if (bp_slots_needed > bp_slots_available)
> bp_min_slot_size = nor->info->sector_size <<
> (bp_slots_needed - bp_slots_available);
> else
> bp_min_slot_size = nor->info->sector_size
Yes, thats what I pointed out in my previous mail, too. So I guess we
agree on that.
> This is a comment from my previous mail.
>> > The exact fact is that locks operate in two different ways
>> > according to flash model.
>> >
>> > (1) the smallest protected portion is fixed.
>> > for BP0-2 : 1/64
>> > for BP0-1 : 1/4
>> > (2) the smallest protected portion is inversely propotional with
>> > number of sectors.
Again. please don't consider the ratio of the protected area to the
flash size.
This is only the result of applying the sector size and IMHO really bad
for
understanding. Use the number of protected sectors. Thus your (2) is
actually
always one sector (as you've already pointed out above).
> (1) - if the slot is insufficient.
> (2) - if the slot is sufficient.
>
> From the fact, that could be rewritten like below. I think it's more
> intuitive one.
>
> if (bp_slots_needed > bp_slots_available) // (1)
> bp_min_slot_size = mtd->size >> bp_slots_available;
Given the reasoning above, I'd prefer having the number of sectors and
thus
the sector_size. Eg. keep the following
bp_min_slot_size = nor->info->sector_size <<
(bp_slots_needed - bp_slots_available);
> else // (2)
> bp_min_slot_size = nor->info->sector_size;
>
> We could also find a few flashes that does not following the overall
> logic. For example, "en25qh256" and "en25qh16" which was manufactured
> by EON. They are always following way (2) no matter what the number of
> slot is. It seems that it could be handled like below with custom hook
> later.
>
> if (bp_slots_needed < bp_slots_available || force)
For the en25qh16 the "bp_slots_needed < bp_slots_available" is already
true, isn't it?
But good catch for the en25qh256. IMHO the rework of the BP bits should
already
add a flag (together with a reference to this flash) so this information
is not lost. what about sth like MIN_LOCK_SIZE_IS_ONE_SECTOR.
-michael
> bp_min_slot_size = nor->info->sector_size;
> else
> bp_min_slot_size = mtd->size >> bp_slots_available;
>
>> Cheers,
>> ta
>>
>
> Thanks,
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [tip: core/objtool] objtool: Fail the kernel build on fatal errors
From: Nick Desaulniers @ 2020-02-20 19:09 UTC (permalink / raw)
To: Philip Li; +Cc: Chen Rong, clang-built-linux
In-Reply-To: <20200220004434.GA5687@intel.com>
(everyone else to bcc)
On Wed, Feb 19, 2020 at 4:44 PM Philip Li <philip.li@intel.com> wrote:
>
> On Wed, Feb 19, 2020 at 02:43:39PM -0800, Nick Desaulniers wrote:
> > On Fri, Feb 14, 2020 at 9:58 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> > >
> > > On Fri, Feb 14, 2020 at 01:10:26AM +0100, Thomas Gleixner wrote:
> > > > Josh Poimboeuf <jpoimboe@redhat.com> writes:
> > > > > On Tue, Feb 11, 2020 at 12:47:38PM -0000, tip-bot2 for Josh Poimboeuf wrote:
> > > > >> The following commit has been merged into the core/objtool branch of tip:
> > > > >>
> > > > >> Commit-ID: 644592d328370af4b3e027b7b1ae9f81613782d8
> > > > >> Gitweb: https://git.kernel.org/tip/644592d328370af4b3e027b7b1ae9f81613782d8
> > > > >> Author: Josh Poimboeuf <jpoimboe@redhat.com>
> > > > >> AuthorDate: Mon, 10 Feb 2020 12:32:38 -06:00
> > > > >> Committer: Borislav Petkov <bp@suse.de>
> > > > >> CommitterDate: Tue, 11 Feb 2020 13:27:03 +01:00
> > > > >>
> > > > >> objtool: Fail the kernel build on fatal errors
> > > > >>
> > > > >> When objtool encounters a fatal error, it usually means the binary is
> > > > >> corrupt or otherwise broken in some way. Up until now, such errors were
> > > > >> just treated as warnings which didn't fail the kernel build.
> > > > >>
> > > > >> However, objtool is now stable enough that if a fatal error is
> > > > >> discovered, it most likely means something is seriously wrong and it
> > > > >> should fail the kernel build.
> > > > >>
> > > > >> Note that this doesn't apply to "normal" objtool warnings; only fatal
> > > > >> ones.
> > > > >
> > > > > Clang still has some toolchain issues which need to be sorted out, so
> > > > > upgrading the fatal errors is causing their CI to fail.
> > > >
> > > > Good. Last time we made it fail they just fixed their stuff.
> > > >
> > > > > So I think we need to drop this one for now.
> > > >
> > > > Why? It's our decision to define which level of toolchain brokeness is
> > > > tolerable.
> > > >
> > > > > Boris, are you able to just drop it or should I send a revert?
> > > >
> > > > I really want to see a revert which has a proper justification why the
> > > > issues of clang are tolerable along with a clear statement when this
> > > > fatal error will come back. And 'when' means a date, not 'when clang is
> > > > fixed'.
> > >
> > > Fair enough. The root cause was actually a bug in binutils which gets
> > > triggered by a new clang feature. So instead of reverting the above
> > > patch, I think I've figured out a way to work around the binutils bug,
> > > while also improving objtool at the same time (win-win).
> > >
> > > The binutils bug will be fixed in binutils 2.35.
> > >
> > > BTW, to be fair, this was less "Clang has issues" and more "Josh is
> > > lazy". I didn't test the patch with Clang -- I tend to rely on 0-day
> > > bot reports because I don't have the bandwidth to test the
> > > kernel/config/toolchain combinations. Nick tells me Clang will soon be
> > > integrated with the 0-day bot, which should help prevent this type of
> > > thing in the future.
> >
> > Hi Rong, Philip,
> > Do you have any status updates on turning on the 0day bot emails to
> > the patch authors in production? It's been quite handy in helping us
> > find issues, for the private mails we've been triaging daily.
> Hi Nick, this is on our schedule in a new 2-3 weeks, sorry not to update
> your in another mail loop earlier.
No worries.
>
> What I plan to do is to cc you for the clang reports when 0-day ci sends
> to kernel patch author. If you notice something may be related to clang (since
> we always integrate newer clang version), you can help filter it out. How
> do you think?
If you would kindly cc our mailing list "clang-built-linux
<clang-built-linux@googlegroups.com>" we'd be happy to continue to
triage and provide suggestions. That level of indirection better
allows us to deal with subscriptions and change of email addresses
without having to disturb you.
--
Thanks,
~Nick Desaulniers
^ 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.