* Re: [PATCH v6 4/6] lib/dlock-list: Make sibling CPUs share the same linked list
From: Jan Kara @ 2017-10-05 8:59 UTC (permalink / raw)
To: Waiman Long
Cc: Alexander Viro, Jan Kara, Jeff Layton, J. Bruce Fields, Tejun Heo,
Christoph Lameter, linux-fsdevel, linux-kernel, Ingo Molnar,
Peter Zijlstra, Andi Kleen, Dave Chinner, Boqun Feng,
Davidlohr Bueso, Waiman Long
In-Reply-To: <1507152007-28753-5-git-send-email-longman@redhat.com>
On Wed 04-10-17 17:20:05, Waiman Long wrote:
> int alloc_dlock_list_heads(struct dlock_list_heads *dlist)
> {
> - int idx;
> + int idx, cnt = nr_dlock_lists ? nr_dlock_lists : nr_cpu_ids;
Hum, is this there for the case where alloc_dlock_list_heads() is called
before nr_dlock_lists is initialized? But how can the dlist be used later
when it has larger number of lists and you don't know how many?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH 10/13] timer: Remove expires and data arguments from DEFINE_TIMER
From: Arnd Bergmann @ 2017-10-05 8:59 UTC (permalink / raw)
To: Kees Cook
Cc: Thomas Gleixner, Andrew Morton, Benjamin Herrenschmidt,
Chris Metcalf, Geert Uytterhoeven, Greg Kroah-Hartman,
Guenter Roeck, Harish Patil, Heiko Carstens, James E.J. Bottomley,
John Stultz, Julian Wiedmann, Kalle Valo, Lai Jiangshan,
Len Brown, Manish Chopra, Mark Gross, Martin K. Petersen,
Martin Schwidefsky, Michael Ellerman, Michael Reed, Networking,
Oleg Nesterov, Paul Mackerras, Pavel Machek, Petr Mladek,
Rafael J. Wysocki, Ralf Baechle, Sebastian Reichel,
Stefan Richter, Stephen Boyd, Sudip Mukherjee, Tejun Heo,
Ursula Braun, Viresh Kumar, Wim Van Sebroeck, linux1394-devel,
open list:RALINK MIPS ARCHITECTURE, linux-pm, linuxppc-dev,
linux-s390, linux-scsi, linux-watchdog, linux-wireless,
Linux Kernel Mailing List
In-Reply-To: <1507159627-127660-11-git-send-email-keescook@chromium.org>
On Thu, Oct 5, 2017 at 1:27 AM, Kees Cook <keescook@chromium.org> wrote:
> Drop the arguments from the macro and adjust all callers with the
> following script:
>
> perl -pi -e 's/DEFINE_TIMER\((.*), 0, 0\);/DEFINE_TIMER($1);/g;' \
> $(git grep DEFINE_TIMER | cut -d: -f1 | sort -u | grep -v timer.h)
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # for m68k parts
I was slightly worried about this large-scale rework, since it might conflict
with new users of DEFINE_TIMER(), causing bisection problems.
However, a little research showed that we have only added two users
in the past five years, so this is not a real concern.
for arch/arm, drivers/char and overall:
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 10/13] timer: Remove expires and data arguments from DEFINE_TIMER
From: Arnd Bergmann @ 2017-10-05 8:59 UTC (permalink / raw)
To: Kees Cook
Cc: Thomas Gleixner, Andrew Morton, Benjamin Herrenschmidt,
Chris Metcalf, Geert Uytterhoeven, Greg Kroah-Hartman,
Guenter Roeck, Harish Patil, Heiko Carstens, James E.J. Bottomley,
John Stultz, Julian Wiedmann, Kalle Valo, Lai Jiangshan,
Len Brown, Manish Chopra, Mark Gross, Martin K. Petersen, M
In-Reply-To: <1507159627-127660-11-git-send-email-keescook@chromium.org>
On Thu, Oct 5, 2017 at 1:27 AM, Kees Cook <keescook@chromium.org> wrote:
> Drop the arguments from the macro and adjust all callers with the
> following script:
>
> perl -pi -e 's/DEFINE_TIMER\((.*), 0, 0\);/DEFINE_TIMER($1);/g;' \
> $(git grep DEFINE_TIMER | cut -d: -f1 | sort -u | grep -v timer.h)
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # for m68k parts
I was slightly worried about this large-scale rework, since it might conflict
with new users of DEFINE_TIMER(), causing bisection problems.
However, a little research showed that we have only added two users
in the past five years, so this is not a real concern.
for arch/arm, drivers/char and overall:
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 10/13] timer: Remove expires and data arguments from DEFINE_TIMER
From: Arnd Bergmann @ 2017-10-05 8:59 UTC (permalink / raw)
To: Kees Cook
Cc: Thomas Gleixner, Andrew Morton, Benjamin Herrenschmidt,
Chris Metcalf, Geert Uytterhoeven, Greg Kroah-Hartman,
Guenter Roeck, Harish Patil, Heiko Carstens, James E.J. Bottomley,
John Stultz, Julian Wiedmann, Kalle Valo, Lai Jiangshan,
Len Brown, Manish Chopra, Mark Gross, Martin K. Petersen
In-Reply-To: <1507159627-127660-11-git-send-email-keescook@chromium.org>
On Thu, Oct 5, 2017 at 1:27 AM, Kees Cook <keescook@chromium.org> wrote:
> Drop the arguments from the macro and adjust all callers with the
> following script:
>
> perl -pi -e 's/DEFINE_TIMER\((.*), 0, 0\);/DEFINE_TIMER($1);/g;' \
> $(git grep DEFINE_TIMER | cut -d: -f1 | sort -u | grep -v timer.h)
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # for m68k parts
I was slightly worried about this large-scale rework, since it might conflict
with new users of DEFINE_TIMER(), causing bisection problems.
However, a little research showed that we have only added two users
in the past five years, so this is not a real concern.
for arch/arm, drivers/char and overall:
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [RFC] mmap(MAP_CONTIG)
From: Guy Shattah @ 2017-10-05 8:58 UTC (permalink / raw)
To: Mike Kravetz, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, Vlastimil Babka
Cc: Marek Szyprowski, Michal Nazarewicz, Aneesh Kumar K.V,
Joonsoo Kim, Christoph Lameter
In-Reply-To: <3c28baa4-f8f5-a86e-4830-bf3c7c74ed4f@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 4411 bytes --]
I'm on vacation and having technical difficulties uploading the slides. I'll upload them once I'm back.
Sorry
Guy
Outlook ???? Android<https://aka.ms/ghei36>
________________________________
From: Vlastimil Babka <vbabka@suse.cz>
Sent: Thursday, October 5, 2017 10:06:49 AM
To: Mike Kravetz; linux-mm@kvack.org; linux-kernel@vger.kernel.org; linux-api@vger.kernel.org
Cc: Marek Szyprowski; Michal Nazarewicz; Aneesh Kumar K.V; Joonsoo Kim; Guy Shattah; Christoph Lameter
Subject: Re: [RFC] mmap(MAP_CONTIG)
On 10/04/2017 01:56 AM, Mike Kravetz wrote:
Hi,
> At Plumbers this year, Guy Shattah and Christoph Lameter gave a presentation
> titled 'User space contiguous memory allocation for DMA' [1]. The slides
Hm I didn't find slides on that link, are they available?
> point out the performance benefits of devices that can take advantage of
> larger physically contiguous areas.
>
> When such physically contiguous allocations are done today, they are done
> within drivers themselves in an ad-hoc manner.
As Michal N. noted, the drivers might have different requirements. Is
contiguity (without extra requirements) so common that it would benefit
from a userspace API change?
Also how are the driver-specific allocations done today? mmap() on the
driver's device? Maybe we could provide some in-kernel API/library to
make them less "ad-hoc". Conversion to MAP_ANONYMOUS would at first seem
like an improvement in that userspace would be able to use a generic
allocation API and all the generic treatment of anonymous pages (LRU
aging, reclaim, migration etc), but the restrictions you listed below
eliminate most of that?
(It's likely that I just don't have enough info about how it works today
so it's difficult to judge)
> In addition to allocations
> for DMA, allocations of this type are also performed for buffers used by
> coprocessors and other acceleration engines.
>
> As mentioned in the presentation, posix specifies an interface to obtain
> physically contiguous memory. This is via typed memory objects as described
> in the posix_typed_mem_open() man page. Since Linux today does not follow
> the posix typed memory object model, adding infrastructure for contiguous
> memory allocations seems to be overkill. Instead, a proposal was suggested
> to add support via a mmap flag: MAP_CONTIG.
>
> mmap(MAP_CONTIG) would have the following semantics:
> - The entire mapping (length size) would be backed by physically contiguous
> pages.
> - If 'length' physically contiguous pages can not be allocated, then mmap
> will fail.
> - MAP_CONTIG only works with MAP_ANONYMOUS mappings.
> - MAP_CONTIG will lock the associated pages in memory. As such, the same
> privileges and limits that apply to mlock will also apply to MAP_CONTIG.
> - A MAP_CONTIG mapping can not be expanded.
> - At fork time, private MAP_CONTIG mappings will be converted to regular
> (non-MAP_CONTIG) mapping in the child. As such a COW fault in the child
> will not require a contiguous allocation.
>
> Some implementation considerations:
> - alloc_contig_range() or similar will be used for allocations larger
> than MAX_ORDER.
> - MAP_CONTIG should imply MAP_POPULATE. At mmap time, all pages for the
> mapping must be 'pre-allocated', and they can only be used for the mapping,
> so it makes sense to 'fault in' all pages.
> - Using 'pre-allocated' pages in the fault paths may be intrusive.
> - We need to keep keep track of those pre-allocated pages until the vma is
> tore down, especially if free_contig_range() must be called.
>
> Thoughts?
> - Is such an interface useful?
> - Any other ideas on how to achieve the same functionality?
> - Any thoughts on implementation?
>
> I have started down the path of pre-allocating contiguous pages at mmap
> time and hanging those off the vma(vm_private_data) with some kludges to
> use the pages at fault time. It is really ugly, which is why I am not
> sharing the code. Hoping for some comments/suggestions.
>
> [1] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linuxplumbersconf.org%2F2017%2Focw%2Fproposals%2F4669&data=02%7C01%7Csguy%40mellanox.com%7Ca0ee0fe4f0f74074b69b08d50bbfa7d5%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636427840155156528&sdata=GYlJ926fwQKSUIKbP7AVI01dasvK%2F0JEWLS%2FoNwJbyU%3D&reserved=0
>
[-- Attachment #2: Type: text/html, Size: 6837 bytes --]
^ permalink raw reply
* [PATCH 3/3] ARM: dts: gr-peach: Add ETHER pin group
From: Jacopo Mondi @ 2017-10-05 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1507193900-23801-1-git-send-email-jacopo+renesas@jmondi.org>
Add pin configuration subnode for ETHER pin group and enable the interface.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
arch/arm/boot/dts/r7s72100-gr-peach.dts | 38 +++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index ad6a627..8b5a2c5 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -68,6 +68,28 @@
/* P6_2 as RxD2; P6_3 as TxD2 */
pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
};
+
+ ether_pins: ether {
+ /* Ethernet on Ports 1,3,5,10 */
+ pinmux = <RZA1_PINMUX(1, 14, 4)>, /* P1_14 = ET_COL */
+ <RZA1_PINMUX(3, 0, 2)>, /* P3_0 = ET_TXCLK */
+ <RZA1_PINMUX(3, 3, 2)>, /* P3_3 = ET_MDIO */
+ <RZA1_PINMUX(3, 4, 2)>, /* P3_4 = ET_RXCLK */
+ <RZA1_PINMUX(3, 5, 2)>, /* P3_5 = ET_RXER */
+ <RZA1_PINMUX(3, 6, 2)>, /* P3_6 = ET_RXDV */
+ <RZA1_PINMUX(5, 9, 2)>, /* P5_9 = ET_MDC */
+ <RZA1_PINMUX(10, 1, 4)>, /* P10_1 = ET_TXER */
+ <RZA1_PINMUX(10, 2, 4)>, /* P10_2 = ET_TXEN */
+ <RZA1_PINMUX(10, 3, 4)>, /* P10_3 = ET_CRS */
+ <RZA1_PINMUX(10, 4, 4)>, /* P10_4 = ET_TXD0 */
+ <RZA1_PINMUX(10, 5, 4)>, /* P10_5 = ET_TXD1 */
+ <RZA1_PINMUX(10, 6, 4)>, /* P10_6 = ET_TXD2 */
+ <RZA1_PINMUX(10, 7, 4)>, /* P10_7 = ET_TXD3 */
+ <RZA1_PINMUX(10, 8, 4)>, /* P10_8 = ET_RXD0 */
+ <RZA1_PINMUX(10, 9, 4)>, /* P10_9 = ET_RXD1 */
+ <RZA1_PINMUX(10, 10, 4)>,/* P10_10 = ET_RXD2 */
+ <RZA1_PINMUX(10, 11, 4)>;/* P10_11 = ET_RXD3 */
+ };
};
&extal_clk {
@@ -88,3 +110,19 @@
status = "okay";
};
+
+ðer {
+ pinctrl-names = "default";
+ pinctrl-0 = <ðer_pins>;
+
+ status = "okay";
+
+ reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <5>;
+
+ renesas,no-ether-link;
+ phy-handle = <&phy0>;
+ phy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: gr-peach: Add ETHER pin group
From: Jacopo Mondi @ 2017-10-05 8:58 UTC (permalink / raw)
To: horms, geert, magnus.damm, robh+dt, mark.rutland, linux
Cc: Jacopo Mondi, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1507193900-23801-1-git-send-email-jacopo+renesas@jmondi.org>
Add pin configuration subnode for ETHER pin group and enable the interface.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
arch/arm/boot/dts/r7s72100-gr-peach.dts | 38 +++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index ad6a627..8b5a2c5 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -68,6 +68,28 @@
/* P6_2 as RxD2; P6_3 as TxD2 */
pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
};
+
+ ether_pins: ether {
+ /* Ethernet on Ports 1,3,5,10 */
+ pinmux = <RZA1_PINMUX(1, 14, 4)>, /* P1_14 = ET_COL */
+ <RZA1_PINMUX(3, 0, 2)>, /* P3_0 = ET_TXCLK */
+ <RZA1_PINMUX(3, 3, 2)>, /* P3_3 = ET_MDIO */
+ <RZA1_PINMUX(3, 4, 2)>, /* P3_4 = ET_RXCLK */
+ <RZA1_PINMUX(3, 5, 2)>, /* P3_5 = ET_RXER */
+ <RZA1_PINMUX(3, 6, 2)>, /* P3_6 = ET_RXDV */
+ <RZA1_PINMUX(5, 9, 2)>, /* P5_9 = ET_MDC */
+ <RZA1_PINMUX(10, 1, 4)>, /* P10_1 = ET_TXER */
+ <RZA1_PINMUX(10, 2, 4)>, /* P10_2 = ET_TXEN */
+ <RZA1_PINMUX(10, 3, 4)>, /* P10_3 = ET_CRS */
+ <RZA1_PINMUX(10, 4, 4)>, /* P10_4 = ET_TXD0 */
+ <RZA1_PINMUX(10, 5, 4)>, /* P10_5 = ET_TXD1 */
+ <RZA1_PINMUX(10, 6, 4)>, /* P10_6 = ET_TXD2 */
+ <RZA1_PINMUX(10, 7, 4)>, /* P10_7 = ET_TXD3 */
+ <RZA1_PINMUX(10, 8, 4)>, /* P10_8 = ET_RXD0 */
+ <RZA1_PINMUX(10, 9, 4)>, /* P10_9 = ET_RXD1 */
+ <RZA1_PINMUX(10, 10, 4)>,/* P10_10 = ET_RXD2 */
+ <RZA1_PINMUX(10, 11, 4)>;/* P10_11 = ET_RXD3 */
+ };
};
&extal_clk {
@@ -88,3 +110,19 @@
status = "okay";
};
+
+ðer {
+ pinctrl-names = "default";
+ pinctrl-0 = <ðer_pins>;
+
+ status = "okay";
+
+ reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <5>;
+
+ renesas,no-ether-link;
+ phy-handle = <&phy0>;
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: gr-peach: Enable MTU2 timer pulse unit
From: Jacopo Mondi @ 2017-10-05 8:58 UTC (permalink / raw)
To: horms-/R6kz+dDXgpPR4JQBCEnsQ, geert-Td1EMuHUCqxL1ZNQvxDV9g,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: Jacopo Mondi, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1507193900-23801-1-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
MTU2 multi-function/multi-channel timer/counter is not enabled for
GR-Peach board. The timer is used as clock event source to schedule
wake-ups, and without this enabled all sleeps not performed through busy
waiting hang the board.
Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
---
arch/arm/boot/dts/r7s72100-gr-peach.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index 20309ac..ad6a627 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -78,6 +78,10 @@
clock-frequency = <48000000>;
};
+&mtu2 {
+ status = "okay";
+};
+
&scif2 {
pinctrl-names = "default";
pinctrl-0 = <&scif2_pins>;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: gr-peach: Enable MTU2 timer pulse unit
From: Jacopo Mondi @ 2017-10-05 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1507193900-23801-1-git-send-email-jacopo+renesas@jmondi.org>
MTU2 multi-function/multi-channel timer/counter is not enabled for
GR-Peach board. The timer is used as clock event source to schedule
wake-ups, and without this enabled all sleeps not performed through busy
waiting hang the board.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
arch/arm/boot/dts/r7s72100-gr-peach.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index 20309ac..ad6a627 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -78,6 +78,10 @@
clock-frequency = <48000000>;
};
+&mtu2 {
+ status = "okay";
+};
+
&scif2 {
pinctrl-names = "default";
pinctrl-0 = <&scif2_pins>;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: gr-peach: Enable MTU2 timer pulse unit
From: Jacopo Mondi @ 2017-10-05 8:58 UTC (permalink / raw)
To: horms, geert, magnus.damm, robh+dt, mark.rutland, linux
Cc: Jacopo Mondi, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1507193900-23801-1-git-send-email-jacopo+renesas@jmondi.org>
MTU2 multi-function/multi-channel timer/counter is not enabled for
GR-Peach board. The timer is used as clock event source to schedule
wake-ups, and without this enabled all sleeps not performed through busy
waiting hang the board.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
arch/arm/boot/dts/r7s72100-gr-peach.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index 20309ac..ad6a627 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -78,6 +78,10 @@
clock-frequency = <48000000>;
};
+&mtu2 {
+ status = "okay";
+};
+
&scif2 {
pinctrl-names = "default";
pinctrl-0 = <&scif2_pins>;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: gr-peach: Fix 'leds' node name indent
From: Jacopo Mondi @ 2017-10-05 8:58 UTC (permalink / raw)
To: horms, geert, magnus.damm, robh+dt, mark.rutland, linux
Cc: linux-renesas-soc, devicetree, Jacopo Mondi, linux-kernel,
linux-arm-kernel
In-Reply-To: <1507193900-23801-1-git-send-email-jacopo+renesas@jmondi.org>
Fix 'leds' node name indent as it was wrongly aligned.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
arch/arm/boot/dts/r7s72100-gr-peach.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index f2ddd11..20309ac 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -53,7 +53,7 @@
};
};
-leds {
+ leds {
status = "okay";
compatible = "gpio-leds";
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: gr-peach: Fix 'leds' node name indent
From: Jacopo Mondi @ 2017-10-05 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1507193900-23801-1-git-send-email-jacopo+renesas@jmondi.org>
Fix 'leds' node name indent as it was wrongly aligned.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
arch/arm/boot/dts/r7s72100-gr-peach.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index f2ddd11..20309ac 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -53,7 +53,7 @@
};
};
-leds {
+ leds {
status = "okay";
compatible = "gpio-leds";
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: gr-peach: Fix 'leds' node name indent
From: Jacopo Mondi @ 2017-10-05 8:58 UTC (permalink / raw)
To: horms, geert, magnus.damm, robh+dt, mark.rutland, linux
Cc: Jacopo Mondi, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1507193900-23801-1-git-send-email-jacopo+renesas@jmondi.org>
Fix 'leds' node name indent as it was wrongly aligned.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
arch/arm/boot/dts/r7s72100-gr-peach.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index f2ddd11..20309ac 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -53,7 +53,7 @@
};
};
-leds {
+ leds {
status = "okay";
compatible = "gpio-leds";
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] ARM: dts: gr-peach: Mix DTS fixes/updates
From: Jacopo Mondi @ 2017-10-05 8:58 UTC (permalink / raw)
To: horms, geert, magnus.damm, robh+dt, mark.rutland, linux
Cc: linux-renesas-soc, devicetree, Jacopo Mondi, linux-kernel,
linux-arm-kernel
Hello,
this series includes three patches for GR-Peach DTS.
The first, very trivial one is the re-proposal of the already sent patch, with
the commit message updated as suggested by Sergei.
The second just enables the Multi-function timer/counter unit which was
disabled and is actually used for timer event generations and wake-ups.
After enabling the MTU unit, ETHER is now working properly, so I am re-proposing
this patch, which had been left out from previous gr-peach DTS series because
the interface was not working correctly.
Thanks
j
Jacopo Mondi (3):
ARM: dts: gr-peach: Fix 'leds' node name indent
ARM: dts: gr-peach: Enable MTU2 timer pulse unit
ARM: dts: gr-peach: Add ETHER pin group
arch/arm/boot/dts/r7s72100-gr-peach.dts | 44 ++++++++++++++++++++++++++++++++-
1 file changed, 43 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* [PATCH 0/3] ARM: dts: gr-peach: Mix DTS fixes/updates
From: Jacopo Mondi @ 2017-10-05 8:58 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
this series includes three patches for GR-Peach DTS.
The first, very trivial one is the re-proposal of the already sent patch, with
the commit message updated as suggested by Sergei.
The second just enables the Multi-function timer/counter unit which was
disabled and is actually used for timer event generations and wake-ups.
After enabling the MTU unit, ETHER is now working properly, so I am re-proposing
this patch, which had been left out from previous gr-peach DTS series because
the interface was not working correctly.
Thanks
j
Jacopo Mondi (3):
ARM: dts: gr-peach: Fix 'leds' node name indent
ARM: dts: gr-peach: Enable MTU2 timer pulse unit
ARM: dts: gr-peach: Add ETHER pin group
arch/arm/boot/dts/r7s72100-gr-peach.dts | 44 ++++++++++++++++++++++++++++++++-
1 file changed, 43 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* [PATCH 0/3] ARM: dts: gr-peach: Mix DTS fixes/updates
From: Jacopo Mondi @ 2017-10-05 8:58 UTC (permalink / raw)
To: horms, geert, magnus.damm, robh+dt, mark.rutland, linux
Cc: Jacopo Mondi, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel
Hello,
this series includes three patches for GR-Peach DTS.
The first, very trivial one is the re-proposal of the already sent patch, with
the commit message updated as suggested by Sergei.
The second just enables the Multi-function timer/counter unit which was
disabled and is actually used for timer event generations and wake-ups.
After enabling the MTU unit, ETHER is now working properly, so I am re-proposing
this patch, which had been left out from previous gr-peach DTS series because
the interface was not working correctly.
Thanks
j
Jacopo Mondi (3):
ARM: dts: gr-peach: Fix 'leds' node name indent
ARM: dts: gr-peach: Enable MTU2 timer pulse unit
ARM: dts: gr-peach: Add ETHER pin group
arch/arm/boot/dts/r7s72100-gr-peach.dts | 44 ++++++++++++++++++++++++++++++++-
1 file changed, 43 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* [GIT PULL] HID fixes
From: Jiri Kosina @ 2017-10-05 8:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
Linus,
please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
to receive HID subsystem fixes
=====
- buffer management size fix for i2c-hid driver, from Adrian Salido
- tool ID regression fixes for Wacom driver from Jason Gerecke
- a few small assorted fixes and a few device ID additions
=====
Thanks.
----------------------------------------------------------------
Aaron Armstrong Skomra (1):
HID: wacom: leds: Don't try to control the EKR's read-only LEDs
Adrian Salido (1):
HID: i2c-hid: allocate hid buffers for real worst case
Dmitry Torokhov (1):
HID: hidraw: fix power sequence when closing device
Hans de Goede (1):
HID: multitouch: Fix system-control buttons not working
Jason Gerecke (5):
HID: wacom: Properly report negative values from Intuos Pro 2 Bluetooth
HID: wacom: Correct coordinate system of touchring and pen twist
HID: wacom: generic: Send MSC_SERIAL and ABS_MISC when leaving prox
HID: wacom: generic: Clear ABS_MISC when tool leaves proximity
HID: wacom: Always increment hdev refcount within wacom_get_hdev_data
Kai-Heng Feng (1):
Revert "HID: multitouch: Support ALPS PTP stick with pid 0x120A"
Lyude (1):
HID: rmi: Make sure the HID device is opened on resume
Nicholas Bishop (1):
HID: add multi-input quirk for IDC6680 touchscreen
Pavel Tatashin (1):
HID: multitouch: support buttons and trackpoint on Lenovo X1 Tab Gen2
Ping Cheng (1):
HID: wacom: bits shifted too much for 9th and 10th buttons
Shrirang Bagul (1):
HID: multitouch: Support ALPS PTP stick with pid 0x120A
drivers/hid/hid-ids.h | 2 +
drivers/hid/hid-multitouch.c | 7 +++
drivers/hid/hid-rmi.c | 13 +++--
drivers/hid/hidraw.c | 2 +-
drivers/hid/i2c-hid/i2c-hid.c | 3 +-
drivers/hid/usbhid/hid-quirks.c | 1 +
drivers/hid/wacom_sys.c | 7 ++-
drivers/hid/wacom_wac.c | 110 ++++++++++++++++++++++++++++++++--------
8 files changed, 118 insertions(+), 27 deletions(-)
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] drm/gem-cma-helper: Change the level of the allocation failure message
From: Boris Brezillon @ 2017-10-05 8:57 UTC (permalink / raw)
To: Eric Engestrom; +Cc: dri-devel
In-Reply-To: <20171005084824.ti6oi7veo4bn7t3s@imgtec.com>
On Thu, 5 Oct 2017 09:48:24 +0100
Eric Engestrom <eric.engestrom@imgtec.com> wrote:
> On Wednesday, 2017-10-04 22:28:54 +0000, Eric Anholt wrote:
> > Boris Brezillon <boris.brezillon@free-electrons.com> writes:
> >
> > > drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to
> > > allocate the amount of memory we requested. This can lead to annoying
> > > error messages when CMA is only one possible source of memory for the BO
> > > allocation.
> > >
> > > Turn this error message into a debug one and add a __must_check specifier
> > > to make sure all callers are checking the return value.
> > >
> > > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> >
> > The __must_check seems unnecessary to me -- you're definitely going to
> > be doing something with the return value, because otherwise why did you
> > call the object allocate function?
>
> Indeed, `__must_check` (aka `warn_unused_result`) only makes sure the
> return value is not discarded, which will probably always be true here.
I agree, this __must_check is not really useful here.
>
> > The `warn_unused_result` attribute causes a warning to be emitted if
> > a caller of the function with this attribute does not use its return
> > value.
>
> I think we need a sparse attribute to check that the return value is
> IS_ERR()-checked?
Can we just turn the dev_err() into dev_dbg() for now? The 'force
callers to check IS_ERR()' is kind of orthogonal to the change I'm
doing here.
> (not volunteering, I have no idea how to add a sparse attribute :)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* r8169 Wake-on-LAN causes immediate ACPI GPE wakeup
From: Daniel Drake @ 2017-10-05 8:57 UTC (permalink / raw)
To: nic_swsd, netdev, linux-acpi, Linux Kernel; +Cc: Linux Upstreaming Team
Hi,
On the Acer laptop models Aspire ES1-533, Aspire ES1-732, PackardBell
ENTE69AP and Gateway NE533, we are seeing a problem where the system
immediately wakes up after being put into S3 suspend.
This problem has been seen on all kernel versions that we have tried,
including 4.14-rc3.
After disabling wakeup sources one by one, we found that the r8169
ethernet is responsible for these wakeups here, the hardware is:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
Subsystem: Acer Incorporated [ALI] Device 1084
Flags: bus master, fast devsel, latency 0, IRQ 124
I/O ports at 1000 [size=256]
Memory at 91204000 (64-bit, non-prefetchable) [size=4K]
Memory at 91200000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Capabilities: [178] L1 PM Substates
Kernel driver in use: r8169
This driver enables WOL by default. The system wakes up immediately
when it is put into S3 suspend, even if there is no ethernet cable
plugged in.
The problem was also reproduced with the r8168 vendor driver, however
it does not occur under Windows, where we can suspend the system just
fine and also wake it up with a magic WOL packet.
Further investigation takes us into ACPI-land. The complete DSDT is here:
https://gist.github.com/dsd/62293b6d8c30a5204128709813a55ffb
Both Windows and Linux associate PCI0.RP05.PXSX with this device, so
let's consider this part of the DSDT:
Device (RP05)
{
Method (_ADR, 0, NotSerialized) // _ADR: Address
{
If (RPA5 != Zero)
{
Return (RPA5) /* \RPA5 */
}
Else
{
Return (0x00130002)
}
}
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x09, 0x04))
}
Device (PXSX)
{
Name (_ADR, Zero) // _ADR: Address
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x08,
0x04
})
}
}
RP05 corresponds to
00:13.0 PCI bridge: Intel Corporation Device 5ada (rev fb)
I am not familiar with this subdevice approach, where PXSX (with
address 0) is detected as a child of the PCI bridge, however both
Windows and Linux associate PXSX with the ethernet device, so I guess
it is correct.
Now to focus on the _PRW power resource for wakeup. The PXSX
(ethernet) device says that it will wake up the system using GPE08.
However if you look at the _L08 GPE08 event handler, you will see that
it does not do anything related to RP05/PXSX (it instead calls into
RP02, which does not even physically exist on this platform) -
suspicious.
On the other hand, the RP05 (root port) _PRW says it will wake up the
system via GPE09, and the _L09 handler at least has one codepath which
could potentially do a Notify(PXSX, 2) to indicate an ethernet wakeup.
But in testing:
- If GPE08 is enabled as a wakeup source, the system will always wake
up as soon as it goes to sleep
- I have never seen a wakeup on GPE09
- Disabling GPE08 and all other GPE wakeups, the system sleeps fine,
and Wake-on-LAN works fine too
So in summary, the messy situation is that the DSDT suggests that
GPE08 will be used for ethernet wakeups, however that GPE seems to
fire instantly during suspend, and actually wake-on-LAN does not
appear to use ACPI GPEs to wake the system it all - it must use some
other mechanism. Windows is for some reason ignoring the ethernet
device _PRW information so it does not suffer this issue.
Does anyone have suggestions for how Linux should work with this?
What logic should we use to ignore the _PRW in this case, or how can
we quirk it?
Also, is there a standard behaviour defined for ethernet drivers
regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default
if it believes the hardware is capable of it, but other ethernet
drivers seem to default to WOL off. (I don't expect users of the
affected consumer laptops here to care about WOL support.)
Daniel
^ permalink raw reply
* Re: [dim PATCH 2/6] dim: url_to_remote can't normally fail
From: Jani Nikula @ 2017-10-05 8:57 UTC (permalink / raw)
To: intel-gfx; +Cc: Daniel Vetter, Rodrigo Vivi
In-Reply-To: <87y3os45ws.fsf@intel.com>
On Tue, 03 Oct 2017, Jani Nikula <jani.nikula@intel.com> wrote:
> On Tue, 03 Oct 2017, Jani Nikula <jani.nikula@intel.com> wrote:
>> Since commit cad37e1910f9 ("dim: auto-add remotes") url_to_remote can't
>> really fail. Same for repo_to_remote when the repo exists. Redirecting
>> their output when the remote isn't there leads to url_to_remote waiting
>> for user input without prompting, giving an appearance of a hang.
>
> Wah. I've been going back and forth with this, but I'm now leaning
> towards reverting cad37e1910f9 ("dim: auto-add remotes") and going back
> to the drawing board with it.
>
> The problem is, url_to_remote, repo_to_remote and friends are low-level
> helpers in the script. That kind of things are better off returning
> true/false status instead of going out of their way to interactively fix
> stuff up. The *caller*, where applicable, should auto-add remotes,
> depending on the case.
>
> I hit the problem first on one machine which doesn't use worktrees. I
> conceded we could make worktrees a requirement. However, I have a strict
> separation between maintainer and developer repos, with no push access
> at all to the remotes from the developer repo. I have no desire to give
> up on that safety measure. However, dim is helpful in the developer repo
> too.
>
> Also, there's been requests to move dim more towards working in the CWD
> instead of cd to predefined repo. I'm not sure it's reasonable to
> require that all of them have all of the remotes available, for no
> particularly good reason. With worktrees the remotes are shared, but if
> you don't use a common tree for all of them, that benefit is lost.
Okay, I admit defeat. I don't have the time or chrystal clear idea how
to fix all this cleanly and nicely, and we can't block on this
indefinitely. One of the problems with tab completion was that
list-upstreams operated in the current dir; I sent a fix on top of this
series. In general, I think we need a better idea on what should work
and operate in CWD. The mixture we have now is not ideal.
So if you would be so kind to review this set so we can move forward,
and let's improve upon this gradually as issues arise.
BR,
Jani.
>
> BR,
> Jani.
>
>
>
>>
>> While at it, change the exit to a return. set -e at the top takes care
>> of aborting.
>>
>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> Cc: Sean Paul <seanpaul@chromium.org>
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> ---
>> dim | 24 ++++++++----------------
>> 1 file changed, 8 insertions(+), 16 deletions(-)
>>
>> diff --git a/dim b/dim
>> index 7832ddca692c..ae8f30b8db83 100755
>> --- a/dim
>> +++ b/dim
>> @@ -282,7 +282,7 @@ function url_to_remote # url [url ...]
>> echoerr "Please set it up yourself using:"
>> echoerr " $ git remote add <name> $url"
>> echoerr "with a name of your choice."
>> - exit 1
>> + return 1
>> fi
>>
>> git remote add $remote $url
>> @@ -1749,10 +1749,7 @@ function dim_list_upstreams
>> {
>> local dim_drm_upstream_remote
>>
>> - # Handle failures gracefully
>> - if ! dim_drm_upstream_remote=$(url_to_remote $drm_upstream_git 2>/dev/null); then
>> - return 0
>> - fi
>> + dim_drm_upstream_remote=$(url_to_remote $drm_upstream_git)
>>
>> echo origin/master
>> echo $dim_drm_upstream_remote/drm-next
>> @@ -1772,17 +1769,14 @@ function dim_update_branches
>>
>> cd $DIM_PREFIX/$DIM_DRM_INTEL
>>
>> - if remote=$(url_to_remote $linux_upstream_git 2>/dev/null); then
>> - echo -n "Fetching linux (local remote $remote)... "
>> - git_fetch_helper $remote
>> - echo "Done."
>> - fi
>> + remote=$(url_to_remote $linux_upstream_git)
>> + echo -n "Fetching linux (local remote $remote)... "
>> + git_fetch_helper $remote
>> + echo "Done."
>>
>> for repo in "${!drm_tip_repos[@]}"; do
>> url_list=${drm_tip_repos[$repo]}
>> - if ! remote=$(url_to_remote $url_list 2>/dev/null); then
>> - continue
>> - fi
>> + remote=$(url_to_remote $url_list)
>> echo -n "Fetching $repo (local remote $remote)... "
>> git_fetch_helper $remote
>> echo "Done."
>> @@ -1826,9 +1820,7 @@ function dim_status
>>
>> for branch in $dim_branches ; do
>> repo=$(branch_to_repo $branch)
>> - if ! remote=$(repo_to_remote $repo) ; then
>> - continue
>> - fi
>> + remote=$(repo_to_remote $repo)
>>
>> patches=$(git log --oneline $remote/$branch ^origin/master ^$drm_remote/drm-next ^$drm_remote/drm-fixes | wc -l)
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v2 2/5] p0008-abbrev.sh: Test find_unique_abbrev() perf
From: Jeff King @ 2017-10-05 8:57 UTC (permalink / raw)
To: Derrick Stolee; +Cc: git, stolee, git
In-Reply-To: <20171005085553.v3eqk73aaknt5fem@sigill.intra.peff.net>
On Thu, Oct 05, 2017 at 04:55:53AM -0400, Jeff King wrote:
> On Mon, Sep 25, 2017 at 05:54:49AM -0400, Derrick Stolee wrote:
>
> > Create helper program test-abbrev to compute the minimum length of a
> > disambiguating short-sha for an input list of object ids.
>
> This seems like something that Git ought to be able to do via real
> commands.
>
> Using "log --stdin --no-walk --format=%h" doesn't quite work, since it
> only handles commits. We ought to be able to ask "cat-file" for this,
> though. E.g., with the patch below you can do:
>
> git cat-file --batch-check='%(objectsize:short)' <input
>
> Or even just dispense with your earlier randomization helper and do:
>
> git cat-file --batch-all-objects --batch-check='%(objectsize:short)'
>
> to compute the abbreviation for every object.
Of course it would help if I bothered to include the patch. Here it is.
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index f5fa4fd75a..a5f911a632 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -225,6 +225,9 @@ static void expand_atom(struct strbuf *sb, const char *atom, int len,
if (is_atom("objectname", atom, len)) {
if (!data->mark_query)
strbuf_addstr(sb, oid_to_hex(&data->oid));
+ } else if (is_atom("objectname:short", atom, len)) {
+ if (!data->mark_query)
+ strbuf_add_unique_abbrev(sb, data->oid.hash, MINIMUM_ABBREV);
} else if (is_atom("objecttype", atom, len)) {
if (data->mark_query)
data->info.typep = &data->type;
-Peff
^ permalink raw reply related
* Re: [PATCH v2 2/5] p0008-abbrev.sh: Test find_unique_abbrev() perf
From: Jeff King @ 2017-10-05 8:55 UTC (permalink / raw)
To: Derrick Stolee; +Cc: git, stolee, git
In-Reply-To: <20170925095452.66833-3-dstolee@microsoft.com>
On Mon, Sep 25, 2017 at 05:54:49AM -0400, Derrick Stolee wrote:
> Create helper program test-abbrev to compute the minimum length of a
> disambiguating short-sha for an input list of object ids.
This seems like something that Git ought to be able to do via real
commands.
Using "log --stdin --no-walk --format=%h" doesn't quite work, since it
only handles commits. We ought to be able to ask "cat-file" for this,
though. E.g., with the patch below you can do:
git cat-file --batch-check='%(objectsize:short)' <input
Or even just dispense with your earlier randomization helper and do:
git cat-file --batch-all-objects --batch-check='%(objectsize:short)'
to compute the abbreviation for every object.
> Perf test p0008-abbrev.sh runs test-abbrev for 100,000 object ids. For
> test 0008.1, these objects exist. For test 0008.2 these objects do not
> exist in the repo (with high probability). For each test, use `sort -R`
> to (deterministically) shuffle the sample of object ids to not check
> abbreviations in lexicographic order.
I know you're not the first to add a test like this, but I'm somewhat
negative on these sorts of micro-benchmark perf tests. They're nice for
showing off an improvement, but there's little indication of how they
impact things that users actually do.
We know that this series makes finding abbreviations cheaper. But how
much does it speed up "git log --oneline" on a real repository
(including absurdly-sized ones)?
-Peff
^ permalink raw reply
* Re: [PATCH v4 07/15] x86: implement set value flow for MBA
From: Jan Beulich @ 2017-10-05 8:55 UTC (permalink / raw)
To: Yi Sun; +Cc: andrew.cooper3, xen-devel, wei.liu2, chao.p.peng, roger.pau
In-Reply-To: <20171005044812.GH11006@yi.y.sun>
>>> On 05.10.17 at 06:48, <yi.y.sun@linux.intel.com> wrote:
> On 17-10-03 23:59:46, Jan Beulich wrote:
>> >>> Yi Sun <yi.y.sun@linux.intel.com> 09/29/17 4:58 AM >>>
>> >On 17-09-28 05:36:11, Jan Beulich wrote:
>> >> >>> On 23.09.17 at 11:48, <yi.y.sun@linux.intel.com> wrote:
>> >> > This patch implements set value flow for MBA including its callback
>> >> > function and domctl interface.
>> >> >
>> >> > It also changes the memebers in 'cos_write_info' to transfer the
>> >> > feature array, feature properties array and value array. Then, we
>> >> > can write all features values on the cos id into MSRs.
>> >> >
>> >> > Because multiple features may co-exist, we need handle all features to write
>> >> > values of them into a COS register with new COS ID. E.g:
>> >> > 1. L3 CAT and MBA co-exist.
>> >> > 2. Dom1 and Dom2 share a same COS ID (2). The L3 CAT CBM of Dom1 is 0x1ff,
>> >> > the MBA Thrtle of Dom1 is 0xa.
>> >> > 3. User wants to change MBA Thrtl of Dom1 to be 0x14. Because COS ID 2 is
>> >> > used by Dom2 too, we have to pick a new COS ID 3. The values of Dom1 on
>> >> > COS ID 3 are all default values as below:
>> >> > ---------
>> >> > | COS 3 |
>> >> > ---------
>> >> > L3 CAT | 0x7ff |
>> >> > ---------
>> >> > MBA | 0x0 |
>> >> > ---------
>> >> > 4. After setting, the L3 CAT CBM value of Dom1 should be kept and the new MBA
>> >> > Thrtl is set. So, the values on COS ID 3 should be below.
>> >> > ---------
>> >> > | COS 3 |
>> >> > ---------
>> >> > L3 CAT | 0x1ff |
>> >> > ---------
>> >> > MBA | 0x14 |
>> >> > ---------
>> >> >
>> >> > So, we should write all features values into their MSRs. That requires the
>> >> > feature array, feature properties array and value array are input.
>> >>
>> >> How is this last aspect (and the respective changes) related to MBA?
>> >> I.e. why isn't this needed with the (also independent but possibly
>> >> co-existing) L2/L3 CAT features?
>> >>
>> >I tried to introduce this in L2 CAT patch set but did not succeed. As there is
>> >no HW that L2 CAT and L3 CAT co-exist so far, I did not insist on this.
>>
>> Hmm, I'm afraid this wasn't then made clear enough to understand. I would
>> certainly not have been against something that could in theory occur with
>> L2/L3 CAT alone. In any event this means you don't want to mix this into this
>> MBA specific change here.
>>
> Anyway, I think you suggest to split this as a new patch, right?
Yes indeed.
>> >> > static void do_write_psr_msrs(void *data)
>> >> > {
>> >> > const struct cos_write_info *info = data;
>> >> > - struct feat_node *feat = info->feature;
>> >> > - const struct feat_props *props = info->props;
>> >> > - unsigned int i, cos = info->cos, cos_num = props->cos_num;
>> >> > + unsigned int i, index = 0, cos = info->cos;
>> >> > + const uint32_t *val_array = info->val;
>> >> >
>> >> > - for ( i = 0; i < cos_num; i++ )
>> >> > + for ( i = 0; i < ARRAY_SIZE(feat_props); i++ )
>> >> > {
>> >> > - if ( feat->cos_reg_val[cos * cos_num + i] != info->val[i] )
>> >> > + struct feat_node *feat = info->features[i];
>> >> > + const struct feat_props *props = info->props[i];
>> >> > + unsigned int cos_num, j;
>> >> > +
>> >> > + if ( !feat || !props )
>> >> > + continue;
>> >> > +
>> >> > + cos_num = props->cos_num;
>> >> > + if ( info->array_len < index + cos_num )
>> >> > + return;
>> >> > +
>> >> > + for ( j = 0; j < cos_num; j++ )
>> >> > {
>> >> > - feat->cos_reg_val[cos * cos_num + i] = info->val[i];
>> >> > - props->write_msr(cos, info->val[i], props->type[i]);
>> >> > + if ( feat->cos_reg_val[cos * cos_num + j] != val_array[index + j] )
>> >> > + feat->cos_reg_val[cos * cos_num + j] =
>> >> > + props->write_msr(cos, val_array[index + j], props->type[j]);
>> >>
>> >> This renders partly useless the check: If hardware can alter the
>> >> value, repeatedly requesting the same value to be written will
>> >> no longer guarantee the MSR write to be skipped. If hardware
>> >> behavior can't be predicted you may want to consider recording
>> >> both the value in found by reading back the register written and
>> >> the value that was written - a match with either would eliminate
>> >> the need to do the write.
>> >>
>> >The hardware behavior is explicitly defined by SDM and mentioned in
>> >'xl-psr.markdown' and 'intel_psr_mba.pandoc'. User should know that HW
>> >can alter MBA value if the value is not valid.
>>
>> So if hardware behavior is fully defined, why don't you pre-adjust what is
>> to be written to the value hardware would alter it to?
>>
> In previous version of MBA patch set, I pre-adjust the value in 'mba_check_thrtl'.
> But Roger did not like that. So, the pre-adjust codes are removed.
Could you point me at or repeat the reason(s) of his dislike?
>> >This check is not only for MBA but also for CAT features that the HW
>> >cannot alter CAT value.
>>
>> I don't understand this part.
>>
> I mean the check here are for all features so we cannot remove it.
I _still_ don't understand: If the check can't be removed (even
without MBA in mind), then the implication would be that the
code prior to this series is buggy. In which case I'd expect you to
submit a standalone bug fix, rather than mixing the fix into here.
>> > Although this check is not a critical check,
>> >it can prevent some non-necessary MSR write.
>>
>> That's my point - while previously all unnecessary writes were avoided,
>> you now avoid only some.
>>
> Without the pre-adjust codes in 'mba_check_thrtl', if user inputs value, e.g.
> 11/22/33/..., this check cannot prevent the write action. So, only some can
> be avoided in current codes.
Right. If it's worthwhile avoiding the writes, all of them should be
avoided when the resulting value isn't going to change. Otherwise
the write avoidance logic can/should be dropped altogether.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v4 3/4] eventdev: Add eventdev ethernet Rx adapter
From: Rao, Nikhil @ 2017-10-05 8:54 UTC (permalink / raw)
To: Jerin Jacob
Cc: bruce.richardson, gage.eads, dev, thomas, harry.van.haaren,
hemant.agrawal, nipun.gupta, narender.vangati, erik.g.carrillo,
abhinandan.gujjar, santosh.shukla
In-Reply-To: <20171002103955.GA11011@jerin>
On 10/2/2017 4:09 PM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Mon, 2 Oct 2017 15:58:56 +0530
>> From: "Rao, Nikhil" <nikhil.rao@intel.com>
>> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>> CC: bruce.richardson@intel.com, gage.eads@intel.com, dev@dpdk.org,
>> thomas@monjalon.net, harry.van.haaren@intel.com, hemant.agrawal@nxp.com,
>> nipun.gupta@nxp.com, narender.vangati@intel.com,
>> erik.g.carrillo@intel.com, abhinandan.gujjar@intel.com,
>> santosh.shukla@caviumnetworks.com
>> Subject: Re: [PATCH v4 3/4] eventdev: Add eventdev ethernet Rx adapter
>> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
>> Thunderbird/52.3.0
>>
>> On 9/25/2017 8:29 AM, Rao, Nikhil wrote:
>>> On 9/24/2017 11:46 PM, Rao, Nikhil wrote:
>>>> On 9/22/2017 2:40 PM, Jerin Jacob wrote:
>>>>
>>>>> When we worked on a prototype, we figured out that we need a
>>>>> separate event type
>>>>> for RX adapter. Probably RTE_EVENT_TYPE_ETHDEV_RX_ADAPTER?
>>>>> The Reason is:
>>>>> - In the HW based Rx adapter case, the packet are coming
>>>>> directly to eventdev once it is configured.
>>>>> - So on a HW implementation of the event dequeue(), CPU needs to
>>>>> convert HW specific
>>>>> metadata to mbuf
>>>>> - The event dequeue() is used in two cases
>>>>> a) octeontx eventdev driver used with any external NIC
>>>>> b) octeontx eventdev driver used with integrated NIC(without service
>>>>> core to inject the packet)
>>>>> We need some identifier to understand case (a) and (b).So, in
>>>>> dequeue(), if the
>>>>> packet is from RTE_EVENT_TYPE_ETHDEV then we can do "HW specific
>>>>> metadata" to mbuf
>>>>> conversion and in another case (!RTE_EVENT_TYPE_ETHDEV) result
>>>>> in no mbuf
>>>>> conversion.
>>>>>
>>>>> Application can check if it is an Ethernet type event by
>>>>> ev.event_type == RTE_EVENT_TYPE_ETHDEV || ev.event_type ==
>>>>> RTE_EVENT_TYPE_ETHDEV_RX_ADAPTER
>>>>>
>>>>
>>>> As per my understanding, the case (a) uses an in built port
>>>> Is it possible for the eventdev PMD to do the conversion based off
>>>> the eventdev port ?
>>>>
>>>
>>> I realized the dequeue wouldn't have knowledge of the port the event was
>>> injected from, the application shouldn't have to see the difference
>>> between case (a) & (b).
>>>
>>> Would it be possible to use the impl_opaque field within struct rte_event ?
>>>
>>> Nikhil
>>
>> Hi Jerin,
>>
>> Any further thoughts on this ?
>
> impl_opaque field could be one option. But I think, NXP driver is using
> it for internal operation. So overriding it from Rx adapter will cause
> issue. How about adding new event type? So it gets a new name space so no
> collision.
>
> ➜ [master][dpdk-next-eventdev] $ git diff
> diff --git a/lib/librte_eventdev/rte_eventdev.h
> b/lib/librte_eventdev/rte_eventdev.h
> index ec7aabd9a..b33423c7e 100644
> --- a/lib/librte_eventdev/rte_eventdev.h
> +++ b/lib/librte_eventdev/rte_eventdev.h
> @@ -878,6 +878,8 @@ rte_event_dev_close(uint8_t dev_id);
> /**< The event generated from cpu for pipelining.
> * Application may use *sub_event_type* to further classify the event
> */
> +#define RTE_EVENT_TYPE_ETHDEV_ADAPTER 0x4
> +/**< The event generated from ethdev Rx adapter */
> #define RTE_EVENT_TYPE_MAX 0x10
> /**< Maximum number of event types */
>
The event source is really RTE_EVENT_TYPE_CPU here, but is the
assumption that the RTE_EVENT_TYPE_CPU name space is owned by the
application (it's actions are driven by a combination of event type and
event sub type) and extending the event source count is the only option
here.
Nikhil
^ permalink raw reply
* [ragnatech:media-tree 2692/2696] drivers/media/rc/gpio-ir-recv.c:38:8: error: implicit declaration of function 'gpiod_get_value'
From: kbuild test robot @ 2017-10-05 8:54 UTC (permalink / raw)
To: Ladislav Michl; +Cc: kbuild-all, Mauro Carvalho Chehab, linux-media, Sean Young
[-- Attachment #1: Type: text/plain, Size: 4445 bytes --]
tree: git://git.ragnatech.se/linux media-tree
head: a8c779eb056e9874c6278151ade857c3ac227db9
commit: eed008e605d13ee4fb64668350be58999e85aac7 [2692/2696] [media] media: rc: gpio-ir-recv: use gpiolib API
config: x86_64-randconfig-s4-10051614 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout eed008e605d13ee4fb64668350be58999e85aac7
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/media/rc/gpio-ir-recv.c: In function 'gpio_ir_recv_irq':
>> drivers/media/rc/gpio-ir-recv.c:38:8: error: implicit declaration of function 'gpiod_get_value' [-Werror=implicit-function-declaration]
val = gpiod_get_value(gpio_dev->gpiod);
^~~~~~~~~~~~~~~
drivers/media/rc/gpio-ir-recv.c: In function 'gpio_ir_recv_probe':
>> drivers/media/rc/gpio-ir-recv.c:60:20: error: implicit declaration of function 'devm_gpiod_get' [-Werror=implicit-function-declaration]
gpio_dev->gpiod = devm_gpiod_get(dev, NULL, GPIOD_IN);
^~~~~~~~~~~~~~
>> drivers/media/rc/gpio-ir-recv.c:60:46: error: 'GPIOD_IN' undeclared (first use in this function)
gpio_dev->gpiod = devm_gpiod_get(dev, NULL, GPIOD_IN);
^~~~~~~~
drivers/media/rc/gpio-ir-recv.c:60:46: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/media/rc/gpio-ir-recv.c:68:18: error: implicit declaration of function 'gpiod_to_irq' [-Werror=implicit-function-declaration]
gpio_dev->irq = gpiod_to_irq(gpio_dev->gpiod);
^~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/gpiod_get_value +38 drivers/media/rc/gpio-ir-recv.c
32
33 static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
34 {
35 int val;
36 struct gpio_rc_dev *gpio_dev = dev_id;
37
> 38 val = gpiod_get_value(gpio_dev->gpiod);
39 if (val >= 0)
40 ir_raw_event_store_edge(gpio_dev->rcdev, val == 1);
41
42 return IRQ_HANDLED;
43 }
44
45 static int gpio_ir_recv_probe(struct platform_device *pdev)
46 {
47 struct device *dev = &pdev->dev;
48 struct device_node *np = dev->of_node;
49 struct gpio_rc_dev *gpio_dev;
50 struct rc_dev *rcdev;
51 int rc;
52
53 if (!np)
54 return -ENODEV;
55
56 gpio_dev = devm_kzalloc(dev, sizeof(*gpio_dev), GFP_KERNEL);
57 if (!gpio_dev)
58 return -ENOMEM;
59
> 60 gpio_dev->gpiod = devm_gpiod_get(dev, NULL, GPIOD_IN);
61 if (IS_ERR(gpio_dev->gpiod)) {
62 rc = PTR_ERR(gpio_dev->gpiod);
63 /* Just try again if this happens */
64 if (rc != -EPROBE_DEFER)
65 dev_err(dev, "error getting gpio (%d)\n", rc);
66 return rc;
67 }
> 68 gpio_dev->irq = gpiod_to_irq(gpio_dev->gpiod);
69 if (gpio_dev->irq < 0)
70 return gpio_dev->irq;
71
72 rcdev = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
73 if (!rcdev)
74 return -ENOMEM;
75
76 rcdev->priv = gpio_dev;
77 rcdev->device_name = GPIO_IR_DEVICE_NAME;
78 rcdev->input_phys = GPIO_IR_DEVICE_NAME "/input0";
79 rcdev->input_id.bustype = BUS_HOST;
80 rcdev->input_id.vendor = 0x0001;
81 rcdev->input_id.product = 0x0001;
82 rcdev->input_id.version = 0x0100;
83 rcdev->dev.parent = dev;
84 rcdev->driver_name = KBUILD_MODNAME;
85 rcdev->min_timeout = 1;
86 rcdev->timeout = IR_DEFAULT_TIMEOUT;
87 rcdev->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
88 rcdev->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
89 rcdev->map_name = of_get_property(np, "linux,rc-map-name", NULL);
90 if (!rcdev->map_name)
91 rcdev->map_name = RC_MAP_EMPTY;
92
93 gpio_dev->rcdev = rcdev;
94
95 rc = devm_rc_register_device(dev, rcdev);
96 if (rc < 0) {
97 dev_err(dev, "failed to register rc device (%d)\n", rc);
98 return rc;
99 }
100
101 platform_set_drvdata(pdev, gpio_dev);
102
103 return devm_request_irq(dev, gpio_dev->irq, gpio_ir_recv_irq,
104 IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
105 "gpio-ir-recv-irq", gpio_dev);
106 }
107
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 23023 bytes --]
^ 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.