* [PATCH 2/2 v3] leds: ns2: Convert to GPIO descriptors
From: Linus Walleij @ 2020-02-20 15:08 UTC (permalink / raw)
To: Jacek Anaszewski, Pavel Machek, Dan Murphy
Cc: linux-leds, Linus Walleij, Vincent Donnefort, Simon Guinot
In-Reply-To: <20200220150833.56542-1-linus.walleij@linaro.org>
This converts the NS2 LED driver to use GPIO descriptors.
We take care to request the GPIOs "as is" which is what
the current driver goes to lengths to achieve, then we use
GPIOs throughout.
As the nodes for each LED does not have any corresponding
device, we need to use the DT-specific accessors to get these
GPIO descriptors from the device tree.
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Move the header inclusion changes from patch 1/2 into
this patch.
ChangeLog v1->v2:
- Collected Simon's Tested-by tag.
---
drivers/leds/leds-ns2.c | 76 +++++++++++++++++------------------------
1 file changed, 32 insertions(+), 44 deletions(-)
diff --git a/drivers/leds/leds-ns2.c b/drivers/leds/leds-ns2.c
index aefac3461138..538ca5755602 100644
--- a/drivers/leds/leds-ns2.c
+++ b/drivers/leds/leds-ns2.c
@@ -12,11 +12,10 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/leds.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/of_gpio.h>
#include "leds.h"
enum ns2_led_modes {
@@ -34,8 +33,8 @@ struct ns2_led_modval {
struct ns2_led {
const char *name;
const char *default_trigger;
- unsigned cmd;
- unsigned slow;
+ struct gpio_desc *cmd;
+ struct gpio_desc *slow;
int num_modes;
struct ns2_led_modval *modval;
};
@@ -54,8 +53,8 @@ struct ns2_led_platform_data {
struct ns2_led_data {
struct led_classdev cdev;
- unsigned int cmd;
- unsigned int slow;
+ struct gpio_desc *cmd;
+ struct gpio_desc *slow;
bool can_sleep;
unsigned char sata; /* True when SATA mode active. */
rwlock_t rw_lock; /* Lock GPIOs. */
@@ -71,8 +70,8 @@ static int ns2_led_get_mode(struct ns2_led_data *led_dat,
int cmd_level;
int slow_level;
- cmd_level = gpio_get_value_cansleep(led_dat->cmd);
- slow_level = gpio_get_value_cansleep(led_dat->slow);
+ cmd_level = gpiod_get_value_cansleep(led_dat->cmd);
+ slow_level = gpiod_get_value_cansleep(led_dat->slow);
for (i = 0; i < led_dat->num_modes; i++) {
if (cmd_level == led_dat->modval[i].cmd_level &&
@@ -105,15 +104,15 @@ static void ns2_led_set_mode(struct ns2_led_data *led_dat,
write_lock_irqsave(&led_dat->rw_lock, flags);
if (!led_dat->can_sleep) {
- gpio_set_value(led_dat->cmd,
- led_dat->modval[i].cmd_level);
- gpio_set_value(led_dat->slow,
- led_dat->modval[i].slow_level);
+ gpiod_set_value(led_dat->cmd,
+ led_dat->modval[i].cmd_level);
+ gpiod_set_value(led_dat->slow,
+ led_dat->modval[i].slow_level);
goto exit_unlock;
}
- gpio_set_value_cansleep(led_dat->cmd, led_dat->modval[i].cmd_level);
- gpio_set_value_cansleep(led_dat->slow, led_dat->modval[i].slow_level);
+ gpiod_set_value_cansleep(led_dat->cmd, led_dat->modval[i].cmd_level);
+ gpiod_set_value_cansleep(led_dat->slow, led_dat->modval[i].slow_level);
exit_unlock:
write_unlock_irqrestore(&led_dat->rw_lock, flags);
@@ -201,26 +200,6 @@ create_ns2_led(struct platform_device *pdev, struct ns2_led_data *led_dat,
int ret;
enum ns2_led_modes mode;
- ret = devm_gpio_request_one(&pdev->dev, template->cmd,
- gpio_get_value_cansleep(template->cmd) ?
- GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
- template->name);
- if (ret) {
- dev_err(&pdev->dev, "%s: failed to setup command GPIO\n",
- template->name);
- return ret;
- }
-
- ret = devm_gpio_request_one(&pdev->dev, template->slow,
- gpio_get_value_cansleep(template->slow) ?
- GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
- template->name);
- if (ret) {
- dev_err(&pdev->dev, "%s: failed to setup slow GPIO\n",
- template->name);
- return ret;
- }
-
rwlock_init(&led_dat->rw_lock);
led_dat->cdev.name = template->name;
@@ -230,8 +209,8 @@ create_ns2_led(struct platform_device *pdev, struct ns2_led_data *led_dat,
led_dat->cdev.groups = ns2_led_groups;
led_dat->cmd = template->cmd;
led_dat->slow = template->slow;
- led_dat->can_sleep = gpio_cansleep(led_dat->cmd) |
- gpio_cansleep(led_dat->slow);
+ led_dat->can_sleep = gpiod_cansleep(led_dat->cmd) |
+ gpiod_cansleep(led_dat->slow);
if (led_dat->can_sleep)
led_dat->cdev.brightness_set_blocking = ns2_led_set_blocking;
else
@@ -286,17 +265,26 @@ ns2_leds_get_of_pdata(struct device *dev, struct ns2_led_platform_data *pdata)
const char *string;
int i, num_modes;
struct ns2_led_modval *modval;
+ struct gpio_desc *gd;
- ret = of_get_named_gpio(child, "cmd-gpio", 0);
- if (ret < 0)
- goto err_node_put;
- led->cmd = ret;
- ret = of_get_named_gpio(child, "slow-gpio", 0);
- if (ret < 0)
- goto err_node_put;
- led->slow = ret;
ret = of_property_read_string(child, "label", &string);
led->name = (ret == 0) ? string : child->name;
+
+ gd = gpiod_get_from_of_node(child, "cmd-gpio", 0,
+ GPIOD_ASIS, led->name);
+ if (IS_ERR(gd)) {
+ ret = PTR_ERR(gd);
+ goto err_node_put;
+ }
+ led->cmd = gd;
+ gd = gpiod_get_from_of_node(child, "slow-gpio", 0,
+ GPIOD_ASIS, led->name);
+ if (IS_ERR(gd)) {
+ ret = PTR_ERR(gd);
+ goto err_node_put;
+ }
+ led->slow = gd;
+
ret = of_property_read_string(child, "linux,default-trigger",
&string);
if (ret == 0)
--
2.24.1
^ permalink raw reply related
* Re: [dpdk-dev] [PATCH v3 0/2] net/mlx5: copy the item flags from prefix flow
From: Raslan Darawsheh @ 2020-02-20 15:09 UTC (permalink / raw)
To: Suanming Mou, Matan Azrad, Slava Ovsiienko; +Cc: dev@dpdk.org
In-Reply-To: <1582206824-103222-1-git-send-email-suanmingm@mellanox.com>
Hi,
Series applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
> -----Original Message-----
> From: Suanming Mou <suanmingm@mellanox.com>
> Sent: Thursday, February 20, 2020 3:54 PM
> To: Matan Azrad <matan@mellanox.com>; Slava Ovsiienko
> <viacheslavo@mellanox.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@mellanox.com>
> Subject: [PATCH v3 0/2] net/mlx5: copy the item flags from prefix flow
>
> For flow split to several subflows, the match items maybe in the prefix
> flow, and the actions are split to the suffix flow.
>
> In this case, for the actions need the user defined match item will not
> create correctly.
>
> Copy the item layers flags to the suffix flow from prefix flow to fix
> the issue.
>
> This patch series should be applied after:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> es.dpdk.org%2Fproject%2Fdpdk%2Flist%2F%3Fseries%3D8613&data=0
> 2%7C01%7Crasland%40mellanox.com%7Cf520b39d2d0548ae5d2808d7b60c50
> 1d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637178036316184
> 939&sdata=8ZXhPrT27gbXwseF3TAwVbAslh7nOnt3%2FuzilxJblGE%3D&
> amp;reserved=0
>
> v2:
> Remove the actions flag inherit. Get the layer flags accordingly
> based on the actions in prefix flow.
>
> v3:
> Fix NULL pointer issue.
>
> Suanming Mou (2):
> net/mlx5: fix layer flags missing in metadata
> net/mlx5: fix lack of match information in meter
>
> drivers/net/mlx5/mlx5_flow.c | 74
> +++++++++++++++++++++++++++++++++++------
> drivers/net/mlx5/mlx5_flow_dv.c | 59 +++++++++++++++++++++++---------
> 2 files changed, 107 insertions(+), 26 deletions(-)
>
> --
> 1.8.3.1
^ permalink raw reply
* Re: [PATCH] backlight: add led-backlight driver
From: Tony Lindgren @ 2020-02-20 15:09 UTC (permalink / raw)
To: Lee Jones
Cc: Pavel Machek, kernel list, linux-arm-kernel, linux-omap, sre,
nekit1000, mpartap, merlijn, martin_rysavy, agx, daniel.thompson,
jingoohan1, dri-devel, tomi.valkeinen, jjhiblot
In-Reply-To: <20200220074849.GF3494@dell>
* Lee Jones <lee.jones@linaro.org> [200220 07:49]:
> On Wed, 19 Feb 2020, Tony Lindgren wrote:
>
> > * Pavel Machek <pavel@ucw.cz> [200219 19:15]:
> > > From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > >
> > > This patch adds a led-backlight driver (led_bl), which is similar to
> > > pwm_bl except the driver uses a LED class driver to adjust the
> > > brightness in the HW. Multiple LEDs can be used for a single backlight.
> > >
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> > > Acked-by: Lee Jones <lee.jones@linaro.org>
> > > Acked-by: Tony Lindgren <tony@atomide.com>
> > > Tested-by: Tony Lindgren <tony@atomide.com>
> > > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > > ---
> > > drivers/video/backlight/Kconfig | 7 ++
> > > drivers/video/backlight/Makefile | 1 +
> > > drivers/video/backlight/led_bl.c | 260 +++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 268 insertions(+)
> > > create mode 100644 drivers/video/backlight/led_bl.c
> > >
> > > Hi!
> > >
> > > Here's the version of the driver I have. AFAICT
> > > default-brightness-level handling is ok, so does not need to be
> > > changed.
> > >
> > > Lee, it would be easiest for me if you could apply it to your tree and
> > > push, but given enough time I can push it to Linus, too.
> >
> > Oh you're using quoted-printable for patches.. Got it applied now,
> > and it still works. Below is also the related dts change that
> > I tested with.
> >
> > Feel free to pick the dts change too, naturally that should
> > not be applied before the driver.
> >
> > If you guys instead want me to pick these both into my fixes
> > branch, just let me know and I'll do the explaining why these
> > are needed as fixes. Basically we no longer have a way to enable
> > the LCD backlight for droid4 manually starting with v5.6-rc1
> > unlike earlier.
>
> Please do. You already have my Ack.
OK pushed out these two patches in omap-for-v5.6/droid4-lcd-fix.
Thanks,
Tony
^ permalink raw reply
* Re: [PATCH v3 05/10] ASoC: tegra: add Tegra210 based AHUB driver
From: Jon Hunter @ 2020-02-20 15:08 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-6-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Audio Hub (AHUB) comprises a collection of hardware accelerators for
> audio pre/post-processing and a programmable full crossbar (XBAR) for
> routing audio data across these accelerators in time and in parallel.
> AHUB supports multiple interfaces to I2S, DSPK, DMIC etc., XBAR is a
> switch used to configure or modify audio routing between HW accelerators
> present inside AHUB.
>
> This patch registers AHUB component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes AHUB interfaces, which can be used to connect different
> components in the ASoC layer. Currently the driver takes care of XBAR
> programming to allow audio data flow through various clients of the AHUB.
> Makefile and Kconfig support is added to allow to build the driver. The
> AHUB component can be enabled in the DT via below compatible bindings.
> - "nvidia,tegra210-ahub" for Tegra210
> - "nvidia,tegra186-ahub" for Tegra186 and Tegra194
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 10 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra210_ahub.c | 651 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra210_ahub.h | 125 ++++++++
> 4 files changed, 788 insertions(+)
> create mode 100644 sound/soc/tegra/tegra210_ahub.c
> create mode 100644 sound/soc/tegra/tegra210_ahub.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH] backlight: add led-backlight driver
From: Tony Lindgren @ 2020-02-20 15:09 UTC (permalink / raw)
To: Lee Jones
Cc: daniel.thompson, mpartap, jingoohan1, merlijn, martin_rysavy,
kernel list, dri-devel, sre, nekit1000, tomi.valkeinen,
Pavel Machek, jjhiblot, linux-omap, agx, linux-arm-kernel
In-Reply-To: <20200220074849.GF3494@dell>
* Lee Jones <lee.jones@linaro.org> [200220 07:49]:
> On Wed, 19 Feb 2020, Tony Lindgren wrote:
>
> > * Pavel Machek <pavel@ucw.cz> [200219 19:15]:
> > > From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > >
> > > This patch adds a led-backlight driver (led_bl), which is similar to
> > > pwm_bl except the driver uses a LED class driver to adjust the
> > > brightness in the HW. Multiple LEDs can be used for a single backlight.
> > >
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> > > Acked-by: Lee Jones <lee.jones@linaro.org>
> > > Acked-by: Tony Lindgren <tony@atomide.com>
> > > Tested-by: Tony Lindgren <tony@atomide.com>
> > > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > > ---
> > > drivers/video/backlight/Kconfig | 7 ++
> > > drivers/video/backlight/Makefile | 1 +
> > > drivers/video/backlight/led_bl.c | 260 +++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 268 insertions(+)
> > > create mode 100644 drivers/video/backlight/led_bl.c
> > >
> > > Hi!
> > >
> > > Here's the version of the driver I have. AFAICT
> > > default-brightness-level handling is ok, so does not need to be
> > > changed.
> > >
> > > Lee, it would be easiest for me if you could apply it to your tree and
> > > push, but given enough time I can push it to Linus, too.
> >
> > Oh you're using quoted-printable for patches.. Got it applied now,
> > and it still works. Below is also the related dts change that
> > I tested with.
> >
> > Feel free to pick the dts change too, naturally that should
> > not be applied before the driver.
> >
> > If you guys instead want me to pick these both into my fixes
> > branch, just let me know and I'll do the explaining why these
> > are needed as fixes. Basically we no longer have a way to enable
> > the LCD backlight for droid4 manually starting with v5.6-rc1
> > unlike earlier.
>
> Please do. You already have my Ack.
OK pushed out these two patches in omap-for-v5.6/droid4-lcd-fix.
Thanks,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [MODERATED] Re: [PATCH 0/2] more sampling fun 0
From: mark gross @ 2020-02-20 15:09 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220081420.GA3328448@kroah.com>
On Thu, Feb 20, 2020 at 09:14:20AM +0100, speck for Greg KH wrote:
> On Wed, Feb 19, 2020 at 02:45:22PM -0800, speck for mark gross wrote:
> > From: mark gross <mgross@linux.intel.com>
> > Subject: [PATCH 0/2] Special Register Buffer Data Sampling patch set
> >
> > Special Register Buffer Data Sampling is a sampling type of vulnerability that
> > leaks data across cores sharing the HW-RNG for vulnerable processors.
> >
> > This leak is fixed by a microcode update and is enabled by default.
> >
> > This new microcode serializes processor access during execution of RDRAND
> > or RDSEED. It ensures that the shared buffer is overwritten before it
> > is released for reuse.
> >
> > The mitigation impacts the throughput of the RDRAND and RDSEED instructions
> > and latency of RT processing running on the socket while executing RDRAND or
> > RDSEED. The micro bechmark of calling RDRAND many times shows a 10x slowdown.
>
> Then we need to stop using RDRAND internally for our "give me a random
> number api" which has spread to more and more parts of the kernel.
FWIW even if the opcodes are slowed by 10x there is no human noticable impact
on boot times. IMO its more a risk to RT applications than anything else.
--mark
> Here's a patch that does so:
> https://lore.kernel.org/lkml/20200216161836.1976-1-Jason@zx2c4.com/
> which I'm going to advise get merged now and backported to the stable
> branches.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH v5 3/3] btrfs: relocation: Use btrfs_backref_iter infrastructure
From: Josef Bacik @ 2020-02-20 15:09 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs; +Cc: Johannes Thumshirn
In-Reply-To: <20200218090129.134450-4-wqu@suse.com>
On 2/18/20 4:01 AM, Qu Wenruo wrote:
> In the core function of relocation, build_backref_tree, it needs to
> iterate all backref items of one tree block.
>
> We don't really want to spend our code and reviewers' time to going
> through tons of supportive code just for the backref walk.
>
> Use btrfs_backref_iter infrastructure to do the loop.
>
> The backref items look would be much more easier to read:
>
> ret = btrfs_backref_iter_start(iter, cur->bytenr);
> for (; ret == 0; ret = btrfs_backref_iter_next(iter)) {
> /* The really important work */
> }
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* [PATCH] Remove meta-arm-iota
From: Jon Mason @ 2020-02-20 15:09 UTC (permalink / raw)
To: meta-arm; +Cc: nd
Feedback received that it is not acceptable to have a distro layer
inside (https://lists.yoctoproject.org/g/meta-arm/message/6). Removing
from meta-arm and will create a separate git repository once that code
is ready.
Change-Id: I74d1083341d90caa038c1bd8c1d53aa565d28460
Signed-off-by: Jon Mason <jon.mason@arm.com>
---
meta-arm-iota/conf/layer.conf | 13 -------------
1 file changed, 13 deletions(-)
delete mode 100644 meta-arm-iota/conf/layer.conf
diff --git a/meta-arm-iota/conf/layer.conf b/meta-arm-iota/conf/layer.conf
deleted file mode 100644
index 392ed9b..0000000
--- a/meta-arm-iota/conf/layer.conf
+++ /dev/null
@@ -1,13 +0,0 @@
-# We have a conf and classes directory, add to BBPATH
-BBPATH .= ":${LAYERDIR}"
-
-# We have recipes-* directories, add to BBFILES
-BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
- ${LAYERDIR}/recipes-*/*/*.bbappend"
-
-BBFILE_COLLECTIONS += "meta-arm-iota"
-BBFILE_PATTERN_meta-arm-iota = "^${LAYERDIR}/"
-BBFILE_PRIORITY_meta-arm-iota = "6"
-
-LAYERDEPENDS_meta-arm-iota = "core"
-LAYERSERIES_COMPAT_meta-arm-iota = "warrior zeus"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 06/10] ASoC: tegra: add Tegra186 based DSPK driver
From: Jon Hunter @ 2020-02-20 15:10 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-7-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital Speaker Controller (DSPK) converts the multi-bit Pulse Code
> Modulation (PCM) audio input to oversampled 1-bit Pulse Density Modulation
> (PDM) output. From the signal flow perpsective, the DSPK can be viewed as
> a PDM transmitter that up-samples the input to the desired sampling rate
> by interpolation then converts the oversampled PCM input to the desired
> 1-bit output via Delta Sigma Modulation (DSM).
>
> This patch registers DSPK component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DSPK interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DSPK devices can be enabled in the DT via
> "nvidia,tegra186-dspk" compatible binding. This driver can be used
> on Tegra194 chip as well.
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> sound/soc/tegra/Kconfig | 13 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra186_dspk.c | 510 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra186_dspk.h | 73 ++++++
> 4 files changed, 598 insertions(+)
> create mode 100644 sound/soc/tegra/tegra186_dspk.c
> create mode 100644 sound/soc/tegra/tegra186_dspk.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 06/10] ASoC: tegra: add Tegra186 based DSPK driver
From: Jon Hunter @ 2020-02-20 15:10 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-7-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital Speaker Controller (DSPK) converts the multi-bit Pulse Code
> Modulation (PCM) audio input to oversampled 1-bit Pulse Density Modulation
> (PDM) output. From the signal flow perpsective, the DSPK can be viewed as
> a PDM transmitter that up-samples the input to the desired sampling rate
> by interpolation then converts the oversampled PCM input to the desired
> 1-bit output via Delta Sigma Modulation (DSM).
>
> This patch registers DSPK component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DSPK interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DSPK devices can be enabled in the DT via
> "nvidia,tegra186-dspk" compatible binding. This driver can be used
> on Tegra194 chip as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 13 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra186_dspk.c | 510 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra186_dspk.h | 73 ++++++
> 4 files changed, 598 insertions(+)
> create mode 100644 sound/soc/tegra/tegra186_dspk.c
> create mode 100644 sound/soc/tegra/tegra186_dspk.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for tools/i915-perf: workaround overzelous compiler warnings (rev2)
From: Patchwork @ 2020-02-20 15:10 UTC (permalink / raw)
To: Lionel Landwerlin; +Cc: igt-dev
In-Reply-To: <20200220133416.1194071-1-lionel.g.landwerlin@intel.com>
== Series Details ==
Series: tools/i915-perf: workaround overzelous compiler warnings (rev2)
URL : https://patchwork.freedesktop.org/series/73709/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> IGTPW_4196
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/index.html
New tests
---------
New tests have been introduced between CI_DRM_7973 and IGTPW_4196:
### New IGT tests (4) ###
* igt@i915_pm_backlight@basic-brightness:
- Statuses : 1 dmesg-warn(s) 17 pass(s) 23 skip(s)
- Exec time: [0.0, 0.24] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses : 1 dmesg-warn(s) 29 pass(s) 11 skip(s)
- Exec time: [0.0, 6.85] s
* igt@i915_pm_rpm@basic-rte:
- Statuses : 1 dmesg-warn(s) 29 pass(s) 11 skip(s)
- Exec time: [0.44, 11.31] s
* igt@i915_pm_rps@basic-api:
- Statuses : 36 pass(s) 5 skip(s)
- Exec time: [0.0, 0.01] s
Known issues
------------
Here are the changes found in IGTPW_4196 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-peppy/igt@gem_close_race@basic-threads.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-hsw-peppy/igt@gem_close_race@basic-threads.html
- fi-byt-n2820: [PASS][3] -> [INCOMPLETE][4] ([i915#45])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@gem_close_race@basic-threads.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-byt-n2820/igt@gem_close_race@basic-threads.html
* igt@gem_flink_basic@bad-flink:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([CI#94] / [i915#402])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@gem_flink_basic@bad-flink.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-tgl-y/igt@gem_flink_basic@bad-flink.html
* igt@i915_selftest@live_gtt:
- fi-bdw-5557u: [PASS][7] -> [TIMEOUT][8] ([fdo#112271])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [FAIL][9] ([CI#94]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@gem_exec_suspend@basic-s4-devices.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-tgl-y/igt@gem_exec_suspend@basic-s4-devices.html
* igt@gem_mmap@basic:
- fi-tgl-y: [DMESG-WARN][11] ([CI#94] / [i915#402]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@gem_mmap@basic.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-tgl-y/igt@gem_mmap@basic.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][13] ([i915#877]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][15] ([i915#217]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
- fi-kbl-7500u: [FAIL][17] ([fdo#111407]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 47)
------------------------------
Additional (5): fi-kbl-soraka fi-ivb-3770 fi-pnv-d510 fi-skl-lmem fi-kbl-7560u
Missing (7): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5453 -> IGTPW_4196
CI-20190529: 20190529
CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4196: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/index.html
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* [dpdk-dev] [PATCH] cryptodev: fix missing device id range checking
From: Adam Dybkowski @ 2020-02-20 15:04 UTC (permalink / raw)
To: dev, fiona.trahe, akhil.goyal; +Cc: Adam Dybkowski, stable
This patch adds range-checking of the device id passed from
the user app code. It prevents out-of-range array accesses
which in some situations resulted in an
application crash (segfault).
Fixes: 3dd4435cf473 ("cryptodev: fix checks related to device id")
Cc: stable@dpdk.org
Signed-off-by: Adam Dybkowski <adamx.dybkowski@intel.com>
---
lib/librte_cryptodev/rte_cryptodev.c | 41 +++++++++++++++++++++++++---
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 6d1d0e9d3..65d61a3ef 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -529,7 +529,8 @@ rte_cryptodev_pmd_get_named_dev(const char *name)
static inline uint8_t
rte_cryptodev_is_valid_device_data(uint8_t dev_id)
{
- if (rte_crypto_devices[dev_id].data == NULL)
+ if (dev_id >= RTE_CRYPTO_MAX_DEVS ||
+ rte_crypto_devices[dev_id].data == NULL)
return 0;
return 1;
@@ -621,8 +622,9 @@ rte_cryptodev_devices_get(const char *driver_name, uint8_t *devices,
void *
rte_cryptodev_get_sec_ctx(uint8_t dev_id)
{
- if (rte_crypto_devices[dev_id].feature_flags &
- RTE_CRYPTODEV_FF_SECURITY)
+ if (dev_id < RTE_CRYPTO_MAX_DEVS &&
+ (rte_crypto_devices[dev_id].feature_flags &
+ RTE_CRYPTODEV_FF_SECURITY))
return rte_crypto_devices[dev_id].security_ctx;
return NULL;
@@ -793,6 +795,11 @@ rte_cryptodev_queue_pair_count(uint8_t dev_id)
{
struct rte_cryptodev *dev;
+ if (!rte_cryptodev_is_valid_device_data(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return 0;
+ }
+
dev = &rte_crypto_devices[dev_id];
return dev->data->nb_queue_pairs;
}
@@ -1258,6 +1265,11 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
uint8_t index;
int ret;
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return -EINVAL;
+ }
+
dev = rte_cryptodev_pmd_get_dev(dev_id);
if (sess == NULL || xforms == NULL || dev == NULL)
@@ -1297,6 +1309,11 @@ rte_cryptodev_asym_session_init(uint8_t dev_id,
uint8_t index;
int ret;
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return -EINVAL;
+ }
+
dev = rte_cryptodev_pmd_get_dev(dev_id);
if (sess == NULL || xforms == NULL || dev == NULL)
@@ -1432,6 +1449,11 @@ rte_cryptodev_sym_session_clear(uint8_t dev_id,
struct rte_cryptodev *dev;
uint8_t driver_id;
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return -EINVAL;
+ }
+
dev = rte_cryptodev_pmd_get_dev(dev_id);
if (dev == NULL || sess == NULL)
@@ -1456,6 +1478,11 @@ rte_cryptodev_asym_session_clear(uint8_t dev_id,
{
struct rte_cryptodev *dev;
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return -EINVAL;
+ }
+
dev = rte_cryptodev_pmd_get_dev(dev_id);
if (dev == NULL || sess == NULL)
@@ -1789,8 +1816,14 @@ rte_cryptodev_driver_id_get(const char *name)
const char *
rte_cryptodev_name_get(uint8_t dev_id)
{
- struct rte_cryptodev *dev = rte_cryptodev_pmd_get_dev(dev_id);
+ struct rte_cryptodev *dev;
+ if (!rte_cryptodev_is_valid_device_data(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return NULL;
+ }
+
+ dev = rte_cryptodev_pmd_get_dev(dev_id);
if (dev == NULL)
return NULL;
--
2.17.1
^ permalink raw reply related
* [Cluster-devel] [PATCH v7 10/24] mm: Add readahead address space operation
From: Matthew Wilcox @ 2020-02-20 15:10 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <5D7CE6BD-FABD-4901-AEF0-E0F10FC00EB1@nvidia.com>
On Thu, Feb 20, 2020 at 10:00:30AM -0500, Zi Yan wrote:
> > +/* The index of the first page in this readahead block */
> > +static inline unsigned int readahead_index(struct readahead_control *rac)
> > +{
> > + return rac->_index;
> > +}
>
> rac->_index is pgoff_t, so readahead_index() should return the same type, right?
> BTW, pgoff_t is unsigned long.
Oh my goodness! Thank you for spotting that. Fortunately, it's only
currently used by tracepoints, so it wasn't causing any trouble, but
that's a nasty landmine to leave lying around. Fixed:
static inline pgoff_t readahead_index(struct readahead_control *rac)
^ permalink raw reply
* [Ocfs2-devel] [PATCH v7 10/24] mm: Add readahead address space operation
From: Matthew Wilcox @ 2020-02-20 15:10 UTC (permalink / raw)
To: Zi Yan
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <5D7CE6BD-FABD-4901-AEF0-E0F10FC00EB1@nvidia.com>
On Thu, Feb 20, 2020 at 10:00:30AM -0500, Zi Yan wrote:
> > +/* The index of the first page in this readahead block */
> > +static inline unsigned int readahead_index(struct readahead_control *rac)
> > +{
> > + return rac->_index;
> > +}
>
> rac->_index is pgoff_t, so readahead_index() should return the same type, right?
> BTW, pgoff_t is unsigned long.
Oh my goodness! Thank you for spotting that. Fortunately, it's only
currently used by tracepoints, so it wasn't causing any trouble, but
that's a nasty landmine to leave lying around. Fixed:
static inline pgoff_t readahead_index(struct readahead_control *rac)
^ permalink raw reply
* Re: [PATCH v7 10/24] mm: Add readahead address space operation
From: Matthew Wilcox @ 2020-02-20 15:10 UTC (permalink / raw)
To: Zi Yan
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <5D7CE6BD-FABD-4901-AEF0-E0F10FC00EB1@nvidia.com>
On Thu, Feb 20, 2020 at 10:00:30AM -0500, Zi Yan wrote:
> > +/* The index of the first page in this readahead block */
> > +static inline unsigned int readahead_index(struct readahead_control *rac)
> > +{
> > + return rac->_index;
> > +}
>
> rac->_index is pgoff_t, so readahead_index() should return the same type, right?
> BTW, pgoff_t is unsigned long.
Oh my goodness! Thank you for spotting that. Fortunately, it's only
currently used by tracepoints, so it wasn't causing any trouble, but
that's a nasty landmine to leave lying around. Fixed:
static inline pgoff_t readahead_index(struct readahead_control *rac)
^ permalink raw reply
* Re: [PATCH v7 10/24] mm: Add readahead address space operation
From: Matthew Wilcox @ 2020-02-20 15:10 UTC (permalink / raw)
To: Zi Yan
Cc: linux-xfs, linux-kernel, linux-f2fs-devel, cluster-devel,
linux-mm, ocfs2-devel, linux-fsdevel, linux-ext4, linux-erofs,
linux-btrfs
In-Reply-To: <5D7CE6BD-FABD-4901-AEF0-E0F10FC00EB1@nvidia.com>
On Thu, Feb 20, 2020 at 10:00:30AM -0500, Zi Yan wrote:
> > +/* The index of the first page in this readahead block */
> > +static inline unsigned int readahead_index(struct readahead_control *rac)
> > +{
> > + return rac->_index;
> > +}
>
> rac->_index is pgoff_t, so readahead_index() should return the same type, right?
> BTW, pgoff_t is unsigned long.
Oh my goodness! Thank you for spotting that. Fortunately, it's only
currently used by tracepoints, so it wasn't causing any trouble, but
that's a nasty landmine to leave lying around. Fixed:
static inline pgoff_t readahead_index(struct readahead_control *rac)
^ permalink raw reply
* Re: [PATCH] ext4: fix handling mount -o remount,nolazytime
From: Konstantin Khlebnikov @ 2020-02-20 15:11 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Andreas Dilger, linux-ext4, Karel Zak, Dmitry Monakhov
In-Reply-To: <20200219162242.GI330201@mit.edu>
On 19/02/2020 19.22, Theodore Y. Ts'o wrote:
> On Wed, Feb 19, 2020 at 12:19:52PM +0300, Konstantin Khlebnikov wrote:
>> Tool "mount" from util-linux >= 2.27 knows about flag MS_LAZYTIME and
>> handles options "lazytime" and "nolazytime" as fs-independent.
>>
>> For ext4 it works for enabling lazytime: mount(MS_REMOUNT | MS_LAZYTIME),
>> but does not work for disabling: mount(MS_REMOUNT).
>>
>> Currently ext4 has performance issue in lazytime implementation caused by
>> contention around inode_hash_lock in ext4_update_other_inodes_time().
>>
>> Fortunately lazytime still could be disabled without unmounting by passing
>> "nolazytime" as fs-specific mount option: mount(MS_REMOUNT, "nolazytime").
>> But modern versions of tool "mount" cannot do that.
>>
>> This patch fixes remount for modern tool and keeps backward compatibility.
>
> Actually, if you are using ancient versions of mount that don't know
> about MS_LAZYTIME, then when you do something like mount -o
> remount,usrquota /dev/sdb" with your patch, it will disable
> MS_LAZYTIME, which would be a backwards incompatible change.
>
> So if we make this change, and there is someone who wants to use
> lazytime on some ancient enterprise linux system which is still using
> an old version of util-linux, and then take a kernel with this change,
> then it will result in a change in the behavior they will see. The
> good news is that RHEL 8 is using util-linux 2.32, but RHEL 7 is still
> using util-linux 2.23.
>
> Lazytime is not enabled by default, so this issue is really only a
> problem for someone which explicitly enables lazytime using a newer
> version of util-linux, and then disables lazytime with a newer version
> of util-linux. So the behaviour of a2fd66d069d8 ("ext4: set lazytime
> on remount if MS_LAZYTIME is set by mount") was in fact an explicit
> decision to do things in that way.
>
> So maybe we might want to change things, assuming that it's unlikely
> users will try to be running new kernels on ancient distros. But I
> really wouldn't want to add a Fixes tag, and I would want to make sure
> this doesn't get backported to older kernels, since the change does
> *not* keep backwards compatibility.
>
> Unfortunately, it's not possible to do this without breaking
> compatibility for at least some systems. The question is whether or
> not we think systems running util-linux less than 2.27 is something we
> care about for new kernels. Times may have changed since
> a2fd66d069d8.
>
> So I might be willing to take this patch (I invite comments from
> others), but there will need to be a DO NOT BACKPORT warning in the
> commit description.
Usually all these options are saved in /etc/fstab and
mount -o remount,... includes them into line passed into syscall.
In this case remounting any other option will not disable lazytime.
But there might be implementations of /bin/mount which doesn't do that.
>
> Cheers,
>
> - Ted
>
^ permalink raw reply
* Re: [PATCH 1/4] Btrfs: move all reflink implementation code into its own file
From: Josef Bacik @ 2020-02-20 15:11 UTC (permalink / raw)
To: fdmanana, linux-btrfs
In-Reply-To: <20200219140547.1641512-1-fdmanana@kernel.org>
On 2/19/20 9:05 AM, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> The reflink code is quite large and has been living in ioctl.c since ever.
> It has grown over the years after many bug fixes and improvements, and
> since I'm planning on making some further improvements on it, it's time
> to get it better organized by moving into its own file, reflink.c
> (similar to what xfs does for example).
>
> This change only moves the code out of ioctl.c into the new file, it
> doesn't do any other change.
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* [PATCH v6 05/16] arc/mm: Use helper fault_signal_pending()
From: Peter Xu @ 2020-02-20 15:11 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Peter Xu, Martin Cracauer, Mike Rapoport, Hugh Dickins,
Jerome Glisse, Kirill A . Shutemov, Matthew Wilcox,
Pavel Emelyanov, Brian Geffon, Maya Gokhale, Denis Plotnikov,
Andrea Arcangeli, Johannes Weiner, Dr . David Alan Gilbert,
Linus Torvalds, Mike Kravetz, Marty McFadden, David Hildenbrand,
Bobby Powers, Mel Gorman
In-Reply-To: <20200220145432.4561-1-peterx@redhat.com>
Let ARC to use the new helper fault_signal_pending() by moving the
signal check out of the retry logic as standalone. This should also
helps to simplify the code a bit.
Signed-off-by: Peter Xu <peterx@redhat.com>
---
arch/arc/mm/fault.c | 34 +++++++++++++---------------------
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index fb86bc3e9b35..6eb821a59b49 100644
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
@@ -133,29 +133,21 @@ void do_page_fault(unsigned long address, struct pt_regs *regs)
fault = handle_mm_fault(vma, address, flags);
+ /* Quick path to respond to signals */
+ if (fault_signal_pending(fault, regs)) {
+ if (!user_mode(regs))
+ goto no_context;
+ return;
+ }
+
/*
- * Fault retry nuances
+ * Fault retry nuances, mmap_sem already relinquished by core mm
*/
- if (unlikely(fault & VM_FAULT_RETRY)) {
-
- /*
- * If fault needs to be retried, handle any pending signals
- * first (by returning to user mode).
- * mmap_sem already relinquished by core mm for RETRY case
- */
- if (fatal_signal_pending(current)) {
- if (!user_mode(regs))
- goto no_context;
- return;
- }
- /*
- * retry state machine
- */
- if (flags & FAULT_FLAG_ALLOW_RETRY) {
- flags &= ~FAULT_FLAG_ALLOW_RETRY;
- flags |= FAULT_FLAG_TRIED;
- goto retry;
- }
+ if (unlikely((fault & VM_FAULT_RETRY) &&
+ (flags & FAULT_FLAG_ALLOW_RETRY))) {
+ flags &= ~FAULT_FLAG_ALLOW_RETRY;
+ flags |= FAULT_FLAG_TRIED;
+ goto retry;
}
bad_area:
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v3 06/10] ASoC: tegra: add Tegra186 based DSPK driver
From: Jon Hunter @ 2020-02-20 15:10 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-7-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital Speaker Controller (DSPK) converts the multi-bit Pulse Code
> Modulation (PCM) audio input to oversampled 1-bit Pulse Density Modulation
> (PDM) output. From the signal flow perpsective, the DSPK can be viewed as
> a PDM transmitter that up-samples the input to the desired sampling rate
> by interpolation then converts the oversampled PCM input to the desired
> 1-bit output via Delta Sigma Modulation (DSM).
>
> This patch registers DSPK component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DSPK interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DSPK devices can be enabled in the DT via
> "nvidia,tegra186-dspk" compatible binding. This driver can be used
> on Tegra194 chip as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 13 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra186_dspk.c | 510 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra186_dspk.h | 73 ++++++
> 4 files changed, 598 insertions(+)
> create mode 100644 sound/soc/tegra/tegra186_dspk.c
> create mode 100644 sound/soc/tegra/tegra186_dspk.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [Xen-devel] [PATCH] rwlock: allow recursive read locking when already locked in write mode
From: Jan Beulich @ 2020-02-20 15:11 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Jürgen Groß, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
xen-devel
In-Reply-To: <20200220143841.GL4679@Air-de-Roger>
On 20.02.2020 15:38, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 03:23:38PM +0100, Jürgen Groß wrote:
>> On 20.02.20 15:11, Roger Pau Monné wrote:
>>> On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
>>>> On 20.02.2020 13:02, Roger Pau Monne wrote:
>>>>> @@ -166,7 +180,8 @@ static inline void _write_unlock(rwlock_t *lock)
>>>>> * If the writer field is atomic, it can be cleared directly.
>>>>> * Otherwise, an atomic subtraction will be used to clear it.
>>>>> */
>>>>> - atomic_sub(_QW_LOCKED, &lock->cnts);
>>>>> + ASSERT(_is_write_locked_by_me(atomic_read(&lock->cnts)));
>>>>> + atomic_sub(_write_lock_val(), &lock->cnts);
>>>>
>>>> I think this would be more efficient with atomic_and(), not
>>>> the least because of the then avoided smp_processor_id().
>>>> Whether to mask off just _QW_WMASK or also the CPU number of
>>>> the last write owner would need to be determined. But with
>>>> using subtraction, in case of problems it'll likely be
>>>> harder to understand what actually went on, from looking at
>>>> the resulting state of the lock (this is in part a pre-
>>>> existing problem, but gets worse with subtraction of CPU
>>>> numbers).
>>>
>>> Right, a mask would be better. Right now both need to be cleared (the
>>> LOCKED and the CPU fields) as there's code that relies on !lock->cnts
>>> as a way to determine that the lock is not read or write locked. If we
>>> left the CPU lying around those checks would need to be adjusted.
>>
>> In case you make _QR_SHIFT 16 it is possible to just write a 2-byte zero
>> value for write_unlock() (like its possible to do so today using a
>> single byte write).
>
> That would limit the readers count to 65536, what do you think Jan?
If the recurse_cpu approach is considered bad, I think this would
be acceptable. But of course you'll need to consult with the Arm
guys regarding the correctness of such a "half" store in their
memory model; I would hope this to be universally okay, but I'm
not entirely certain.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH v2 0/3] Migration mechanism with FD
From: Oksana Vohchana @ 2020-02-20 15:10 UTC (permalink / raw)
To: qemu-devel; +Cc: ovoshcha, philmd, ehabkost, wainersm, crosa
To test migration through the file descriptor we should build and provide
a path to socket_scm_helper file. This way is inconvenient for acceptance
testing.
This series provides new functions to receive and send messages over a UNIX
socket. And adds a new migration test.
v2:
- Fix warning of line over 80 characters
Oksana Vohchana (3):
Adding functions _send_fds and _recv_fds
Updates send_fd_scm function
Acceptance test: FD migration
python/qemu/machine.py | 88 +++++++++++++++++++++++++----------
tests/acceptance/migration.py | 21 +++++++++
2 files changed, 85 insertions(+), 24 deletions(-)
--
2.21.1
^ permalink raw reply
* [PATCH v2 3/3] Acceptance test: FD migration
From: Oksana Vohchana @ 2020-02-20 15:10 UTC (permalink / raw)
To: qemu-devel; +Cc: ovoshcha, philmd, ehabkost, wainersm, crosa
In-Reply-To: <20200220151039.20552-1-ovoshcha@redhat.com>
Adds a new migration test through the file descriptor.
Signed-off-by: Oksana Vohchana <ovoshcha@redhat.com>
---
tests/acceptance/migration.py | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/tests/acceptance/migration.py b/tests/acceptance/migration.py
index a8367ca023..7f4879ce5d 100644
--- a/tests/acceptance/migration.py
+++ b/tests/acceptance/migration.py
@@ -10,7 +10,10 @@
# later. See the COPYING file in the top-level directory.
+import os
import tempfile
+from socket import socketpair, AF_UNIX, SOCK_STREAM
+
from avocado_qemu import Test
from avocado import skipUnless
@@ -75,3 +78,21 @@ class Migration(Test):
"""
free_port = self._get_free_port()
dest_uri = 'exec:nc -l localhost %u' % free_port
+
+ def test_migration_with_fd(self):
+ opaque = 'fd-migration'
+ data_to_send = b"{\"execute\": \"getfd\", \"arguments\": \
+ {\"fdname\": \"fd-migration\"}}"
+ send_socket, recv_socket = socketpair(AF_UNIX, SOCK_STREAM)
+ fd1 = send_socket.fileno()
+ fd2 = recv_socket.fileno()
+ os.set_inheritable(fd2, True)
+
+ source_vm = self.get_vm()
+ source_vm.launch()
+ source_vm.send_fd_scm(fd=fd1, data=data_to_send)
+
+ dest_vm = self.get_vm('-incoming', 'fd:%s' % fd2)
+ dest_vm.launch()
+ source_vm.qmp('migrate', uri='fd:%s' % opaque)
+ self.assert_migration(source_vm, dest_vm)
--
2.21.1
^ permalink raw reply related
* Re: [PATCH V4 5/5] vdpasim: vDPA device simulator
From: Jason Gunthorpe @ 2020-02-20 15:12 UTC (permalink / raw)
To: Jason Wang
Cc: mst@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
tiwei.bie@intel.com, maxime.coquelin@redhat.com,
cunming.liang@intel.com, zhihong.wang@intel.com,
rob.miller@broadcom.com, xiao.w.wang@intel.com,
haotian.wang@sifive.com, lingshan.zhu@intel.com,
eperezma@redhat.com, lulu@redhat.com
In-Reply-To: <20200220061141.29390-6-jasowang@redhat.com>
On Thu, Feb 20, 2020 at 02:11:41PM +0800, Jason Wang wrote:
> +static void vdpasim_device_release(struct device *dev)
> +{
> + struct vdpasim *vdpasim = dev_to_sim(dev);
> +
> + cancel_work_sync(&vdpasim->work);
> + kfree(vdpasim->buffer);
> + vhost_iotlb_free(vdpasim->iommu);
> + kfree(vdpasim);
> +}
> +
> +static struct vdpasim *vdpasim_create(void)
> +{
> + struct virtio_net_config *config;
> + struct vhost_iotlb *iommu;
> + struct vdpasim *vdpasim;
> + struct device *dev;
> + void *buffer;
> + int ret = -ENOMEM;
> +
> + iommu = vhost_iotlb_alloc(2048, 0);
> + if (!iommu)
> + goto err;
> +
> + buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!buffer)
> + goto err_buffer;
> +
> + vdpasim = kzalloc(sizeof(*vdpasim), GFP_KERNEL);
> + if (!vdpasim)
> + goto err_alloc;
> +
> + vdpasim->buffer = buffer;
> + vdpasim->iommu = iommu;
> +
> + config = &vdpasim->config;
> + config->mtu = 1500;
> + config->status = VIRTIO_NET_S_LINK_UP;
> + eth_random_addr(config->mac);
> +
> + INIT_WORK(&vdpasim->work, vdpasim_work);
> + spin_lock_init(&vdpasim->lock);
> +
> + vringh_set_iotlb(&vdpasim->vqs[0].vring, vdpasim->iommu);
> + vringh_set_iotlb(&vdpasim->vqs[1].vring, vdpasim->iommu);
> +
> + dev = &vdpasim->dev;
> + dev->release = vdpasim_device_release;
> + dev->coherent_dma_mask = DMA_BIT_MASK(64);
> + set_dma_ops(dev, &vdpasim_dma_ops);
> + dev_set_name(dev, "%s", VDPASIM_NAME);
> +
> + ret = device_register(&vdpasim->dev);
> + if (ret)
> + goto err_init;
It is a bit weird to be creating this dummy parent, couldn't this be
done by just passing a NULL parent to vdpa_alloc_device, doing
set_dma_ops() on the vdpasim->vdpa->dev and setting dma_device to
vdpasim->vdpa->dev ?
> + vdpasim->vdpa = vdpa_alloc_device(dev, dev, &vdpasim_net_config_ops);
> + if (ret)
> + goto err_vdpa;
> + ret = vdpa_register_device(vdpasim->vdpa);
> + if (ret)
> + goto err_register;
> +
> + return vdpasim;
> +
> +err_register:
> + put_device(&vdpasim->vdpa->dev);
> +err_vdpa:
> + device_del(&vdpasim->dev);
> + goto err;
> +err_init:
> + put_device(&vdpasim->dev);
> + goto err;
If you do the vdmasim alloc first, and immediately do
device_initialize() then all the failure paths can do put_device
instead of having this ugly goto unwind split. Just check for
vdpasim->iommu == NULL during release.
> +static int __init vdpasim_dev_init(void)
> +{
> + vdpasim_dev = vdpasim_create();
> +
> + if (!IS_ERR(vdpasim_dev))
> + return 0;
> +
> + return PTR_ERR(vdpasim_dev);
> +}
> +
> +static int vdpasim_device_remove_cb(struct device *dev, void *data)
> +{
> + struct vdpa_device *vdpa = dev_to_vdpa(dev);
> +
> + vdpa_unregister_device(vdpa);
> +
> + return 0;
> +}
> +
> +static void __exit vdpasim_dev_exit(void)
> +{
> + device_for_each_child(&vdpasim_dev->dev, NULL,
> + vdpasim_device_remove_cb);
Why the loop? There is only one device, and it is in the global
varaible vdmasim_dev ?
Jason
^ permalink raw reply
* Re: [PATCH V4 5/5] vdpasim: vDPA device simulator
From: Jason Gunthorpe @ 2020-02-20 15:12 UTC (permalink / raw)
To: Jason Wang
Cc: mst@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
tiwei.bie@intel.com, maxime.coquelin@redhat.com,
cunming.liang@intel.com, zhihong.wang@intel.com,
rob.miller@broadcom.com, xiao.w.wang@intel.com,
haotian.wang@sifive.com, lingshan.zhu@intel.com,
eperezma@redhat.com, lulu@redhat.com, Parav Pandit,
kevin.tian@intel.com, stefanha@redhat.com, rdunlap@infradead.org,
hch@infradead.org, aadam@redhat.com, Jiri Pirko, Shahaf Shuler,
hanand@xilinx.com, mhabets@solarflare.com
In-Reply-To: <20200220061141.29390-6-jasowang@redhat.com>
On Thu, Feb 20, 2020 at 02:11:41PM +0800, Jason Wang wrote:
> +static void vdpasim_device_release(struct device *dev)
> +{
> + struct vdpasim *vdpasim = dev_to_sim(dev);
> +
> + cancel_work_sync(&vdpasim->work);
> + kfree(vdpasim->buffer);
> + vhost_iotlb_free(vdpasim->iommu);
> + kfree(vdpasim);
> +}
> +
> +static struct vdpasim *vdpasim_create(void)
> +{
> + struct virtio_net_config *config;
> + struct vhost_iotlb *iommu;
> + struct vdpasim *vdpasim;
> + struct device *dev;
> + void *buffer;
> + int ret = -ENOMEM;
> +
> + iommu = vhost_iotlb_alloc(2048, 0);
> + if (!iommu)
> + goto err;
> +
> + buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!buffer)
> + goto err_buffer;
> +
> + vdpasim = kzalloc(sizeof(*vdpasim), GFP_KERNEL);
> + if (!vdpasim)
> + goto err_alloc;
> +
> + vdpasim->buffer = buffer;
> + vdpasim->iommu = iommu;
> +
> + config = &vdpasim->config;
> + config->mtu = 1500;
> + config->status = VIRTIO_NET_S_LINK_UP;
> + eth_random_addr(config->mac);
> +
> + INIT_WORK(&vdpasim->work, vdpasim_work);
> + spin_lock_init(&vdpasim->lock);
> +
> + vringh_set_iotlb(&vdpasim->vqs[0].vring, vdpasim->iommu);
> + vringh_set_iotlb(&vdpasim->vqs[1].vring, vdpasim->iommu);
> +
> + dev = &vdpasim->dev;
> + dev->release = vdpasim_device_release;
> + dev->coherent_dma_mask = DMA_BIT_MASK(64);
> + set_dma_ops(dev, &vdpasim_dma_ops);
> + dev_set_name(dev, "%s", VDPASIM_NAME);
> +
> + ret = device_register(&vdpasim->dev);
> + if (ret)
> + goto err_init;
It is a bit weird to be creating this dummy parent, couldn't this be
done by just passing a NULL parent to vdpa_alloc_device, doing
set_dma_ops() on the vdpasim->vdpa->dev and setting dma_device to
vdpasim->vdpa->dev ?
> + vdpasim->vdpa = vdpa_alloc_device(dev, dev, &vdpasim_net_config_ops);
> + if (ret)
> + goto err_vdpa;
> + ret = vdpa_register_device(vdpasim->vdpa);
> + if (ret)
> + goto err_register;
> +
> + return vdpasim;
> +
> +err_register:
> + put_device(&vdpasim->vdpa->dev);
> +err_vdpa:
> + device_del(&vdpasim->dev);
> + goto err;
> +err_init:
> + put_device(&vdpasim->dev);
> + goto err;
If you do the vdmasim alloc first, and immediately do
device_initialize() then all the failure paths can do put_device
instead of having this ugly goto unwind split. Just check for
vdpasim->iommu == NULL during release.
> +static int __init vdpasim_dev_init(void)
> +{
> + vdpasim_dev = vdpasim_create();
> +
> + if (!IS_ERR(vdpasim_dev))
> + return 0;
> +
> + return PTR_ERR(vdpasim_dev);
> +}
> +
> +static int vdpasim_device_remove_cb(struct device *dev, void *data)
> +{
> + struct vdpa_device *vdpa = dev_to_vdpa(dev);
> +
> + vdpa_unregister_device(vdpa);
> +
> + return 0;
> +}
> +
> +static void __exit vdpasim_dev_exit(void)
> +{
> + device_for_each_child(&vdpasim_dev->dev, NULL,
> + vdpasim_device_remove_cb);
Why the loop? There is only one device, and it is in the global
varaible vdmasim_dev ?
Jason
^ 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.