* [PATCH] drm/exynos: dsi: fix workaround for the legacy clock name
From: Marek Szyprowski @ 2020-02-20 12:30 UTC (permalink / raw)
To: dri-devel, linux-samsung-soc
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Seung-Woo Kim,
Marek Szyprowski
In-Reply-To: <CGME20200220123022eucas1p21d015e2880680ae1c16e4b2a1d0ebb18@eucas1p2.samsung.com>
Writing to the built-in strings arrays doesn't work if driver is loaded
as kernel module. This is also considered as a bad pattern. Fix this by
adding a call to clk_get() with legacy clock name. This fixes following
kernel oops if driver is loaded as module:
Unable to handle kernel paging request at virtual address bf047978
pgd = (ptrval)
[bf047978] *pgd=59344811, *pte=5903c6df, *ppte=5903c65f
Internal error: Oops: 80f [#1] SMP ARM
Modules linked in: mc exynosdrm(+) analogix_dp rtc_s3c exynos_ppmu i2c_gpio
CPU: 1 PID: 212 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200219 #326
videodev: Linux video capture interface: v2.00
Hardware name: Samsung Exynos (Flattened Device Tree)
PC is at exynos_dsi_probe+0x1f0/0x384 [exynosdrm]
LR is at exynos_dsi_probe+0x1dc/0x384 [exynosdrm]
...
Process systemd-udevd (pid: 212, stack limit = 0x(ptrval))
...
[<bf03cf14>] (exynos_dsi_probe [exynosdrm]) from [<c09b1ca0>] (platform_drv_probe+0x6c/0xa4)
[<c09b1ca0>] (platform_drv_probe) from [<c09afcb8>] (really_probe+0x210/0x350)
[<c09afcb8>] (really_probe) from [<c09aff74>] (driver_probe_device+0x60/0x1a0)
[<c09aff74>] (driver_probe_device) from [<c09b0254>] (device_driver_attach+0x58/0x60)
[<c09b0254>] (device_driver_attach) from [<c09b02dc>] (__driver_attach+0x80/0xbc)
[<c09b02dc>] (__driver_attach) from [<c09ade00>] (bus_for_each_dev+0x68/0xb4)
[<c09ade00>] (bus_for_each_dev) from [<c09aefd8>] (bus_add_driver+0x130/0x1e8)
[<c09aefd8>] (bus_add_driver) from [<c09b0d64>] (driver_register+0x78/0x110)
[<c09b0d64>] (driver_register) from [<bf038558>] (exynos_drm_init+0xe8/0x11c [exynosdrm])
[<bf038558>] (exynos_drm_init [exynosdrm]) from [<c0302fa8>] (do_one_initcall+0x50/0x220)
[<c0302fa8>] (do_one_initcall) from [<c03dd02c>] (do_init_module+0x60/0x210)
[<c03dd02c>] (do_init_module) from [<c03dbf44>] (load_module+0x1c0c/0x2310)
[<c03dbf44>] (load_module) from [<c03dc85c>] (sys_finit_module+0xac/0xbc)
[<c03dc85c>] (sys_finit_module) from [<c0301000>] (ret_fast_syscall+0x0/0x54)
Exception stack(0xd979bfa8 to 0xd979bff0)
...
---[ end trace db16efe05faab470 ]---
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 33628d85edad..08a8ce3f499c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1787,9 +1787,10 @@ static int exynos_dsi_probe(struct platform_device *pdev)
dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
if (IS_ERR(dsi->clks[i])) {
if (strcmp(clk_names[i], "sclk_mipi") == 0) {
- strcpy(clk_names[i], OLD_SCLK_MIPI_CLK_NAME);
- i--;
- continue;
+ dsi->clks[i] = devm_clk_get(dev,
+ OLD_SCLK_MIPI_CLK_NAME);
+ if (!IS_ERR(dsi->clks[i]))
+ continue;
}
dev_info(dev, "failed to get the clock: %s\n",
--
2.17.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [Bug 1823790] Re: QEMU mishandling of SO_PEERSEC forces systemd into tight loop
From: Laurent Vivier @ 2020-02-20 12:21 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <155475569461.20468.17957138207618410360.malonedeb@chaenomeles.canonical.com>
This seems to be the error reported in
https://bugs.launchpad.net/qemu/+bug/1857811
** Changed in: qemu
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Title:
QEMU mishandling of SO_PEERSEC forces systemd into tight loop
Status in QEMU:
Fix Committed
Bug description:
While building Debian images for embedded ARM target systems I
detected that QEMU seems to force newer systemd daemons into a tight
loop.
My setup is the following:
Host machine: Ubuntu 18.04, amd64
LXD container: Debian Buster, arm64, systemd 241
QEMU: qemu-aarch64-static, 4.0.0-rc2 (custom build) and 3.1.0 (Debian 1:3.1+dfsg-7)
To easily reproduce the issue I have created the following repository:
https://github.com/lueschem/edi-qemu
The call where systemd gets looping is the following:
2837 getsockopt(3,1,31,274891889456,274887218756,274888927920) = -1 errno=34 (Numerical result out of range)
Furthermore I also verified that the issue is not related to LXD.
The same behavior can be reproduced using systemd-nspawn.
This issue reported against systemd seems to be related:
https://github.com/systemd/systemd/issues/11557
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1823790/+subscriptions
^ permalink raw reply
* Re: [dpdk-dev] [dpdk-stable] [PATCH] app/testpmd: fix identifier size for port attach
From: Wisam Monther @ 2020-02-20 12:32 UTC (permalink / raw)
To: Ferruh Yigit, wenzhuo.lu@intel.com, dev@dpdk.org,
Raslan Darawsheh, Matan Azrad
Cc: mukawa@igel.co.jp, stable@dpdk.org
In-Reply-To: <d61a7452-f542-f0fc-f046-efd98dfdadc0@intel.com>
When attaching new device, it needs to pass the white list options with the PCI,
For example if I want the following set of options with the new attach device it will fail
Due to not enough space:
port attach 0000:03:00.0,l3_vxlan_en=1,txq_inline_mpw=77,dv_xmeta_en=1,txqs_min_inline=0,dv_esw_en=1,dv_flow_en=1,txq_inline_min=28,txq_inline_max=65
-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@intel.com>
Sent: Thursday, February 20, 2020 2:28 PM
To: Wisam Monther <wisamm@mellanox.com>; wenzhuo.lu@intel.com; dev@dpdk.org; Raslan Darawsheh <rasland@mellanox.com>; Matan Azrad <matan@mellanox.com>
Cc: mukawa@igel.co.jp; stable@dpdk.org
Subject: Re: [dpdk-stable] [PATCH] app/testpmd: fix identifier size for port attach
On 2/19/2020 4:47 PM, Wisam Jaddo wrote:
> Identifier for new port may contain white list options, and white list
> options will not fit into 128 from STR_TOKEN_SIZE, instead having 4096
> char from STR_MULTI_TOKEN_SIZE will provide better and more options
Out of curiosity, what device identifier doesn't fit to 128 chars, can you please give a sample?
>
> Fixes: edab33b1c01d ("app/testpmd: support port hotplug")
> Cc: mukawa@igel.co.jp
> Cc: stable@dpdk.org
>
> Signed-off-by: Wisam Jaddo <wisamm@mellanox.com>
> ---
> app/test-pmd/cmdline.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> 38b6d80..a037a55 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -1446,7 +1446,7 @@ cmdline_parse_inst_t cmd_set_port_setup_on = {
> struct cmd_operate_attach_port_result {
> cmdline_fixed_string_t port;
> cmdline_fixed_string_t keyword;
> - cmdline_fixed_string_t identifier;
> + cmdline_multi_string_t identifier;
> };
>
> static void cmd_operate_attach_port_parsed(void *parsed_result, @@
> -1469,7 +1469,7 @@ cmdline_parse_token_string_t cmd_operate_attach_port_keyword =
> keyword, "attach");
> cmdline_parse_token_string_t cmd_operate_attach_port_identifier =
> TOKEN_STRING_INITIALIZER(struct cmd_operate_attach_port_result,
> - identifier, NULL);
> + identifier, TOKEN_STRING_MULTI);
>
> cmdline_parse_inst_t cmd_operate_attach_port = {
> .f = cmd_operate_attach_port_parsed,
>
^ permalink raw reply
* Re: [PATCH 4/4] crypto: hisilicon/sec2 - Add pbuffer mode for SEC driver
From: Xu Zaibo @ 2020-02-20 12:32 UTC (permalink / raw)
To: John Garry, herbert, davem
Cc: qianweili, tanghui20, forest.zhouchang, linuxarm, zhangwei375,
shenyang39, yekai13, linux-crypto
In-Reply-To: <07f82b86-fa3a-c4e5-f4bc-f12c4dbefd09@huawei.com>
On 2020/2/20 20:20, John Garry wrote:
> On 20/02/2020 12:16, Xu Zaibo wrote:
>>
>> On 2020/2/20 19:07, John Garry wrote:
>>> On 20/02/2020 10:10, Xu Zaibo wrote:
>>>> Hi,
>>>>
>>>>
>>>> On 2020/2/20 17:50, John Garry wrote:
>>>>> On 20/02/2020 09:04, Zaibo Xu wrote:
>>>>>> From: liulongfang <liulongfang@huawei.com>
>>>>>>
>>>>>> In the scenario of SMMU translation, the SEC performance of short
>>>>>> messages
>>>>>> (<512Bytes) cannot meet our expectations. To avoid this, we
>>>>>> reserve the
>>>>>> plat buffer (PBUF) memory for small packets when creating TFM.
>>>>>>
>>>>>
>>>>> I haven't gone through the code here, but why not use this method
>>>>> also for non-translated? What are the pros and cons?
>>>> Because non-translated has no performance or throughput problems.
>>>>
>>>
>>> OK, so no problem, but I was asking could it be improved, and, if
>>> so, what would be the drawbacks?
>>>
>>> As for the change to check if the IOMMU is translating, it seems
>>> exact same as that for the hi1616 driver...
>>>
>> Currently, I find the only drawback is needing more memory :),
>
> OK, so that is a drawback.
>
>> what's your idea?
>
> I am just asking if we get any performance gain for using this same
> method for non-IOMMU case, and does the gain (if any) in performance
> outweigh the additional memory usage?
Sorry for my misunderstanding. As our testing, no gain for no-iommu
case, because of memory copy.
>
>> Yes, the same as SEC V1.
>
> So it could be factored out :)
It is a good idea. However, now SEC V1 and V2 are in different
directories, more, this checking logic is quite simple.
And for our HPRE and ZIP, there is no performance or throughput problem
as IOMMU on.
Cheers,
Zaibo
.
>
> thanks,
> john
> .
>
^ permalink raw reply
* Re: [PATCH v5 3/5] iio: amplifiers: hmc425a: Add support for HMC425A attenuator
From: Bia, Beniamin @ 2020-02-20 12:32 UTC (permalink / raw)
To: jic23@kernel.org
Cc: biabeniamin@outlook.com, lars@metafoo.de,
linux-kernel@vger.kernel.org, knaack.h@gmx.de,
Ardelean, Alexandru, robh+dt@kernel.org,
devicetree@vger.kernel.org, Hennerich, Michael,
linux-iio@vger.kernel.org, mark.rutland@arm.com,
pmeerw@pmeerw.net
In-Reply-To: <20200214140959.528a546e@archlinux>
Hi,
I checked the modifications and everything works as expected.
Thanks,
Ben
On Fri, 2020-02-14 at 14:09 +0000, Jonathan Cameron wrote:
> [External]
>
> On Thu, 6 Feb 2020 17:11:47 +0200
> Beniamin Bia <beniamin.bia@analog.com> wrote:
>
> > This patch adds support for the HMC425A 0.5 dB LSB GaAs MMIC 6-BIT
> > DIGITAL POSITIVE CONTROL ATTENUATOR, 2.2 - 8.0 GHz.
> >
> > Datasheet:
> >
https://www.analog.com/media/en/technical-documentation/data-sheets/hmc425A.pdf
> >
> > Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
>
> 2 things left in here. I'll have a go at fixing them up to save us
> going
> to v6 but please take a look at the result and check I haven't broken
> anything!
>
> Applied to the togreg branch of iio.git and pushed out as testing for
> the autobuilders to have a play with it.
>
> Thanks,
>
> Jonathan
>
> > ---
> > Changes in v5:
> > -properties in HMC425A_CHAN on separate lines
> > -of_device_get_match instead of of_match_device
> >
> > drivers/iio/amplifiers/Kconfig | 10 ++
> > drivers/iio/amplifiers/Makefile | 1 +
> > drivers/iio/amplifiers/hmc425a.c | 253
> > +++++++++++++++++++++++++++++++
> > 3 files changed, 264 insertions(+)
> > create mode 100644 drivers/iio/amplifiers/hmc425a.c
> >
> > diff --git a/drivers/iio/amplifiers/Kconfig
> > b/drivers/iio/amplifiers/Kconfig
> > index da7f126d197b..9b02c9a2bc8a 100644
> > --- a/drivers/iio/amplifiers/Kconfig
> > +++ b/drivers/iio/amplifiers/Kconfig
> > @@ -22,4 +22,14 @@ config AD8366
> > To compile this driver as a module, choose M here: the
> > module will be called ad8366.
> >
> > +config HMC425
> > + tristate "Analog Devices HMC425A and similar GPIO Gain
> > Amplifiers"
> > + depends on GPIOLIB
> > + help
> > + Say yes here to build support for Analog Devices HMC425A and
> > similar
> > + gain amplifiers or step attenuators.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called hmc425a.
> > +
> > endmenu
> > diff --git a/drivers/iio/amplifiers/Makefile
> > b/drivers/iio/amplifiers/Makefile
> > index 9abef2ebe9bc..19a89db1d9b1 100644
> > --- a/drivers/iio/amplifiers/Makefile
> > +++ b/drivers/iio/amplifiers/Makefile
> > @@ -5,3 +5,4 @@
> >
> > # When adding new entries keep the list in alphabetical order
> > obj-$(CONFIG_AD8366) += ad8366.o
> > +obj-$(CONFIG_HMC425) += hmc425a.o
> > \ No newline at end of file
>
> I'll fix the no newline..
>
> > diff --git a/drivers/iio/amplifiers/hmc425a.c
> > b/drivers/iio/amplifiers/hmc425a.c
> > new file mode 100644
> > index 000000000000..b0d624a7ad05
> > --- /dev/null
> > +++ b/drivers/iio/amplifiers/hmc425a.c
> > @@ -0,0 +1,253 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * HMC425A and similar Gain Amplifiers
> > + *
> > + * Copyright 2020 Analog Devices Inc.
> > + */
> > +
> > +#include <linux/device.h>
> > +#include <linux/err.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/iio/iio.h>
> > +#include <linux/iio/sysfs.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/sysfs.h>
> > +
> > +enum hmc425a_type {
> > + ID_HMC425A,
> > +};
> > +
> > +struct hmc425a_chip_info {
> > + const char *name;
> > + const struct iio_chan_spec *channels;
> > + unsigned int num_channels;
> > + unsigned int num_gpios;
> > + int gain_min;
> > + int gain_max;
> > + int default_gain;
> > +};
> > +
> > +struct hmc425a_state {
> > + struct regulator *reg;
> > + struct mutex lock; /* protect sensor state */
> > + struct hmc425a_chip_info *chip_info;
> > + struct gpio_descs *gpios;
> > + enum hmc425a_type type;
> > + u32 gain;
> > +};
> > +
> > +static int hmc425a_write(struct iio_dev *indio_dev, u32 value)
> > +{
> > + struct hmc425a_state *st = iio_priv(indio_dev);
> > + DECLARE_BITMAP(values, BITS_PER_TYPE(value));
> > +
> > + values[0] = value;
> > +
> > + gpiod_set_array_value_cansleep(st->gpios->ndescs, st->gpios-
> > >desc,
> > + NULL, values);
> > + return 0;
> > +}
> > +
> > +static int hmc425a_read_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan, int *val,
> > + int *val2, long m)
> > +{
> > + struct hmc425a_state *st = iio_priv(indio_dev);
> > + int code, gain = 0;
> > + int ret;
> > +
> > + mutex_lock(&st->lock);
> > + switch (m) {
> > + case IIO_CHAN_INFO_HARDWAREGAIN:
> > + code = st->gain;
> > +
> > + switch (st->type) {
> > + case ID_HMC425A:
> > + gain = ~code * -500;
> > + break;
> > + }
> > +
> > + *val = gain / 1000;
> > + *val2 = (gain % 1000) * 1000;
> > +
> > + ret = IIO_VAL_INT_PLUS_MICRO_DB;
> > + break;
> > + default:
> > + ret = -EINVAL;
> > + }
> > + mutex_unlock(&st->lock);
> > +
> > + return ret;
> > +};
> > +
> > +static int hmc425a_write_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan, int val,
> > + int val2, long mask)
> > +{
> > + struct hmc425a_state *st = iio_priv(indio_dev);
> > + struct hmc425a_chip_info *inf = st->chip_info;
> > + int code = 0, gain;
> > + int ret;
> > +
> > + if (val < 0)
> > + gain = (val * 1000) - (val2 / 1000);
> > + else
> > + gain = (val * 1000) + (val2 / 1000);
> > +
> > + if (gain > inf->gain_max || gain < inf->gain_min)
> > + return -EINVAL;
> > +
> > + switch (st->type) {
> > + case ID_HMC425A:
> > + code = ~((abs(gain) / 500) & 0x3F);
> > + break;
> > + }
> > +
> > + mutex_lock(&st->lock);
> > + switch (mask) {
> > + case IIO_CHAN_INFO_HARDWAREGAIN:
> > + st->gain = code;
> > +
> > + ret = hmc425a_write(indio_dev, st->gain);
> > + break;
> > + default:
> > + ret = -EINVAL;
> > + }
> > + mutex_unlock(&st->lock);
> > +
> > + return ret;
> > +}
> > +
> > +static int hmc425a_write_raw_get_fmt(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan,
> > + long mask)
> > +{
> > + switch (mask) {
> > + case IIO_CHAN_INFO_HARDWAREGAIN:
> > + return IIO_VAL_INT_PLUS_MICRO_DB;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +static const struct iio_info hmc425a_info = {
> > + .read_raw = &hmc425a_read_raw,
> > + .write_raw = &hmc425a_write_raw,
> > + .write_raw_get_fmt = &hmc425a_write_raw_get_fmt,
> > +};
> > +
> > +#define HMC425A_CHAN(_channel)
> > \
> > +{
> > \
> > + .type = IIO_VOLTAGE,
> > \
> > + .output = 1,
> > \
> > + .indexed = 1,
> > \
> > + .channel = _channel,
> > \
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_HARDWAREGAIN),
> > \
> > +}
> > +
> > +static const struct iio_chan_spec hmc425a_channels[] = {
> > + HMC425A_CHAN(0),
> > +};
> > +
> > +/* Match table for of_platform binding */
> > +static const struct of_device_id hmc425a_of_match[] = {
> > + { .compatible = "adi,hmc425a", .data = (void *)ID_HMC425A },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, hmc425a_of_match);
> > +
> > +static void hmc425a_reg_disable(void *data)
> > +{
> > + struct hmc425a_state *st = data;
> > +
> > + regulator_disable(st->reg);
> > +}
> > +
> > +static struct hmc425a_chip_info hmc425a_chip_info_tbl[] = {
> > + [ID_HMC425A] = {
> > + .name = "hmc425a",
> > + .channels = hmc425a_channels,
> > + .num_channels = ARRAY_SIZE(hmc425a_channels),
> > + .num_gpios = 6,
> > + .gain_min = -31500,
> > + .gain_max = 0,
> > + .default_gain = -0x40, /* set default gain -31.5db*/
> > + },
> > +};
> > +
> > +static int hmc425a_probe(struct platform_device *pdev)
> > +{
> > + struct iio_dev *indio_dev;
> > + struct hmc425a_state *st;
> > + int ret;
> > +
> > + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*st));
> > + if (!indio_dev)
> > + return -ENOMEM;
> > +
> > + st = iio_priv(indio_dev);
> > + st->type = (enum hmc425a_type)of_device_get_match_data(&pdev-
> > >dev);
> > +
> > + st->chip_info = &hmc425a_chip_info_tbl[st->type];
> > + indio_dev->num_channels = st->chip_info->num_channels;
> > + indio_dev->channels = st->chip_info->channels;
> > + indio_dev->name = st->chip_info->name;
> > + st->gain = st->chip_info->default_gain;
> > +
> > + st->gpios = devm_gpiod_get_array(&pdev->dev, "ctrl",
> > GPIOD_OUT_LOW);
> > + if (IS_ERR(st->gpios)) {
> > + ret = PTR_ERR(st->gpios);
> > + if (ret != -EPROBE_DEFER)
> > + dev_err(&pdev->dev, "failed to get gpios\n");
> > + return ret;
> > + }
> > +
> > + if (st->gpios->ndescs != st->chip_info->num_gpios) {
> > + dev_err(&pdev->dev, "%d GPIOs needed to operate\n",
> > + st->chip_info->num_gpios);
> > + return -ENODEV;
> > + }
> > +
> > + st->reg = devm_regulator_get_optional(&pdev->dev, "vcc-
> > supply");
>
> Sorry I'd missed this before. Why is this optional? I think
> what is needed here is to just let the regulator framework provide
> a stub if no regulator is supplied in DT.
>
> We only play this optional game if we have regulators that are really
> optional such as reference voltages on parts that also have internal
> references that can be used.
>
> > + if (IS_ERR(st->reg)) {
> > + if (PTR_ERR(st->reg) == -EPROBE_DEFER)
> > + return -EPROBE_DEFER;
> > +
> > + st->reg = NULL;
> > + } else {
> > + ret = regulator_enable(st->reg);
> > + if (ret)
> > + return ret;
> > + ret = devm_add_action_or_reset(&pdev->dev,
> > hmc425a_reg_disable,
> > + st);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + mutex_init(&st->lock);
> > +
> > + indio_dev->dev.parent = &pdev->dev;
> > + indio_dev->info = &hmc425a_info;
> > + indio_dev->modes = INDIO_DIRECT_MODE;
> > +
> > + return devm_iio_device_register(&pdev->dev, indio_dev);
> > +}
> > +
> > +static struct platform_driver hmc425a_driver = {
> > + .driver = {
> > + .name = KBUILD_MODNAME,
> > + .of_match_table = hmc425a_of_match,
> > + },
> > + .probe = hmc425a_probe,
> > +};
> > +module_platform_driver(hmc425a_driver);
> > +
> > +MODULE_AUTHOR("Michael Hennerich <michael.hennerich@analog.com>");
> > +MODULE_DESCRIPTION("Analog Devices HMC425A and similar GPIO
> > control Gain Amplifiers");
> > +MODULE_LICENSE("GPL v2");
>
>
^ permalink raw reply
* Re: [PATCH 0/2] phy: ti: gmii-sel: two fixes
From: Kishon Vijay Abraham I @ 2020-02-20 12:36 UTC (permalink / raw)
To: Grygorii Strashko, linux-kernel; +Cc: Sekhar Nori
In-Reply-To: <20200214190801.3030-1-grygorii.strashko@ti.com>
On 15/02/20 12:37 am, Grygorii Strashko wrote:
> Hi Kishon,
>
> Here the two minor fixes for TI phy-gmii-sel PHY.
> - Patch 1: few minor copy-paste errors.
> - Patch 2: enables back gmii mode (not used now, so no issues reported til now)
>
> Grygorii Strashko (2):
> phy: ti: gmii-sel: fix set of copy-paste errors
> phy: ti: gmii-sel: do not fail in case of gmii
merged, thanks!
-Kishon
>
> drivers/phy/ti/phy-gmii-sel.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/5] arm64/vdso: use the fault callback to map vvar pages
From: Vincenzo Frascino @ 2020-02-20 12:36 UTC (permalink / raw)
To: Andrei Vagin
Cc: linux-arm-kernel, linux-kernel, Thomas Gleixner, Dmitry Safonov
In-Reply-To: <20200204175913.74901-2-avagin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
Hi Andrei,
On 04/02/2020 17:59, Andrei Vagin wrote:
> This is required to support time namespaces where a time namespace data
> page is different for each namespace.
>
> Signed-off-by: Andrei Vagin <avagin@gmail.com>
> ---
[...]
> @@ -206,6 +210,8 @@ static int aarch32_vdso_mremap(const struct vm_special_mapping *sm,
> #define C_SIGPAGE 1
> #define C_PAGES (C_SIGPAGE + 1)
> #endif /* CONFIG_COMPAT_VDSO */
> +static vm_fault_t vvar_fault(const struct vm_special_mapping *sm,
> + struct vm_area_struct *vma, struct vm_fault *vmf);
I think you forgot to remove this one :)
[...]
--
Regards,
Vincenzo
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 14291 bytes --]
^ permalink raw reply
* Re: [igt-dev] [RFC PATCH i-g-t v2] tests/gem_userptr_blits: Enhance invalid mapping exercise
From: Janusz Krzysztofik @ 2020-02-20 12:36 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev, intel-gfx
In-Reply-To: <158143949995.3635.18328569070749519341@skylake-alporthouse-com>
Hi Chris,
On Tuesday, February 11, 2020 5:44:59 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-11 14:30:48)
> > @@ -2009,8 +2016,31 @@ igt_main_args("c:", NULL, help_str, opt_handler,
NULL)
> > igt_subtest("invalid-null-pointer")
> > test_invalid_null_pointer(fd);
> >
> > - igt_subtest("invalid-gtt-mapping")
> > - test_invalid_gtt_mapping(fd);
> > + igt_describe("Verify userptr on top of GTT mapping to GEM
object will fail");
> > + igt_subtest("invalid-gtt-mapping") {
> > + gem_require_mappable_ggtt(fd);
> > + test_invalid_mapping(fd, I915_MMAP_OFFSET_GTT);
> > + }
>
> #include "i915/gem_mman.h"
> igt_subtest_with_dynamic("invalid-mmap-offset") {
> for_each_mmap_offset_type(t) {
> igt_dynamic_f("%s", t->name)
> test_invalid_mapping(fd, t);
>
> In test_invalid_mapping, instead of do_ioctl(MMAP_OFFSET) use
> igt_require(igt_ioctl(MMAP_OFFSET, &arg) == 0);
Inspired by Michał, I've revisited this construct and now I think a confusing
side effect of it may be expected. When run on a driver with no mmap-offset
support, igt_ioctl(MMAP_OFFSET, &arg) would succeed for each t->type and the
test would claim success for every mapping type.
Something like this should help:
if (t->type != I915_MMAP_OFFSET_GTT)
igt_require(gem_has_mmap_offset(fd);
If my finding occurs correct, I'll update my patches and resubmit.
Thanks,
Janusz
>
> (Or igt_require_f if you like to keep the spiel.)
>
> }
> }
> }
>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH 1/5] arm64/vdso: use the fault callback to map vvar pages
From: Vincenzo Frascino @ 2020-02-20 12:36 UTC (permalink / raw)
To: Andrei Vagin
Cc: Thomas Gleixner, linux-kernel, linux-arm-kernel, Dmitry Safonov
In-Reply-To: <20200204175913.74901-2-avagin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
Hi Andrei,
On 04/02/2020 17:59, Andrei Vagin wrote:
> This is required to support time namespaces where a time namespace data
> page is different for each namespace.
>
> Signed-off-by: Andrei Vagin <avagin@gmail.com>
> ---
[...]
> @@ -206,6 +210,8 @@ static int aarch32_vdso_mremap(const struct vm_special_mapping *sm,
> #define C_SIGPAGE 1
> #define C_PAGES (C_SIGPAGE + 1)
> #endif /* CONFIG_COMPAT_VDSO */
> +static vm_fault_t vvar_fault(const struct vm_special_mapping *sm,
> + struct vm_area_struct *vma, struct vm_fault *vmf);
I think you forgot to remove this one :)
[...]
--
Regards,
Vincenzo
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 14291 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Bug 1857811] Re: qemu user static binary seems to lack support for network namespace.
From: Laurent Vivier @ 2020-02-20 12:27 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <157762661516.5433.16221584605990009162.malonedeb@gac.canonical.com>
Could you run something like "sudo strace -yyy unshare --net chroot ..."
with your failing binary to see what returns the host kernel?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1857811
Title:
qemu user static binary seems to lack support for network namespace.
Status in QEMU:
New
Bug description:
Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I
see the following error message.
Unable to configure loopback interface: Operation not supported
If I disable emerge's network-sandbox which utilizes network
namespace, the error disappears.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1857811/+subscriptions
^ permalink raw reply
* Re: [Intel-gfx] [RFC PATCH i-g-t v2] tests/gem_userptr_blits: Enhance invalid mapping exercise
From: Janusz Krzysztofik @ 2020-02-20 12:36 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev, intel-gfx
In-Reply-To: <158143949995.3635.18328569070749519341@skylake-alporthouse-com>
Hi Chris,
On Tuesday, February 11, 2020 5:44:59 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-11 14:30:48)
> > @@ -2009,8 +2016,31 @@ igt_main_args("c:", NULL, help_str, opt_handler,
NULL)
> > igt_subtest("invalid-null-pointer")
> > test_invalid_null_pointer(fd);
> >
> > - igt_subtest("invalid-gtt-mapping")
> > - test_invalid_gtt_mapping(fd);
> > + igt_describe("Verify userptr on top of GTT mapping to GEM
object will fail");
> > + igt_subtest("invalid-gtt-mapping") {
> > + gem_require_mappable_ggtt(fd);
> > + test_invalid_mapping(fd, I915_MMAP_OFFSET_GTT);
> > + }
>
> #include "i915/gem_mman.h"
> igt_subtest_with_dynamic("invalid-mmap-offset") {
> for_each_mmap_offset_type(t) {
> igt_dynamic_f("%s", t->name)
> test_invalid_mapping(fd, t);
>
> In test_invalid_mapping, instead of do_ioctl(MMAP_OFFSET) use
> igt_require(igt_ioctl(MMAP_OFFSET, &arg) == 0);
Inspired by Michał, I've revisited this construct and now I think a confusing
side effect of it may be expected. When run on a driver with no mmap-offset
support, igt_ioctl(MMAP_OFFSET, &arg) would succeed for each t->type and the
test would claim success for every mapping type.
Something like this should help:
if (t->type != I915_MMAP_OFFSET_GTT)
igt_require(gem_has_mmap_offset(fd);
If my finding occurs correct, I'll update my patches and resubmit.
Thanks,
Janusz
>
> (Or igt_require_f if you like to keep the spiel.)
>
> }
> }
> }
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [Intel-gfx] [PATCH 2/2] drm/i915: Protect i915_request_await_start from early waits
From: Chris Wilson @ 2020-02-20 12:36 UTC (permalink / raw)
To: intel-gfx; +Cc: matthew.auld
In-Reply-To: <20200220123608.1666271-1-chris@chris-wilson.co.uk>
We need to be extremely careful inside i915_request_await_start() as it
needs to walk the list of requests in the foreign timeline with very
little protection. As we hold our own timeline mutex, we can not nest
inside the signaler's timeline mutex, so all that remains is our RCU
protection. However, to be safe we need to tell the compiler that we may
be traversing the list only under RCU protection, and furthermore we
need to start declaring requests as elements of the timeline from their
construction.
Fixes: 9ddc8ec027a3 ("drm/i915: Eliminate the trylock for awaiting an earlier request")
Fixes: 6a79d848403d ("drm/i915: Lock signaler timeline while navigating")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_request.c | 43 ++++++++++++++++++++---------
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index d53af93b919b..28f135ebeaa0 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -290,7 +290,7 @@ bool i915_request_retire(struct i915_request *rq)
spin_unlock_irq(&rq->lock);
remove_from_client(rq);
- list_del(&rq->link);
+ list_del_rcu(&rq->link);
intel_context_exit(rq->context);
intel_context_unpin(rq->context);
@@ -736,6 +736,8 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
rq->infix = rq->ring->emit; /* end of header; start of user payload */
intel_context_mark_active(ce);
+ list_add_tail_rcu(&rq->link, &tl->requests);
+
return rq;
err_unwind:
@@ -792,13 +794,21 @@ i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
GEM_BUG_ON(i915_request_timeline(rq) ==
rcu_access_pointer(signal->timeline));
+ if (i915_request_started(signal))
+ return 0;
+
fence = NULL;
rcu_read_lock();
spin_lock_irq(&signal->lock);
- if (!i915_request_started(signal) &&
- !list_is_first(&signal->link,
- &rcu_dereference(signal->timeline)->requests)) {
- struct i915_request *prev = list_prev_entry(signal, link);
+ do {
+ struct list_head *pos = READ_ONCE(signal->link.prev);
+ struct i915_request *prev;
+
+ if (i915_request_started(signal))
+ break;
+
+ if (pos == &rcu_dereference(signal->timeline)->requests)
+ break;
/*
* Peek at the request before us in the timeline. That
@@ -806,13 +816,22 @@ i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
* after acquiring a reference to it, confirm that it is
* still part of the signaler's timeline.
*/
- if (i915_request_get_rcu(prev)) {
- if (list_next_entry(prev, link) == signal)
- fence = &prev->fence;
- else
- i915_request_put(prev);
+ prev = list_entry(pos, typeof(*prev), link);
+ if (!i915_request_get_rcu(prev))
+ break;
+
+ if (i915_request_completed(prev)) {
+ i915_request_put(prev);
+ break;
}
- }
+
+ if (READ_ONCE(prev->link.next) != &signal->link) {
+ i915_request_put(prev);
+ break;
+ }
+
+ fence = &prev->fence;
+ } while (0);
spin_unlock_irq(&signal->lock);
rcu_read_unlock();
if (!fence)
@@ -1253,8 +1272,6 @@ __i915_request_add_to_timeline(struct i915_request *rq)
0);
}
- list_add_tail(&rq->link, &timeline->requests);
-
/*
* Make sure that no request gazumped us - if it was allocated after
* our i915_request_alloc() and called __i915_request_add() before
--
2.25.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Intel-gfx] [PATCH 1/2] drm/i915: Double check bumping after the spinlock
From: Chris Wilson @ 2020-02-20 12:36 UTC (permalink / raw)
To: intel-gfx; +Cc: matthew.auld
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_scheduler.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c
index 59f70b674665..be770f2419b1 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -363,6 +363,9 @@ static void __bump_priority(struct i915_sched_node *node, unsigned int bump)
{
struct i915_sched_attr attr = node->attr;
+ if (attr.priority & bump)
+ return;
+
attr.priority |= bump;
__i915_schedule(node, &attr);
}
--
2.25.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Buildroot] [Bug 12571] New: ltp-testsuite : Build failure
From: bugzilla at busybox.net @ 2020-02-20 12:37 UTC (permalink / raw)
To: buildroot
https://bugs.busybox.net/show_bug.cgi?id=12571
Bug ID: 12571
Summary: ltp-testsuite : Build failure
Product: buildroot
Version: 2019.11.1
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: learn2kab at gmail.com
CC: buildroot at uclibc.org
Target Milestone: ---
Hello,
While trying to prepare images for Beaglebone Black with "ltp-testsuite"
included (keeping other parameters to their default values),the build process
breaks .
-----------------------------
Error Message with Default Settings:
-----------------------------
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Copying files into the device: __populate_fs: Could not allocate block in ext2
filesystem while writing file "fanotify10"
mkfs.ext4: Could not allocate block in ext2 filesystem while populating file
system
*** Maybe you need to increase the filesystem size
(BR2_TARGET_ROOTFS_EXT2_SIZE)
fs/ext2/ext2.mk:46: recipe for target
'/home/workpc/dir_buildroot/buildroot-2019.11.1/output/images/rootfs.ext2'
failed
make[1]: ***
[/home/workpc/dir_buildroot/buildroot-2019.11.1/output/images/rootfs.ext2]
Error 1
Makefile:84: recipe for target '_all' failed
make: *** [_all] Error 2
-----------------------------
Updated the value of "BR2_TARGET_ROOTFS_EXT2_SIZE" from 60M to 64G.
An error message mentioning
"part rootfs size (536870912) too small for rootfs.ext4 (68719476736)"
(as below) appears in the build log.
-------------------------------
Error Message with Modified Values:
-------------------------------
INFO: cmd: "find
'/home/workpc/dir_buildroot/buildroot-2019.11.1/output/build/genimage.tmp/root'
-depth -type d -printf '%P\0' | xargs -0 -I {} touch -r
'/tmp/tmp.7ROXYVc0KU/{}'
'/home/workpc/dir_buildroot/buildroot-2019.11.1/output/build/genimage.tmp/root/{}'"
(stderr):
ERROR: hdimage(sdcard.img): part rootfs size (536870912) too small for
rootfs.ext4 (68719476736)
Makefile:809: recipe for target 'target-post-image' failed
make[1]: *** [target-post-image] Error 1
Makefile:84: recipe for target '_all' failed
make: *** [_all] Error 2
--------------------------------
What would be the apt value for this parameter??
Should any other parameter be accordingly modified??
Please advice.
Regards,
Adarsh
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: [PATCH v3 04/22] x86/doublefault: Make memmove() notrace/NOKPROBE
From: Peter Zijlstra @ 2020-02-20 12:37 UTC (permalink / raw)
To: Borislav Petkov
Cc: Steven Rostedt, linux-kernel, linux-arch, mingo, joel, gregkh,
gustavo, tglx, paulmck, josh, mathieu.desnoyers, jiangshanlai,
luto, tony.luck, frederic, dan.carpenter, mhiramat
In-Reply-To: <20200220121727.GB507@zn.tnic>
On Thu, Feb 20, 2020 at 01:17:27PM +0100, Borislav Petkov wrote:
> On Wed, Feb 19, 2020 at 04:57:15PM +0100, Peter Zijlstra wrote:
> > - memmove(&gpregs->ip, (void *)regs->sp, 5*8);
> > + for (i = 0; i < count; i++) {
> > + int idx = (dst <= src) ? i : count - i;
> > + dst[idx] = src[idx];
> > + }
>
> Or, you can actually unroll it. This way it even documents clearly what
> it does:
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index fe38015ed50a..2b790a574ba5 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -298,6 +298,7 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, long error_code, unsign
> regs->ip == (unsigned long)native_irq_return_iret)
> {
> struct pt_regs *gpregs = (struct pt_regs *)this_cpu_read(cpu_tss_rw.x86_tss.sp0) - 1;
> + unsigned long *p = (unsigned long *)regs->sp;
>
> /*
> * regs->sp points to the failing IRET frame on the
> @@ -305,7 +306,11 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, long error_code, unsign
> * in gpregs->ss through gpregs->ip.
> *
> */
> - memmove(&gpregs->ip, (void *)regs->sp, 5*8);
> + gpregs->ip = *p;
> + gpregs->cs = *(p + 1);
> + gpregs->flags = *(p + 2);
> + gpregs->sp = *(p + 3);
> + gpregs->ss = *(p + 4);
> gpregs->orig_ax = 0; /* Missing (lost) #GP error code */
>
> /*
While I love that; is that actually correct? This is an unroll of
memcpy() not memmove(). IFF the ranges overlap, the above is buggered.
Was the original memmove() really needed?
^ permalink raw reply
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
From: Arnd Bergmann @ 2020-02-20 12:37 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Florian Weimer, Helmut Grohne, GNU C Library, Vineet Gupta,
Palmer Dabbelt, Zong Li, debian-arm, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, Alistair Francis, arcml,
Joseph Myers
In-Reply-To: <20200220103716.2f526933@jawa>
On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de> wrote:
> > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> >
> > Would it be possible to take a snapshot of your glibc tree
>
> The description of the status of Y2038 supporting glibc on ARM 32 can
> be found here [1].
>
> The most recent patches for Y2038 supporting glibc can be always found
> in the 'y2038_edge' branch [2].
Ok.
> > and start testing this out with debian-rebootstrap [1]?
>
> I've been using OE/Yocto for testing as it allows building glibc
> sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and
> mips - but not tested).
>...
> However, I did not yet tried debian-rebootstrap. I will look if this
> can be reused as well.
The reason I'm asking about debian-rebootstrap is less about testing
glibc itself than about testing the rest of user space to figure out better
what needs to be done when rebuilding with _TIME_BITS=64, and to
start fixing more upstream packages, with the hope of having enough
of it done in time for the Debian 11 release.
> > Are there any glibc issues that prevent it from working correctly,
>
> I think that the glibc wrappers for most important syscalls are now
> converted.
>
> What is missing:
>
> - NTPL (threads)
> - stat
Do you mean that code using these will fail to work correctly with
-D_TIME_BITS=64 at the moment, or that the interfaces are there
but they are not y2038 safe? Without pthreads or stat, we probably
wouldn't get too far in rebootstrap, but if the interfaces are there
and mostly work, then we don't need to rely on them being
y2038-safe just yet. An obvious next step would be to run the
resulting code with the RTC set 20 years ahead, and that requires
it all to work.
> - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
> some basic tests [4], but this may be not enough.
This is probably something where debian-rebootstrap could help,
as building and testing more user space packages will excercise
additional code paths in glibc as well. There is also some work
in Linaro to ensure that LTP tests the low-level syscall interfaces
in both the time32 and time64 variants.
Arnd
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply
* Re: [PATCH] babeltrace2: added 2.0.1
From: Anders Wallin @ 2020-02-20 12:38 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: OE-core
In-Reply-To: <CANNYZj9t2+ugT15XbYrqkgA23MHEQxy_9t=PnutoCQr2f0AA-A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
Hi Alex,
should I update the patch to include changes to maintainer file,
packagegroup etc in the same way as for babeltrace or
is it something you will do?
Anders Wallin
On Wed, Feb 19, 2020 at 5:02 PM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:
> On Wed, 19 Feb 2020 at 16:56, Jonathan Rajotte-Julien <
> jonathan.rajotte-julien@efficios.com> wrote:
>
>> > There are some things where the namespaces are quite specific (python
>> > vs python3, gtk(+) 2/3/4, qt) but they're fairly few and far between.
>> >
>> > If babeltrace2 will replace babeltrace and become babeltrace, we
>> > probably want to keep PN as babeltrace. If it will be known as
>> > babeltrace2 always, we probably change PN.
>>
>> Babeltrace 2 executable will be forever named babeltrace2.
>>
>> Hope this clear up this part a bit.
>>
>
> Right, then I'm fine with naming the recipe babeltrace2.
>
> Alex
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 2099 bytes --]
^ permalink raw reply
* Re: [CFT 6/8] net: macb: use resolved link config in mac_link_up()
From: Andrew Lunn @ 2020-02-20 12:38 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Alexandre Belloni, Florian Fainelli, Heiner Kallweit,
David S. Miller, netdev, Nicolas Ferre
In-Reply-To: <20200220101828.GV25745@shell.armlinux.org.uk>
> Thanks, that looks reasonable to me. I'll replace my patch with this
> one if it's appropriate for net-next when I send this series for
> merging. However, I see most affected network driver maintainers
> haven't responded yet, which is rather disappointing. So, thanks
> for taking the time to look at this.
Hi Russell
I suspect most maintainers are lazy. Give them a branch to pull, and
they might be more likely to test.
Andrew
^ permalink raw reply
* Re: w83627ehf crash in 5.6.0-rc2-00055-gca7e1fd1026c
From: Dr. David Alan Gilbert @ 2020-02-20 12:14 UTC (permalink / raw)
To: Meelis Roos; +Cc: linux-hwmon, LKML, Chen Zhou
In-Reply-To: <434212bb-4eb9-7366-3255-79826d0e65bc@linux.ee>
* Meelis Roos (mroos@linux.ee) wrote:
> While reading w83627ehf sensors output on D425KT mainboard, I consistently get NULL dereference as below.
>
> 5.5.0 worked OK but gave a warning on driver load:
> [ 104.514954] w83627ehf: Found W83627DHG-P chip at 0x290
> [ 104.515634] w83627ehf w83627ehf.656: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
>
> This is dmesg from current git (loading the driver and reading sensors with lm-sensors - no driver loading warning any more):
>
> [ 764.718192] w83627ehf: Found W83627DHG-P chip at 0x290
> [ 774.574874] BUG: kernel NULL pointer dereference, address: 0000000000000000
> [ 774.574889] #PF: supervisor read access in kernel mode
> [ 774.574895] #PF: error_code(0x0000) - not-present page
> [ 774.574901] PGD 0 P4D 0
> [ 774.574909] Oops: 0000 [#1] SMP NOPTI
> [ 774.574917] CPU: 0 PID: 604 Comm: sensors Not tainted 5.6.0-rc2-00055-gca7e1fd1026c #29
> [ 774.574923] Hardware name: /D425KT, BIOS MWPNT10N.86A.0132.2013.0726.1534 07/26/2013
> [ 774.574939] RIP: 0010:w83627ehf_read_string+0x27/0x70 [w83627ehf]
> [ 774.574947] Code: 00 00 00 55 53 48 8d 64 24 f0 83 fa 15 48 8b 5f 78 75 29 83 fe 01 75 24 48 63 c9 48 8b 6b 58 48 83 f9 03 77 24 0f b6 44 0b 50 <48> 8b 44 c5 00 49 89 00 48 8d 64 24 10 5b 31 c0 5d c3 48 8d 64 24
> [ 774.574958] RSP: 0018:ffffb95980657df8 EFLAGS: 00010293
> [ 774.574965] RAX: 0000000000000000 RBX: ffff96caaa7f5218 RCX: 0000000000000000
> [ 774.574972] RDX: 0000000000000015 RSI: 0000000000000001 RDI: ffff96caa736ec08
> [ 774.574978] RBP: 0000000000000000 R08: ffffb95980657e20 R09: 0000000000000001
> [ 774.574985] R10: ffff96caaa635cc0 R11: 0000000000000000 R12: ffff96caa9f7cf00
> [ 774.574991] R13: ffff96caa9ec3d00 R14: ffff96caa9ec3d28 R15: ffff96caa9ec3d40
> [ 774.574999] FS: 00007fbc7c4e2740(0000) GS:ffff96caabc00000(0000) knlGS:0000000000000000
> [ 774.575008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 774.575015] CR2: 0000000000000000 CR3: 0000000129d58000 CR4: 00000000000006f0
> [ 774.575021] Call Trace:
> [ 774.575036] ? cp_new_stat+0x12d/0x160
> [ 774.575048] hwmon_attr_show_string+0x37/0x70 [hwmon]
Sorry about that!
It looks like not all chips have temp_label, so I think we need to change w83627ehf_is_visible
which has:
if (attr == hwmon_temp_input || attr == hwmon_temp_label)
return 0444;
to
if (attr == hwmon_temp_input)
return 0444;
if (attr == hwmon_temp_label) {
if (data->temp_label)
return 0444;
else
return 0;
}
Does that work for you?
Dave
> [ 774.575060] dev_attr_show+0x14/0x50
> [ 774.575071] sysfs_kf_seq_show+0xb5/0x1b0
> [ 774.575081] seq_read+0xcf/0x460
> [ 774.575091] vfs_read+0x9b/0x150
> [ 774.575100] ksys_read+0x5f/0xe0
> [ 774.575111] do_syscall_64+0x48/0x190
> [ 774.575121] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 774.575130] RIP: 0033:0x7fbc7c715871
> [ 774.575138] Code: fe ff ff 50 48 8d 3d 76 e5 09 00 e8 e9 ef 01 00 66 0f 1f 84 00 00 00 00 00 48 8d 05 69 3b 0d 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 c3 66 0f 1f 44 00 00 48 83 ec 28 48 89 54
> [ 774.575151] RSP: 002b:00007ffe5092d848 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
> [ 774.575161] RAX: ffffffffffffffda RBX: 00005630bdfb1330 RCX: 00007fbc7c715871
> [ 774.575168] RDX: 0000000000001000 RSI: 00007ffe5092d8e0 RDI: 0000000000000003
> [ 774.575175] RBP: 00007fbc7c7e5560 R08: 0000000000000003 R09: 00007fbc7c7e43b0
> [ 774.575182] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000001000
> [ 774.575190] R13: 00007ffe5092d8e0 R14: 0000000000000d68 R15: 00007fbc7c7e4960
> [ 774.575199] Modules linked in: w83627ehf hwmon_vid snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_pcsp snd_hda_core ir_rc6_decoder rc_rc6_mce uas r8169 mceusb snd_pcm
> iTCO_wdt rc_core snd_timer iTCO_vendor_support realtek snd libphy soundcore i2c_i801 lpc_ich parport_pc mfd_core parport coretemp hwmon autofs4
> [ 774.575247] CR2: 0000000000000000
> [ 774.575254] ---[ end trace 607462057ab8a988 ]---
> [ 774.575264] RIP: 0010:w83627ehf_read_string+0x27/0x70 [w83627ehf]
> [ 774.575273] Code: 00 00 00 55 53 48 8d 64 24 f0 83 fa 15 48 8b 5f 78 75 29 83 fe 01 75 24 48 63 c9 48 8b 6b 58 48 83 f9 03 77 24 0f b6 44 0b 50 <48> 8b 44 c5 00 49 89 00 48 8d 64 24 10 5b 31 c0 5d c3 48 8d 64 24
> [ 774.575287] RSP: 0018:ffffb95980657df8 EFLAGS: 00010293
> [ 774.575294] RAX: 0000000000000000 RBX: ffff96caaa7f5218 RCX: 0000000000000000
> [ 774.575301] RDX: 0000000000000015 RSI: 0000000000000001 RDI: ffff96caa736ec08
> [ 774.575308] RBP: 0000000000000000 R08: ffffb95980657e20 R09: 0000000000000001
> [ 774.575316] R10: ffff96caaa635cc0 R11: 0000000000000000 R12: ffff96caa9f7cf00
> [ 774.575323] R13: ffff96caa9ec3d00 R14: ffff96caa9ec3d28 R15: ffff96caa9ec3d40
> [ 774.575331] FS: 00007fbc7c4e2740(0000) GS:ffff96caabc00000(0000) knlGS:0000000000000000
> [ 774.575340] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 774.575347] CR2: 0000000000000000 CR3: 0000000129d58000 CR4: 00000000000006f0
>
>
> --
> Meelis Roos <mroos@linux.ee>
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
* [Buildroot] [Bug 12571] ltp-testsuite : Build failure
From: bugzilla at busybox.net @ 2020-02-20 12:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-12571-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=12571
--- Comment #1 from learn2kab at gmail.com ---
Created attachment 8366
--> https://bugs.busybox.net/attachment.cgi?id=8366&action=edit
".config" file for "beaglebone_defconfig" configuration
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Force PSR probe only after full initialization
From: Mun, Gwan-gyeong @ 2020-02-20 12:39 UTC (permalink / raw)
To: intel-gfx@lists.freedesktop.org, Souza, Jose
Cc: Nikula, Jani, zwisler@google.com
In-Reply-To: <20200218203916.58636-1-jose.souza@intel.com>
On Tue, 2020-02-18 at 12:39 -0800, José Roberto de Souza wrote:
> Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
> once to enable PSR") was forcing the state compute too earlier
> causing errors because not everything was initialized, so here
> moving to i915_driver_register() when everything is ready and driver
> is registering into the rest of the system.
>
> Also fixing the place where it disarm the force probe as during the
> atomic check phase errors could happen like the ones due locking and
> it would cause PSR to never be enabled if that happens.
> Leaving the disarm to the atomic commit phase, intel_psr_enable() or
> intel_psr_update() will be called even if the current state do not
> allow PSR to be enabled.
>
> v2: Check if intel_dp is null in intel_psr_force_mode_changed_set()
> v3: Check intel_dp before get dev_priv
>
> Fixes: 60c6a14b489b ("drm/i915/display: Force the state compute phase
> once to enable PSR")
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151
> Tested-by: Ross Zwisler <zwisler@google.com>
> Reported-by: Ross Zwisler <zwisler@google.com>
> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 22 ++++++++++++++++++++--
> drivers/gpu/drm/i915/display/intel_psr.h | 1 +
> drivers/gpu/drm/i915/i915_drv.c | 3 +++
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 4 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index b4942b6445ae..2a0f7354fba5 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -936,6 +936,8 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>
> + intel_psr_force_mode_changed_set(intel_dp, false);
> +
Hi,
intel_psr_enable() and intel_psr_update already have checking routine
for CAN_PSR and has_psr.
therefore we don't need to check twice here.
And if there are no issues that moving "disarming force_mode_changed"
to intel_psr_compute_config(),
can we move them to intel_psr_compute_config()?
> if (!crtc_state->has_psr)
> return;
>
> @@ -1096,6 +1098,8 @@ void intel_psr_update(struct intel_dp
> *intel_dp,
> struct i915_psr *psr = &dev_priv->psr;
> bool enable, psr2_enable;
>
> + intel_psr_force_mode_changed_set(intel_dp, false);
> +
> if (!CAN_PSR(dev_priv) || READ_ONCE(psr->dp) != intel_dp)
> return;
>
> @@ -1629,7 +1633,7 @@ void intel_psr_atomic_check(struct
> drm_connector *connector,
> struct drm_crtc_state *crtc_state;
>
> if (!CAN_PSR(dev_priv) || !new_state->crtc ||
> - dev_priv->psr.initially_probed)
> + !dev_priv->psr.force_mode_changed)
> return;
>
> intel_connector = to_intel_connector(connector);
> @@ -1640,5 +1644,19 @@ void intel_psr_atomic_check(struct
> drm_connector *connector,
> crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> new_state->crtc);
> crtc_state->mode_changed = true;
> - dev_priv->psr.initially_probed = true;
> +}
> +
> +void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp,
> bool set)
IMHO, it would be better intel_psr_set_force_mode_changed() as a
function name.
> +{
> + struct drm_i915_private *dev_priv;
> +
> + if (!intel_dp)
> + return;
> +
> + dev_priv = dp_to_i915(intel_dp);
> + if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp) ||
> + intel_dp != dev_priv->psr.dp)
> + return;
> +
> + dev_priv->psr.force_mode_changed = set;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.h
> b/drivers/gpu/drm/i915/display/intel_psr.h
> index c58a1d438808..27a70468e2b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.h
> +++ b/drivers/gpu/drm/i915/display/intel_psr.h
> @@ -40,5 +40,6 @@ bool intel_psr_enabled(struct intel_dp *intel_dp);
> void intel_psr_atomic_check(struct drm_connector *connector,
> struct drm_connector_state *old_state,
> struct drm_connector_state *new_state);
> +void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp,
> bool set);
>
> #endif /* __INTEL_PSR_H__ */
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index f7a1c33697b7..83791c197611 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -58,6 +58,7 @@
> #include "display/intel_hotplug.h"
> #include "display/intel_overlay.h"
> #include "display/intel_pipe_crc.h"
> +#include "display/intel_psr.h"
> #include "display/intel_sprite.h"
> #include "display/intel_vga.h"
>
> @@ -1256,6 +1257,8 @@ static void i915_driver_register(struct
> drm_i915_private *dev_priv)
>
> intel_audio_init(dev_priv);
>
> + intel_psr_force_mode_changed_set(dev_priv->psr.dp, true);
> +
> /*
> * Some ports require correctly set-up hpd registers for
> detection to
> * work properly (leading to ghost connected connector status),
> e.g. VGA
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 3330b538d379..a546655072bd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -505,7 +505,7 @@ struct i915_psr {
> bool dc3co_enabled;
> u32 dc3co_exit_delay;
> struct delayed_work dc3co_work;
> - bool initially_probed;
> + bool force_mode_changed;
> };
>
> #define QUIRK_LVDS_SSC_DISABLE (1<<1)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [MODERATED] Re: [PATCH 1/2] more sampling fun 1
From: Greg KH @ 2020-02-20 12:39 UTC (permalink / raw)
To: speck
In-Reply-To: <051675aa-0392-c7ad-1bca-3624972a3388@citrix.com>
On Thu, Feb 20, 2020 at 11:00:40AM +0000, speck for Andrew Cooper wrote:
> On 20/02/2020 10:13, speck for Borislav Petkov wrote:
> > On Thu, Feb 20, 2020 at 10:10:03AM +0000, speck for Andrew Cooper wrote:
> >> Because it is under embargo until May 12th.
> > Maybe 2/2 is - which I don't have in my mbox - but by staring only at
> > 1/2 there's nothing to embargo there AFAICT.
> >
>
> Right, but a lone patch (coming pre-reviewed even!) adding stepping
> support into the speculative model checking is going to be about as
> subtle as the KPTI work was :)
Don't pre-review it then. Just submit it like any other normal cleanup
patch.
thanks,
greg k-h
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v17 3/7] drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state
From: Jani Nikula @ 2020-02-20 12:40 UTC (permalink / raw)
To: Stanislav Lisovskiy, intel-gfx
In-Reply-To: <20200220120741.6917-4-stanislav.lisovskiy@intel.com>
On Thu, 20 Feb 2020, Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> wrote:
> We might be willing to call intel_atomic_get_old_global_obj_state
> and intel_atomic_get_new_global_obj_state right away, however
> those are not initializing global obj state as
> intel_atomic_get_global_obj_state does.
> Extracted initializing part to separate function and now using this
> also in intel_atomic_get_old_global_obj_state and intel_atomic_get_new_global_obj_state
>
> v2: - Fixed typo in function call
>
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 28 ++++++++++++++++++++++++-
> drivers/gpu/drm/i915/display/intel_bw.h | 9 ++++++++
> 2 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
> index 58b264bc318d..ff57277e8880 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -374,7 +374,33 @@ static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> return data_rate;
> }
>
> -static struct intel_bw_state *
> +struct intel_bw_state *
> +intel_atomic_get_old_bw_state(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_global_state *bw_state;
> +
> + bw_state = intel_atomic_get_old_global_obj_state(state, &dev_priv->bw_obj);
> + if (IS_ERR(bw_state))
> + return ERR_CAST(bw_state);
> +
> + return to_intel_bw_state(bw_state);
> +}
> +
> +struct intel_bw_state *
> +intel_atomic_get_new_bw_state(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_global_state *bw_state;
> + bw_state = intel_atomic_get_new_global_obj_state(state, &dev_priv->bw_obj);
> +
> + if (IS_ERR(bw_state))
> + return ERR_CAST(bw_state);
> +
> + return to_intel_bw_state(bw_state);
> +}
> +
> +struct intel_bw_state *
> intel_atomic_get_bw_state(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h
> index a8aa7624c5aa..ac004d6f4276 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -24,6 +24,15 @@ struct intel_bw_state {
>
> #define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)
>
> +struct intel_bw_state *
> +intel_atomic_get_old_bw_state(struct intel_atomic_state *state);
> +
> +struct intel_bw_state *
> +intel_atomic_get_new_bw_state(struct intel_atomic_state *state);
> +
> +struct intel_bw_state *
> +intel_atomic_get_bw_state(struct intel_atomic_state *state);
> +
I'm trying to promote a convention that a module foo_bar.[ch] would
export functions prefixed foo_bar_. Here, intel_bw_* like below.
BR,
Jani.
> void intel_bw_init_hw(struct drm_i915_private *dev_priv);
> int intel_bw_init(struct drm_i915_private *dev_priv);
> int intel_bw_atomic_check(struct intel_atomic_state *state);
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 0/5] arm64: add the time namespace support
From: Vincenzo Frascino @ 2020-02-20 12:40 UTC (permalink / raw)
To: Andrei Vagin
Cc: linux-arm-kernel, linux-kernel, Thomas Gleixner, Dmitry Safonov
In-Reply-To: <20200204175913.74901-1-avagin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
Hi Andrei,
On 04/02/2020 17:59, Andrei Vagin wrote:
> Allocate the time namespace page among VVAR pages and add the logic
> to handle faults on VVAR properly.
>
> If a task belongs to a time namespace then the VVAR page which contains
> the system wide VDSO data is replaced with a namespace specific page
> which has the same layout as the VVAR page. That page has vdso_data->seq
> set to 1 to enforce the slow path and vdso_data->clock_mode set to
> VCLOCK_TIMENS to enforce the time namespace handling path.
>
> The extra check in the case that vdso_data->seq is odd, e.g. a concurrent
> update of the VDSO data is in progress, is not really affecting regular
> tasks which are not part of a time namespace as the task is spin waiting
> for the update to finish and vdso_data->seq to become even again.
>
> If a time namespace task hits that code path, it invokes the corresponding
> time getter function which retrieves the real VVAR page, reads host time
> and then adds the offset for the requested clock which is stored in the
> special VVAR page.
>
Thank you for adding the arm64 support of time namespaces. Overall it looks fine
to me even if I have few comments. I will test it in the coming days just to
make sure I did not miss something major. I will keep you updated on the results.
> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Dmitry Safonov <dima@arista.com>
>
> Andrei Vagin (5):
> arm64/vdso: use the fault callback to map vvar pages
> arm64/vdso: Zap vvar pages when switching to a time namespace
> arm64/vdso: Add time napespace page
> arm64/vdso: Handle faults on timens page
> arm64/vdso: Restrict splitting VVAR VMA
>
> arch/arm64/Kconfig | 1 +
> .../include/asm/vdso/compat_gettimeofday.h | 11 ++
> arch/arm64/include/asm/vdso/gettimeofday.h | 8 ++
> arch/arm64/kernel/vdso.c | 134 ++++++++++++++++--
> arch/arm64/kernel/vdso/vdso.lds.S | 3 +-
> arch/arm64/kernel/vdso32/vdso.lds.S | 3 +-
> include/vdso/datapage.h | 1 +
> 7 files changed, 147 insertions(+), 14 deletions(-)
>
--
Regards,
Vincenzo
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 14291 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] arm64: add the time namespace support
From: Vincenzo Frascino @ 2020-02-20 12:40 UTC (permalink / raw)
To: Andrei Vagin
Cc: Thomas Gleixner, linux-kernel, linux-arm-kernel, Dmitry Safonov
In-Reply-To: <20200204175913.74901-1-avagin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
Hi Andrei,
On 04/02/2020 17:59, Andrei Vagin wrote:
> Allocate the time namespace page among VVAR pages and add the logic
> to handle faults on VVAR properly.
>
> If a task belongs to a time namespace then the VVAR page which contains
> the system wide VDSO data is replaced with a namespace specific page
> which has the same layout as the VVAR page. That page has vdso_data->seq
> set to 1 to enforce the slow path and vdso_data->clock_mode set to
> VCLOCK_TIMENS to enforce the time namespace handling path.
>
> The extra check in the case that vdso_data->seq is odd, e.g. a concurrent
> update of the VDSO data is in progress, is not really affecting regular
> tasks which are not part of a time namespace as the task is spin waiting
> for the update to finish and vdso_data->seq to become even again.
>
> If a time namespace task hits that code path, it invokes the corresponding
> time getter function which retrieves the real VVAR page, reads host time
> and then adds the offset for the requested clock which is stored in the
> special VVAR page.
>
Thank you for adding the arm64 support of time namespaces. Overall it looks fine
to me even if I have few comments. I will test it in the coming days just to
make sure I did not miss something major. I will keep you updated on the results.
> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Dmitry Safonov <dima@arista.com>
>
> Andrei Vagin (5):
> arm64/vdso: use the fault callback to map vvar pages
> arm64/vdso: Zap vvar pages when switching to a time namespace
> arm64/vdso: Add time napespace page
> arm64/vdso: Handle faults on timens page
> arm64/vdso: Restrict splitting VVAR VMA
>
> arch/arm64/Kconfig | 1 +
> .../include/asm/vdso/compat_gettimeofday.h | 11 ++
> arch/arm64/include/asm/vdso/gettimeofday.h | 8 ++
> arch/arm64/kernel/vdso.c | 134 ++++++++++++++++--
> arch/arm64/kernel/vdso/vdso.lds.S | 3 +-
> arch/arm64/kernel/vdso32/vdso.lds.S | 3 +-
> include/vdso/datapage.h | 1 +
> 7 files changed, 147 insertions(+), 14 deletions(-)
>
--
Regards,
Vincenzo
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 14291 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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.