* Re: Incorrect name of PCM
From: Christopher Head @ 2018-07-23 16:14 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <s5h7elm1k39.wl-tiwai@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 921 bytes --]
On July 23, 2018 12:34:34 AM PDT, Takashi Iwai <tiwai@suse.de> wrote:
>
>For playing via HDMI on your machine, you'd need to pass as "aplay -L"
>shows, one of the following:
>
>> hdmi:CARD=NVidia,DEV=0
>> HDA NVidia, HDMI 0
>> HDMI Audio Output
>> hdmi:CARD=NVidia,DEV=1
>> HDA NVidia, HDMI 1
>> HDMI Audio Output
>> hdmi:CARD=NVidia,DEV=2
>> HDA NVidia, HDMI 2
>> HDMI Audio Output
>> hdmi:CARD=NVidia,DEV=3
>> HDA NVidia, HDMI 3
>> HDMI Audio Output
>
>The device number depends on the HDMI port you plugged in.
>The above can be in a shorter form like "hdmi:1,0", too.
Hi,
Thanks for responding. Did you miss this part of the aplay -L output?
hdmi:CARD=PCH,DEV=0
HDA Intel PCH, VT1708S Digital
HDMI Audio Output
This is the part I think is wrong, not the parts mentioning the NVidia HDMI outputs.
Thanks,
--
Christopher Head
--
Christopher Head
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 244 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a77980: add RWDT support
From: Sergei Shtylyov @ 2018-07-23 16:14 UTC (permalink / raw)
To: Simon Horman
Cc: Mark Rutland, devicetree, Catalin Marinas, Magnus Damm,
Will Deacon, linux-renesas-soc, Rob Herring, linux-arm-kernel
In-Reply-To: <20180723160827.ziuivshq2mtagexq@verge.net.au>
On 07/23/2018 07:08 PM, Simon Horman wrote:
>> Describe RWDT in the R8A77980 SoC device tree.
>>
>> Enable RWDT on the Condor and V3H Starter Kit boards.
>>
>> Based on the original (and large) patch by Vladimir Barinov.
>>
>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> The patch is against the 'renesas-devel-20180720-v4.18-rc5' of Simon Horman's
>> 'renesas.git' repo. It depends on Geert Uytterhoeven's clock driver patches
>> (adding the RWDT clock) in order to work...
>
> But it is safe to apply without those patches, right?
The RWDT driver should just fail to probe with -ENOENT.
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
TY!
MBR, Sergei
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77980: add RWDT support
From: Sergei Shtylyov @ 2018-07-23 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723160827.ziuivshq2mtagexq@verge.net.au>
On 07/23/2018 07:08 PM, Simon Horman wrote:
>> Describe RWDT in the R8A77980 SoC device tree.
>>
>> Enable RWDT on the Condor and V3H Starter Kit boards.
>>
>> Based on the original (and large) patch by Vladimir Barinov.
>>
>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> The patch is against the 'renesas-devel-20180720-v4.18-rc5' of Simon Horman's
>> 'renesas.git' repo. It depends on Geert Uytterhoeven's clock driver patches
>> (adding the RWDT clock) in order to work...
>
> But it is safe to apply without those patches, right?
The RWDT driver should just fail to probe with -ENOENT.
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
TY!
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a77980: add RWDT support
From: Sergei Shtylyov @ 2018-07-23 16:14 UTC (permalink / raw)
To: Simon Horman
Cc: linux-renesas-soc, Rob Herring, devicetree, Mark Rutland,
Magnus Damm, linux-arm-kernel, Catalin Marinas, Will Deacon
In-Reply-To: <20180723160827.ziuivshq2mtagexq@verge.net.au>
On 07/23/2018 07:08 PM, Simon Horman wrote:
>> Describe RWDT in the R8A77980 SoC device tree.
>>
>> Enable RWDT on the Condor and V3H Starter Kit boards.
>>
>> Based on the original (and large) patch by Vladimir Barinov.
>>
>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> The patch is against the 'renesas-devel-20180720-v4.18-rc5' of Simon Horman's
>> 'renesas.git' repo. It depends on Geert Uytterhoeven's clock driver patches
>> (adding the RWDT clock) in order to work...
>
> But it is safe to apply without those patches, right?
The RWDT driver should just fail to probe with -ENOENT.
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
TY!
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] drivers/memory/Kconfig: Add CONFIG_OF dependency
From: Boris Brezillon @ 2018-07-23 16:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Randy Dunlap, Anders Roxell, Miquel Raynal,
Linux Kernel Mailing List, Rob Herring, DTML
In-Reply-To: <CAK8P3a0p_8HWz0kLLrkwmpcbt4BsMiDG=hFK4SxeJygucZ1yMg@mail.gmail.com>
On Mon, 23 Jul 2018 18:04:52 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jul 23, 2018 at 5:40 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Mon, Jul 23, 2018 at 11:41 AM, Boris Brezillon
> > <boris.brezillon@bootlin.com> wrote:
> >> On Mon, 23 Jul 2018 11:34:43 +0200
> >> Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >>> On Sun, Jul 22, 2018 at 8:29 AM, Boris Brezillon
> >>> <boris.brezillon@bootlin.com> wrote:
> >>> > +Arnd, Rob and the DT ML.
> >>> >
> >>> > On Sat, 21 Jul 2018 14:53:47 -0700
> >>> > Randy Dunlap <rdunlap@infradead.org> wrote:
> >>> >
> >>> >> On 07/21/2018 01:00 PM, Anders Roxell wrote:
> >>> >> > JZ4780_NEMC doesn't depend on OF, and if OF isn't enabled we get this
> >>> >> > error:
> >>> >> > drivers/memory/jz4780-nemc.c: In function ‘jz4780_nemc_num_banks’:
> >>> >> > drivers/memory/jz4780-nemc.c:72:10: error: implicit declaration of
> >>> >> > function ‘of_read_number’; did you mean ‘down_read_nested’?
> >>> >> > [-Werror=implicit-function-declaration]
> >>> >> > bank = of_read_number(prop, 1);
> >>> >> > ^~~~~~~~~~~~~~
> >>> >> > down_read_nested
> >>> >
> >>> > Looks like of.h defines stubs so that people can compile-test without
> >>> > CONFIG_OF selected. Maybe we should move of_read_number() and
> >>> > of_read_ulong() out of the #ifdef CONFIG_OF section.
> >>>
> >>> That seems fine, though the added dependency seems appropriate
> >>> here as well. of_read_number() is rarely used, and for the most part in
> >>> powerpc specific code that is guaranteed to have CONFIG_OF enabled,
> >>> so it's not that likely to cause many more problems.
> >>
> >> Ok, then I'll let Miquel apply Anders' patch to the NAND tree.
> >>
> >> Thanks for your feedback.
> >
> > My randconfig build bot just ran into a second problem with this driver
> > with CONFIG_GPIOLIB disabled:
> >
> > drivers/mtd/nand/raw/jz4740_nand.c: In function 'jz_nand_dev_ready':
> > drivers/mtd/nand/raw/jz4740_nand.c:133:9: error: implicit declaration
> > of function 'gpiod_get_value_cansleep'; did you mean
> > 'gpio_get_value_cansleep'? [-Werror=implicit-function-declaration]
> > return gpiod_get_value_cansleep(nand->busy_gpio);
> > ^~~~~~~~~~~~~~~~~~~~~~~~
> > gpio_get_value_cansleep
> > drivers/mtd/nand/raw/jz4740_nand.c: In function 'jz_nand_probe':
> > drivers/mtd/nand/raw/jz4740_nand.c:388:20: error: implicit declaration
> > of function 'devm_gpiod_get_optional'; did you mean
> > 'devm_gpio_request_one'? [-Werror=implicit-function-declaration]
> > nand->busy_gpio = devm_gpiod_get_optional(&pdev->dev, "busy", GPIOD_IN);
> > ^~~~~~~~~~~~~~~~~~~~~~~
> > devm_gpio_request_one
> > drivers/mtd/nand/raw/jz4740_nand.c:388:64: error: 'GPIOD_IN'
> > undeclared (first use in this function); did you mean 'GPIOF_IN'?
> > nand->busy_gpio = devm_gpiod_get_optional(&pdev->dev, "busy", GPIOD_IN);
> > ^~~~~~~~
> > GPIOF_IN
> >
> >
> > We could add another dependency here or (my preference) include
> > linux/gpio/consumer.h to fix that. Do you want a separate patch for
> > it, or should Anders send a combined patch?
>
> One more failure, not analyzed yet:
>
> /git/arm-soc/drivers/mtd/nand/raw/jz4740_nand.c: In function
> 'jz_nand_select_chip':
> /git/arm-soc/drivers/mtd/nand/raw/jz4740_nand.c:87:9: error: implicit
> declaration of function 'readl'; did you mean 'krealloc'?
> [-Werror=implicit-function-declaration]
> ctrl = readl(nand->base + JZ_REG_NAND_CTRL);
> ^~~~~
Yep, somehow io.h was indirectly included by gpio.h. I fixed that in my
patch when replacing gpio.h by gpio/consumer.h by including linux/io.h.
^ permalink raw reply
* Re: wireguardnl: Go package for interacting with WireGuard via generic netlink
From: Jason A. Donenfeld @ 2018-07-23 16:22 UTC (permalink / raw)
To: mdlayher; +Cc: WireGuard mailing list
In-Reply-To: <ba866611-cd70-5183-bcd4-1ea1e7cc36a5@gmail.com>
On Mon, Jul 23, 2018 at 5:59 PM Matt Layher <mdlayher@gmail.com> wrote:
>
> An update for those on the list, I've implemented Jason's requested name
> change and the API is now set up to allow seamless kernel and userspace
> implementations via https://godoc.org/github.com/mdlayher/wireguardctrl.
>
> I will explicitly encourage callers to use this interface rather than
> the "wireguardnl" package, unless we do end up with useful
> netlink-specific functionality like the situation I described previously.
>
> I'll keep working on this for now and report back when I have a working
> userspace implementation. Should be quite straightforward compared to
> dealing with netlink! :)
Wonderful! Thanks Matt!
^ permalink raw reply
* Re: wireguardnl: Go package for interacting with WireGuard via generic netlink
From: Jason A. Donenfeld @ 2018-07-23 16:22 UTC (permalink / raw)
To: mdlayher; +Cc: WireGuard mailing list
In-Reply-To: <4de6eec9-9239-5e4e-60c1-e287b3be336a@gmail.com>
Hey Matt,
On Mon, Jul 23, 2018 at 5:29 PM Matt Layher <mdlayher@gmail.com> wrote:
> While I will encourage the use of the unified interface, I read that
> there could be future work to allow the netlink interface to support
> something like multicast group notifications. Would you plan on
> implementing the same functionality for the userspace interface?
Yes, absolutely. We're aiming for full parity with the API.
^ permalink raw reply
* master - lvconvert: restrict command matching for no option variant
From: David Teigland @ 2018-07-23 16:13 UTC (permalink / raw)
To: lvm-devel
Gitweb: https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=8a66c81b9beb87f2f381e7e2aa76e4e54fd19934
Commit: 8a66c81b9beb87f2f381e7e2aa76e4e54fd19934
Parent: 63ec42f428e010dcc638d887a5089d491b36b0e9
Author: David Teigland <teigland@redhat.com>
AuthorDate: Mon Jul 23 11:08:12 2018 -0500
Committer: David Teigland <teigland@redhat.com>
CommitterDate: Mon Jul 23 11:12:38 2018 -0500
lvconvert: restrict command matching for no option variant
The 'lvconvert LV' command def has caused multiple problems
for command matching because it matches the required options
of any lvconvert command. Any lvconvert with incorrect options
ends up matching 'lvconvert LV', which then produces an error
about incorrect options being used for 'lvconvert LV'. This
prevents suggestions from nearest-command partial command matches.
Add a special case for 'lvconvert LV' so that it won't be used
as a partial match for a command that has options specified.
---
lib/commands/toolcontext.h | 1 +
tools/command-lines.in | 2 +-
tools/lvmcmdline.c | 14 ++++++++++++++
3 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/lib/commands/toolcontext.h b/lib/commands/toolcontext.h
index 3c7ef54..2ac7a1e 100644
--- a/lib/commands/toolcontext.h
+++ b/lib/commands/toolcontext.h
@@ -95,6 +95,7 @@ struct cmd_context {
char **argv;
struct arg_values *opt_arg_values;
struct dm_list arg_value_groups;
+ int opt_count; /* total number of options (beginning with - or --) */
/*
* Position args remaining after command name
diff --git a/tools/command-lines.in b/tools/command-lines.in
index 6192b03..d6cd04e 100644
--- a/tools/command-lines.in
+++ b/tools/command-lines.in
@@ -727,7 +727,7 @@ RULE: all and lv_is_converting
# for compat since this was how it used to be done.
lvconvert LV_mirror_raid
OO: OO_LVCONVERT
-ID: lvconvert_start_poll
+ID: lvconvert_plain
DESC: Poll LV to continue conversion (also see --startpoll)
DESC: or waits till conversion/mirror syncing is finished
FLAGS: SECONDARY_SYNTAX
diff --git a/tools/lvmcmdline.c b/tools/lvmcmdline.c
index cb1753d..84825af 100644
--- a/tools/lvmcmdline.c
+++ b/tools/lvmcmdline.c
@@ -117,6 +117,7 @@ static const struct command_function _command_functions[CMD_COUNT] = {
/* lvconvert utility to trigger polling on an LV. */
{ lvconvert_start_poll_CMD, lvconvert_start_poll_cmd },
+ { lvconvert_plain_CMD, lvconvert_start_poll_cmd },
/* lvconvert utilities for creating/maintaining thin and cache objects. */
{ lvconvert_to_thinpool_CMD, lvconvert_to_pool_cmd },
@@ -1583,6 +1584,17 @@ static struct command *_find_command(struct cmd_context *cmd, const char *path,
if (arg_is_set(cmd, help_ARG) || arg_is_set(cmd, help2_ARG) || arg_is_set(cmd, longhelp_ARG) || arg_is_set(cmd, version_ARG))
return &commands[i];
+ /*
+ * The 'lvconvert LV' cmd def matches any lvconvert cmd which throws off
+ * nearest-command partial-match suggestions. Make it a special case so
+ * that it won't be used as a close match. If the command has any option
+ * set (other than -v), don't attempt to match it to 'lvconvert LV'.
+ */
+ if (commands[i].command_enum == lvconvert_plain_CMD) {
+ if (cmd->opt_count - cmd->opt_arg_values[verbose_ARG].count)
+ continue;
+ }
+
match_required = 0; /* required parameters that match */
match_ro = 0; /* required opt_args that match */
match_rp = 0; /* required pos_args that match */
@@ -2101,6 +2113,8 @@ static int _process_command_line(struct cmd_context *cmd, int *argc, char ***arg
if (goval == '?')
return 0;
+ cmd->opt_count++;
+
/*
* translate the option value used by getopt into the enum
* value (e.g. foo_ARG) from the args array.
^ permalink raw reply related
* Re: Regression with crc32c selection? (solved - pilot error)
From: Holger Hoffstätte @ 2018-07-23 15:11 UTC (permalink / raw)
To: Patrik Lundquist; +Cc: linux-btrfs
In-Reply-To: <CAA7pwKMRuDLS64zqQuTHN4DbM2HE-wBkpPJw-7kmAy6NJxqg_g@mail.gmail.com>
On 07/23/18 16:39, Patrik Lundquist wrote:
> $ uname -a
> Linux nas 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 GNU/Linux
>
> $ dmesg | grep Btrfs
> [ 8.168408] Btrfs loaded, crc32c=crc32c-intel
>
> $ lsmod | grep crc32
> crc32_pclmul 16384 0
> libcrc32c 16384 1 btrfs
> crc32c_generic 16384 0
> crc32c_intel 24576 2
Ooohh..thanks for that. I wouldn't be surprised it's because my libcrc
is built-in (probably because of built-in xfs) and at initialization time
doesn't see any modules, so it always selects the generic impl.
Since btrfs is only ever loaded last, the previous btrfs init code could
properly detect/load/use the crc32c-intel module.
I switched the crc32c impls to built-in and what do you know:
Jul 23 17:04:26 ragnarok kernel: Btrfs loaded, crc32c=crc32c-intel
\o/
Thanks Patrick!
Holger
^ permalink raw reply
* Re: [PATCH 03/14] format-patch: teach --interdiff to respect -v/--reroll-count
From: Duy Nguyen @ 2018-07-23 16:12 UTC (permalink / raw)
To: Eric Sunshine
Cc: Git Mailing List, Johannes Schindelin,
Ævar Arnfjörð Bjarmason, Stefan Beller
In-Reply-To: <20180722095717.17912-4-sunshine@sunshineco.com>
On Sun, Jul 22, 2018 at 11:57 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
>
> The --interdiff option introduces the embedded interdiff generically as
> "Interdiff:", however, we can do better when --reroll-count is specified
Oh boy. --reroll-count was added in 2012 and here I am typing
--subject-prefix='PATCH vX' everyday, thinking that somebody should
really do something about it. I've learned --reroll-count today!
> diff --git a/revision.h b/revision.h
> index 61931fbac5..ffeadc261a 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -215,6 +215,7 @@ struct rev_info {
> /* interdiff */
> const struct object_id *idiff_oid1;
> const struct object_id *idiff_oid2;
> + const char *idiff_title;
I feel we're abusing struct rev_info a bit for this since this
interdiff thing is very builtin/log.c's business and not at all
related to rev walk. Is it possible (and easy) to just pass
idfff_title from cmd_format_patch to make_cover_letter()? If it's a
lot of code, then I guess we can just leave it here.
--
Duy
^ permalink raw reply
* Re: [PATCH] drivers/memory/Kconfig: Add CONFIG_OF dependency
From: Boris Brezillon @ 2018-07-23 16:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Randy Dunlap, Anders Roxell, Miquel Raynal,
Linux Kernel Mailing List, Rob Herring, DTML
In-Reply-To: <CAK8P3a10SsWuPXzOyRcNKa+ukvj_Gq13JyDTngoU8DJu6_MR0Q@mail.gmail.com>
On Mon, 23 Jul 2018 17:40:29 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jul 23, 2018 at 11:41 AM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > On Mon, 23 Jul 2018 11:34:43 +0200
> > Arnd Bergmann <arnd@arndb.de> wrote:
> >
> >> On Sun, Jul 22, 2018 at 8:29 AM, Boris Brezillon
> >> <boris.brezillon@bootlin.com> wrote:
> >> > +Arnd, Rob and the DT ML.
> >> >
> >> > On Sat, 21 Jul 2018 14:53:47 -0700
> >> > Randy Dunlap <rdunlap@infradead.org> wrote:
> >> >
> >> >> On 07/21/2018 01:00 PM, Anders Roxell wrote:
> >> >> > JZ4780_NEMC doesn't depend on OF, and if OF isn't enabled we get this
> >> >> > error:
> >> >> > drivers/memory/jz4780-nemc.c: In function ‘jz4780_nemc_num_banks’:
> >> >> > drivers/memory/jz4780-nemc.c:72:10: error: implicit declaration of
> >> >> > function ‘of_read_number’; did you mean ‘down_read_nested’?
> >> >> > [-Werror=implicit-function-declaration]
> >> >> > bank = of_read_number(prop, 1);
> >> >> > ^~~~~~~~~~~~~~
> >> >> > down_read_nested
> >> >
> >> > Looks like of.h defines stubs so that people can compile-test without
> >> > CONFIG_OF selected. Maybe we should move of_read_number() and
> >> > of_read_ulong() out of the #ifdef CONFIG_OF section.
> >>
> >> That seems fine, though the added dependency seems appropriate
> >> here as well. of_read_number() is rarely used, and for the most part in
> >> powerpc specific code that is guaranteed to have CONFIG_OF enabled,
> >> so it's not that likely to cause many more problems.
> >
> > Ok, then I'll let Miquel apply Anders' patch to the NAND tree.
> >
> > Thanks for your feedback.
>
> My randconfig build bot just ran into a second problem with this driver
> with CONFIG_GPIOLIB disabled:
>
> drivers/mtd/nand/raw/jz4740_nand.c: In function 'jz_nand_dev_ready':
> drivers/mtd/nand/raw/jz4740_nand.c:133:9: error: implicit declaration
> of function 'gpiod_get_value_cansleep'; did you mean
> 'gpio_get_value_cansleep'? [-Werror=implicit-function-declaration]
> return gpiod_get_value_cansleep(nand->busy_gpio);
> ^~~~~~~~~~~~~~~~~~~~~~~~
> gpio_get_value_cansleep
> drivers/mtd/nand/raw/jz4740_nand.c: In function 'jz_nand_probe':
> drivers/mtd/nand/raw/jz4740_nand.c:388:20: error: implicit declaration
> of function 'devm_gpiod_get_optional'; did you mean
> 'devm_gpio_request_one'? [-Werror=implicit-function-declaration]
> nand->busy_gpio = devm_gpiod_get_optional(&pdev->dev, "busy", GPIOD_IN);
> ^~~~~~~~~~~~~~~~~~~~~~~
> devm_gpio_request_one
> drivers/mtd/nand/raw/jz4740_nand.c:388:64: error: 'GPIOD_IN'
> undeclared (first use in this function); did you mean 'GPIOF_IN'?
> nand->busy_gpio = devm_gpiod_get_optional(&pdev->dev, "busy", GPIOD_IN);
> ^~~~~~~~
> GPIOF_IN
>
>
> We could add another dependency here or (my preference) include
> linux/gpio/consumer.h to fix that. Do you want a separate patch for
> it, or should Anders send a combined patch?
I already fixed that one last week [1], it's been applied yet.
Thanks,
Boris
[1]http://patchwork.ozlabs.org/patch/946614/
^ permalink raw reply
* Re: [PATCH v6 06/13] mm, dev_pagemap: Do not clear ->mapping on final put
From: Dave Jiang @ 2018-07-23 16:12 UTC (permalink / raw)
To: Jérôme Glisse
Cc: Dan Williams, linux-nvdimm, Jan Kara, linux-kernel, stable,
linux-mm, linux-fsdevel, Andrew Morton, hch
In-Reply-To: <153154380137.34503.3754023882460956800.stgit@dwillia2-desk3.amr.corp.intel.com>
Jerome,
Is it possible to get an ack for this? Thanks!
On 07/13/2018 09:50 PM, Dan Williams wrote:
> MEMORY_DEVICE_FS_DAX relies on typical page semantics whereby ->mapping
> is only ever cleared by truncation, not final put.
>
> Without this fix dax pages may forget their mapping association at the
> end of every page pin event.
>
> Move this atypical behavior that HMM wants into the HMM ->page_free()
> callback.
>
> Cc: <stable@vger.kernel.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: JA(C)rA'me Glisse <jglisse@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Fixes: d2c997c0f145 ("fs, dax: use page->mapping...")
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> kernel/memremap.c | 1 -
> mm/hmm.c | 2 ++
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/memremap.c b/kernel/memremap.c
> index 5857267a4af5..62603634a1d2 100644
> --- a/kernel/memremap.c
> +++ b/kernel/memremap.c
> @@ -339,7 +339,6 @@ void __put_devmap_managed_page(struct page *page)
> __ClearPageActive(page);
> __ClearPageWaiters(page);
>
> - page->mapping = NULL;
> mem_cgroup_uncharge(page);
>
> page->pgmap->page_free(page, page->pgmap->data);
> diff --git a/mm/hmm.c b/mm/hmm.c
> index de7b6bf77201..f9d1d89dec4d 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -963,6 +963,8 @@ static void hmm_devmem_free(struct page *page, void *data)
> {
> struct hmm_devmem *devmem = data;
>
> + page->mapping = NULL;
> +
> devmem->ops->free(devmem, page);
> }
>
>
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
>
^ permalink raw reply
* Re: [PATCH v6 06/13] mm, dev_pagemap: Do not clear ->mapping on final put
From: Dave Jiang @ 2018-07-23 16:12 UTC (permalink / raw)
To: Jérôme Glisse
Cc: Jan Kara, linux-nvdimm, linux-kernel, stable, hch, linux-mm,
linux-fsdevel, Andrew Morton
In-Reply-To: <153154380137.34503.3754023882460956800.stgit@dwillia2-desk3.amr.corp.intel.com>
Jerome,
Is it possible to get an ack for this? Thanks!
On 07/13/2018 09:50 PM, Dan Williams wrote:
> MEMORY_DEVICE_FS_DAX relies on typical page semantics whereby ->mapping
> is only ever cleared by truncation, not final put.
>
> Without this fix dax pages may forget their mapping association at the
> end of every page pin event.
>
> Move this atypical behavior that HMM wants into the HMM ->page_free()
> callback.
>
> Cc: <stable@vger.kernel.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Jérôme Glisse <jglisse@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Fixes: d2c997c0f145 ("fs, dax: use page->mapping...")
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> kernel/memremap.c | 1 -
> mm/hmm.c | 2 ++
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/memremap.c b/kernel/memremap.c
> index 5857267a4af5..62603634a1d2 100644
> --- a/kernel/memremap.c
> +++ b/kernel/memremap.c
> @@ -339,7 +339,6 @@ void __put_devmap_managed_page(struct page *page)
> __ClearPageActive(page);
> __ClearPageWaiters(page);
>
> - page->mapping = NULL;
> mem_cgroup_uncharge(page);
>
> page->pgmap->page_free(page, page->pgmap->data);
> diff --git a/mm/hmm.c b/mm/hmm.c
> index de7b6bf77201..f9d1d89dec4d 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -963,6 +963,8 @@ static void hmm_devmem_free(struct page *page, void *data)
> {
> struct hmm_devmem *devmem = data;
>
> + page->mapping = NULL;
> +
> devmem->ops->free(devmem, page);
> }
>
>
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [PATCH v6 06/13] mm, dev_pagemap: Do not clear ->mapping on final put
From: Dave Jiang @ 2018-07-23 16:12 UTC (permalink / raw)
To: Jérôme Glisse
Cc: Dan Williams, linux-nvdimm, Jan Kara, linux-kernel, stable,
linux-mm, Jérôme Glisse, linux-fsdevel, Andrew Morton,
hch
In-Reply-To: <153154380137.34503.3754023882460956800.stgit@dwillia2-desk3.amr.corp.intel.com>
Jerome,
Is it possible to get an ack for this? Thanks!
On 07/13/2018 09:50 PM, Dan Williams wrote:
> MEMORY_DEVICE_FS_DAX relies on typical page semantics whereby ->mapping
> is only ever cleared by truncation, not final put.
>
> Without this fix dax pages may forget their mapping association at the
> end of every page pin event.
>
> Move this atypical behavior that HMM wants into the HMM ->page_free()
> callback.
>
> Cc: <stable@vger.kernel.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Jérôme Glisse <jglisse@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Fixes: d2c997c0f145 ("fs, dax: use page->mapping...")
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> kernel/memremap.c | 1 -
> mm/hmm.c | 2 ++
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/memremap.c b/kernel/memremap.c
> index 5857267a4af5..62603634a1d2 100644
> --- a/kernel/memremap.c
> +++ b/kernel/memremap.c
> @@ -339,7 +339,6 @@ void __put_devmap_managed_page(struct page *page)
> __ClearPageActive(page);
> __ClearPageWaiters(page);
>
> - page->mapping = NULL;
> mem_cgroup_uncharge(page);
>
> page->pgmap->page_free(page, page->pgmap->data);
> diff --git a/mm/hmm.c b/mm/hmm.c
> index de7b6bf77201..f9d1d89dec4d 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -963,6 +963,8 @@ static void hmm_devmem_free(struct page *page, void *data)
> {
> struct hmm_devmem *devmem = data;
>
> + page->mapping = NULL;
> +
> devmem->ops->free(devmem, page);
> }
>
>
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
>
^ permalink raw reply
* Re: Incorrect name of PCM
From: Christopher Head @ 2018-07-23 16:11 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5h7elm1k39.wl-tiwai@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 898 bytes --]
On July 23, 2018 12:34:34 AM PDT, Takashi Iwai <tiwai@suse.de> wrote:
>
>For playing via HDMI on your machine, you'd need to pass as "aplay -L"
>shows, one of the following:
>
>> hdmi:CARD=NVidia,DEV=0
>> HDA NVidia, HDMI 0
>> HDMI Audio Output
>> hdmi:CARD=NVidia,DEV=1
>> HDA NVidia, HDMI 1
>> HDMI Audio Output
>> hdmi:CARD=NVidia,DEV=2
>> HDA NVidia, HDMI 2
>> HDMI Audio Output
>> hdmi:CARD=NVidia,DEV=3
>> HDA NVidia, HDMI 3
>> HDMI Audio Output
>
>The device number depends on the HDMI port you plugged in.
>The above can be in a shorter form like "hdmi:1,0", too.
Hi,
Thanks for responding. Did you miss this part of the aplay -L output?
hdmi:CARD=PCH,DEV=0
HDA Intel PCH, VT1708S Digital
HDMI Audio Output
This is the part I think is wrong, not the parts mentioning the NVidia HDMI outputs.
Thanks,
--
Christopher Head
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 244 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [NOT YET PULL] Trial of labeling lines in code snippets
From: Akira Yokosawa @ 2018-07-23 15:09 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: perfbook, Akira Yokosawa
In-Reply-To: <20180722224906.GI12945@linux.vnet.ibm.com>
On 2018/07/22 15:49:06 -0700, Paul E. McKenney wrote:
> On Mon, Jul 23, 2018 at 12:43:05AM +0900, Akira Yokosawa wrote:
>> On 2018/07/21 09:51:03 -0700, Paul E. McKenney wrote:
>>> On Sat, Jul 21, 2018 at 09:19:53AM +0900, Akira Yokosawa wrote:
>>>> Hi Paul,
>>>>
>>>> So, an experimental branch to label particular lines in code
>>>> snippets is ready for review.
>>>> The branch is based on current master of yours.
>>>>
>>>> I've converted 4 code snippets in Section 4.2. and updated
>>>> corresponding code samples (sans forkjoin.c because it is
>>>> quite simplified in Listing 4.1).
>>>>
>>>> Does this approach look reasonable to you?
>>>
>>> This does look promising, thank you! Please give me some time to think
>>> this over a bit. My normal approach would end up with very long labels
>>> in the code, which might be OK. The argument against is that tying the
>>> listing caption to the actual code might not be a great thing.
>>
>> One idea is to embed meta labels in code samples.
>> When converting them to a proper Verbatim sources, short labels such
>> as " //\lnlbl{foo}" can be converted to long ones such as
>> "%lnlbl[ln:<chapter>:<basename of snippet file>:foo]" in the script
>> to remove " //".
>>
>> To do this, we need to embed extra meta data as comments in sample
>> code.
>>
>> For example, the source of waitall() function (in api-pthread.h) can be
>> written as the following (in the form of \lnlbl{}):
>>
>> ----
>> /*
>> * Wait on all child processes.
>> */
>> static __inline__ void waitall(void)
>> {
>> // \begin{snippet}[chapter=toolsoftrade,name=waitall,commandchars=[\%\[\]]
>> int pid;
>> int status;
>>
>> for (;;) { //\lnlbl{loopa}
>> pid = wait(&status); //\lnlb{wait}
>> if (pid == -1) {
>> if (errno == ECHILD) //\lnlb{ECHILD}
>> break; //\lnlbl{break}
>> perror("wait"); //\lnlbl{perror}
>> exit(EXIT_FAILURE); //\lnlbl{exit}
>> }
>> poll(NULL, 0, 1);
>> } //\lnlbl{loopb}
>> }
>> // \end{snippet}
>> ...
>> ----
>>
>> , and it can be extracted and converted into CodeSamples/api-pthread/waitall.tex
>> in the following way (including substitution of escape charactors):
>>
>> \begin{Verbatim}[commandchars=[\%\[\]]
>> int pid;
>> int status;
>>
>> for (;;) {%lnlbl[ln:toolsoftrade:waitall:loopa]
>> pid = wait(&status);%lnlbl[ln:toolsoftrade:waitall:wait]
>> if (pid == -1) {
>> if (errno == ECHILD)%lnlbl[ln:toolsoftrade:waitall:ECHILD]
>> break;%lnlbl[ln:toolsoftrade:break]
>> perror("wait");%lnlbl[ln:toolsoftrade:perror]
>> exit(EXIT_FAILURE);%lnlbl[ln:toolsoftrade:exit]
>> }
>> poll(NULL, 0, 1);
>> }%lnlbl[ln:toolsoftrade:loopb]
>> }
>> \end{Verbatim}
>>
>> This file can be read in toolsoftrade.tex in the following way:
>>
>> ---
>> \begin{listing}[tbp]
>> \input{CodeSamples/api-pthread/waitall}
>> \caption{Using the \tco{wait()} Primitive}
>> \label{lst:toolsoftrade:Using the wait() Primitive}
>> \end{listing}
>> ---
>>
>> The conversion script should not be so hard to implement.
>> Update of build scripts should also be possible to automate these
>> conversions.
>>
>> If you'd like to use the caption of the listing in the final labels,
>> the caption should also be given in the meta \begin{snippet} command.
>> But for lines in code snippets, using file names as labels sounds
>> reasonable to me.
>
> I believe that your scheme is pretty close. My thought is directory,
> file, function, label. You have all but file already. That allows
> captions to change without changing the line label, which seems like a
> good thing.
In the end, "chapter=foo,name=bar,func=baz" can be expressed as
"labelprefix=foo:bar:baz in the option to meta \begin{snippet} command.
So you can put any string you like there.
I'll do v2 of the trial branch along this scheme, hopefully
including build script/Makefile updates. Maybe in a week or so.
Thanks, Akira
>
> Seem reasonable?
>
> Thanx, Paul
>
>> Thoughts?
>>
>> Thanks, Akira
>>
>>>
>>> Again, looks promising, thank you!
>>>
>>> Thanx, Paul
>>>
>>>> Thanks, Akira
>>>>
>>>> ---
>>>> The following changes since commit e3191997557e0d33b862e267fb4d5971e879ca07:
>>>>
>>>> utilities: Provide scripts instead of broken symlinks (2018-07-18 11:40:57 -0700)
>>>>
>>>> are available in the git repository at:
>>>>
>>>> https://github.com/akiyks/perfbook trial-fancyvrb
>>>>
>>>> for you to fetch changes up to 2154a175e469e6238c89d4c494d204a9ddbaa20a:
>>>>
>>>> [EXP] Update hyphen2endash (2018-07-21 09:17:34 +0900)
>>>>
>>>> ----------------------------------------------------------------
>>>> Akira Yokosawa (3):
>>>> [EXP] toolsoftrade: Add labels in code samples as comments
>>>> [EXP] toolsoftrade: Reference line in code snippets by label
>>>> [EXP] Update hyphen2endash
>>>>
>>>> CodeSamples/api-pthreads/api-pthreads.h | 14 +-
>>>> CodeSamples/toolsoftrade/forkjoinvar.c | 10 +-
>>>> CodeSamples/toolsoftrade/pcreate.c | 5 +-
>>>> perfbook.tex | 6 +
>>>> toolsoftrade/toolsoftrade.tex | 221 +++++++++++++++++---------------
>>>> utilities/hyphen2endash.sh | 3 +
>>>> 6 files changed, 141 insertions(+), 118 deletions(-)
>>>>
>>>
>>
>
^ permalink raw reply
* Re: Does /dev/urandom now block until initialised ?
From: Jeffrey Walton @ 2018-07-23 16:11 UTC (permalink / raw)
To: Theodore Y. Ts'o, Ken Moffat, Linux Crypto Mailing List, lkml
In-Reply-To: <20180723151608.GE3358@thunk.org>
On Mon, Jul 23, 2018 at 11:16 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> On Mon, Jul 23, 2018 at 04:43:01AM +0100, Ken Moffat wrote:
>> ...
> One of the reasons why I didn't see the problem when I was developing
> the remediation patch for CVE-2018-1108 is because I run Debian
> testing, which doesn't have this particular Red Hat patch.
Off-topic, I'm kind of surprised it took that long to fix it (if I am
parsing things correctly).
I believe Stephan Mueller wrote up the weakness a couple of years ago.
He's the one who explained the interactions to me. Mueller was even
cited at https://github.com/systemd/systemd/issues/4167.
It is too bad he Mueller not receive credit for it in the CVE database.
Jeff
^ permalink raw reply
* Re: INFO: task hung in fuse_reverse_inval_entry
From: Miklos Szeredi @ 2018-07-23 15:09 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: linux-fsdevel, LKML, syzkaller-bugs, syzbot
In-Reply-To: <CACT4Y+Y2ec4-ywG+FWocir6XXkwt-11qD+SAFwswtG2Ng6BS4A@mail.gmail.com>
On Mon, Jul 23, 2018 at 3:37 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Mon, Jul 23, 2018 at 3:05 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> Biggest conceptual problem: your definition of fuse-server is weak.
>> Take the following example: process A is holding the fuse device fd
>> and is forwarding requests and replies to/from process B via a pipe.
>> So basically A is just a proxy that does nothing interesting, the
>> "real" server is B. But according to your definition B is not a
>> server, only A is.
>
> I proposed to abort fuse conn when all fuse device fd's are "killed"
> (all processes having the fd opened are killed). So if _only_ process
> B is killed, then, yes, it will still hang. However if A is killed or
> both A and B (say, process group, everything inside of pid namespace,
> etc) then the deadlock will be autoresolved without human
> intervention.
Okay, so you're saying:
1) when process gets SIGKILL and is uninterruptible sleep mark process as doomed
2) for a particular fuse instance find set of fuse device fd
references that are in non-doomed tasks; if there are none then abort
fuse instance
Right?
The above is not an implementation proposal, just to get us on the
same page regarding the concept.
>> And this is just a simple example, parts of the server might be on
>> different machines, etc... It's impossible to automatically detect if
>> a process is acting as a fuse server or not.
>
> It does not seem we need the precise definition. If no one ever can
> write anything into the fd, we can safely abort the connection (?).
Seems to me so.
> If
> we don't, we can either get that the process exits normally and the
> connection is doomed anyway, so no difference in behavior, or we can
> get a deadlock.
>
>> We could let the fuse server itself notify the kernel that it's a fuse
>> server. That might help in the cases where the deadlock is
>> accidental, but obviously not in the case when done by a malicious
>> agent. I'm not sure it's worth the effort. Also I have no idea how
>> the respective maintainers would take the idea of "kill hooks"... It
>> would probably be a lot of work for little gain.
>
> What looks wrong to me here is that fuse is only (?) subsystem in
> kernel that stops SIGKILL from working and requires complex custom
> dance performed by a human operator (which is not necessary there at
> all). Say, if a process has opened a socket, whatever, I don't need to
> locate and abort something in socketctl fs, just SIGKILL. If a
> processes has opened a file, I don't need to locate the fd in /proc
> and abort it, just SIGKILL. If a process has created an ipc object, I
> don't need to do any special dance, just SIGKILL. fuse is somehow very
> special, if we have more such cases, it definitely won't scale.
> I understand that there can be implementation difficulties, but
> fundamentally that's how things should work -- choose target
> processes, kill, done, right?
Yes, it would be nice.
But I'm not sure it will fly due to implementation difficulties. It's
definitely not a high prio feature currently for me, but I'll happily
accept patches.
Thanks,
Miklos
^ permalink raw reply
* [MODERATED] Re: L!TF Bulletin #4: The state of the horrors
From: David Woodhouse @ 2018-07-23 16:10 UTC (permalink / raw)
To: speck
In-Reply-To: <alpine.DEB.2.21.1807131608360.2171@nanos.tec.linutronix.de>
On Fri, 2018-07-13 at 17:08 +0200, speck for Thomas Gleixner wrote:
>
> The stable branches linux-4.14.y, linux-4.16.y and linux-4.17.y have been
> rebased to the latest stable versions. David Woodhouse said he's looking
> into updating the linux-4.9.y stable branch in the next days.
I've just pushed out a first version of the linux-4.9.y branch. It's
basically completely untested except that it builds and boots in
'qemu-system-x86_64 -kernel arch/x86/kernel/bzImage' and panics about
the lack of root filesystem without panicking about anything *else*
first.
^ permalink raw reply
* [PATCH] sun4i: dts: add gpu node to sun4i-a10 platform
From: stevenvandenbrandenstift @ 2018-07-23 16:09 UTC (permalink / raw)
To: wens, robh+dt, mark.rutland, maxime.ripard, linux-arm-kernel,
linux-kernel, devicetree
Cc: Steven Vanden Branden
From: Steven Vanden Branden <stevenvandenbrandenstift@gmail.com>
Add mali gpu node to sun4i a10 platforms.
Tested with offscreen rendering with lima mesa (freedesktop gitlab)
Signed-off-by: Steven Vanden Branden <stevenvandenbrandenstift@gmail.com>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 3a1c6b45c9a1..be22f18b1462 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -1001,6 +1001,27 @@
status = "disabled";
};
+ mali: gpu@1c40000 {
+ compatible = "allwinner,sun4i-a10-mali", "arm,mali-400";
+ reg = <0x01c40000 0x10000>;
+ interrupts = <69>,
+ <70>,
+ <71>,
+ <72>,
+ <73>;
+ interrupt-names = "gp",
+ "gpmmu",
+ "pp0",
+ "ppmmu0",
+ "pmu";
+ clocks = <&ccu CLK_AHB_GPU>, <&ccu CLK_GPU>;
+ clock-names = "bus", "core";
+ resets = <&ccu RST_GPU>;
+
+ assigned-clocks = <&ccu CLK_GPU>;
+ assigned-clock-rates = <384000000>;
+ };
+
fe0: display-frontend@1e00000 {
compatible = "allwinner,sun4i-a10-display-frontend";
reg = <0x01e00000 0x20000>;
--
2.17.1
^ permalink raw reply related
* [PATCH] sun4i: dts: add gpu node to sun4i-a10 platform
From: stevenvandenbrandenstift at gmail.com @ 2018-07-23 16:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Steven Vanden Branden <stevenvandenbrandenstift@gmail.com>
Add mali gpu node to sun4i a10 platforms.
Tested with offscreen rendering with lima mesa (freedesktop gitlab)
Signed-off-by: Steven Vanden Branden <stevenvandenbrandenstift@gmail.com>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 3a1c6b45c9a1..be22f18b1462 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -1001,6 +1001,27 @@
status = "disabled";
};
+ mali: gpu at 1c40000 {
+ compatible = "allwinner,sun4i-a10-mali", "arm,mali-400";
+ reg = <0x01c40000 0x10000>;
+ interrupts = <69>,
+ <70>,
+ <71>,
+ <72>,
+ <73>;
+ interrupt-names = "gp",
+ "gpmmu",
+ "pp0",
+ "ppmmu0",
+ "pmu";
+ clocks = <&ccu CLK_AHB_GPU>, <&ccu CLK_GPU>;
+ clock-names = "bus", "core";
+ resets = <&ccu RST_GPU>;
+
+ assigned-clocks = <&ccu CLK_GPU>;
+ assigned-clock-rates = <384000000>;
+ };
+
fe0: display-frontend at 1e00000 {
compatible = "allwinner,sun4i-a10-display-frontend";
reg = <0x01e00000 0x20000>;
--
2.17.1
^ permalink raw reply related
* Re: [Qemu-devel] [PULL 0/5] target-arm queue
From: Peter Maydell @ 2018-07-23 16:08 UTC (permalink / raw)
To: QEMU Developers
In-Reply-To: <20180723144152.13885-1-peter.maydell@linaro.org>
On 23 July 2018 at 15:41, Peter Maydell <peter.maydell@linaro.org> wrote:
> target-arm queue for 3.0:
>
> Thomas' fixes for instrospection issues with a handful of
> devices (including one microblaze one that I include in this
> pullreq for convenience's sake), plus my bugfix for a
> corner case of small MPU region support.
>
> thanks
> -- PMM
>
> The following changes since commit 55b1f14cefcb19ce6d5e28c4c83404230888aa7e:
>
> Merge remote-tracking branch 'remotes/vivier2/tags/linux-user-for-3.0-pull-request' into staging (2018-07-23 14:03:14 +0100)
>
> are available in the Git repository at:
>
> git://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20180723
>
> for you to fetch changes up to 1ddc9b98c3cb89fe23a55ba924000fd645253e87:
>
> hw/intc/exynos4210_gic: Turn instance_init into realize function (2018-07-23 15:21:27 +0100)
>
> ----------------------------------------------------------------
> target-arm queue:
> * spitz, exynos: fix bugs when introspecting some devices
> * hw/microblaze/xlnx-zynqmp-pmu: Fix introspection problem in 'xlnx, zynqmp-pmu-soc'
> * target/arm: Correctly handle overlapping small MPU regions
> * hw/sd/bcm2835_sdhost: Fix PIO mode writes
>
Applied, thanks.
-- PMM
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a77980: add RWDT support
From: Simon Horman @ 2018-07-23 16:08 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland, devicetree, Catalin Marinas, Magnus Damm,
Will Deacon, linux-renesas-soc, Rob Herring, linux-arm-kernel
In-Reply-To: <175a491f-a827-4a92-1884-2f1490d38a52@cogentembedded.com>
On Fri, Jul 20, 2018 at 10:21:45PM +0300, Sergei Shtylyov wrote:
> Describe RWDT in the R8A77980 SoC device tree.
>
> Enable RWDT on the Condor and V3H Starter Kit boards.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> The patch is against the 'renesas-devel-20180720-v4.18-rc5' of Simon Horman's
> 'renesas.git' repo. It depends on Geert Uytterhoeven's clock driver patches
> (adding the RWDT clock) in order to work...
But it is safe to apply without those patches, right?
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77980: add RWDT support
From: Simon Horman @ 2018-07-23 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <175a491f-a827-4a92-1884-2f1490d38a52@cogentembedded.com>
On Fri, Jul 20, 2018 at 10:21:45PM +0300, Sergei Shtylyov wrote:
> Describe RWDT in the R8A77980 SoC device tree.
>
> Enable RWDT on the Condor and V3H Starter Kit boards.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> The patch is against the 'renesas-devel-20180720-v4.18-rc5' of Simon Horman's
> 'renesas.git' repo. It depends on Geert Uytterhoeven's clock driver patches
> (adding the RWDT clock) in order to work...
But it is safe to apply without those patches, right?
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a77980: add RWDT support
From: Simon Horman @ 2018-07-23 16:08 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-renesas-soc, Rob Herring, devicetree, Mark Rutland,
Magnus Damm, linux-arm-kernel, Catalin Marinas, Will Deacon
In-Reply-To: <175a491f-a827-4a92-1884-2f1490d38a52@cogentembedded.com>
On Fri, Jul 20, 2018 at 10:21:45PM +0300, Sergei Shtylyov wrote:
> Describe RWDT in the R8A77980 SoC device tree.
>
> Enable RWDT on the Condor and V3H Starter Kit boards.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> The patch is against the 'renesas-devel-20180720-v4.18-rc5' of Simon Horman's
> 'renesas.git' repo. It depends on Geert Uytterhoeven's clock driver patches
> (adding the RWDT clock) in order to work...
But it is safe to apply without those patches, right?
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ 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.