[PATCH v3 3/7] ALSA: hda - rename dell_led_set_func to dell_micmute_led_set_func

[Michał Kępień]

With dell_app_wmi_led_set() replaced by dell_micmute_led_set(), rename
the function pointer to the latter for consistency.

Signed-off-by: Michał Kępień 
Tested-by: Alex Hung 
Reviewed-by: Pali Rohár 
Acked-by: Takashi Iwai 
---
 sound/pci/hda/dell_wmi_helper.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c
index e128c8096772..516237ad6ef5 100644
--- a/sound/pci/hda/dell_wmi_helper.c
+++ b/sound/pci/hda/dell_wmi_helper.c
@@ -6,7 +6,7 @@
 #include 
 
 static int dell_led_value;
-static int (*dell_led_set_func)(int);
+static int (*dell_micmute_led_set_func)(int);
 static void (*dell_old_cap_hook)(struct hda_codec *,
 struct snd_kcontrol *,
 struct snd_ctl_elem_value *);
@@ -18,7 +18,7 @@ static void update_dell_wmi_micmute_led(struct hda_codec 
*codec,
if (dell_old_cap_hook)
dell_old_cap_hook(codec, kcontrol, ucontrol);
 
-   if (!ucontrol || !dell_led_set_func)
+   if (!ucontrol || !dell_micmute_led_set_func)
return;
if (strcmp("Capture Switch", ucontrol->id.name) == 0 && 
ucontrol->id.index == 0) {
/* TODO: How do I verify if it's a mono or stereo here? */
@@ -26,8 +26,8 @@ static void update_dell_wmi_micmute_led(struct hda_codec 
*codec,
if (val == dell_led_value)
return;
dell_led_value = val;
-   if (dell_led_set_func)
-   dell_led_set_func(dell_led_value);
+   if (dell_micmute_led_set_func)
+   dell_micmute_led_set_func(dell_led_value);
}
 }
 
@@ -39,15 +39,15 @@ static void alc_fixup_dell_wmi(struct hda_codec *codec,
bool removefunc = false;
 
if (action == HDA_FIXUP_ACT_PROBE) {
-   if (!dell_led_set_func)
-   dell_led_set_func = 
symbol_request(dell_micmute_led_set);
-   if (!dell_led_set_func) {
+   if (!dell_micmute_led_set_func)
+   dell_micmute_led_set_func = 
symbol_request(dell_micmute_led_set);
+   if (!dell_micmute_led_set_func) {
codec_warn(codec, "Failed to find dell wmi symbol 
dell_micmute_led_set\n");
return;
}
 
removefunc = true;
-   if (dell_led_set_func(false) >= 0) {
+   if (dell_micmute_led_set_func(false) >= 0) {
dell_led_value = 0;
if (spec->gen.num_adc_nids > 1 && 
!spec->gen.dyn_adc_switch)
codec_dbg(codec, "Skipping micmute LED control 
due to several ADCs");
@@ -60,9 +60,9 @@ static void alc_fixup_dell_wmi(struct hda_codec *codec,
 
}
 
-   if (dell_led_set_func && (action == HDA_FIXUP_ACT_FREE || removefunc)) {
+   if (dell_micmute_led_set_func && (action == HDA_FIXUP_ACT_FREE || 
removefunc)) {
symbol_put(dell_micmute_led_set);
-   dell_led_set_func = NULL;
+   dell_micmute_led_set_func = NULL;
dell_old_cap_hook = NULL;
}
 }
-- 
2.11.1

[PATCH v3 0/7] Move dell-led to drivers/platform/x86

[Michał Kępień]

This patch series moves the dell-led driver from the LED subsystem to
the x86 platform driver subsystem.

The original motivation behind this effort was to move all code using
the dell-smbios module to the x86 platform driver subsystem.  While I
was investigating the possibilities to do that, it quickly emerged that
dell-led can and in fact should be moved to the x86 platform driver
subsystem in its entirety.

dell-led consists of two major parts:

  - the part exposing a microphone mute LED interface, introduced in
db6d8cc00773 ("dell-led: add mic mute led interface"); this
interface is used by sound/pci/hda/dell_wmi_helper.c; while the
original implementation used a WMI interface, it was changed to use
dell-smbios in cf0d7ea33596 ("dell-led: use dell_smbios_find_token()
for finding mic DMI tokens") and 0c41a08e131d ("dell-led: use
dell_smbios_send_request() for performing SMBIOS calls"),

  - the part handling an activity LED present in Dell Latitude 2100
netbooks, introduced in 72dcd8d08aca ("leds: Add Dell Business Class
Netbook LED driver"); it binds to a specific WMI GUID and then
registers a LED device which is controlled using WMI (i.e. it is
essentially a WMI driver).

Patches 1 and 2 clean up the microphone mute LED interface to minimize
the amount of code moved around.

Patch 3 updates a variable name in sound/pci/hda/dell_wmi_helper.c so
that it better matches that variable's role.

Patch 4 moves the microphone mute LED interface to
drivers/platform/x86/dell-laptop.c, effectively causing
sound/pci/hda/dell_wmi_helper.c to depend on CONFIG_DELL_LAPTOP instead
of CONFIG_LEDS_DELL_NETBOOKS.

Patch 5 reverts dell-led to the state it was in after its initial commit
72dcd8d08aca ("leds: Add Dell Business Class Netbook LED driver") by
removing all remnants of the microphone mute LED handling code.

Patch 6 moves all that is left of dell-led (i.e. the activity LED part,
as originally implemented), to a new module which is placed in
drivers/platform/x86/dell-wmi-led.c.

Patch 7 fixes coding style issues in drivers/platform/x86/dell-wmi-led.c
to make sure it gets a clean start in the x86 platform driver subsystem.

As all patches except patch 3 in this series affect the LED subsystem,
the series is based on linux-leds/for-next.

Changes from v2:

  - Add patch 7 fixing coding style issues (feedback from Joe and Andy
taken into account).

  - Add leading zero to constants in patch 4.

  - Move dell-led.h include one line higher in patch 4.

Changes from v1:

  - Squash patches 2-4 from v1 into a single patch (#2 in v2).

  - Add patch 3.

  - Fix subject pattern in patch 4.

  - Slight commit message adjustments, including fixing a typo
("COFIG_LEDS_DELL_NETBOOKS") in patch 6.

  - Remove the name of the module's source file from the header comment
in drivers/platform/x86/dell-wmi-led.c to avoid the need to update
it in the future.

 drivers/leds/Kconfig   |   9 --
 drivers/leds/Makefile  |   1 -
 drivers/platform/x86/Kconfig   |   8 ++
 drivers/platform/x86/Makefile  |   1 +
 drivers/platform/x86/dell-laptop.c |  28 
 .../dell-led.c => platform/x86/dell-wmi-led.c} | 141 +
 include/linux/dell-led.h   |   6 +-
 sound/pci/hda/dell_wmi_helper.c|  30 ++---
 8 files changed, 86 insertions(+), 138 deletions(-)
 rename drivers/{leds/dell-led.c => platform/x86/dell-wmi-led.c} (56%)

-- 
2.11.1

[PATCH v3 4/7] platform/x86: dell-laptop: import dell_micmute_led_set() from drivers/leds/dell-led.c

[Michał Kępień]

To ensure all users of dell-smbios are in drivers/platform/x86, move the
dell_micmute_led_set() method from drivers/leds/dell-led.c to
drivers/platform/x86/dell-laptop.c.

Signed-off-by: Michał Kępień 
Tested-by: Alex Hung 
Reviewed-by: Pali Rohár 
Acked-by: Andy Shevchenko 
Acked-by: Takashi Iwai 
---
 drivers/leds/dell-led.c| 29 -
 drivers/platform/x86/dell-laptop.c | 28 
 sound/pci/hda/dell_wmi_helper.c|  6 +++---
 3 files changed, 31 insertions(+), 32 deletions(-)

diff --git a/drivers/leds/dell-led.c b/drivers/leds/dell-led.c
index f9002d9bb757..c9cc36a7c890 100644
--- a/drivers/leds/dell-led.c
+++ b/drivers/leds/dell-led.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "../platform/x86/dell-smbios.h"
 
 MODULE_AUTHOR("Louis Davis/Jim Dailey");
@@ -43,34 +42,6 @@ MODULE_ALIAS("wmi:" DELL_LED_BIOS_GUID);
 #define CMD_LED_OFF17
 #define CMD_LED_BLINK  18
 
-#define GLOBAL_MIC_MUTE_ENABLE 0x364
-#define GLOBAL_MIC_MUTE_DISABLE0x365
-
-int dell_micmute_led_set(int state)
-{
-   struct calling_interface_buffer *buffer;
-   struct calling_interface_token *token;
-
-   if (state == 0)
-   token = dell_smbios_find_token(GLOBAL_MIC_MUTE_DISABLE);
-   else if (state == 1)
-   token = dell_smbios_find_token(GLOBAL_MIC_MUTE_ENABLE);
-   else
-   return -EINVAL;
-
-   if (!token)
-   return -ENODEV;
-
-   buffer = dell_smbios_get_buffer();
-   buffer->input[0] = token->location;
-   buffer->input[1] = token->value;
-   dell_smbios_send_request(1, 0);
-   dell_smbios_release_buffer();
-
-   return state;
-}
-EXPORT_SYMBOL_GPL(dell_micmute_led_set);
-
 struct bios_args {
unsigned char length;
unsigned char result_code;
diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index 14392a01ab36..9e35205779c0 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "dell-rbtn.h"
@@ -42,6 +43,8 @@
 #define KBD_LED_AUTO_50_TOKEN 0x02EB
 #define KBD_LED_AUTO_75_TOKEN 0x02EC
 #define KBD_LED_AUTO_100_TOKEN 0x02F6
+#define GLOBAL_MIC_MUTE_ENABLE 0x0364
+#define GLOBAL_MIC_MUTE_DISABLE 0x0365
 
 struct quirk_entry {
u8 touchpad_led;
@@ -1972,6 +1975,31 @@ static void kbd_led_exit(void)
led_classdev_unregister(&kbd_led);
 }
 
+int dell_micmute_led_set(int state)
+{
+   struct calling_interface_buffer *buffer;
+   struct calling_interface_token *token;
+
+   if (state == 0)
+   token = dell_smbios_find_token(GLOBAL_MIC_MUTE_DISABLE);
+   else if (state == 1)
+   token = dell_smbios_find_token(GLOBAL_MIC_MUTE_ENABLE);
+   else
+   return -EINVAL;
+
+   if (!token)
+   return -ENODEV;
+
+   buffer = dell_smbios_get_buffer();
+   buffer->input[0] = token->location;
+   buffer->input[1] = token->value;
+   dell_smbios_send_request(1, 0);
+   dell_smbios_release_buffer();
+
+   return state;
+}
+EXPORT_SYMBOL_GPL(dell_micmute_led_set);
+
 static int __init dell_init(void)
 {
struct calling_interface_buffer *buffer;
diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c
index 516237ad6ef5..7efa7bd7acb2 100644
--- a/sound/pci/hda/dell_wmi_helper.c
+++ b/sound/pci/hda/dell_wmi_helper.c
@@ -2,7 +2,7 @@
  * to be included from codec driver
  */
 
-#if IS_ENABLED(CONFIG_LEDS_DELL_NETBOOKS)
+#if IS_ENABLED(CONFIG_DELL_LAPTOP)
 #include 
 
 static int dell_led_value;
@@ -67,10 +67,10 @@ static void alc_fixup_dell_wmi(struct hda_codec *codec,
}
 }
 
-#else /* CONFIG_LEDS_DELL_NETBOOKS */
+#else /* CONFIG_DELL_LAPTOP */
 static void alc_fixup_dell_wmi(struct hda_codec *codec,
   const struct hda_fixup *fix, int action)
 {
 }
 
-#endif /* CONFIG_LEDS_DELL_NETBOOKS */
+#endif /* CONFIG_DELL_LAPTOP */
-- 
2.11.1

[PATCH v3 2/7] ALSA: hda - use dell_micmute_led_set() instead of dell_app_wmi_led_set()

[Michał Kępień]

The dell_app_wmi_led_set() method introduced in commit db6d8cc00773
("dell-led: add mic mute led interface") was implemented as an easily
extensible entry point for other modules to set the state of various
LEDs.  However, almost three years later it is still only used to
control the mic mute LED, so it will be replaced with direct calls to
dell_micmute_led_set().

Signed-off-by: Michał Kępień 
Tested-by: Alex Hung 
Reviewed-by: Pali Rohár 
Acked-by: Takashi Iwai 
---
 drivers/leds/dell-led.c | 20 ++--
 include/linux/dell-led.h|  6 +-
 sound/pci/hda/dell_wmi_helper.c | 12 ++--
 3 files changed, 9 insertions(+), 29 deletions(-)

diff --git a/drivers/leds/dell-led.c b/drivers/leds/dell-led.c
index e8e8f67224c1..f9002d9bb757 100644
--- a/drivers/leds/dell-led.c
+++ b/drivers/leds/dell-led.c
@@ -46,7 +46,7 @@ MODULE_ALIAS("wmi:" DELL_LED_BIOS_GUID);
 #define GLOBAL_MIC_MUTE_ENABLE 0x364
 #define GLOBAL_MIC_MUTE_DISABLE0x365
 
-static int dell_micmute_led_set(int state)
+int dell_micmute_led_set(int state)
 {
struct calling_interface_buffer *buffer;
struct calling_interface_token *token;
@@ -69,23 +69,7 @@ static int dell_micmute_led_set(int state)
 
return state;
 }
-
-int dell_app_wmi_led_set(int whichled, int on)
-{
-   int state = 0;
-
-   switch (whichled) {
-   case DELL_LED_MICMUTE:
-   state = dell_micmute_led_set(on);
-   break;
-   default:
-   pr_warn("led type %x is not supported\n", whichled);
-   break;
-   }
-
-   return state;
-}
-EXPORT_SYMBOL_GPL(dell_app_wmi_led_set);
+EXPORT_SYMBOL_GPL(dell_micmute_led_set);
 
 struct bios_args {
unsigned char length;
diff --git a/include/linux/dell-led.h b/include/linux/dell-led.h
index 7009b8bec77b..3f033c48071e 100644
--- a/include/linux/dell-led.h
+++ b/include/linux/dell-led.h
@@ -1,10 +1,6 @@
 #ifndef __DELL_LED_H__
 #define __DELL_LED_H__
 
-enum {
-   DELL_LED_MICMUTE,
-};
-
-int dell_app_wmi_led_set(int whichled, int on);
+int dell_micmute_led_set(int on);
 
 #endif
diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c
index 19d41da79f93..e128c8096772 100644
--- a/sound/pci/hda/dell_wmi_helper.c
+++ b/sound/pci/hda/dell_wmi_helper.c
@@ -6,7 +6,7 @@
 #include 
 
 static int dell_led_value;
-static int (*dell_led_set_func)(int, int);
+static int (*dell_led_set_func)(int);
 static void (*dell_old_cap_hook)(struct hda_codec *,
 struct snd_kcontrol *,
 struct snd_ctl_elem_value *);
@@ -27,7 +27,7 @@ static void update_dell_wmi_micmute_led(struct hda_codec 
*codec,
return;
dell_led_value = val;
if (dell_led_set_func)
-   dell_led_set_func(DELL_LED_MICMUTE, dell_led_value);
+   dell_led_set_func(dell_led_value);
}
 }
 
@@ -40,14 +40,14 @@ static void alc_fixup_dell_wmi(struct hda_codec *codec,
 
if (action == HDA_FIXUP_ACT_PROBE) {
if (!dell_led_set_func)
-   dell_led_set_func = 
symbol_request(dell_app_wmi_led_set);
+   dell_led_set_func = 
symbol_request(dell_micmute_led_set);
if (!dell_led_set_func) {
-   codec_warn(codec, "Failed to find dell wmi symbol 
dell_app_wmi_led_set\n");
+   codec_warn(codec, "Failed to find dell wmi symbol 
dell_micmute_led_set\n");
return;
}
 
removefunc = true;
-   if (dell_led_set_func(DELL_LED_MICMUTE, false) >= 0) {
+   if (dell_led_set_func(false) >= 0) {
dell_led_value = 0;
if (spec->gen.num_adc_nids > 1 && 
!spec->gen.dyn_adc_switch)
codec_dbg(codec, "Skipping micmute LED control 
due to several ADCs");
@@ -61,7 +61,7 @@ static void alc_fixup_dell_wmi(struct hda_codec *codec,
}
 
if (dell_led_set_func && (action == HDA_FIXUP_ACT_FREE || removefunc)) {
-   symbol_put(dell_app_wmi_led_set);
+   symbol_put(dell_micmute_led_set);
dell_led_set_func = NULL;
dell_old_cap_hook = NULL;
}
-- 
2.11.1

[no subject]

[MACDONALD, MISHUNA]

Good morning sir/madam, we are presently offering business and personal loans
at low rates at Al Futtaim GE Finance for 2 percent per year and
you are qualified to received the loan. if interested, send request now to: 
aeonthan...@gmail.com

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

[Felipe Balbi]

Hi,

Baolin Wang  writes:
>>> (One possible approach would be to have the setup routine return
>>> different values for explicit and implicit status stages -- for
>>> example, return 1 if it wants to submit an explicit status request.
>>> That wouldn't be very different from the current
>>> USB_GADGET_DELAYED_STATUS approach.)
>>
>> not really, no. The idea was for composite.c and/or functions to support
>> both methods (temporarily) and use "gadget->wants_explicit_stages" to
>> explicitly queue DATA and STATUS. That would mean that f_mass_storage
>> wouldn't have to return DELAYED_STATUS if
>> (gadget->wants_explicit_stages).
>>
>> After all UDCs are converted over and set wants_explicit_stages (which
>> should all be done in a single series), then we get rid of the flag and
>> the older method of DELAYED_STATUS.
>
> (Sorry for late reply due to my holiday)
> I also met the problem pointed by Alan, from my test, I still want to
> need one return value to indicate if it wants to submit an explicit
> status request. Think about the Control-IN with a data stage, we can
> not get the STATUS phase request from usb_ep_queue() call, and we need

why not? wLength tells you that this is a 3-stage transfer. Gadget
driver should be able to figure out that it needs to usb_ep_queue()
another request for status stage.

> to handle this STATUS phase request in dwc3_ep0_xfernotready(). But
> Control-OUT will get one 0-length IN request for the status stage from
> usb_ep_queue(), so we need one return value from setup routine to

no we don't :-)

> distinguish these in dwc3_ep0_xfernotready(), or we can not handle
> status request correctly. Maybe I missed something else.
>>
>>> On the other hand, I am very doubtful about requiring explicit setup
>>> requests.
>>
>> right, me too ;-)
>
> So do you suggest me continue to try to do this? Thanks.

explicit setup? no
explicit status? yes

If you don't wanna do it, it's fine :-) I'll just add to my TODO
list. It just depends on how much other tasks you have on your end ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 09/35] x86: Convert remaining uses of pr_warning to pr_warn

[Juergen Gross]

On 17/02/17 08:11, Joe Perches wrote:
> To enable eventual removal of pr_warning
> 
> This makes pr_warn use consistent for arch/x86
> 
> Prior to this patch, there were 46 uses of pr_warning and
> 122 uses of pr_warn in arch/x86
> 
> Miscellanea:
> 
> o Coalesce a few formats and realign arguments
> o Convert a couple of multiple line printks to single line
> 
> Signed-off-by: Joe Perches 
> ---
>  arch/x86/kernel/amd_gart_64.c  | 12 +++--
>  arch/x86/kernel/apic/apic.c| 46 
> --
>  arch/x86/kernel/apic/apic_noop.c   |  2 +-
>  arch/x86/kernel/setup_percpu.c |  4 +--
>  arch/x86/kernel/tboot.c| 15 ++-
>  arch/x86/kernel/tsc_sync.c |  8 +++---
>  arch/x86/mm/kmmio.c|  8 +++---
>  arch/x86/mm/mmio-mod.c |  5 ++--
>  arch/x86/mm/numa.c | 12 -
>  arch/x86/mm/numa_emulation.c   |  6 ++---
>  arch/x86/mm/testmmiotrace.c|  5 ++--
>  arch/x86/oprofile/op_x86_model.h   |  6 ++---
>  arch/x86/platform/olpc/olpc-xo15-sci.c |  2 +-
>  arch/x86/platform/sfi/sfi.c|  3 +--
>  arch/x86/xen/debugfs.c |  2 +-
>  arch/x86/xen/setup.c   |  2 +-
>  16 files changed, 63 insertions(+), 75 deletions(-)

Xen parts:

Reviewed-by: Juergen Gross 


Juergen

[PATCH 1/6] perf utils: Add perf_quiet_option()

[Namhyung Kim]

The perf_quiet_option() is to suppress all messages.  It's intended to
be called just after parsing options.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/debug.c | 17 +
 tools/perf/util/debug.h |  1 +
 2 files changed, 18 insertions(+)

diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c
index c1838b643108..03eb81f30d0d 100644
--- a/tools/perf/util/debug.c
+++ b/tools/perf/util/debug.c
@@ -203,11 +203,28 @@ int perf_debug_option(const char *str)
v = (v < 0) || (v > 10) ? 0 : v;
}
 
+   if (quiet)
+   v = -1;
+
*var->ptr = v;
free(s);
return 0;
 }
 
+int perf_quiet_option(void)
+{
+   struct debug_variable *var = &debug_variables[0];
+
+   /* disable all debug messages */
+   while (var->name) {
+   *var->ptr = -1;
+   var++;
+   }
+
+   quiet = true;
+   return 0;
+}
+
 #define DEBUG_WRAPPER(__n, __l)\
 static int pr_ ## __n ## _wrapper(const char *fmt, ...)\
 {  \
diff --git a/tools/perf/util/debug.h b/tools/perf/util/debug.h
index d242adc3d5a2..98832f5531d3 100644
--- a/tools/perf/util/debug.h
+++ b/tools/perf/util/debug.h
@@ -54,5 +54,6 @@ int veprintf(int level, int var, const char *fmt, va_list 
args);
 
 int perf_debug_option(const char *str);
 void perf_debug_setup(void);
+int perf_quiet_option(void);
 
 #endif /* __PERF_DEBUG_H */
-- 
2.11.1

[PATCH 6/6] perf record: Honor quiet option properly

[Namhyung Kim]

It should call perf_quiet_option() to suppress messages.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-record.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 6cd6776052e7..47ca5ff02c35 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1677,6 +1677,9 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
argc = parse_options(argc, argv, record_options, record_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
+   if (quiet)
+   perf_quiet_option();
+
if (!argc && target__none(&rec->opts.target))
usage_with_options(record_usage, record_options);
 
-- 
2.11.1

[PATCH 5/6] perf annotate: Add -q/--quiet option

[Namhyung Kim]

The -q/--quiet option is to suppress any message.  Sometimes users just
want to see the numbers and it can be used for that case.

Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-annotate.txt | 4 
 tools/perf/builtin-annotate.c  | 4 
 tools/perf/util/annotate.c | 2 +-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-annotate.txt 
b/tools/perf/Documentation/perf-annotate.txt
index 8ffbd272952d..a89273d8e744 100644
--- a/tools/perf/Documentation/perf-annotate.txt
+++ b/tools/perf/Documentation/perf-annotate.txt
@@ -39,6 +39,10 @@ OPTIONS
 --verbose::
 Be more verbose. (Show symbol address, etc)
 
+-q::
+--quiet::
+   Do not show any message.  (Suppress -v)
+
 -D::
 --dump-raw-trace::
 Dump raw trace in ASCII.
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index ebb628332a6e..4f52d85f5ebc 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -410,6 +410,7 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_BOOLEAN('f', "force", &file.force, "don't complain, do it"),
OPT_INCR('v', "verbose", &verbose,
"be more verbose (show symbol address, etc)"),
+   OPT_BOOLEAN('q', "quiet", &quiet, "do now show any message"),
OPT_BOOLEAN('D', "dump-raw-trace", &dump_trace,
"dump raw trace in ASCII"),
OPT_BOOLEAN(0, "gtk", &annotate.use_gtk, "Use the GTK interface"),
@@ -463,6 +464,9 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
annotate.sym_hist_filter = argv[0];
}
 
+   if (quiet)
+   perf_quiet_option();
+
file.path  = input_name;
 
annotate.session = perf_session__new(&file, false, &annotate.tool);
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 06cc04e5806a..273f21fa32b5 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1768,7 +1768,7 @@ int symbol__annotate_printf(struct symbol *sym, struct 
map *map,
printf("%-*.*s\n",
   graph_dotted_len, graph_dotted_len, graph_dotted_line);
 
-   if (verbose)
+   if (verbose > 0)
symbol__annotate_hits(sym, evsel);
 
list_for_each_entry(pos, ¬es->src->source, node) {
-- 
2.11.1

[PATCH 3/6] perf report: Add -q/--quiet option

[Namhyung Kim]

The -q/--quiet option is to suppress any message.  Sometimes users just
want to see the numbers and it can be used for that case.

Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-report.txt |  4 
 tools/perf/builtin-report.c  | 21 -
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index f2914f03ae7b..c04cc0647c16 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -25,6 +25,10 @@ OPTIONS
 --verbose::
 Be more verbose. (show symbol address, etc)
 
+-q::
+--quiet::
+   Do not show any message.  (Suppress -v)
+
 -n::
 --show-nr-samples::
Show the number of samples for each symbol
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index dbd7fa028861..0a88670e56f3 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -320,6 +320,9 @@ static size_t hists__fprintf_nr_sample_events(struct hists 
*hists, struct report
size_t size = sizeof(buf);
int socked_id = hists->socket_filter;
 
+   if (quiet)
+   return 0;
+
if (symbol_conf.filter_relative) {
nr_samples = hists->stats.nr_non_filtered_samples;
nr_events = hists->stats.total_non_filtered_period;
@@ -372,7 +375,11 @@ static int perf_evlist__tty_browse_hists(struct 
perf_evlist *evlist,
 {
struct perf_evsel *pos;
 
-   fprintf(stdout, "#\n# Total Lost Samples: %" PRIu64 "\n#\n", 
evlist->stats.total_lost_samples);
+   if (!quiet) {
+   fprintf(stdout, "#\n# Total Lost Samples: %" PRIu64 "\n#\n",
+   evlist->stats.total_lost_samples);
+   }
+
evlist__for_each_entry(evlist, pos) {
struct hists *hists = evsel__hists(pos);
const char *evname = perf_evsel__name(pos);
@@ -382,7 +389,7 @@ static int perf_evlist__tty_browse_hists(struct perf_evlist 
*evlist,
continue;
 
hists__fprintf_nr_sample_events(hists, rep, evname, stdout);
-   hists__fprintf(hists, true, 0, 0, rep->min_percent, stdout,
+   hists__fprintf(hists, !quiet, 0, 0, rep->min_percent, stdout,
   symbol_conf.use_callchain);
fprintf(stdout, "\n\n");
}
@@ -716,6 +723,7 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
"input file name"),
OPT_INCR('v', "verbose", &verbose,
"be more verbose (show symbol address, etc)"),
+   OPT_BOOLEAN('q', "quiet", &quiet, "Do not show any message"),
OPT_BOOLEAN('D', "dump-raw-trace", &dump_trace,
"dump raw trace in ASCII"),
OPT_STRING('k', "vmlinux", &symbol_conf.vmlinux_name,
@@ -863,6 +871,9 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
report.symbol_filter_str = argv[0];
}
 
+   if (quiet)
+   perf_quiet_option();
+
if (symbol_conf.vmlinux_name &&
access(symbol_conf.vmlinux_name, R_OK)) {
pr_err("Invalid file: %s\n", symbol_conf.vmlinux_name);
@@ -983,14 +994,14 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
goto error;
}
 
-   if (report.header || report.header_only) {
+   if ((report.header || report.header_only) && !quiet) {
perf_session__fprintf_info(session, stdout,
   report.show_full_info);
if (report.header_only) {
ret = 0;
goto error;
}
-   } else if (use_browser == 0) {
+   } else if (use_browser == 0 && !quiet) {
fputs("# To display the perf.data header info, please use 
--header/--header-only options.\n#\n",
  stdout);
}
@@ -1009,7 +1020,7 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
 * providing it only in verbose mode not to bloat too
 * much struct symbol.
 */
-   if (verbose) {
+   if (verbose > 0) {
/*
 * XXX: Need to provide a less kludgy way to ask for
 * more space per symbol, the u32 is for the index on
-- 
2.11.1

Re: [linux-sunxi] [PATCH 03/21] net-next: stmmac: add optional setup function

[Corentin Labbe]

On Thu, Feb 16, 2017 at 09:38:33PM +0100, Peter Korsgaard wrote:
> > "Corentin" == Corentin Labbe  writes:
> 
>  > Instead of ading more ifthen login for adding a new mac_device_info
> 
> s/login/logic/
> 
> -- 
> Bye, Peter Korsgaard

Thanks, will fix it.
Regards
Corentin Labbe

[PATCH 4/6] perf diff: Add -q/--quiet option

[Namhyung Kim]

The -q/--quiet option is to suppress any message.  Sometimes users just
want to see the numbers and it can be used for that case.

Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-diff.txt |  4 
 tools/perf/builtin-diff.c  | 14 ++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/tools/perf/Documentation/perf-diff.txt 
b/tools/perf/Documentation/perf-diff.txt
index 66dbe3dee74b..a79c84ae61aa 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -73,6 +73,10 @@ OPTIONS
Be verbose, for instance, show the raw counts in addition to the
diff.
 
+-q::
+--quiet::
+   Do not show any message.  (Suppress -v)
+
 -f::
 --force::
 Don't do ownership validation.
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 70a289347591..1b96a318 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -691,7 +691,7 @@ static void hists__process(struct hists *hists)
hists__precompute(hists);
hists__output_resort(hists, NULL);
 
-   hists__fprintf(hists, true, 0, 0, 0, stdout,
+   hists__fprintf(hists, !quiet, 0, 0, 0, stdout,
   symbol_conf.use_callchain);
 }
 
@@ -739,12 +739,14 @@ static void data_process(void)
hists__link(hists_base, hists);
}
 
-   fprintf(stdout, "%s# Event '%s'\n#\n", first ? "" : "\n",
-   perf_evsel__name(evsel_base));
+   if (!quiet) {
+   fprintf(stdout, "%s# Event '%s'\n#\n", first ? "" : 
"\n",
+   perf_evsel__name(evsel_base));
+   }
 
first = false;
 
-   if (verbose || data__files_cnt > 2)
+   if (verbose > 0 || ((data__files_cnt > 2) && !quiet))
data__fprintf();
 
/* Don't sort callchain for perf diff */
@@ -807,6 +809,7 @@ static const char * const diff_usage[] = {
 static const struct option options[] = {
OPT_INCR('v', "verbose", &verbose,
"be more verbose (show symbol address, etc)"),
+   OPT_BOOLEAN('q', "quiet", &quiet, "Do not show any message"),
OPT_BOOLEAN('b', "baseline-only", &show_baseline_only,
"Show only items with match in baseline"),
OPT_CALLBACK('c', "compute", &compute,
@@ -1328,6 +1331,9 @@ int cmd_diff(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
argc = parse_options(argc, argv, options, diff_usage, 0);
 
+   if (quiet)
+   perf_quiet_option();
+
if (symbol__init(NULL) < 0)
return -1;
 
-- 
2.11.1

[PATCH 2/6] perf utils: Check verbose flag properly

[Namhyung Kim]

It now can have negative value to suppress the message entirely.  So it
needs to check it being positive.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/dso.c| 2 +-
 tools/perf/util/hist.c   | 6 +++---
 tools/perf/util/pmu.c| 8 
 tools/perf/util/sort.c   | 8 
 tools/perf/util/symbol-elf.c | 2 +-
 5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 28d41e709128..1a03e9e310a4 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -1058,7 +1058,7 @@ int dso__name_len(const struct dso *dso)
 {
if (!dso)
return strlen("[unknown]");
-   if (verbose)
+   if (verbose > 0)
return dso->long_name_len;
 
return dso->short_name_len;
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 32c6a939e4cc..eaf72a938fb4 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -69,7 +69,7 @@ void hists__calc_col_len(struct hists *hists, struct 
hist_entry *h)
 */
if (h->ms.sym) {
symlen = h->ms.sym->namelen + 4;
-   if (verbose)
+   if (verbose > 0)
symlen += BITS_PER_LONG / 4 + 2 + 3;
hists__new_col_len(hists, HISTC_SYMBOL, symlen);
} else {
@@ -93,7 +93,7 @@ void hists__calc_col_len(struct hists *hists, struct 
hist_entry *h)
if (h->branch_info) {
if (h->branch_info->from.sym) {
symlen = (int)h->branch_info->from.sym->namelen + 4;
-   if (verbose)
+   if (verbose > 0)
symlen += BITS_PER_LONG / 4 + 2 + 3;
hists__new_col_len(hists, HISTC_SYMBOL_FROM, symlen);
 
@@ -107,7 +107,7 @@ void hists__calc_col_len(struct hists *hists, struct 
hist_entry *h)
 
if (h->branch_info->to.sym) {
symlen = (int)h->branch_info->to.sym->namelen + 4;
-   if (verbose)
+   if (verbose > 0)
symlen += BITS_PER_LONG / 4 + 2 + 3;
hists__new_col_len(hists, HISTC_SYMBOL_TO, symlen);
 
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 49bfee0e3d9e..7ba31ff44b75 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -745,7 +745,7 @@ static int pmu_resolve_param_term(struct parse_events_term 
*term,
}
}
 
-   if (verbose)
+   if (verbose > 0)
printf("Required parameter '%s' not specified\n", term->config);
 
return -1;
@@ -803,7 +803,7 @@ static int pmu_config_term(struct list_head *formats,
 
format = pmu_find_format(formats, term->config);
if (!format) {
-   if (verbose)
+   if (verbose > 0)
printf("Invalid event/parameter '%s'\n", term->config);
if (err) {
char *pmu_term = pmu_formats_string(formats);
@@ -838,7 +838,7 @@ static int pmu_config_term(struct list_head *formats,
val = term->val.num;
else if (term->type_val == PARSE_EVENTS__TERM_TYPE_STR) {
if (strcmp(term->val.str, "?")) {
-   if (verbose) {
+   if (verbose > 0) {
pr_info("Invalid sysfs entry %s=%s\n",
term->config, term->val.str);
}
@@ -1223,7 +1223,7 @@ void print_pmu_events(const char *event_glob, bool 
name_only, bool quiet_flag,
printf("%*s", 8, "[");
wordwrap(aliases[j].desc, 8, columns, 0);
printf("]\n");
-   if (verbose)
+   if (verbose > 0)
printf("%*s%s/%s/\n", 8, "", aliases[j].pmu, 
aliases[j].str);
} else
printf("  %-50s [Kernel PMU event]\n", aliases[j].name);
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index df622f4e301e..0ff622288d24 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -151,7 +151,7 @@ static int64_t _sort__dso_cmp(struct map *map_l, struct map 
*map_r)
if (!dso_l || !dso_r)
return cmp_null(dso_r, dso_l);
 
-   if (verbose) {
+   if (verbose > 0) {
dso_name_l = dso_l->long_name;
dso_name_r = dso_r->long_name;
} else {
@@ -172,8 +172,8 @@ static int _hist_entry__dso_snprintf(struct map *map, char 
*bf,
 size_t size, unsigned int width)
 {
if (map && map->dso) {
-   const char *dso_name = !verbose ? map->dso->short_name :
-   map->dso->long_name;
+   const char *dso_name = verbose > 0 ? map->dso->long_name :
+   map->dso->short_name;
  

[PATCHSET 0/6] perf tools: Add -q/--quiet option to suppress messages (v1)

[Namhyung Kim]

Hello,

The -q/--quiet option is to suppress headers or messages (in stdio) so
that it can be copied to other place if users just want to see the
numbers.  This was suggested by Arnaldo.

Note that this patchset only implements it in a couple of commands.
If it seems ok, it can be applied to others later.

The code also is available at 'perf/quiet-v1' branch in my tree

  git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

Thanks,
Namhyung


Namhyung Kim (6):
  perf utils: Add perf_quiet_option()
  perf utils: Check verbose flag properly
  perf report: Add -q/--quiet option
  perf diff: Add -q/--quiet option
  perf annotate: Add -q/--quiet option
  perf record: Honor quiet option properly

 tools/perf/Documentation/perf-annotate.txt |  4 
 tools/perf/Documentation/perf-diff.txt |  4 
 tools/perf/Documentation/perf-report.txt   |  4 
 tools/perf/builtin-annotate.c  |  4 
 tools/perf/builtin-diff.c  | 14 ++
 tools/perf/builtin-record.c|  3 +++
 tools/perf/builtin-report.c| 21 -
 tools/perf/util/annotate.c |  2 +-
 tools/perf/util/debug.c| 17 +
 tools/perf/util/debug.h|  1 +
 tools/perf/util/dso.c  |  2 +-
 tools/perf/util/hist.c |  6 +++---
 tools/perf/util/pmu.c  |  8 
 tools/perf/util/sort.c |  8 
 tools/perf/util/symbol-elf.c   |  2 +-
 15 files changed, 77 insertions(+), 23 deletions(-)

-- 
2.11.1

Re: [PATCH] of: add EXPORT_SYMBOL for of_device_compatible_match

[Corentin Labbe]

On Wed, Feb 15, 2017 at 07:34:57AM -0800, Frank Rowand wrote:
> On 02/15/17 06:22, Corentin Labbe wrote:
> > This symbol will be needed for the dwmac-sun8i ethernet driver.
> > For letting it to be build as module, of_device_compatible_match need to
> > be exported.
> > 
> > Signed-off-by: Corentin Labbe 
> > ---
> >  drivers/of/base.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index df6f6e3..fba351b 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -524,6 +524,7 @@ int of_device_compatible_match(struct device_node 
> > *device,
> >  
> > return score;
> >  }
> > +EXPORT_SYMBOL(of_device_compatible_match);
> >  
> >  /**
> >   * of_machine_is_compatible - Test root of device tree for a given 
> > compatible value
> > 
> 
> 
> 
> Rob's reply to the last person who requested that:
> 
>It's not missing because no modules use it. It's generally preferred
>to use a match table and of_match_node.
> 
> -Frank

I replace of_device_compatible_match like you said and it works.
Thanks
Corentin Labbe

Geode LX AES driver warning, kernel 4.9.10

[Boszormenyi Zoltan]

Hi,

this did not occur in the 4.8.x series but I get this with 4.9.9 and 4.9.10:

[   13.785289] [ cut here ]
[   13.785314] WARNING: CPU: 0 PID: 1 at drivers/base/dd.c:344 
driver_probe_device+0x3f7/0x430
[   13.785319] Modules linked in:
[   13.785339] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.10 #1
[   13.785347]  ce0bddd0 cbb0050a  cc03db65 ce0bde00 cb853a5a cbff2e50 

[   13.785381]  0001 cc03db65 0158 cbc1a987 0158 ce00b068 cc166c14 
cc166c14
[   13.785416]  ce0bde14 cb853b2a 0009   ce0bde44 cbc1a987 
cbb4ac19
[   13.785449] Call Trace:
[   13.785481]  [] dump_stack+0x58/0x7e
[   13.785497]  [] __warn+0xea/0x110
[   13.785514]  [] ? driver_probe_device+0x3f7/0x430
[   13.785530]  [] warn_slowpath_null+0x2a/0x30
[   13.785545]  [] driver_probe_device+0x3f7/0x430
[   13.785562]  [] ? pci_match_id+0x9/0x90
[   13.785578]  [] ? pci_match_device+0xd4/0xf0
[   13.785594]  [] __driver_attach+0xf1/0x100
[   13.785618]  [] ? _raw_spin_lock+0x9/0x30
[   13.785634]  [] ? klist_next+0x1b/0xf0
[   13.785649]  [] ? driver_probe_device+0x430/0x430
[   13.785675]  [] bus_for_each_dev+0x47/0x80
[   13.785690]  [] driver_attach+0x1e/0x20
[   13.785705]  [] ? driver_probe_device+0x430/0x430
[   13.785719]  [] bus_add_driver+0x147/0x260
[   13.785737]  [] driver_register+0x59/0xe0
[   13.785753]  [] ? cleanup_entry_list+0xa/0x3d
[   13.785773]  [] ? efivars_kobject+0x8/0x20
[   13.785794]  [] ? efibc_init+0x3a/0x3a
[   13.785809]  [] __pci_register_driver+0x33/0x40
[   13.785826]  [] geode_aes_driver_init+0x14/0x16
[   13.785841]  [] do_one_initcall+0x42/0x180
[   13.785862]  [] ? parameq+0x18/0x70
[   13.785879]  [] ? parse_args+0x178/0x4c0
[   13.785903]  [] kernel_init_freeable+0x146/0x1dd
[   13.785919]  [] ? set_debug_rodata+0xf/0xf
[   13.785933]  [] ? rest_init+0x70/0x70
[   13.785948]  [] kernel_init+0x10/0x100
[   13.785964]  [] ? schedule_tail+0x11/0x50
[   13.785978]  [] ? rest_init+0x70/0x70
[   13.785996]  [] ret_from_fork+0x1b/0x28
[   13.786064] ---[ end trace 2345b58de526115e ]---
[   13.786216] Geode LX AES :00:01.2: guessed PCI INT A -> IRQ 10
[   13.786291] Geode LX AES :00:01.2: sharing IRQ 10 with :00:01.1
[   13.797843] Geode LX AES :00:01.2: GEODE AES engine enabled.

What has changed in 4.9.x that causes this?

Best regards,
Zoltán Böszörményi

RE: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

[Kweh, Hock Leong]

> -Original Message-
> From: Bryan O'Donoghue [mailto:pure.lo...@nexus-software.ie]
> Sent: Friday, February 17, 2017 8:54 AM
> To: Kweh, Hock Leong ; Jan Kiszka
> ; Andy Shevchenko 
> Cc: Matt Fleming ; Ard Biesheuvel
> ; linux-...@vger.kernel.org; Linux Kernel Mailing
> List ; Borislav Petkov 
> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
> images
> 
> 
> 
> On 16/02/17 03:00, Kweh, Hock Leong wrote:
> >> -Original Message-
> >> From: Jan Kiszka [mailto:jan.kis...@siemens.com]
> >> Sent: Thursday, February 16, 2017 3:00 AM
> >> To: Andy Shevchenko 
> >> Cc: Matt Fleming ; Ard Biesheuvel
> >> ; linux-...@vger.kernel.org; Linux Kernel
> >> Mailing List ; Borislav Petkov
> >> ; Kweh, Hock Leong ; Bryan
> >> O'Donoghue 
> >> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support
> >> signed Quark images
> >>
> >> On 2017-02-15 19:50, Jan Kiszka wrote:
> >>> On 2017-02-15 19:46, Andy Shevchenko wrote:
>  On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka
>  
> >> wrote:
> > See patch 2 for the background.
> >
> > Series has been tested on the Galileo Gen2, to exclude
> > regressions, with a firmware.cap without security header and the
> > SIMATIC IOT2040 which requires the header because of its mandatory
> secure boot.
> 
>  Briefly looking to the code it looks like a real hack.
>  Sorry, but it would be carefully (re-)designed.
> >>>
> >>> The interface that the firmware provides us? That should have been
> >>> done differently, I agree, but I'm not too much into those firmware
> >>> details, specifically when it comes to signatures.
> >>>
> >>> The Linux code was designed around that suboptimal situation. If
> >>> there are better ideas, I'm all ears.
> >>>
> >>
> >> Expanding CC's as requested by Andy.
> >>
> >> Jan
> >>
> >
> > Hi Jan,
> >
> > While I upstreaming the capsule loader patches, I did work with
> > maintainer Matt and look into this security header created for Quark.
> > Eventually both of us agreed that this will not be upstream to
> > mainline as it is really a Quark specific implementation.
> 
> What's the logic of that ?
> 
> It should be possible to provide a hook (or a custom function).
> 
> >
> > The proper implementation may require to work with UEFI community to
> > expand its capsule spec to support signed binary.
> 
> Are you volunteering to do that with - getting the CSH into the UEFI spec ?
> 
> If not then we should have a method to load/ignore a capsule including the 
> CSH,
> if so then we should have a realistic timeline laid out for getting that spec 
> work
> done.
> 
> Hint: I don't believe integrating the CSH into the UEFI standard will 
> happen...
> 

Hi Jan & Bryan,

Please don't get me wrong. I am not rejecting the patch submission.
I am just sharing a summary for the discussion that I had had it a year back
with maintainer Matt for this topic. From the discussion, we did mention
what would be the proper handling to this case. And to have UEFI expand
it capsule support and take in signed binary would be a more secured way.
So, influencing UEFI community to have such support would be the right
move throughout the discussion. That is my summary.

Of course, influencing the UEFI community would be the longer path.
I think it is worth for try to bring the topic up here again to see if Matt
would reconsider it. 


Regards,
Wilson

Re: [PATCH v2] i2c: at91: ensure state is restored after suspending

[Ludovic Desroches]

On Thu, Feb 16, 2017 at 06:27:59PM +0100, Alexandre Belloni wrote:
> When going to suspend, the I2C registers may be lost because the power to
> VDDcore is cut. Restore them when resuming.
> 
> Signed-off-by: Alexandre Belloni 

Acked-by: Ludovic Desroches 

> ---
> Changes in v2:
>  - don't cache unecessary registers and simply call at91_init_twi_bus()
> 
> 
>  drivers/i2c/busses/i2c-at91.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index 0b86c6173e07..c925a690cb32 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -1180,6 +1180,7 @@ static int at91_twi_suspend_noirq(struct device *dev)
>  
>  static int at91_twi_resume_noirq(struct device *dev)
>  {
> + struct at91_twi_dev *twi_dev = dev_get_drvdata(dev);
>   int ret;
>  
>   if (!pm_runtime_status_suspended(dev)) {
> @@ -1191,6 +1192,8 @@ static int at91_twi_resume_noirq(struct device *dev)
>   pm_runtime_mark_last_busy(dev);
>   pm_request_autosuspend(dev);
>  
> + at91_init_twi_bus(twi_dev);
> +
>   return 0;
>  }
>  
> -- 
> 2.11.0
> 

Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

[Helge Deller]

On 17.02.2017 02:08, Kees Cook wrote:
> On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek  wrote:
>> Hi!
>>
>>>
>>> -config DEBUG_RODATA
>>> +config STRICT_KERNEL_RWX
>>>   bool "Make kernel text and rodata read-only" if 
>>> ARCH_OPTIONAL_KERNEL_RWX
>>>   depends on ARCH_HAS_STRICT_KERNEL_RWX
>>>   default !ARCH_OPTIONAL_KERNEL_RWX ||
>>
>> Debug features are expected to have runtime cost, so kconfig help is
>> silent about those. But there are runtime costs, right? It would be
>> nice to mention them in the help text...
> 
> It depends on the architecture. The prior help text for arm said:
> 
>  The tradeoff is that each region is padded to section-size (1MiB)
>  boundaries (because their permissions are different and splitting
>  the 1M pages into 4K ones causes TLB performance problems), which
>  can waste memory.
> 
> parisc (somewhat inaccurately) said:
> 
>  This option may have a slight performance impact because a
>  portion of the kernel code won't be covered by a TLB anymore.

The logic on parisc is actually:
If huge page support is enabled, we map 1MB pages (and behave like arm wrt 
alignments).
If huge page support is disabled we stay at 4k/PAGE_SIZE pages (without 1M 
alignment).
 
> IIUC, arm64 does what parisc is hinting at: mappings at the end are
> broken down to PAGE_SIZE. 

On parisc we never implemented that.

> On x86, IIUC, there's actually no change to
> TLB performance due to how the mappings are already set up.
> 
> I'm not sure the best way to express this in the new help text. Do you
> have some suggestions on wording? Personally, I don't really think
> it's worth mentioning this in Kconfig help,

I agree on this.

> which, in theory, is
> supposed to limit how technical it gets. And I think the performance
> impact is almost entirely negligible compared to the risks addressed.

Helge

[PATCH][RFC v4] ACPI throttling: Disable the MSR T-state if enabled after resumed

[Chen Yu]

Previously a bug was reported that on certain Broadwell
platform, after resumed from S3, the CPU is running at
an anomalously low speed, due to the BIOS has enabled the
MSR throttling across S3. The solution to this was to introduce
a quirk framework to save/restore tstate MSR register around
suspend/resume, in Commit 7a9c2dd08ead ("x86/pm:
Introduce quirk framework to save/restore extra MSR
registers around suspend/resume").

However there are still three problems left:
1. More and more reports show that other platforms also
   encountered the same issue, so the quirk list might
   be endless.
2. Each CPUs should take the save/restore operation into
   consideration, rather than the boot CPU alone.
3. Normally ACPI T-state re-evaluation is done on resume,
   however there is no _TSS on the bogus platform, thus
   above re-evaluation code does not run on that machine.

Solution:
This patch is based on the fact that, we generally should not
expect the system to come back from resume with throttling
enabled, but leverage the OS components to deal with it,
such as thermal event. So we simply clear the MSR T-state
and print the warning if it is found to be enabled after
resumed back. Besides, we can remove the quirk in previous patch
later.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90041
Reported-and-tested-by: Kadir 
Suggested-by: Len Brown 
Cc: Len Brown 
Cc: "Rafael J. Wysocki" 
Cc: Pavel Machek 
Cc: Zhang Rui 
Cc: Ingo Molnar 
Cc: linux...@vger.kernel.org
Signed-off-by: Chen Yu 
---
 drivers/acpi/processor_throttling.c | 58 +
 1 file changed, 58 insertions(+)

diff --git a/drivers/acpi/processor_throttling.c 
b/drivers/acpi/processor_throttling.c
index a12f96c..e121449 100644
--- a/drivers/acpi/processor_throttling.c
+++ b/drivers/acpi/processor_throttling.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -64,6 +65,7 @@ struct acpi_processor_throttling_arg {
 static int acpi_processor_get_throttling(struct acpi_processor *pr);
 int acpi_processor_set_throttling(struct acpi_processor *pr,
int state, bool force);
+static void throttling_msr_reevaluate(int cpu);
 
 static int acpi_processor_update_tsd_coord(void)
 {
@@ -386,6 +388,15 @@ void acpi_processor_reevaluate_tstate(struct 
acpi_processor *pr,
pr->flags.throttling = 0;
return;
}
+   /*
+* It was found after resumed from suspend to ram, some BIOSes would
+* adjust the MSR tstate, however on these platforms no _PSS is provided
+* thus we never have a chance to adjust the MSR T-state anymore.
+* Thus force clearing it if MSR T-state is enabled, because generally
+* we never expect to come back from resume with throttling enabled.
+* Later let other components to adjust T-state if necessary.
+*/
+   throttling_msr_reevaluate(pr->id);
/* the following is to recheck whether the T-state is valid for
 * the online CPU
 */
@@ -758,6 +769,24 @@ static int acpi_throttling_wrmsr(u64 value)
}
return ret;
 }
+
+static long msr_reevaluate_fn(void *data)
+{
+   u64 msr = 0;
+
+   acpi_throttling_rdmsr(&msr);
+   if (msr) {
+   printk_once(KERN_ERR "PM: The BIOS might have modified the MSR 
T-state, clear it for now.\n");
+   acpi_throttling_wrmsr(0);
+   }
+   return 0;
+}
+
+static void throttling_msr_reevaluate(int cpu)
+{
+   work_on_cpu(cpu, msr_reevaluate_fn, NULL);
+}
+
 #else
 static int acpi_throttling_rdmsr(u64 *value)
 {
@@ -772,8 +801,37 @@ static int acpi_throttling_wrmsr(u64 value)
"HARDWARE addr space,NOT supported yet\n");
return -1;
 }
+
+static long msr_reevaluate_fn(void *data)
+{
+   return 0;
+}
+
+static void throttling_msr_reevaluate(int cpu)
+{
+}
 #endif
 
+void acpi_throttling_resume(void)
+{
+   msr_reevaluate_fn(NULL);
+}
+
+static struct syscore_ops acpi_throttling_syscore_ops = {
+   .resume = acpi_throttling_resume,
+};
+
+static int acpi_throttling_init_ops(void)
+{
+   /*
+* Reevaluate on boot CPU. Since it is not always CPU0,
+* we can not invoke throttling_msr_reevaluate(0) directly.
+*/
+   register_syscore_ops(&acpi_throttling_syscore_ops);
+   return 0;
+}
+device_initcall(acpi_throttling_init_ops);
+
 static int acpi_read_throttling_status(struct acpi_processor *pr,
u64 *value)
 {
-- 
2.7.4

Re: [PATCH 2/3] KVM: use separate generations for each address space

[Paolo Bonzini]

> > +   /*
> > +* Generations must be different for each address space.
> > +* Init kvm generation close to the maximum to easily test the
> > +* code of handling generation number wrap-around.
> > +*/
> > +   slots->generation = i * 2 - 150;
> > +   rcu_assign_pointer(kvm->memslots[i], slots);
> > }
> 
> I can't seem to understand why rcu_assign_pointer wasn't used before.
> kvm->memslots[i] was a rcu protected pointer even before this change,
> right ?

Actually, a better match is RCU_INIT_POINTER.  Here there is no concurrent
reader because we're just initializing the struct kvm.  There is something
else providing synchronization between this writer and the "first" RCU
read-side.  It could be signaling a condition variable, creating a thread,
or releasing a mutex; all three of them have release semantics, which
means they imply a smp_wmb just like rcu_assign_pointer does.

Paolo


> > if (init_srcu_struct(&kvm->srcu))
> > @@ -870,8 +872,14 @@ static struct kvm_memslots
> > *install_new_memslots(struct kvm *kvm,
> >  * Increment the new memslot generation a second time. This prevents
> >  * vm exits that race with memslot updates from caching a memslot
> >  * generation that will (potentially) be valid forever.
> > +*
> > +* Generations must be unique even across address spaces.  We do not 
> > need
> > +* a global counter for that, instead the generation space is evenly
> > split
> > +* across address spaces.  For example, with two address spaces, address
> > +* space 0 will use generations 0, 4, 8, ... while * address space 1 
> > will
> > +* use generations 2, 6, 10, 14, ...
> >  */
> > -   slots->generation++;
> > +   slots->generation += KVM_ADDRESS_SPACE_NUM * 2 - 1;
> >  
> > kvm_arch_memslots_updated(kvm, slots);
> 

Re: [PATCH 12/17] md: raid1: avoid direct access to bvec table in process_checks()

[kbuild test robot]

Hi Ming,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc8]
[cannot apply to next-20170216]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ming-Lei/md-cleanup-on-direct-access-to-bvec-table/20170216-210357
config: powerpc-cell_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   In file included from arch/powerpc/include/asm/page.h:331:0,
from arch/powerpc/include/asm/thread_info.h:34,
from include/linux/thread_info.h:25,
from include/asm-generic/preempt.h:4,
from ./arch/powerpc/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from drivers/md/raid1.c:34:
   drivers/md/raid1.c: In function 'raid1d':
>> include/asm-generic/memory_model.h:54:52: warning: 'sbio_pages$' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
#define __page_to_pfn(page) (unsigned long)((page) - vmemmap)
   ^
   drivers/md/raid1.c:2008:42: note: 'sbio_pages$' was declared here
 struct page *pbio_pages[RESYNC_PAGES], *sbio_pages[RESYNC_PAGES];
 ^~
   drivers/md/raid1.c:2075:9: warning: 'page_len$' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
if (memcmp(page_address(p),
^~~
page_address(s),

page_len[j]))

   drivers/md/raid1.c:2007:6: note: 'page_len$' was declared here
 int page_len[RESYNC_PAGES];
 ^~~~
   In file included from arch/powerpc/include/asm/page.h:331:0,
from arch/powerpc/include/asm/thread_info.h:34,
from include/linux/thread_info.h:25,
from include/asm-generic/preempt.h:4,
from ./arch/powerpc/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from drivers/md/raid1.c:34:
>> include/asm-generic/memory_model.h:54:52: warning: 'pbio_pages$' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
#define __page_to_pfn(page) (unsigned long)((page) - vmemmap)
   ^
   drivers/md/raid1.c:2008:15: note: 'pbio_pages$' was declared here
 struct page *pbio_pages[RESYNC_PAGES], *sbio_pages[RESYNC_PAGES];
  ^~
   drivers/md/raid1.c:1978:8: warning: 'pages$' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
   if (r1_sync_page_io(rdev, sect, s,
   ^~
 pages[idx],
 ~~~
 READ) != 0)
 ~
   drivers/md/raid1.c:1872:15: note: 'pages$' was declared here
 struct page *pages[RESYNC_PAGES];
  ^

vim +54 include/asm-generic/memory_model.h

a117e66e KAMEZAWA Hiroyuki  2006-03-27  38  ({  unsigned long __pfn = (pfn);
\
c5d71243 Rafael J. Wysocki  2008-11-08  39  unsigned long __nid = 
arch_pfn_to_nid(__pfn);  \
a117e66e KAMEZAWA Hiroyuki  2006-03-27  40  NODE_DATA(__nid)->node_mem_map 
+ arch_local_page_offset(__pfn, __nid);\
a117e66e KAMEZAWA Hiroyuki  2006-03-27  41  })
a117e66e KAMEZAWA Hiroyuki  2006-03-27  42  
67de6482 Andy Whitcroft 2006-06-23  43  #define __page_to_pfn(pg)   
\
aa462abe Ian Campbell   2011-08-17  44  ({  const struct page *__pg = (pg); 
\
a0140c1d KAMEZAWA Hiroyuki  2006-03-27  45  struct pglist_data *__pgdat = 
NODE_DATA(page_to_nid(__pg)); \
a0140c1d KAMEZAWA Hiroyuki  2006-03-27  46  (unsigned long)(__pg - 
__pgdat->node_mem_map) + \
a0140c1d KAMEZAWA Hiroyuki  2006-03-27  47   __pgdat->node_start_pfn;   
\
a117e66e KAMEZAWA Hiroyuki  2006-03-27  48  })
a117e66e KAMEZAWA 

[RFC 1/2] fs,eventpoll: Add ability to install target file by its number

[Cyrill Gorcunov]

When we checkpoint a process we look into /proc//fdinfo/ of eventpoll
file and parse target files list from there. In most situations this is fine
because target file is present in the /proc//fd/ list. But in case if file
descriptor was dup'ed or transferred via unix socket and closed after,
it might not be in the list and we can't figure out which file descriptor
to pass into epoll_ctl call.

To resolve this tie lets add EPOLL_CTL_DUP operation which simply takes
target file descriptor number and installs it into a caller's file table,
thus we can use kcmp() syscall and figure out which exactly file to be
added into eventpoll on restore procedure.

Signed-off-by: Cyrill Gorcunov 
CC: Andrey Vagin 
CC: Pavel Emelyanov 
CC: Al Viro 
CC: Andrew Morton 
CC: Michael Kerrisk 
CC: Kir Kolyshkin 
---
 fs/eventpoll.c |   74 +++--
 include/uapi/linux/eventpoll.h |1 
 2 files changed, 65 insertions(+), 10 deletions(-)

Index: linux-ml.git/fs/eventpoll.c
===
--- linux-ml.git.orig/fs/eventpoll.c
+++ linux-ml.git/fs/eventpoll.c
@@ -361,7 +361,7 @@ static inline struct epitem *ep_item_fro
 /* Tells if the epoll_ctl(2) operation needs an event copy from userspace */
 static inline int ep_op_has_event(int op)
 {
-   return op != EPOLL_CTL_DEL;
+   return op != EPOLL_CTL_DEL && op != EPOLL_CTL_DUP;
 }
 
 /* Initialize the poll safe wake up structure */
@@ -967,6 +967,20 @@ free_uid:
return error;
 }
 
+static struct epitem *ep_find_tfd(struct eventpoll *ep, int tfd)
+{
+   struct rb_node *rbp;
+   struct epitem *epi;
+
+   for (rbp = rb_first(&ep->rbr); rbp; rbp = rb_next(rbp)) {
+   epi = rb_entry(rbp, struct epitem, rbn);
+   if (epi->ffd.fd == tfd)
+   return epi;
+   }
+
+   return NULL;
+}
+
 /*
  * Search the file inside the eventpoll tree. The RB tree operations
  * are protected by the "mtx" mutex, and ep_find() must be called with
@@ -979,6 +993,9 @@ static struct epitem *ep_find(struct eve
struct epitem *epi, *epir = NULL;
struct epoll_filefd ffd;
 
+   if (unlikely(!file))
+   return ep_find_tfd(ep, fd);
+
ep_set_ffd(&ffd, file, fd);
for (rbp = ep->rbr.rb_node; rbp; ) {
epi = rb_entry(rbp, struct epitem, rbn);
@@ -1787,6 +1804,28 @@ static void clear_tfile_check_list(void)
INIT_LIST_HEAD(&tfile_check_list);
 }
 
+static int ep_install_tfd(struct eventpoll *ep, struct epitem *epi)
+{
+   struct file *file;
+   int ret = -ENOENT;
+
+   rcu_read_lock();
+   if (get_file_rcu(epi->ffd.file))
+   file = epi->ffd.file;
+   else
+   file = NULL;
+   rcu_read_unlock();
+
+   if (file) {
+   ret = get_unused_fd_flags(0);
+   if (ret >= 0)
+   fd_install(ret, file);
+   else
+   fput(file);
+   }
+   return ret;
+}
+
 /*
  * Open an eventpoll file descriptor.
  */
@@ -1867,15 +1906,24 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, in
if (!f.file)
goto error_return;
 
-   /* Get the "struct file *" for the target file */
-   tf = fdget(fd);
-   if (!tf.file)
-   goto error_fput;
-
-   /* The target file descriptor must support poll */
-   error = -EPERM;
-   if (!tf.file->f_op->poll)
-   goto error_tgt_fput;
+   if (likely(op != EPOLL_CTL_DUP)) {
+   /* Get the "struct file *" for the target file */
+   tf = fdget(fd);
+   if (!tf.file)
+   goto error_fput;
+
+   /* The target file descriptor must support poll */
+   error = -EPERM;
+   if (!tf.file->f_op->poll)
+   goto error_tgt_fput;
+   } else {
+   /*
+* A special case where target file
+* is to be looked up and installed
+* into a caller.
+*/
+   memset(&tf, 0, sizeof(tf));
+   }
 
/* Check if EPOLLWAKEUP is allowed */
if (ep_op_has_event(op))
@@ -1972,6 +2020,12 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, in
else
error = -ENOENT;
break;
+   case EPOLL_CTL_DUP:
+   if (epi)
+   error = ep_install_tfd(ep, epi);
+   else
+   error = -ENOENT;
+   break;
case EPOLL_CTL_MOD:
if (epi) {
if (!(epi->event.events & EPOLLEXCLUSIVE)) {
Index: linux-ml.git/include/uapi/linux/eventpoll.h
===
--- linux-ml.git.orig/include/uapi/linux/eventpoll.h
+++ linux-ml.git/include/uapi/linux/eventpoll.h
@@ -25,6 +25,7 @@
 #define EPOLL_CTL_ADD 1
 #define EPOLL_CTL_

[RFC 0/2] fs,eventpoll: Add EPOLL_CTL_DUP into epoll_ctl syscall

[Cyrill Gorcunov]

In the series new EPOLL_CTL_DUP operation introduced, we need it
to be able to restore target file descriptors in case if they
were dup'ed (or received via unix message) before registering
and closed after, so the fdinfo info shows file number which
application no longer having.

Please take a look. Kir, I slightly updated manpage to mention
the reason why we need this operation.

Cyrill

Re: [PATCH v4 18/36] media: Add i.MX media core driver

[Philipp Zabel]

On Thu, 2017-02-16 at 17:33 -0800, Steve Longerbeam wrote:
> 
> On 02/16/2017 05:02 AM, Philipp Zabel wrote:
> > On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> 
> >> +
> >> +- Clean up and move the ov5642 subdev driver to drivers/media/i2c, and
> >> +  create the binding docs for it.
> >
> > This is done already, right?
> 
> 
> I cleaned up ov5640 and moved it to drivers/media/i2c with binding docs,
> but not the ov5642 yet.

Ok, thanks.

> >> +- The Frame Interval Monitor could be exported to v4l2-core for
> >> +  general use.
> >> +
> >> +- The subdev that is the original source of video data (referred to as
> >> +  the "sensor" in the code), is called from various subdevs in the
> >> +  pipeline in order to set/query the video standard ({g|s|enum}_std)
> >> +  and to get/set the original frame interval from the capture interface
> >> +  ([gs]_parm). Instead, the entities that need this info should call its
> >> +  direct neighbor, and the neighbor should propagate the call to its
> >> +  neighbor in turn if necessary.
> >
> > Especially the [gs]_parm fix is necessary to present userspace with the
> > correct frame interval in case of frame skipping in the CSI.
> 
> 
> Right, understood. I've added this to list of fixes for version 5.
> 
> What a pain though! It means propagating every call to g_frame_interval
> upstream until a subdev "that cares" returns ret == 0 or
> ret != -ENOIOCTLCMD. And that goes for any other chained subdev call
> as well.

Not at all. Since the frame interval is a property of the pad, that had
to be propagated downstream by media-ctl along with media bus format,
frame size, and colorimetry earlier.

regards
Philipp

Re: [PATCH] clk: sunxi-ng: sun6i: Fix enable bit offset for hdmi-ddc module clock

[Maxime Ripard]

On Tue, Feb 14, 2017 at 10:23:32AM +0800, Chen-Yu Tsai wrote:
> The enable bit offset for the hdmi-ddc module clock is wrong. It is
> pointing to the main hdmi module clock enable bit.
> 
> Reported-by: Bob Ham 
> Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
> Cc: sta...@vger.kernel.org # 4.9.x-
> Signed-off-by: Chen-Yu Tsai 

Queued as a fix for 4.11, thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

[Djalal Harouni]

On Fri, Feb 17, 2017 at 2:57 AM, Eric W. Biederman
 wrote:
> James Bottomley  writes:
>
>> On Thu, 2017-02-16 at 11:42 -0500, Vivek Goyal wrote:
>>> On Thu, Feb 16, 2017 at 07:51:58AM -0800, James Bottomley wrote:
>>>
>>> [..]
>>> > > Two levels of checks will simplify this a bit. Top level inode
>>> > > will belong to the user namespace of caller and checks should
>>> > > pass. And mounter's creds will have ownership over the real inode
>>> > > so no additional namespace shifting required there.
>>> >
>>> > That's the problem: for a marked mount, they don't.
>>>
>>> In this new model it does not fit directly.
>>>
>>> I was playing with a slightly different approach and modified patches
>>> so that real root still does the mounting and takes an mount option
>>> which specifies which user namespace we want to shift into. Thanks to
>>> Eric for the idea.
>>>
>>> mount -t shiftfs -o userns_fd= source shifted-fs
>
>> This is a non-starter because it doesn't work for the unprivileged use
>> case, which is what I'm really interested in.
>
> But I believe it does.  It just requires a bit more work for in the
> shiftfs filesystem above.  It should be perfectly possible with the help
> of newuidmap to create a user namespace with the desired mappings.
>
> My understanding is that Vivek started with requiring root to mount the
> filesystem only as a simplification during development, and that the
> plan is to get the basic use case working and then allow unprivileged
> mounting.
>
>> For fully unprivileged
>> containers you don't have an orchestration system to ask to build the
>> container.  You can get init scripts to set stuff up for you, like the
>> marks, but ideally it should just work even without that (so an inode
>> flag following project semantics seems really appealing), but after
>> that the unprivileged user should be able to build their own
>> containers.
>>
>> As you saw from the reply to Eric, this approach (which I have tried)
>> also opens up a whole can of worms for non-FS_USERNS_MOUNT filesystems.
>>
>
> From what I can see we have two cases we care about.
> A) A non-default mapping from the filesystem to the rest of the system
>and roughly s_user_ns provides that but we need a review of the
>filesystems to make certain something has not been forgotten.
>
> B) A filesystem image sitting around in a directory somewhere that
>we want to map differently into different user namespaces while
>using the same files as backing store.
>
> For the second case what is interesting technically is that we want
> multiple mappings.  A user namespace appears adequate to specify those
> extra mappings (effectively from kuids to kuids).
>
> So we need something to associate the additional mapping with a
> directory tree.  A stackable filesystem with it's own s_user_ns field
> appears a very straight forward way to do that.  Especially if it can
> figure out how to assert that the underlying filesystem image is
> read-only (doesn't overlayfs require that?).  Making the entire stack
> read-only.
>
> I don't see a problem with that for unprivileged use (except possibly
> the read-only enforcement on the unerlying directory tree).
>
> What Vivek is talking about appears to be perfectly correct.  Performing
> the underlying filesystem permission checks as the possibly unprivileged
> user who mounted shiftfs.  After performing a set of permission checks
> (at the shiftfs level) as the user who is accessing the files.
>
>
> . . .
>
>
> I think I am missing something but I completely do not understand that
> subthread that says use file marks and perform the work in the vfs.
> The problem is that fundamentally we need multiple mappings and I don't
> see a mark on a file (even an inherited mark) providing the mapping so I
> don't see the point.
>
> Which leaves two possible places to store the extra mapping.  In the
> struct mount.  Or in a stacked filesystem super_block.  For a stacked
> filesystem I can see where to store the extra translation.  In the upper
> filesystems upper inode.   And we can perform the practical permission
> check on the upper inode as well.
>
> For a vfs level solution it looks like we would have to change all of
> the permission checking code in the kernel to have a special case for
> this kind of mapping.  Which does not sound maintainable.

Facts: for basic permissions: 3 files changed, 19 insertions(+), 6
deletions(-)  https://lkml.org/lkml/2016/5/4/417

That made permissions work for basically *all* filesystems. However
yes it does not handle xattr acls...

> So at the moment I don't think a vfs level solution makes any sense.
>
The permissions change was already done when userns were merged. What
you may need is VFS accessors, instead of working directly on
inode->i_uid ask the VFS to give you the right i_uid (which can also
be the case of projectid proposed by Christoph iff I got it right...)
you need it for both ways: to report to userspace and the other way to
pass it to 

Re: [PATCH 20/21] ARM: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig

[Maxime Ripard]

Hi,

On Thu, Feb 16, 2017 at 01:48:58PM +0100, Corentin Labbe wrote:
> From: LABBE Corentin 
> 
> Enable the dwmac-sun8i driver in the sunxi default configuration
> 
> Signed-off-by: Corentin Labbe 
> ---
>  arch/arm/configs/sunxi_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/sunxi_defconfig 
> b/arch/arm/configs/sunxi_defconfig
> index da92c25..33bde86 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -40,6 +40,7 @@ CONFIG_ATA=y
>  CONFIG_AHCI_SUNXI=y
>  CONFIG_NETDEVICES=y
>  CONFIG_SUN4I_EMAC=y
> +CONFIG_DWMAC_SUN8I=m

I think I'd prefer to have it compiled statically, just like the other
net drivers, and drivers in general.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 08/35] sparc: Convert remaining use of pr_warning to pr_warn

[Sam Ravnborg]

On Thu, Feb 16, 2017 at 11:11:21PM -0800, Joe Perches wrote:
> To enable eventual removal of pr_warning
> 
> This makes pr_warn use consistent for arch/sparc
> 
> Prior to this patch, there was 1 use of pr_warning and
> 8 uses of pr_warn in arch/sparc
> 
> Signed-off-by: Joe Perches 
> ---
>  arch/sparc/kernel/smp_64.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/sparc/kernel/smp_64.c b/arch/sparc/kernel/smp_64.c
> index dcb12d9002e9..ca0f8faa79a9 100644
> --- a/arch/sparc/kernel/smp_64.c
> +++ b/arch/sparc/kernel/smp_64.c
> @@ -1564,9 +1564,8 @@ void __init setup_per_cpu_areas(void)
>   pcpu_alloc_bootmem,
>   pcpu_free_bootmem);
>   if (rc)
> - pr_warning("PERCPU: %s allocator failed (%d), "
> -"falling back to page size\n",
> -pcpu_fc_names[pcpu_chosen_fc], rc);
> + pr_warn("PERCPU: %s allocator failed (%d), falling back 
> to page size\n",
> + pcpu_fc_names[pcpu_chosen_fc], rc);

Good to see that the string is now on one line.

Acked-by: Sam Ravnborg 

Re: [PATCH] clk: sunxi-ng: sun6i: Fix enable bit offset for hdmi-ddc module clock

[Maxime Ripard]

Hi Bob,

On Tue, Feb 14, 2017 at 10:20:55PM +, Bob Ham wrote:
> On Tue, 2017-02-14 at 10:23 +0800, Chen-Yu Tsai wrote:
> > The enable bit offset for the hdmi-ddc module clock is wrong. It is
> > pointing to the main hdmi module clock enable bit.
> > 
> > Reported-by: Bob Ham 
> > Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
> > Cc: sta...@vger.kernel.org # 4.9.x-
> > Signed-off-by: Chen-Yu Tsai 
> > ---
> > 
> > Hi Bob,
> > 
> > Can you try this patch and see if it fixes your HDMI issue?
> > With the kernel running without "clk_ignore_unused" that is.
> 
> Hi Chen-Yu,
> 
> Unfortunately, that doesn't fix it; I get the same behaviour as without
> clk_ignore_unused.

can you apply that patch and give us your kernel boot logs?

Thanks!

--8<-
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939fb6bb..0a23b03ea393 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -773,7 +773,9 @@ static void clk_disable_unused_subtree(struct clk_core 
*core)
if (core->enable_count)
goto unlock_out;

-   if (core->flags & CLK_IGNORE_UNUSED)
+   printk("Ignoring %s\n", core->name);
+
+   if (true)
goto unlock_out;

/*
---8<---

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] clk: sunxi: ccu-sun5i needs nkmp

[Maxime Ripard]

On Tue, Feb 14, 2017 at 10:29:45PM +0100, Arnd Bergmann wrote:
> A randconfig build ran into this rare link error:
> 
> drivers/clk/sunxi-ng/ccu-sun5i.o:(.data.__compound_literal.1+0x4): undefined 
> reference to `ccu_nkmp_ops'
> drivers/clk/sunxi-ng/ccu-sun5i.o:(.data.__compound_literal.7+0x4): undefined 
> reference to `ccu_nkmp_ops'
> 
> This adds the missing 'select'.
> 
> Fixes: 5e73761786d6 ("clk: sunxi-ng: Add sun5i CCU driver")
> Signed-off-by: Arnd Bergmann 

Queued as a fix for 4.11, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 08/21] ARM: dts: sun8i-h3: add dwmac-sun8i rgmii pins

[Maxime Ripard]

On Thu, Feb 16, 2017 at 01:48:46PM +0100, Corentin Labbe wrote:
> This patch add pinctrl node for dwmac-sun8i on H3.
> 
> Signed-off-by: Corentin Labbe 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 61d56d2..59ed40e 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -349,6 +349,17 @@
>   function = "i2c2";
>   };
>  
> + emac_rgmii_pins: emac0@0 {
> + allwinner,pins = "PD0", "PD1", "PD2", "PD3",
> + "PD4", "PD5", "PD7",
> + "PD8", "PD9", "PD10",
> + "PD12", "PD13", "PD15",
> + "PD16", "PD17";
> + allwinner,function = "emac";

Please use the generic pin config properties (ie. pins and functions).

> + allwinner,drive = ;

Why do you need to use 40mA?

> + allwinner,pull = ;

This is the default now.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Maxime Ripard]

Hi,

On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
> I was wondering about the following. Wasn't there some strict
> requirement about code going upstream, which also included that there
> was a full open-source driver stack for it?
> 
> I don't see how this is the case for Mali, neither in the kernel, nor in
> userspace. I'm aware that the Mali kernel driver is open-source. But it
> is not upstream, maintained out of tree, and won't land upstream in its
> current form (no resemblence to a DRM driver at all). And let's not talk
> about the userspace part.
> 
> So, why should this be here?

The device tree is a representation of the hardware itself. The state
of the driver support doesn't change the hardware you're running on,
just like your BIOS/UEFI on x86 won't change the device it reports to
Linux based on whether it has a driver for it.

So yes, unfortunately, we don't have a driver upstream at the
moment. But that doesn't prevent us from describing the hardware
accurately.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 05/21] net-next: stmmac: Add dwmac-sun8i

[Maxime Ripard]

Hi,

On Thu, Feb 16, 2017 at 01:48:43PM +0100, Corentin Labbe wrote:
> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> allwinner.
> In fact the only common part is the descriptor management and the first
> register function.
> 
> Signed-off-by: Corentin Labbe 
> ---
>  drivers/net/ethernet/stmicro/stmmac/Kconfig|  11 +
>  drivers/net/ethernet/stmicro/stmmac/Makefile   |   1 +
>  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c  | 892 
> +
>  .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c   |   3 +
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |  27 +-
>  .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   9 +-
>  include/linux/stmmac.h |   1 +
>  7 files changed, 941 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig 
> b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index cfbe363..85c0e41 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -145,6 +145,17 @@ config DWMAC_SUNXI
> This selects Allwinner SoC glue layer support for the
> stmmac device driver. This driver is used for A20/A31
> GMAC ethernet controller.
> +
> +config DWMAC_SUN8I
> + tristate "Allwinner sun8i GMAC support"
> + default ARCH_SUNXI
> + depends on OF && (ARCH_SUNXI || COMPILE_TEST)
> + ---help---
> +   Support for Allwinner H3 A83T A64 EMAC ethernet controllers.
> +
> +   This selects Allwinner SoC glue layer support for the
> +   stmmac device driver. This driver is used for H3/A83T/A64
> +   EMAC ethernet controller.
>  endif
>  
>  config STMMAC_PCI
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile 
> b/drivers/net/ethernet/stmicro/stmmac/Makefile
> index 700c603..fd4937a 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
>  obj-$(CONFIG_DWMAC_STI)  += dwmac-sti.o
>  obj-$(CONFIG_DWMAC_STM32)+= dwmac-stm32.o
>  obj-$(CONFIG_DWMAC_SUNXI)+= dwmac-sunxi.o
> +obj-$(CONFIG_DWMAC_SUN8I)+= dwmac-sun8i.o
>  obj-$(CONFIG_DWMAC_DWC_QOS_ETH)  += dwmac-dwc-qos-eth.o
>  obj-$(CONFIG_DWMAC_GENERIC)  += dwmac-generic.o
>  stmmac-platform-objs:= stmmac_platform.o
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> new file mode 100644
> index 000..0951eb9
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> @@ -0,0 +1,892 @@
> +/*
> + * dwmac-sun8i.c - Allwinner sun8i DWMAC specific glue layer
> + *
> + * Copyright (C) 2017 Corentin Labbe 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "stmmac.h"
> +#include "stmmac_platform.h"
> +
> +struct emac_variant {
> + u32 default_syscon_value;

Why do you need a default value? Can't you read it from the syscon
directly?

> + int internal_phy;
> + bool support_mii;
> + bool support_rmii;
> + bool support_rgmii;
> +};
> +
> +struct sunxi_priv_data {
> + struct clk *tx_clk;
> + struct clk *ephy_clk;
> + struct regulator *regulator;
> + struct reset_control *rst_ephy;
> + const struct emac_variant *variant;
> + bool use_internal_phy;
> + struct regmap *regmap;
> +};
> +
> +static const struct emac_variant emac_variant_h3 = {
> + .default_syscon_value = 0x58000,
> + .internal_phy = PHY_INTERFACE_MODE_MII,
> + .support_mii = true,
> + .support_rmii = true,
> + .support_rgmii = true
> +};
> +
> +static const struct emac_variant emac_variant_a83t = {
> + .default_syscon_value = 0,
> + .internal_phy = 0,
> + .support_mii = true,
> + .support_rgmii = true
> +};
> +
> +static const struct emac_variant emac_variant_a64 = {
> + .default_syscon_value = 0,
> + .internal_phy = 0,
> + .support_mii = true,
> + .support_rmii = true,
> + .support_rgmii = true
> +};
> +
> +#define EMAC_BASIC_CTL0 0x00
> +#define EMAC_BASIC_CTL1 0x04
> +#define EMAC_INT_STA0x08
> +#define EMAC_INT_EN 0x0C
> +#define EMAC_TX_CTL00x10
> +#define EMAC_TX_CTL10x14
> +#define E

Re: [PATCH v6 5/5] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board

[Maxime Ripard]

On Wed, Feb 15, 2017 at 12:35:39AM +0100, Rask Ingemann Lambertsen wrote:
> On Fri, Feb 10, 2017 at 05:22:21PM +0800, Chen-Yu Tsai wrote:
> > On Fri, Feb 10, 2017 at 4:59 PM, Maxime Ripard
> >  wrote:
> > > Hi,
> > >
> > > On Thu, Feb 09, 2017 at 12:34:06AM +0100, Rask Ingemann Lambertsen wrote:
> [...]
> > >> diff --git a/arch/arm/boot/dts/sun9i-a80-cx-a99.dts 
> > >> b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> > >> new file mode 100644
> > >> index 000..f5496d2
> > >> --- /dev/null
> > >> +++ b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> [...]
> > >> + pmic@745 {
> > >> + compatible = "x-powers,axp808", "x-powers,axp806";
> > 
> > As you mentioned elsewhere, they are not really compatible.
> > You should drop the latter compatible.
> 
> The compatibility is good enough that it works fine with the driver that
> went into kernel 4.9 and 4.10. Using this device tree file, I have built and
> booted 4.9.9 and 4.10-rc7 kernels as per the instructions here;
> https://linux-sunxi.org/Sunchip_CX-A99#Linux_kernel
> Likewise any other AXP806 driver which doesn't touch the register at address
> 0xff will work fine.
>
> So, the disadvantage of removing the "x-powers,axp806" compatible is that
> it breaks on two kernel versions where it works fine with the compatible.
> What is the advantage of removing the "x-powers,axp806" compatible?

This works fine for the features you tested, which are the
regulators. All the other features of the PMIC are untested, and might
or might not change, so you really don't know about the overall
capability of the PMIC with another model.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 04/21] ARM: sun8i: dt: Add DT bindings documentation for Allwinner dwmac-sun8i

[Maxime Ripard]

Hi,

On Thu, Feb 16, 2017 at 01:48:42PM +0100, Corentin Labbe wrote:
> This patch adds documentation for Device-Tree bindings for the
> Allwinner dwmac-sun8i driver.
> 
> Signed-off-by: Corentin Labbe 
> ---
>  .../devicetree/bindings/net/dwmac-sun8i.txt| 86 
> ++
>  1 file changed, 86 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt 
> b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> new file mode 100644
> index 000..ac806c6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> @@ -0,0 +1,86 @@
> +* Allwinner sun8i GMAC ethernet controller
> +
> +This device is a platform glue layer for stmmac.
> +Please see stmmac.txt for the other unchanged properties.
> +
> +Required properties:
> +- compatible: should be one of the following string:
> + "allwinner,sun8i-a83t-emac"
> + "allwinner,sun8i-h3-emac"
> + "allwinner,sun50i-a64-emac"
> +- reg: address and length of the register for the device.
> +- interrupts: interrupt for the device
> +- interrupt-names: should be "macirq"
> +- clocks: A phandle to the reference clock for this device
> +- clock-names: should be "stmmaceth"
> +- resets: A phandle to the reset control for this device
> +- reset-names: should be "stmmaceth"
> +- phy-mode: See ethernet.txt
> +- phy-handle: See ethernet.txt
> +- #address-cells: shall be 1
> +- #size-cells: shall be 0
> +- syscon: A phandle to the syscon of the SoC with one of the following
> + compatible string:
> +  - allwinner,sun8i-h3-system-controller
> +  - allwinner,sun8i-a64-system-controller
> +  - allwinner,sun8i-a83t-system-controller
> +
> +Optional properties:
> +- allwinner,tx-delay: TX clock delay chain value. Range value is 0-0x07. 
> Default is 0)
> +- allwinner,rx-delay: RX clock delay chain value. Range value is 0-0x1F. 
> Default is 0)
> +Both delay properties does not have units, there are arbitrary value.
> +The TX/RX clock delay chain settings are board specific and could be found
> +in vendor FEX files.
> +
> +Optional properties for "allwinner,sun8i-h3-emac":
> +- allwinner,leds-active-low: EPHY LEDs are active low
> +
> +Required child node of emac:
> +- mdio bus node: should be named mdio
> +
> +Required properties of the mdio node:
> +- #address-cells: shall be 1
> +- #size-cells: shall be 0
> +
> +The device node referenced by "phy" or "phy-handle" should be a child node
> +of the mdio node. See phy.txt for the generic PHY bindings.
> +
> +Required properties of the phy node with "allwinner,sun8i-h3-emac":
> +- clocks: an extra phandle to the reference clock for the EPHY
> +- resets: an extra phandle to the reset control for the EPHY
> +
> +Required properties for the system controller:
> +- reg: address and length of the register for the device.
> +- compatible: should be "syscon" and one of the following string:
> + "allwinner,sun8i-h3-system-controller"
> + "allwinner,sun8i-a64-system-controller"
> + "allwinner,sun8i-a83t-system-controller"

This should be in a separate binding document.

What does it describe / represent?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] KVM: VMX: use vmcs_set/clear_bits for CPU-based execution controls

[Paolo Bonzini]

- Original Message -
> From: "Bandan Das" 
> To: "Paolo Bonzini" 
> Cc: linux-kernel@vger.kernel.org, k...@vger.kernel.org
> Sent: Friday, February 17, 2017 1:04:14 AM
> Subject: Re: [PATCH] KVM: VMX: use vmcs_set/clear_bits for CPU-based 
> execution controls
> 
> Paolo Bonzini  writes:
> 
> > Signed-off-by: Paolo Bonzini 
> > ---
> 
> I took a quick look and found these two potential
> consumers of these set/clear wrappers.
> 
> vmcs_set_secondary_exec_control()
> vmx_set_virtual_x2apic_mode()
> 
> Since this has been reviewed already,
> we can just have them later in a follow up
> (unless you left them out intentionally).

Both of these can both set and clear bits, so they could be the
consumer of a new function

void vmcs_write_bits(u16 field, u32 value, u32 mask)

but I don't see much benefit in introducing it; the cognitive
load is higher than vmcs_{set,clear}_bits.

Paolo

Re: [PATCH v6 5/5] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board

[Maxime Ripard]

On Thu, Feb 16, 2017 at 07:17:54AM +0100, Rask Ingemann Lambertsen wrote:
> > > Supported features (+ means tested):
> > > + One Cortex-A7 CPU core (or four with experimental U-Boot PSCI patches)
> > > + AXP808 power management chip
> > > + OZ80120 voltage regulator
> > > + Serial console port (internal)
> > > + eMMC and SD card slot
> > > + USB 2.0 host ports on on-board USB hub
> > > + SATA port on on-board SATA-to-USB bridge *
> > > + IEEE 802.11 a/b/g/n/ac SDIO Wifi
> > > + Real-time clock
> > > + LEDs
> > > - IR receiver for remote control
> > > 
> > > * Only shows up when a SATA device is connected. Also, if a power source
> > >   is connected to the USB 3.0 connector across power cycles (e.g. FEL
> > >   boot), the bridge may not properly reset and not show up on the USB bus.
> > >   The vendor U-Boot performs some unknown magic which resets the bridge.
> > 
> > Is that magic at the USB level, or specific to the bridge itself?
> 
> I don't know, but since the other USB port connected to the hub comes up
> fine, I'm assuming it's something to do with the SATA-to-USB bridge.

But where is that magic written to then? the USB controller registers,
or is it an USB packet?

> > > diff --git a/arch/arm/boot/dts/sun9i-a80-cx-a99.dts 
> > > b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> > > new file mode 100644
> > > index 000..f5496d2
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> [...]
> > > + /* USB 3.0 standard-A receptacle. For now, only Vbus is supported. */
> > 
> > I'm not sure what you mean by "only VBUS is supported"? Is there any
> > other signal?
> 
> I'm just trying to say that at the moment, all the connector will do is to
> supply power to a connected device (for charging batteries or whatever).

So the USB controller itself is non-functionnal then?

> > > + reg_usb0_vbus: regulator-usb0-vbus {
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "usb0-vbus";
> > > + regulator-min-microvolt = <500>;
> > > + regulator-max-microvolt = <500>;
> > > + gpio = <&pio 7 15 GPIO_ACTIVE_HIGH>;/* PH15 */
> > > + enable-active-high;
> > 
> > This is redundant with the GPIO flag
> 
> No. I have now tested without "enable-active-high" and then Vbus stays off.
> This is also in line with the binding documentation:
> 
> "- enable-active-high: Polarity of GPIO is Active high
>  If this property is missing, the default assumed is Active low."
>
> It also seems to me that the way this is implemented in Linux, the GPIO
> polarity flag is ignored.

It works just fine if the driver uses the gpiod API. If that driver
doesn't, then that driver needs some fixing :)

> > > + regulator-always-on;
> > 
> > And it shouldn't be always on. The USB driver will enable it if needs
> > be.
> 
> Yes, we just don't have a driver for the A80 USB 3.0 port yet.

Aaah, so that's what you meant. Leave it out of the DT then.

> > > +  * A GL850G hub with two external USB connectors is connected
> > > +  * to ehci0. Each has a Vbus regulator controlled by a GPIO:
> > > +  * PL7 for port 1, closest to the 12 V power connector, and
> > > +  * PL8 for port 2, next to the SD card slot.
> > > +  * Because regulator-fixed doesn't support a GPIO list, and
> > > +  * allwinner,sun9i-a80-usb-phy doesn't support more than one
> > > +  * supply, we have to use regulator-always-on on usb1-2-vbus.
> > > +  * Note that the GPIO pins also need cldo1 to be enabled.
> > > +  */
> > 
> > What is the source of those regulators connected then? Some PMIC
> > regulator? AC-IN?
> 
> These two regulators are supplied from a fixed 12 V to 5 V DC-DC converter
> which can't be controlled in any way.

Ok.

> > > + reg_usb1_1_vbus: regulator-usb1-1-vbus {
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "usb1-1-vbus";
> > > + regulator-min-microvolt = <500>;
> > > + regulator-max-microvolt = <500>;
> > > + gpio = <&r_pio 0 7 GPIO_ACTIVE_HIGH>;   /* PL7 */
> > > + enable-active-high;
> > > + };
> > > +
> > > + reg_usb1_2_vbus: regulator-usb1-2-vbus {
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "usb1-2-vbus";
> > > + regulator-min-microvolt = <500>;
> > > + regulator-max-microvolt = <500>;
> > > + gpio = <&r_pio 0 8 GPIO_ACTIVE_HIGH>;   /* PL8 */
> > > + enable-active-high;
> > > + regulator-always-on;
> > 
> > Same comment about always on. If the driver needs fixing to grab an
> > additional regulator, fix it, but this shouldn't be left that way.
> 
> I agree, but a lot of work is missing to get to that point. To get the USB
> ports up and running, you need to enable quite a few regulators:
> 1. VDD09-USB for the controller internals.

This one has never been needed in any SoC before. You should
definitely add a regulator property to the USB controller node then,
and add a regulator_get to the driver. Ideall

Re: [PATCH] groups: don't return unmapped gids in getgroups(2)

[Aleksa Sarai]

One thing overlooked by commit 9cc46516ddf4 ("userns: Add a knob to
disable setgroups on a per user namespace basis") is that because
setgroups(2) no longer works in user namespaces it doesn't make any
sense to be returning weird group IDs that the process cannot do
anything with.


This code works the same weather or not setgroups is enabled.


Yes. Sorry, I explain the reasoning for this better below. But the point 
is that "65534" is ambiguous in this context and can lead to confusion 
for a userspace program.


However, you have a point that when setgroups is enabled then this code 
will effectively hide groups which the process may wish to drop. I'm not 
sure what you would like to do in this instance -- but I'd prefer if we 
first agree on whether this is a worthwhile issue to solve in the kernel 
or if userspace should just hack around it (which I've already partially 
done[1]).



This change, along with the other changes made to require unprivileged
users to always disable setgroups(2), means that userspace programs such
as apt break inside rootless containers. While this change does change
the userspace ABI, any userspace program that has to deal with
getgroups(2) would have to filter out these "fake" group IDs anyway.
This just makes it so that less applications will have to handle this
broken API.


Is it broken?  Unless I am mistaken if we have a 16bit getgroups
call and we 32bit group ids  getgroups it behaves exactly the same way.


When I say "broken" what I mean is that getgroups(2) is telling 
userspace that "you are a member of group 65534". But you now have two 
different (confusing) cases that can result:


1. That group is not mapped. Which means that anything that application 
assumes about getgroups(2) returning sane results now needs to be 
cross-checked with /proc/self/uid_map and checking whether setgroups 
will actually work. Apt is an example of such a program -- it attempts 
to drop all privileges using setgroups(2) because getgroups(2) tells it 
that has some supplementary groups.


2. That group _is_ mapped. Now the application has no way of knowing 
whether it actually is in group 65534 (aside from experimenting with 
files and trying to see what its _actual_ groups are).


Note that in both cases it is not simple to be completely sure whether 
the 65534 that getgroups(2) returned actually means "unmapped" or



The value we is (u16)-2.  The traditional linux group id for this
purpose.


Okay, but 65534 is a valid group ID as well. So while in principle it's 
reserved for this purpose, returning an "invalid" group ID that is 
actually a valid value is just confusing.



In all other contexts the best we can do for applications has been to
return the user id or group id that says the value you are looking for
does not fit in this context.  Which makes me suspect this is not the
right solution for getgroups.


While with getuid() and getgid() I understand this logic (though I 
strongly feel there should be an EUNMAPPED, I understand why it doesn't 
exist). With get{u,g}id() there is an implicit statement that 
overflow_{u,g}id should be semantically equivalent to "unmapped {U,G}ID".


However, this doesn't (IMO) apply to getgroups(2). getgroups(2) tells 
you what groups you are a member of, and there is a semantic difference 
to "you are a member of group #overflow_gid" and "you are in an unmapped 
group".



I don't know why apt breaks.  You have not described that.  Perhaps apt
is seeing something misconfigured and complaining properly.



I investigated this quite a bit while trying to get rootless containers 
to work with runC. After reading the code again, apt actually does two 
things:


1. Unconditionally does setgroups(1, &some_gid). This obviously breaks 
in rootless containers, but can be fixed.


2. It then has some checks to verify that it has dropped privileges 
correctly. Now, you _can_ disable these checks but I would prefer not to 
(many other programs have similar code to make sure they are safely 
dropping privileges). If you look in apt-pkg/contrib/fileutl.cc you'll 
see this [abbreviated] function:


bool DropPrivileges()
{
/* ... */
  // Verify that the user isn't still in any supplementary groups
  long const ngroups_max = sysconf(_SC_NGROUPS_MAX);
  std::unique_ptr gidlist(new gid_t[ngroups_max]);
  if (unlikely(gidlist == NULL))
	 return _error->Error("Allocation of a list of size %lu for getgroups 
failed", ngroups_max);

  ssize_t gidlist_nr;
  if ((gidlist_nr = getgroups(ngroups_max, gidlist.get())) < 0)
	 return _error->Errno("getgroups", "Could not get new groups (%lu)", 
ngroups_max);

  for (ssize_t i = 0; i < gidlist_nr; ++i)
 if (gidlist[i] != pw->pw_gid)
	return _error->Error("Could not switch group, user %s is still in 
group %d", toUser.c_str(), gidlist[i]);

/* ... */
}

Which will fail in rootless containers, and there's nothing you can do 
as a user other than disable the checks an

Re: [PATCH 4/5] KVM: add __kvm_request_needs_mb

[Christian Borntraeger]

On 02/16/2017 08:49 PM, David Hildenbrand wrote:
> Am 16.02.2017 um 17:04 schrieb Radim Krčmář:
>> A macro to optimize requests that do not need a memory barrier because
>> they have no dependencies.  An architecture can implement a function
>> that says which requests do not need memory barriers when handling them.
>>
>> Signed-off-by: Radim Krčmář 
>> ---
>>  include/linux/kvm_host.h | 41 +
>>  virt/kvm/kvm_main.c  |  3 ++-
>>  2 files changed, 39 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index d899473859d3..2cc438685af8 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -1097,8 +1097,8 @@ static inline int kvm_ioeventfd(struct kvm *kvm, 
>> struct kvm_ioeventfd *args)
>>   *  2) remote request with no data (= kick)
>>   *  3) remote request with data (= kick + mb)
>>   *
>> - * TODO: the API is inconsistent -- a request doesn't call kvm_vcpu_kick(), 
>> but
>> - * forces smp_wmb() for all requests.
>> + * TODO: the API does not distinguish local and remote requests -- remote
>> + * should contain kvm_vcpu_kick().
>>   */
> 
> Just for your info, kvm_vcpu_kick() and kvm_make_all_cpus_request() do
> not work on s390x (and in its current form never will). I tried to make
> it work once, but I gave up.
> 
> s390x uses kvm_s390_sync_request()->kvm_s390_vcpu_request() to kick a
> guest out of guest mode. A special bit in the SIE control block is used
> to perform the kick (exit_sie(), STOP request), and another bit to
> prevent the guest from reentering the SIE, until the request has been
> handled (to avoid races).
> 
> This is really complicated stuff, and the basic reason for it (if I
> remember correctly) is that s390x does reenable all interrupts when
> entering the sie (see kvm-s390.c:__vcpu_run()). So the fancy smp-based
> kicks don't work (as it is otherwise just racy), and if I remember
> correctly, SMP reschedule signals (s390x external calls) would be
> slower. (Christian, please correct me if I'm wrong)

No the reason was that there are some requests that need to be handled
outside run SIE. For example one reason was the guest prefix page.
This must be mapped read/write ALL THE TIME when a guest is running,
otherwise the host might crash. So we have to exit SIE and make sure that
it does not reenter, therefore we use the RELOAD_MMU request from a notifier
that is called from page table functions, whenever memory management decides
to unmap/write protect (dirty pages tracking, reference tracking, page migration
or compaction...)

SMP-based request wills kick out the guest, but for some thing like the
one above it will be too late.

 
> So this statement, is at least from a s390x point of view wrong. The
> kvm_vcpu_kick() function would have to be rerouted to an appropriate
> s390x implementation (or that whole smp and OUTSIDE_GUEST_MODE stuff
> would have to be factored out).
> 

Re: [PATCH] platform/x86: ideapad-laptop: Add sysfs interface for touchpad state

[Dmitry Torokhov]

On Fri, Feb 17, 2017 at 09:39:20AM +0200, Andy Shevchenko wrote:
> On Fri, Feb 17, 2017 at 5:33 AM, Darren Hart  wrote:
> > On Tue, Feb 14, 2017 at 07:46:12PM +0530, Ritesh Raj Sarraf wrote:
> >> Lenovo Yoga (many variants: Yoga, Yoga2 Pro, Yoga2 13, Yoga3 Pro, Yoga 3
> >> 14 etc) has multiple modles that are a hybrid laptop, working in laptop
> >> mode as well as tablet mode.
> 
> > That said, we need to make these systems usable, and as there appears not 
> > to be
> > an accepted standard way of doing this, I don't object to the approach. 
> > However,
> > you mentioned in the bug comments (#64) on 2/12:
> >
> > "I have attached the final patch that I had proposed, but for whatever
> > reasons, the maintainer isn't convinced that that interface is needed."
> >
> > This is the only version of this patch I have seen.
> 
> This patch is actually a v2 that includes maintainers as I had asked
> and additional paragraph to explain why we need such interface.
> 
> > Who objected to the patch?
> 
> I was trying to understand why /dev/input/eventX can not be used for a such.
> 
> > I would like to hear from Rafael and Dmitry, for their opinion on an ACPI 
> > or INPUT
> > interface for indicating TABLET_MODE to userspace. Even if we accept this 
> > patch
> > as is, we should be thinking about how to do this in a standard way.

Kernel should send EV_SW/SW_TABLET_MODE to communicate tablet mode to
userspace; clients should be listening to these events.

It looks like the patch is trying to provide a way to disable the
touchpad when transitioning in tablet mode. In ChromeOS we have a notion
of "inhibiting" input devices, where userspace policy daemon tells the
kernel that it is not interested in events from a given device and input
core will suppress events from such device (and driver may optionally
put device into low power mode, if it chooses to do so). But in this
case the control seems to be totally outside of the input driver (which
I suspect is PS/2 device), so the policy daemon would have to have
specific knowledge of this new knob.

BTW, I am not sure if this is actually reliable: if system goes to S3
with lid open and user changes it into tablet form, nobody will tell the
EC that touchpad should be ignored and it will wake up the tablet.

Thanks.

-- 
Dmitry

Re: [PATCH 20/35] drivers/isdn: Convert remaining uses of pr_warning to pr_warn

[Paul Bolle]

On Thu, 2017-02-16 at 23:11 -0800, Joe Perches wrote:
> To enable eventual removal of pr_warning
> 
> This makes pr_warn use consistent for drivers/isdn
> 
> Prior to this patch, there were 20 uses of pr_warning and
> 3 uses of pr_warn in drivers/isdn
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/isdn/gigaset/interface.c|  2 +-

Gigaset hunk looks good to me:
    Acked-by: Paul Bolle 

>  drivers/isdn/hardware/mISDN/avmfritz.c  | 17 +
>  drivers/isdn/hardware/mISDN/hfcmulti.c  |  8 
>  drivers/isdn/hardware/mISDN/hfcpci.c|  4 ++--
>  drivers/isdn/hardware/mISDN/hfcsusb.c   |  4 ++--
>  drivers/isdn/hardware/mISDN/mISDNipac.c |  4 ++--
>  drivers/isdn/hardware/mISDN/mISDNisar.c | 10 +-
>  drivers/isdn/hardware/mISDN/netjet.c|  8 
>  drivers/isdn/hardware/mISDN/w6692.c | 12 ++--
>  drivers/isdn/mISDN/hwchannel.c  |  8 
>  10 files changed, 39 insertions(+), 38 deletions(-)


Paul Bolle

Re: [PATCH v5 13/15] livepatch: change to a per-task consistency model

[Miroslav Benes]

On Thu, 16 Feb 2017, Josh Poimboeuf wrote:

> On Thu, Feb 16, 2017 at 03:33:26PM +0100, Miroslav Benes wrote:
> > 
> > > @@ -347,22 +356,36 @@ static int __klp_enable_patch(struct klp_patch 
> > > *patch)
> > >  
> > >   pr_notice("enabling patch '%s'\n", patch->mod->name);
> > >  
> > > + klp_init_transition(patch, KLP_PATCHED);
> > > +
> > > + /*
> > > +  * Enforce the order of the func->transition writes in
> > > +  * klp_init_transition() and the ops->func_stack writes in
> > > +  * klp_patch_object(), so that klp_ftrace_handler() will see the
> > > +  * func->transition updates before the handler is registered and the
> > > +  * new funcs become visible to the handler.
> > > +  */
> > > + smp_wmb();
> > > +
> > >   klp_for_each_object(patch, obj) {
> > >   if (!klp_is_object_loaded(obj))
> > >   continue;
> > >  
> > >   ret = klp_patch_object(obj);
> > > - if (ret)
> > > - goto unregister;
> > > + if (ret) {
> > > + pr_warn("failed to enable patch '%s'\n",
> > > + patch->mod->name);
> > > +
> > > + klp_cancel_transition();
> > > + return ret;
> > > + }
> > 
> > [...]
> > 
> > > +static void klp_complete_transition(void)
> > > +{
> > > + struct klp_object *obj;
> > > + struct klp_func *func;
> > > + struct task_struct *g, *task;
> > > + unsigned int cpu;
> > > +
> > > + if (klp_target_state == KLP_UNPATCHED) {
> > > + /*
> > > +  * All tasks have transitioned to KLP_UNPATCHED so we can now
> > > +  * remove the new functions from the func_stack.
> > > +  */
> > > + klp_unpatch_objects(klp_transition_patch);
> > > +
> > > + /*
> > > +  * Make sure klp_ftrace_handler() can no longer see functions
> > > +  * from this patch on the ops->func_stack.  Otherwise, after
> > > +  * func->transition gets cleared, the handler may choose a
> > > +  * removed function.
> > > +  */
> > > + synchronize_rcu();
> > > + }
> > > +
> > > + if (klp_transition_patch->immediate)
> > > + goto done;
> > > +
> > > + klp_for_each_object(klp_transition_patch, obj)
> > > + klp_for_each_func(obj, func)
> > > + func->transition = false;
> > > +
> > > + /* Prevent klp_ftrace_handler() from seeing KLP_UNDEFINED state */
> > > + if (klp_target_state == KLP_PATCHED)
> > > + synchronize_rcu();
> > > +
> > > + read_lock(&tasklist_lock);
> > > + for_each_process_thread(g, task) {
> > > + WARN_ON_ONCE(test_tsk_thread_flag(task, TIF_PATCH_PENDING));
> > > + task->patch_state = KLP_UNDEFINED;
> > > + }
> > > + read_unlock(&tasklist_lock);
> > > +
> > > + for_each_possible_cpu(cpu) {
> > > + task = idle_task(cpu);
> > > + WARN_ON_ONCE(test_tsk_thread_flag(task, TIF_PATCH_PENDING));
> > > + task->patch_state = KLP_UNDEFINED;
> > > + }
> > > +
> > > +done:
> > > + klp_target_state = KLP_UNDEFINED;
> > > + klp_transition_patch = NULL;
> > > +}
> > > +
> > > +/*
> > > + * This is called in the error path, to cancel a transition before it has
> > > + * started, i.e. klp_init_transition() has been called but
> > > + * klp_start_transition() hasn't.  If the transition *has* been started,
> > > + * klp_reverse_transition() should be used instead.
> > > + */
> > > +void klp_cancel_transition(void)
> > > +{
> > > + klp_target_state = !klp_target_state;
> > > + klp_complete_transition();
> > > +}
> > 
> > If we fail to enable patch in __klp_enable_patch(), we call 
> > klp_cancel_transition() and get to klp_complete_transition(). If the patch 
> > has immediate set to true, the module would not be allowed to go (the 
> > changes are in the last patch unfortunately, but my remark is closely 
> > related to klp_cancel_transition() and __klp_enable_patch()). This could 
> > annoy a user if it was due to a trivial reason. So we could call  
> > module_put() in this case. It should be safe as no task could be in a new 
> > function thanks to klp_ftrace_handler() logic.
> > 
> > Pity I have not spotted this earlier.
> > 
> > Putting module_put(patch->mod) right after klp_cancel_transition() call in 
> > __klp_enable_patch() would be the simplest fix (as a part of 15/15 patch). 
> > Maybe with a comment that it is safe to do it there.
> > 
> > What do you think?
> 
> Good catch.  I agree that 15/15 should have something like that.
> 
> Also, the module_put() will be needed for non-immediate patches which
> have a func->immediate set.

Right. This further complicates it.
 
> What do you think about the following?  I tried to put the logic in
> klp_complete_transition(), so the module_put()'s would be in one place.
> But it was too messy, so I put it in klp_cancel_transition() instead.
>
> diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
> index e96346e..bd1c1fd 100644
> --- a/kernel/livepatch/transition.c
> +++ b/kernel/l

Re: [PATCH 1/4] Documentation: w1_therm: clearly state about binary value for precision

[Mariusz Bialonczyk]

On Thu, 16 Feb 2017 10:05:36 +0100
Mariusz Bialonczyk  wrote:

> Signed-off-by: Mariusz Bialonczyk 
> ---
>  Documentation/w1/slaves/w1_therm | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/w1/slaves/w1_therm 
> b/Documentation/w1/slaves/w1_therm
> index d1f93af..e10cd91 100644
> --- a/Documentation/w1/slaves/w1_therm
> +++ b/Documentation/w1/slaves/w1_therm
> @@ -42,6 +42,7 @@ SRAM, so it is reset when the sensor gets power-cycled.
>  To store the current precision configuration into EEPROM, the value 0
>  has to be written to the sysfs w1_slave file. Since the EEPROM has a limited
>  amount of writes (>50k), this command should be used wisely.
> +Note: this precision value has to be a binary one-byte value, not ASCII.
>  
>  The module parameter strong_pullup can be set to 0 to disable the
>  strong pullup, 1 to enable autodetection or 2 to force strong pullup.
> -- 
> 2.9.3
> 

Please skip this single patch. I was wrong about it.
w1_slave_store is using kstrtoint() so it is currently ok.

regards,
-- 
Mariusz Białończyk | xmpp/e-mail: ma...@skyboo.net
http://manio.skyboo.net | https://github.com/manio

Re: [PATCH v5 00/15] livepatch: hybrid consistency model

[Miroslav Benes]

On Mon, 13 Feb 2017, Josh Poimboeuf wrote:

> Here's v5 of the consistency model, targeted for 4.12.  Only a few minor
> changes this time.
> 
> v5:
> - return -EINVAL in __save_stack_trace_reliable()
> - only call show_stack() once
> - add save_stack_trace_tsk_reliable() define for !CONFIG_STACKTRACE
> - update kernel version and date in ABI doc
> - make suggested improvements to livepatch.txt
> - update barrier comments
> - remove klp_try_complete_transition() call from klp_start_transition()
> - move end of klp_try_complete_transition() into klp_complete_transition()
> - fix __klp_enable_patch() error path
> - check for transition in klp_module_going()

All the changes since v4 look good to me (except for module_put() in 
__klp_enable_patch() mentioned elsewhere).

Thanks,
Miroslav

Re: [PATCH 20/21] ARM: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig

[Corentin Labbe]

On Thu, Feb 16, 2017 at 08:08:27PM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Thu, Feb 16, 2017 at 01:48:58PM +0100, Corentin Labbe wrote:
> > From: LABBE Corentin 
> > 
> > Enable the dwmac-sun8i driver in the sunxi default configuration
> > 
> > Signed-off-by: Corentin Labbe 
> > ---
> >  arch/arm/configs/sunxi_defconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/configs/sunxi_defconfig 
> > b/arch/arm/configs/sunxi_defconfig
> > index da92c25..33bde86 100644
> > --- a/arch/arm/configs/sunxi_defconfig
> > +++ b/arch/arm/configs/sunxi_defconfig
> > @@ -40,6 +40,7 @@ CONFIG_ATA=y
> >  CONFIG_AHCI_SUNXI=y
> >  CONFIG_NETDEVICES=y
> >  CONFIG_SUN4I_EMAC=y
> > +CONFIG_DWMAC_SUN8I=m
> 
> I think I'd prefer to have it compiled statically, just like the other
> net drivers, and drivers in general.
> 
> Thanks!
> Maxime
> 

In previous sun8i-emac, someone request that CONFIG must be set as module 
because kernel went too big.
But I do not care to set it statically.

Regards
Corentin Labbe

Re: [PATCH] platform/x86: ideapad-laptop: Add sysfs interface for touchpad state

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Darren,

On Thu, 2017-02-16 at 19:33 -0800, Darren Hart wrote:
> On Tue, Feb 14, 2017 at 07:46:12PM +0530, Ritesh Raj Sarraf wrote:
> > 
> > 
> That said, we need to make these systems usable, and as there appears not to
> be
> an accepted standard way of doing this, I don't object to the approach.
> However,
> you mentioned in the bug comments (#64) on 2/12:
> 
> "I have attached the final patch that I had proposed, but for whatever
> reasons, the maintainer isn't convinced that that interface is needed."
> 
> This is the only version of this patch I have seen. Who objected to the patch?
> 

Sorry. Nobody objected to it. I didn't hear back after last conversation with
Andy and wrongly presumed that adding that interface was a no go.


> I would like to hear from Rafael and Dmitry, for their opinion on an ACPI or
> INPUT
> interface for indicating TABLET_MODE to userspace. Even if we accept this
> patch
> as is, we should be thinking about how to do this in a standard way.
> 

Yes. That would be ideal. But as you mentioned, currently, not all drivers do
it. So my hope was to have this touchpad interface exposed, which could be used
by applications to derive tablet status.

Lenovo Yogas, when flipped to tablet mode orientation, disables the keyboard and
touchpad.


> > 
> > This patch adds a sysfs interface for read/write access under:
> > /sys/bus/platform/devices/VPC2004\:00/touchpad_mode
> > 

Can you please help here ?

Documentation/ABI/testing/sysfs-platform-ideapad-laptop mentions that the sysfs
path would be /sys/devices/platform/ideapad/ whereas what I actually see on my
machine is /sys/bus/platform/devices/VPC2004:00/

> > Signed-off-by: Ritesh Raj Sarraf 
> > ---
> >  .../ABI/testing/sysfs-platform-ideapad-laptop  |  9 ++
> >  drivers/platform/x86/ideapad-laptop.c  | 33
> > ++
> >  2 files changed, 42 insertions(+)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
> > b/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
> > index b31e782bd985..401e37e5acbd 100644
> > --- a/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
> > +++ b/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
> > @@ -17,3 +17,12 @@ Description:
> >     * 2 -> Dust Cleaning
> >     * 4 -> Efficient Thermal Dissipation Mode
> >  
> > +What:  /sys/devices/platform/ideapad/touchpad_mode
> > +Date:  Jan 2017
> > +KernelVersion: 4.11
> > +Contact:   "Ritesh Raj Sarraf "
> > +Description:
> > +   Control touchpad mode.
> > +* 1 -> Switched On
> > +* 0 -> Switched Off
> 
> Please use consistent whitespace for indentation, in this case, use tabs for
> the
> above two lines.
> 

Thanks. Done (and fixed my .vimrc too).

> > +
> > diff --git a/drivers/platform/x86/ideapad-laptop.c
> > b/drivers/platform/x86/ideapad-laptop.c
> > index f46ece2ce3c4..639af45b45b6 100644
> > --- a/drivers/platform/x86/ideapad-laptop.c
> > +++ b/drivers/platform/x86/ideapad-laptop.c
> > @@ -423,9 +423,42 @@ static ssize_t store_ideapad_fan(struct device *dev,
> >  
> >  static DEVICE_ATTR(fan_mode, 0644, show_ideapad_fan, store_ideapad_fan);
> >  
> > +
> > +static ssize_t show_touchpad_mode(struct device *dev,
> > +   struct device_attribute *attr,
> > +   char *buf)
> > +{
> > +   unsigned long result;
> > +   struct ideapad_private *priv = dev_get_drvdata(dev);
> 
> For consistency of coding style, please list longest variable declarations
> first, and proceed in decreasing line length. "Reverse Christmas Tree Order".
> 

Thank you. Done.

> > +
> > +   if (read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, &result))
> > +   return sprintf(buf, "-1\n");
> > +   return sprintf(buf, "%lu\n", result);
> > +}
> > +
> > +static ssize_t store_touchpad_mode(struct device *dev,
> > +    struct device_attribute *attr,
> > +    const char *buf, size_t count)
> > +{
> > +   int ret, state;
> > +   struct ideapad_private *priv = dev_get_drvdata(dev);
> 
> Reverse christmas tree order
> 
> > +
> > +   if (!count)
> > +   return 0;
> > +   if (sscanf(buf, "%i", &state) != 1)
> > +   return -EINVAL;
> 
> Please use kstrtoint, and no need to check for count as this function won't
> get
> called if it is 0.
> 

Done. Thank you.

> > +   ret = write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, state);
> > +   if (ret < 0)
> > +   return -EIO;
> > +   return count;
> > +}
> > +
> > +static DEVICE_ATTR(touchpad_mode, 0644, show_touchpad_mode,
> > store_touchpad_mode);
> 
> Please use:
> 
> static DEVICE_ATTR_RW(touchpad_mode);
> 
> You'll need to move the show_ and store_ prefixes to be postfixes, see
> toshiba-acpi.c for several examples.
> 

Thank you. I am building the kernel the test/

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Borislav Petkov]

On Fri, Feb 17, 2017 at 09:53:21AM +0800, Xunlei Pang wrote:
> It changes the value of cpu_online_mask/etc which will cause confusion to 
> vmcore analysis.

Then export the crashing_cpu variable, initialize it to something
invalid in the first kernel, -1 for example, and test it in the #MC
handlier like this:

int cpu;

...

cpu = smp_processor_id();

if (cpu_is_offline(cpu) ||
((crashing_cpu != -1) && (crashing_cpu != cpu)) {
u64 mcgstatus;

mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
if (mcgstatus & MCG_STATUS_RIPV) {
mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
return;
}
}

> Moreover, for the code(see comment inlined)
> 
> if (cpu_is_offline(smp_processor_id())) {
> u64 mcgstatus;
> 
> mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
> if (mcgstatus & MCG_STATUS_RIPV) { // This condition may be 
> not true, the mce triggered on kdump cpu 
>  // 
> doesn't need to have this bit set for the other cpus remain in 1st kernel. 

Is this on kvm or on a real hardware? Because for kvm I don't care. And
don't say "theoretically".

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v3] xen,input: try to read screen resolution for xen-kbdfront

[Juergen Gross]

On 30/01/17 16:10, Juergen Gross wrote:
> Instead of using the default resolution of 800*600 for the pointing
> device of xen-kbdfront try to read the resolution of the (virtual)
> framebuffer device. Use the default as fallback only.
> 
> Signed-off-by: Juergen Gross 

Dmitry, any comment from you?

In case you don't object I can carry this patch through the Xen tree.


Juergen

> ---
> V3: add case of late framebuffer registration (Oleksandr Andrushchenko)
> V2: get framebuffer resolution only if CONFIG_FB (Dmitry Torokhov)
> ---
>  drivers/input/misc/xen-kbdfront.c | 46 
> ---
>  1 file changed, 43 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c 
> b/drivers/input/misc/xen-kbdfront.c
> index 3900875..9a20800 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -39,6 +40,9 @@ struct xenkbd_info {
>   int irq;
>   struct xenbus_device *xbdev;
>   char phys[32];
> +#ifdef CONFIG_FB_NOTIFY
> + struct notifier_block nb;
> +#endif
>  };
>  
>  static int xenkbd_remove(struct xenbus_device *);
> @@ -105,10 +109,29 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>   return IRQ_HANDLED;
>  }
>  
> +#ifdef CONFIG_FB
> +#ifdef CONFIG_FB_NOTIFY
> +static int xenkbd_fb_event(struct notifier_block *self,
> +unsigned long action, void *data)
> +{
> + struct xenkbd_info *info = container_of(self, struct xenkbd_info, nb);
> + struct fb_info *fb = registered_fb[0];
> +
> + if (action != FB_EVENT_FB_REGISTERED || !fb)
> + return 0;
> +
> + input_set_abs_params(info->ptr, ABS_X, 0, fb->var.xres_virtual, 0, 0);
> + input_set_abs_params(info->ptr, ABS_Y, 0, fb->var.yres_virtual, 0, 0);
> +
> + return 0;
> +}
> +#endif
> +#endif
> +
>  static int xenkbd_probe(struct xenbus_device *dev,
> const struct xenbus_device_id *id)
>  {
> - int ret, i;
> + int ret, i, width, height;
>   unsigned int abs;
>   struct xenkbd_info *info;
>   struct input_dev *kbd, *ptr;
> @@ -173,9 +196,22 @@ static int xenkbd_probe(struct xenbus_device *dev,
>   ptr->id.product = 0xfffe;
>  
>   if (abs) {
> + width = XENFB_WIDTH;
> + height = XENFB_HEIGHT;
> +#ifdef CONFIG_FB
> + if (registered_fb[0]) {
> + width = registered_fb[0]->var.xres_virtual;
> + height = registered_fb[0]->var.yres_virtual;
> + } else {
> +#ifdef CONFIG_FB_NOTIFY
> + info->nb.notifier_call = xenkbd_fb_event;
> + fb_register_client(&info->nb);
> +#endif
> + }
> +#endif
>   __set_bit(EV_ABS, ptr->evbit);
> - input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
> - input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
> + input_set_abs_params(ptr, ABS_X, 0, width, 0, 0);
> + input_set_abs_params(ptr, ABS_Y, 0, height, 0, 0);
>   } else {
>   input_set_capability(ptr, EV_REL, REL_X);
>   input_set_capability(ptr, EV_REL, REL_Y);
> @@ -222,6 +258,10 @@ static int xenkbd_remove(struct xenbus_device *dev)
>   struct xenkbd_info *info = dev_get_drvdata(&dev->dev);
>  
>   xenkbd_disconnect_backend(info);
> +#ifdef CONFIG_FB_NOTIFY
> + if (info->nb.notifier_call)
> + fb_unregister_client(&info->nb);
> +#endif
>   if (info->kbd)
>   input_unregister_device(info->kbd);
>   if (info->ptr)
> 

[PATCH 1/1] gpio: altera: Use handle_level_irq when configured as a level_high

[Phil Reid]

When a threaded irq handler is chained attached to one of the gpio
pins when configure for level irq the altera_gpio_irq_leveL_high_handler
does not mask the interrupt while being handled by the chained irq.
This resulting in the threaded irq not getting enough cycles to complete
quickly enough before the irq was disabled as faulty.
It looks like handle_level_irq should be used in this situation
instead of handle_simple_irq.

Signed-off-by: Phil Reid 
---
 drivers/gpio/gpio-altera.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c
index 5bddbd5..d67dcca 100644
--- a/drivers/gpio/gpio-altera.c
+++ b/drivers/gpio/gpio-altera.c
@@ -310,7 +310,8 @@ static int altera_gpio_probe(struct platform_device *pdev)
altera_gc->interrupt_trigger = reg;
 
ret = gpiochip_irqchip_add(&altera_gc->mmchip.gc, &altera_irq_chip, 0,
-   handle_simple_irq, IRQ_TYPE_NONE);
+   altera_gc->interrupt_trigger == IRQ_TYPE_LEVEL_HIGH ?
+   handle_level_irq : handle_simple_irq, IRQ_TYPE_NONE);
 
if (ret) {
dev_err(&pdev->dev, "could not add irqchip\n");
-- 
1.8.3.1

Re: [PATCH 08/21] ARM: dts: sun8i-h3: add dwmac-sun8i rgmii pins

[Corentin Labbe]

On Thu, Feb 16, 2017 at 08:06:32PM +0100, Maxime Ripard wrote:
> On Thu, Feb 16, 2017 at 01:48:46PM +0100, Corentin Labbe wrote:
> > This patch add pinctrl node for dwmac-sun8i on H3.
> > 
> > Signed-off-by: Corentin Labbe 
> > ---
> >  arch/arm/boot/dts/sun8i-h3.dtsi | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> > b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 61d56d2..59ed40e 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -349,6 +349,17 @@
> > function = "i2c2";
> > };
> >  
> > +   emac_rgmii_pins: emac0@0 {
> > +   allwinner,pins = "PD0", "PD1", "PD2", "PD3",
> > +   "PD4", "PD5", "PD7",
> > +   "PD8", "PD9", "PD10",
> > +   "PD12", "PD13", "PD15",
> > +   "PD16", "PD17";
> > +   allwinner,function = "emac";
> 
> Please use the generic pin config properties (ie. pins and functions).
> 
> > +   allwinner,drive = ;
> 
> Why do you need to use 40mA?
> 
> > +   allwinner,pull = ;
> 
> This is the default now.
> 

Will fix that in all DT

Thanks
Corentin Labbe

[PATCH] Staging: BCM2835-Audio: bcm2835-pcm: single line block statement braces fix

[Daniel Perez de Andres]

A single line statement under an if clause doesn't require braces {}

Signed-off-by: Daniel Perez de Andres 
---
 drivers/staging/bcm2835-audio/bcm2835-pcm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835-pcm.c 
b/drivers/staging/bcm2835-audio/bcm2835-pcm.c
index 014bf7a..a2a8694 100644
--- a/drivers/staging/bcm2835-audio/bcm2835-pcm.c
+++ b/drivers/staging/bcm2835-audio/bcm2835-pcm.c
@@ -317,9 +317,9 @@ static int snd_bcm2835_pcm_prepare(struct snd_pcm_substream 
*substream)
err = bcm2835_audio_set_params(alsa_stream, channels,
alsa_stream->params_rate,
alsa_stream->pcm_format_width);
-   if (err < 0) {
+   if (err < 0)
audio_error(" error setting hw params\n");
-   }
+
 
bcm2835_audio_setup(alsa_stream);
 
-- 
2.7.4

Re: [PATCH] platform/x86: ideapad-laptop: Add sysfs interface for touchpad state

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Dmitry,

On Fri, 2017-02-17 at 00:48 -0800, Dmitry Torokhov wrote:
> It looks like the patch is trying to provide a way to disable the
> touchpad when transitioning in tablet mode. 

The keyboard/touchpad get disabled, by hardware, when flipped to tablet mode.
Since currently, the driver has no way to expose a tablet-mode interface, we
relied on this behavior, for the Lenovo Yoga device types.

> In ChromeOS we have a notion
> of "inhibiting" input devices, where userspace policy daemon tells the
> kernel that it is not interested in events from a given device and input
> core will suppress events from such device (and driver may optionally
> put device into low power mode, if it chooses to do so). But in this
> case the control seems to be totally outside of the input driver (which
> I suspect is PS/2 device), so the policy daemon would have to have
> specific knowledge of this new knob.
> 
> BTW, I am not sure if this is actually reliable: if system goes to S3
> with lid open and user changes it into tablet form, nobody will tell the
> EC that touchpad should be ignored and it will wake up the tablet.

I am not sure what you mean here. But:

root@learner:/sys/bus/platform/devices/VPC2004:00# When in normal mode^C
root@learner:/sys/bus/platform/devices/VPC2004:00# cat touchpad_mode 
1

S3 Suspend here. THen flip hw to tablet mode. Now, hit power btn to Resume.

root@learner:/sys/bus/platform/devices/VPC2004:00# Now in tablet mode^C
root@learner:/sys/bus/platform/devices/VPC2004:00# cat touchpad_mode 
0

- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlimwAQACgkQpjpYo/Lh
dWkzIw/+NMiQ4A/OplUP/g6mTfba5zyuN0g9Or6RwzXyPrFsWbPAN4E6pcNIM1OT
oy8RAnrqdSQymVH5atbR/ysPwlzG19+LWB4FVlVdkDMKkVonAHmUX+mL9+KFa7E5
+RmpS9Hzc6cLv1kpKMUeLD7j9U3I4NkUEsxDZwLk916KE6fCthGsmbn1gGADv3oT
/lErDW7MLaImR67cmHmRhfhIotQPokcn3OVT/Eb7K8UjvXQLlWnDxMdxlQ7xDTua
aJ3c/lB+FQytwp/JBSbNpzspNcCX5mmkh6PERXhxLJzL1CpCz3qnwKwKyeoGFcjv
goj+CTZNsnGqaBuZThNI2vVWJRHqGCX2qp3IyWrSzNa6j5SfMTlgr0a/WsI7rpiY
4+81OXoeCVcr+ZGO4wtsvR1WDWvXqb+0bWYByNu85L/Rj9KWzxfh1mbtahG6odi8
bp7/+1cy55+d4XnX2/QHgkXdSCelBPtwH+aJUBp5av1N6t88+Dat8p3EyK30Cyp/
XfdglsfKWvmJX+hLBgR75ejy3cvr5iBIuExuULZNd8qrj+4dYDt4cYQB/MnttLt4
HZ1c/qSjMTDPdMBb4s3C844Pgk6QsKHJwLEl2zTN8HqNTMdwHBktyFPEzsRqV6Wn
Kea6z4lFUwS17LCaq/bhCwvYcFJm2XSimtXWj1a50YdwEgAiT5o=
=nuhe
-END PGP SIGNATURE-

Re: [PATCH 1/1] gpio: altera: Use handle_level_irq when configured as a level_high

[Andy Shevchenko]

On Fri, Feb 17, 2017 at 11:12 AM, Phil Reid  wrote:
> When a threaded irq handler is chained attached to one of the gpio
> pins when configure for level irq the altera_gpio_irq_leveL_high_handler
> does not mask the interrupt while being handled by the chained irq.
> This resulting in the threaded irq not getting enough cycles to complete
> quickly enough before the irq was disabled as faulty.
> It looks like handle_level_irq should be used in this situation
> instead of handle_simple_irq.

> @@ -310,7 +310,8 @@ static int altera_gpio_probe(struct platform_device *pdev)
> altera_gc->interrupt_trigger = reg;
>
> ret = gpiochip_irqchip_add(&altera_gc->mmchip.gc, &altera_irq_chip, 0,
> -   handle_simple_irq, IRQ_TYPE_NONE);
> +   altera_gc->interrupt_trigger == IRQ_TYPE_LEVEL_HIGH ?
> +   handle_level_irq : handle_simple_irq, IRQ_TYPE_NONE);

AFAIK, handle_bad_irq() should be used here.

-- 
With Best Regards,
Andy Shevchenko

[PATCH] platform/x86: intel_pmc_ipc: Use XTAL freq based on cpuid

[Rajneesh Bhardwaj]

This patch uses crystal frequency based on the cpu model.

On Apollo Lake SoC we have 19.2 MHz clock frequency for counting S0ix
residency but this clock frequency might change on future platforms
depending on the crystal oscillator.

Signed-off-by: Shanth Murthy 
Signed-off-by: Rajneesh Bhardwaj 
---
Note:
This patch depends on the following:
 * platform/x86: intel_pmc_ipc: read s0ix residency API
 * platform/x86: intel_pmc_ipc: Add APL PMC PCI Id

 drivers/platform/x86/intel_pmc_ipc.c | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_ipc.c 
b/drivers/platform/x86/intel_pmc_ipc.c
index 6b6bdf1..557f017 100644
--- a/drivers/platform/x86/intel_pmc_ipc.c
+++ b/drivers/platform/x86/intel_pmc_ipc.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -61,11 +62,11 @@
 #define GCR_TELEM_DEEP_S0IX_OFFSET 0x1078
 #define GCR_TELEM_SHLW_S0IX_OFFSET 0x1080
 
-/* Residency with clock rate at 19.2MHz to usecs */
-#define S0IX_RESIDENCY_IN_USECS(d, s)  \
+/* Convert S0ix residency to usecs based on XTAL frequency */
+#define S0IX_RESIDENCY_IN_USECS(d, s, x)   \
 ({ \
-   u64 result = 10ull * ((d) + (s));   \
-   do_div(result, 192);\
+   u64 result = 1000ull * ((d) + (s)); \
+   do_div(result, x);  \
result; \
 })
 
@@ -131,6 +132,7 @@
resource_size_t gcr_base;
int gcr_size;
bool has_gcr_regs;
+   u32 xtal_khz;
 
/* punit */
struct platform_device *punit_dev;
@@ -201,6 +203,18 @@ static inline u64 gcr_data_readq(u32 offset)
return readq(ipcdev.ipc_base + offset);
 }
 
+static int get_xtal_clock_freq(void)
+{
+   switch (boot_cpu_data.x86_model) {
+   case INTEL_FAM6_ATOM_GOLDMONT:
+   ipcdev.xtal_khz = 19200;
+   break;
+   default:
+   return -EINVAL;
+   }
+   return 0;
+}
+
 static int intel_pmc_ipc_check_status(void)
 {
int status;
@@ -787,7 +801,7 @@ int intel_pmc_s0ix_counter_read(u64 *data)
deep = gcr_data_readq(GCR_TELEM_DEEP_S0IX_OFFSET);
shlw = gcr_data_readq(GCR_TELEM_SHLW_S0IX_OFFSET);
 
-   *data = S0IX_RESIDENCY_IN_USECS(deep, shlw);
+   *data = S0IX_RESIDENCY_IN_USECS(deep, shlw, ipcdev.xtal_khz);
 
return 0;
 }
@@ -835,6 +849,12 @@ static int ipc_plat_probe(struct platform_device *pdev)
goto err_irq;
}
 
+   ret = get_xtal_clock_freq();
+   if (ret) {
+   dev_err(&pdev->dev, "Failed to get XTAL freq\n");
+   goto err_sys;
+   }
+
ret = sysfs_create_group(&pdev->dev.kobj, &intel_ipc_group);
if (ret) {
dev_err(&pdev->dev, "Failed to create sysfs group %d\n",
-- 
1.9.1

[PATCH] target/user: Add daynmic growing data area feature support

[lixiubo]

From: Xiubo Li 

Currently for the TCMU, the ring buffer size is fixed to 64K cmd
area + 1M data area, and this will be bottlenecks for high iops.

The struct tcmu_cmd_entry {} size is fixed about 44 bytes without
iovec[N], and the size of struct iovec[N] is about (16 * N) bytes.

The sizeof(cmd entry) will be [44B, N *16 + 44B], and corresponding
iovec[N] size will be [0, N * 4096], so the ratio of
sizeof(cmd entry) : sizeof(entry datas) ==
(N * 16 + 44)Bytes : (N * 4096)Bytes == (N * 16)/(N * 4096) +
44/(N*4096) == 4/1024 + 11/(N * 1024).

When N is bigger, the ratio will be smaller. If N >= 1, the ratio
will be [15/1024, 4/1024), for this the ratio 15 : 1024 will be
enough. But maybe some iscsi cmds has no datas, N == 0. So the ratio
should be bigger.

For now we will increase the data area size to 1G, and the cmd area
size to 128M. The tcmu-runner should mmap() about (128M + 1G) when
running and the TCMU will dynamically grows the data area from 0 to
max 1G size.

The cmd area memory will be allocated through vmalloc(), and the data
area's blocks will be allocated individually later when needed.

The allocated data area block memory will be managed via radix tree.
For now the bitmap still be the most efficient way to search and
manage the block index, this could be update later.

Signed-off-by: Xiubo Li 
Signed-off-by: Jianfei Hu 
---
 drivers/target/target_core_user.c | 241 ++
 1 file changed, 167 insertions(+), 74 deletions(-)

diff --git a/drivers/target/target_core_user.c 
b/drivers/target/target_core_user.c
index 2e33100..f2e3769 100644
--- a/drivers/target/target_core_user.c
+++ b/drivers/target/target_core_user.c
@@ -2,6 +2,7 @@
  * Copyright (C) 2013 Shaohua Li 
  * Copyright (C) 2014 Red Hat, Inc.
  * Copyright (C) 2015 Arrikto, Inc.
+ * Copyright (C) 2017 Chinamobile, Inc.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -65,12 +67,15 @@
 
 #define TCMU_TIME_OUT (30 * MSEC_PER_SEC)
 
-#define DATA_BLOCK_BITS 256
-#define DATA_BLOCK_SIZE 4096
+/* For cmd area, the size is fixed 64M */
+#define CMDR_SIZE (64 * 1024 * 1024)
 
-#define CMDR_SIZE (16 * 4096)
+/* For data area, the size is fixed 1G */
+#define DATA_BLOCK_BITS (256 * 1024)
+#define DATA_BLOCK_SIZE 4096
 #define DATA_SIZE (DATA_BLOCK_BITS * DATA_BLOCK_SIZE)
 
+/* The ring buffer size is 64M + 1G */
 #define TCMU_RING_SIZE (CMDR_SIZE + DATA_SIZE)
 
 static struct device *tcmu_root_device;
@@ -103,6 +108,7 @@ struct tcmu_dev {
size_t data_size;
 
DECLARE_BITMAP(data_bitmap, DATA_BLOCK_BITS);
+   struct radix_tree_root data_blocks;
 
wait_queue_head_t wait_cmdr;
/* TODO should this be a mutex? */
@@ -120,15 +126,22 @@ struct tcmu_dev {
 
 #define CMDR_OFF sizeof(struct tcmu_mailbox)
 
+struct tcmu_data_block_index {
+   struct list_head list;
+   uint32_t index;
+};
+
 struct tcmu_cmd {
struct se_cmd *se_cmd;
struct tcmu_dev *tcmu_dev;
 
-   uint16_t cmd_id;
+   uint32_t cmd_id;
 
/* Can't use se_cmd when cleaning up expired cmds, because if
   cmd has been completed then accessing se_cmd is off limits */
-   DECLARE_BITMAP(data_bitmap, DATA_BLOCK_BITS);
+   uint32_t dbi_cnt;
+   uint32_t dbi_cur;
+   uint32_t *dbi;
 
unsigned long deadline;
 
@@ -159,10 +172,77 @@ enum tcmu_multicast_groups {
.netnsok = true,
 };
 
+static int tcmu_db_get_empty_block(struct tcmu_dev *udev, void **addr)
+{
+   void *p;
+   uint32_t block;
+   int ret;
+
+   block = find_first_zero_bit(udev->data_bitmap, DATA_BLOCK_BITS);
+   set_bit(block, udev->data_bitmap);
+
+   p = radix_tree_lookup(&udev->data_blocks, block);
+   if (!p) {
+   p = kzalloc(DATA_BLOCK_SIZE, GFP_ATOMIC);
+   if (!p) {
+   clear_bit(block, udev->data_bitmap);
+   return -ENOMEM;
+   }
+
+   ret = radix_tree_insert(&udev->data_blocks, block, p);
+   if (ret) {
+   kfree(p);
+   clear_bit(block, udev->data_bitmap);
+   return ret;
+   }
+   }
+
+   *addr = p;
+   return block;
+}
+
+static void *tcmu_db_get_block_addr(struct tcmu_dev *udev, uint32_t block)
+{
+   return radix_tree_lookup(&udev->data_blocks, block);
+}
+
+#definetcmu_cmd_reset_dbi_cur(cmd) ((cmd)->dbi_cur = 0)
+#define tcmu_cmd_set_dbi(cmd, index) ((cmd)->dbi[(cmd)->dbi_cur++] = (index))
+#define tcmu_cmd_get_dbi(cmd) ((cmd)->dbi[(cmd)->dbi_cur++])
+
+static void tcmu_cmd_free_data(struct tcmu_cmd *tcmu_cmd)
+{
+   struct tcmu_dev *udev = tcmu_cmd->tcmu_dev;
+   uint32_t bi;
+
+   for (bi = 0; bi < tcmu_cmd->dbi_cnt; bi++)
+   clear_b

[PATCH v3] watchdog: add driver for StreamLabs USB watchdog device

[Alexey Klimov]

This patch creates new driver that supports StreamLabs usb watchdog
device. This device plugs into 9-pin usb header and connects to
reset pin and reset button on common PC.

USB commands used to communicate with device were reverse
engineered using usbmon.

Signed-off-by: Alexey Klimov 
---

Changes in v3:
 -- coding style cleanups and rebase;
 -- buffer is allocated with separate allocation;
 -- adding comments about max/min limits;
 -- rework start/stop commands implementation;
 -- fix first if-check in probe() function;

Previous version: https://www.spinics.net/lists/linux-watchdog/msg09092.html

 drivers/watchdog/Kconfig  |  16 ++
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/streamlabs_wdt.c | 321 ++
 3 files changed, 338 insertions(+)
 create mode 100644 drivers/watchdog/streamlabs_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index acb00b53a520..6a2195d8cc5c 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1852,6 +1852,22 @@ config USBPCWATCHDOG
 
  Most people will say N.
 
+config USB_STREAMLABS_WATCHDOG
+   tristate "StreamLabs USB watchdog driver"
+   depends on USB
+   ---help---
+ This is the driver for the USB Watchdog dongle from StreamLabs.
+ If you correctly connect reset pins to motherboard Reset pin and
+ to Reset button then this device will simply watch your kernel to make
+ sure it doesn't freeze, and if it does, it reboots your computer
+ after a certain amount of time.
+
+
+ To compile this driver as a module, choose M here: the
+ module will be called streamlabs_wdt.
+
+ Most people will say N. Say yes or M if you want to use such usb 
device.
+
 comment "Watchdog Pretimeout Governors"
 
 config WATCHDOG_PRETIMEOUT_GOV
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0c3d35e3c334..d4a61222ccd2 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_WDTPCI) += wdt_pci.o
 
 # USB-based Watchdog Cards
 obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
+obj-$(CONFIG_USB_STREAMLABS_WATCHDOG) += streamlabs_wdt.o
 
 # ALPHA Architecture
 
diff --git a/drivers/watchdog/streamlabs_wdt.c 
b/drivers/watchdog/streamlabs_wdt.c
new file mode 100644
index ..4442d053d9f7
--- /dev/null
+++ b/drivers/watchdog/streamlabs_wdt.c
@@ -0,0 +1,321 @@
+/*
+ * StreamLabs USB Watchdog driver
+ *
+ * Copyright (c) 2016-2017 Alexey Klimov 
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * USB Watchdog device from Streamlabs:
+ * https://www.stream-labs.com/en/catalog/?cat_id=1203&item_id=323
+ *
+ * USB commands have been reverse engineered using usbmon.
+ */
+
+#define DRIVER_AUTHOR "Alexey Klimov "
+#define DRIVER_DESC "StreamLabs USB watchdog driver"
+#define DRIVER_NAME "usb_streamlabs_wdt"
+
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
+
+#define USB_STREAMLABS_WATCHDOG_VENDOR 0x13c0
+#define USB_STREAMLABS_WATCHDOG_PRODUCT0x0011
+
+/*
+ * one buffer is used for communication, however transmitted message is only
+ * 32 bytes long
+ */
+#define BUFFER_TRANSFER_LENGTH 32
+#define BUFFER_LENGTH  64
+#define USB_TIMEOUT350
+
+#define STREAMLABS_CMD_START   0xaacc
+#define STREAMLABS_CMD_STOP0xbbff
+
+/* timeouts values are taken from windows program */
+#define STREAMLABS_WDT_MIN_TIMEOUT 1
+#define STREAMLABS_WDT_MAX_TIMEOUT 46
+
+struct streamlabs_wdt {
+   struct watchdog_device wdt_dev;
+   struct usb_interface *intf;
+
+   struct mutex lock;
+   u8 *buffer;
+};
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+/*
+ * This function is used to check if watchdog actually changed
+ * its state to disabled that is reported in first two bytes of response
+ * message.
+ */
+static int usb_streamlabs_wdt_check_stop(u16 *buf)
+{
+   if (buf[0] != cpu_to_le16(STREAMLABS_CMD_STOP))
+   return -EINVAL;
+
+   return 0;
+}
+
+static int usb_streamlabs_wdt_validate_response(u8 *buf)
+{
+   /*
+* If watchdog device understood the command it will acknowledge
+* with values 1,2,3,4 at indexes 10, 11, 12, 13 in response message
+* when response treated as 8bit message.
+*/
+   if (buf[10] != 1 || buf[11] != 2 || buf[12] != 3 || buf[13] !=

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

[Jan Kiszka]

On 2017-02-17 09:23, Kweh, Hock Leong wrote:
>> -Original Message-
>> From: Bryan O'Donoghue [mailto:pure.lo...@nexus-software.ie]
>> Sent: Friday, February 17, 2017 8:54 AM
>> To: Kweh, Hock Leong ; Jan Kiszka
>> ; Andy Shevchenko 
>> Cc: Matt Fleming ; Ard Biesheuvel
>> ; linux-...@vger.kernel.org; Linux Kernel Mailing
>> List ; Borislav Petkov 
>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
>> images
>>
>>
>>
>> On 16/02/17 03:00, Kweh, Hock Leong wrote:
 -Original Message-
 From: Jan Kiszka [mailto:jan.kis...@siemens.com]
 Sent: Thursday, February 16, 2017 3:00 AM
 To: Andy Shevchenko 
 Cc: Matt Fleming ; Ard Biesheuvel
 ; linux-...@vger.kernel.org; Linux Kernel
 Mailing List ; Borislav Petkov
 ; Kweh, Hock Leong ; Bryan
 O'Donoghue 
 Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support
 signed Quark images

 On 2017-02-15 19:50, Jan Kiszka wrote:
> On 2017-02-15 19:46, Andy Shevchenko wrote:
>> On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka
>> 
 wrote:
>>> See patch 2 for the background.
>>>
>>> Series has been tested on the Galileo Gen2, to exclude
>>> regressions, with a firmware.cap without security header and the
>>> SIMATIC IOT2040 which requires the header because of its mandatory
>> secure boot.
>>
>> Briefly looking to the code it looks like a real hack.
>> Sorry, but it would be carefully (re-)designed.
>
> The interface that the firmware provides us? That should have been
> done differently, I agree, but I'm not too much into those firmware
> details, specifically when it comes to signatures.
>
> The Linux code was designed around that suboptimal situation. If
> there are better ideas, I'm all ears.
>

 Expanding CC's as requested by Andy.

 Jan

>>>
>>> Hi Jan,
>>>
>>> While I upstreaming the capsule loader patches, I did work with
>>> maintainer Matt and look into this security header created for Quark.
>>> Eventually both of us agreed that this will not be upstream to
>>> mainline as it is really a Quark specific implementation.
>>
>> What's the logic of that ?
>>
>> It should be possible to provide a hook (or a custom function).
>>
>>>
>>> The proper implementation may require to work with UEFI community to
>>> expand its capsule spec to support signed binary.
>>
>> Are you volunteering to do that with - getting the CSH into the UEFI spec ?
>>
>> If not then we should have a method to load/ignore a capsule including the 
>> CSH,
>> if so then we should have a realistic timeline laid out for getting that 
>> spec work
>> done.
>>
>> Hint: I don't believe integrating the CSH into the UEFI standard will 
>> happen...
>>
> 
> Hi Jan & Bryan,
> 
> Please don't get me wrong. I am not rejecting the patch submission.
> I am just sharing a summary for the discussion that I had had it a year back
> with maintainer Matt for this topic. From the discussion, we did mention
> what would be the proper handling to this case. And to have UEFI expand

Do you happen to have a reference to the part of the discussions that
deal with the CSH topic?

> it capsule support and take in signed binary would be a more secured way.
> So, influencing UEFI community to have such support would be the right
> move throughout the discussion. That is my summary.
> 
> Of course, influencing the UEFI community would be the longer path.
> I think it is worth for try to bring the topic up here again to see if Matt
> would reconsider it. 

I just can re-express my frustration that this essential step hasn't
been started years ago by whoever designed the extension. Then I bet
there would have been constructive feedback on the interface BEFORE its
ugliness spread to broader use.

Or is there a technical need, in general or on Quark, to have the
signature header right before the standard capsule *for the handover* to
the firmware? I mean, I would naively put it into another capsule and
prepend that to the core so that the existing UEFI API can palate it
transparently and cleanly.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH V3 3/7] mm: reclaim MADV_FREE pages

[Minchan Kim]

On Fri, Feb 17, 2017 at 02:41:08PM +0900, Minchan Kim wrote:
> Hi Johannes,
> 
> On Thu, Feb 16, 2017 at 01:40:18PM -0500, Johannes Weiner wrote:
> > On Tue, Feb 14, 2017 at 11:36:09AM -0800, Shaohua Li wrote:
> > > @@ -1419,11 +1419,18 @@ static int try_to_unmap_one(struct page *page, 
> > > struct vm_area_struct *vma,
> > >   VM_BUG_ON_PAGE(!PageSwapCache(page) && 
> > > PageSwapBacked(page),
> > >   page);
> > >  
> > > - if (!PageDirty(page) && (flags & TTU_LZFREE)) {
> > > - /* It's a freeable page by MADV_FREE */
> > > - dec_mm_counter(mm, MM_ANONPAGES);
> > > - rp->lazyfreed++;
> > > - goto discard;
> > > + if (flags & TTU_LZFREE) {
> > > + if (!PageDirty(page)) {
> > > + /* It's a freeable page by MADV_FREE */
> > > + dec_mm_counter(mm, MM_ANONPAGES);
> > > + rp->lazyfreed++;
> > > + goto discard;
> > > + } else {
> > > + set_pte_at(mm, address, pvmw.pte, 
> > > pteval);
> > > + ret = SWAP_FAIL;
> > > + page_vma_mapped_walk_done(&pvmw);
> > > + break;
> > > + }
> > 
> > I don't understand why we need the TTU_LZFREE bit in general. More on
> > that below at the callsite.
> 
> The reason I introduced it was ttu is used for migration/THP split path
> as well as reclaim. It's clear to discard them in reclaim path because
> it means surely memory pressure now but not sure with other path.
> 
> If you guys think it's always win to discard them in try_to_unmap
> unconditionally, I think it would be better to be separate patch.

I was totally wrong.

Anon page with THP split/migration/HWPoison will not reach to discard path
in try_to_unmap_one so Johannes is right. We don't need TTU_LZFREE.

Sorry for the noise.

Thanks.

Re: [PATCH 1/5] KVM: change API for requests to match bit operations

[Cornelia Huck]

On Thu, 16 Feb 2017 17:04:45 +0100
Radim Krčmář  wrote:

> kvm_make_request was a wrapper that added barriers to bit_set and
> kvm_check_request did the same for bit_test and bit_check, but the name
> was not very obvious and we were also lacking operations that cover
> bit_test and bit_clear, which resulted in an inconsistent use.
> 
> The renaming:
>   kvm_request_set<- kvm_make_request
>   kvm_request_test_and_clear <- kvm_check_request
> 
> Automated with coccinelle script:
>   @@
>   expression VCPU, REQ;
>   @@
>   -kvm_make_request(REQ, VCPU)
>   +kvm_request_set(REQ, VCPU)
> 
>   @@
>   expression VCPU, REQ;
>   @@
>   -kvm_check_request(REQ, VCPU)
>   +kvm_request_test_and_clear(REQ, VCPU)

Forgot your s-o-b?

> ---
>  arch/mips/kvm/emulate.c  |   2 +-
>  arch/mips/kvm/trap_emul.c|   2 +-
>  arch/powerpc/kvm/book3s_pr.c |   2 +-
>  arch/powerpc/kvm/booke.c |  16 +++---
>  arch/powerpc/kvm/powerpc.c   |   2 +-
>  arch/s390/kvm/kvm-s390.c |  22 
>  arch/s390/kvm/kvm-s390.h |   4 +-
>  arch/s390/kvm/priv.c |   4 +-
>  arch/x86/kvm/hyperv.c|  14 ++---
>  arch/x86/kvm/i8259.c |   2 +-
>  arch/x86/kvm/lapic.c |  22 
>  arch/x86/kvm/mmu.c   |  14 ++---
>  arch/x86/kvm/pmu.c   |   6 +-
>  arch/x86/kvm/svm.c   |  12 ++--
>  arch/x86/kvm/vmx.c   |  30 +-
>  arch/x86/kvm/x86.c   | 128 
> +--
>  include/linux/kvm_host.h |  30 --
>  virt/kvm/kvm_main.c  |   4 +-
>  18 files changed, 167 insertions(+), 149 deletions(-)

(...lots of coccinelle changes...)

> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 8d69d5150748..21f91de3098b 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1084,24 +1084,42 @@ static inline int kvm_ioeventfd(struct kvm *kvm, 
> struct kvm_ioeventfd *args)
>  
>  #endif /* CONFIG_HAVE_KVM_EVENTFD */
>  
> -static inline void kvm_make_request(int req, struct kvm_vcpu *vcpu)
> +/*
> + * An API for setting KVM requests.
> + * The general API design is inspired by bit_* API.
> + *
> + * A request can be set either to itself or to a remote VCPU.  If the request
> + * is set to a remote VCPU, then the VCPU needs to be notified, which is
> + * usually done with kvm_vcpu_kick().
> + * The request can also mean that some data is ready, so a remote requests
> + * needs a smp_wmb().  i.e. there are three types of requests:
> + *  1) local request
> + *  2) remote request with no data (= kick)
> + *  3) remote request with data (= kick + mb)
> + *
> + * TODO: the API is inconsistent -- a request doesn't call kvm_vcpu_kick(), 
> but
> + * forces smp_wmb() for all requests.
> + */
> +static inline void kvm_request_set(unsigned req, struct kvm_vcpu *vcpu)

Should we make req unsigned long as well, so that it matches the bit
api even more?

>  {
>   /*
> -  * Ensure the rest of the request is published to kvm_check_request's
> -  * caller.  Paired with the smp_mb__after_atomic in kvm_check_request.
> +  * Ensure the rest of the request is published to
> +  * kvm_request_test_and_clear's caller.
> +  * Paired with the smp_mb__after_atomic in kvm_request_test_and_clear.
>*/
>   smp_wmb();
>   set_bit(req, &vcpu->requests);
>  }
>  
> -static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu)
> +static inline bool kvm_request_test_and_clear(unsigned req, struct kvm_vcpu 
> *vcpu)
>  {
>   if (test_bit(req, &vcpu->requests)) {
>   clear_bit(req, &vcpu->requests);
>  
>   /*
> -  * Ensure the rest of the request is visible to 
> kvm_check_request's
> -  * caller.  Paired with the smp_wmb in kvm_make_request.
> +  * Ensure the rest of the request is visible to
> +  * kvm_request_test_and_clear's caller.
> +  * Paired with the smp_wmb in kvm_request_set.
>*/
>   smp_mb__after_atomic();
>   return true;

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

[Pan Xinhui]

在 2017/2/17 14:05, Michael Ellerman 写道:

Pan Xinhui  writes:

diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 9c0e17c..f6e5c3d 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -76,6 +76,7 @@ static int xmon_gate;
  #endif /* CONFIG_SMP */

  static unsigned long in_xmon __read_mostly = 0;
+static int xmon_off = !IS_ENABLED(CONFIG_XMON_DEFAULT);


I think the logic would probably clearer if we invert this to become
xmon_on.


yep, make sense.


@@ -3266,16 +3269,16 @@ static int __init setup_xmon_sysrq(void)
  __initcall(setup_xmon_sysrq);
  #endif /* CONFIG_MAGIC_SYSRQ */

-static int __initdata xmon_early, xmon_off;
+static int __initdata xmon_early;

  static int __init early_parse_xmon(char *p)
  {
if (!p || strncmp(p, "early", 5) == 0) {
/* just "xmon" is equivalent to "xmon=early" */
-   xmon_init(1);
xmon_early = 1;
+   xmon_off = 0;
} else if (strncmp(p, "on", 2) == 0)
-   xmon_init(1);
+   xmon_off = 0;


You've just changed the timing of when xmon gets enabled for the above
two cases, from here which is called very early, to xmon_setup() which
is called much later in boot.

That effectively disables xmon for most of the boot, which we do not
want to do.


Although it is not often that kernel got stucked during boot. Yes, the behavior 
changed anyway. Will fix that in v3.


cheers

Re: [PATCH V3 0/4] Define coherent device memory node

[Mel Gorman]

On Fri, Feb 17, 2017 at 09:14:44AM +1100, Balbir Singh wrote:
> 
> 
> On 16/02/17 05:20, Mel Gorman wrote:
> > On Wed, Feb 15, 2017 at 05:37:22PM +0530, Anshuman Khandual wrote:
> >>This four patches define CDM node with HugeTLB & Buddy allocation
> >> isolation. Please refer to the last RFC posting mentioned here for more
> > 
> > Always include the background with the changelog itself. Do not assume that
> > people are willing to trawl through a load of past postings to assemble
> > the picture. I'm only taking a brief look because of the page allocator
> > impact but it does not appear that previous feedback was addressed.
> > 
> > In itself, the series does very little and as Vlastimil already pointed
> > out, it's not a good idea to try merge piecemeal when people could not
> > agree on the big picture (I didn't dig into it).
> > 
> 
> The idea of CDM is independent of how some of the other problems related
> to AutoNUMA balancing is handled.

What has Automatic NUMA balancing got to do with CDM?

Even if you're trying to draw a comparison between how the patches were
developed in comparison to CDM, it's a poor example. Regardless of which
generation of NUMA balancing implementation considered (there were three
contenders), each of them was a working implementation that had a measurable
impact on a number of workloads. In many cases, performance data was
included. The instructions on how workloads could use it were clear even
if there were disagreements on exactly what the tuning options should be.
While the feature evolved over time and improved for different classes of
workload, the first set of patches merged were functional.

> The idea of this patchset was to introduce
> the concept of memory that is not necessarily system memory, but is coherent
> in terms of visibility/access with some restrictions
> 

Which should be done without special casing the page allocator, cpusets and
special casing how cpusets are handled. It's not necessary for any other
mechanism used to restrict access to portions of memory such as cpusets,
mempolicies or even memblock reservations.

> > The only reason I'm commenting at all is to say that I am extremely opposed
> > to the changes made to the page allocator paths that are specific to
> > CDM. It's been continual significant effort to keep the cost there down
> > and this is a mess of special cases for CDM. The changes to hugetlb to
> > identify "memory that is not really memory" with special casing is also
> > quite horrible.
> > 
> > It's completely unclear that even if one was to assume that CDM memory
> > should be expressed as nodes why such systems do not isolate all processes
> > from CDM nodes by default and then allow access via memory policies or
> > cpusets instead of special casing the page allocator fast path. It's also
> > completely unclear what happens if a device should then access the CDM
> > and how that should be synchronised with the core, if that is even possible.
> > 
> 
> A big part of this is driven by the need to special case what allocations
> go there. The idea being that an allocation should get there only when
> explicitly requested.

cpuset, mempolicy or mmap of a device file that mediates whether device
or system memory is used. For the last option, I don't know the specifics
but given that HMM worked on this for years, there should be ables of
the considerations and complications that arise. I'm not familiar with
the specifics.

> Unfortunately, IIUC node distance is not a good
> isolation metric.

I don't recall suggesting that.

> CPUsets are heavily driven by user space and we
> believe that setting up CDM is not an administrative operation, its
> going to be hard for an administrator or user space application to set
> up the right policy or an installer to figure it out.

So by this design, an application is expected to know nothing about how
to access CDM yet be CDM-aware? The application is either aware of CDM or
it isn't. It's either known how to access it or it does not.

Even if it was a case that the arch layer provides hooks to alter the global
nodemask and expose a special file of the CDM nodemask to userspace then
it would still avoid special casing in the various allocators. It would
not address the problem at all of how devices are meant to be informed
that there is CDM memory with work to do but that has been raised elsewhere.

> It does not help
> that CPUSets assume inheritance from the root hierarchy. As far as the
> overheads go, one could consider using STATIC_KEYS if that is worthwhile.
> 

Hiding the overhead in static keys could not change the fact that the various
allocator paths should not need to be CDM-aware or special casing CDM when
there already are existing mechanisms for avoiding regions of memory.

-- 
Mel Gorman
SUSE Labs

counting file descriptors with a cgroup controller

[Łukasz Stelmach]

Hi,

We need to limit and monitor the number of file descriptors processes
keep open. If a process exceeds certain limit we'd like to terminate it
and restart it or reboot the whole system. Currently the RLIMIT API
allows limiting the number of file descriptors but to achieve our goals
we'd need to make sure all programmes we run handle EMFILE errno
properly. That is why we consider developing a cgroup controller that
limits the number of open file descriptors of its members (similar to
 memory controler).

Any comments? Is there any alternative that:

+ does not require modifications of user-land code,
+ enables other process (e.g. init) to be notified and apply policy.

Kind regards,
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics


signature.asc
Description: PGP signature

Re: [PATCH] KVM: x86: remove code for lazy FPU handling

[Paolo Bonzini]

On 17/02/2017 01:45, Bandan Das wrote:
> Paolo Bonzini  writes:
> 
>> The FPU is always active now when running KVM.
> 
> The lazy code was a performance optimization, correct ?
> Is this just dormant code and being removed ? Maybe
> mentioning the reasoning in a little more detail is a good
> idea.

Lazy FPU support was removed completely from arch/x86.  Apparently,
things such as SSE-optimized mem* and str* functions made it much less
useful.  At this point the KVM code is unnecessary too.

Paolo

> The removal itself looks clean. I was really hoping that you
> would have forgotten removing "fpu_active" from struct kvm_vcpu()
> but you hadn't ;)
> 
> Bandan
> 
>> Signed-off-by: Paolo Bonzini 
>> ---
>>  arch/x86/include/asm/kvm_host.h |   3 --
>>  arch/x86/kvm/cpuid.c|   2 -
>>  arch/x86/kvm/svm.c  |  43 ++-
>>  arch/x86/kvm/vmx.c  | 112 
>> ++--
>>  arch/x86/kvm/x86.c  |   7 +--
>>  include/linux/kvm_host.h|   1 -
>>  6 files changed, 19 insertions(+), 149 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/kvm_host.h 
>> b/arch/x86/include/asm/kvm_host.h
>> index e4f13e714bcf..74ef58c8ff53 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -55,7 +55,6 @@
>>  #define KVM_REQ_TRIPLE_FAULT  10
>>  #define KVM_REQ_MMU_SYNC  11
>>  #define KVM_REQ_CLOCK_UPDATE  12
>> -#define KVM_REQ_DEACTIVATE_FPU13
>>  #define KVM_REQ_EVENT 14
>>  #define KVM_REQ_APF_HALT  15
>>  #define KVM_REQ_STEAL_UPDATE  16
>> @@ -936,8 +935,6 @@ struct kvm_x86_ops {
>>  unsigned long (*get_rflags)(struct kvm_vcpu *vcpu);
>>  void (*set_rflags)(struct kvm_vcpu *vcpu, unsigned long rflags);
>>  u32 (*get_pkru)(struct kvm_vcpu *vcpu);
>> -void (*fpu_activate)(struct kvm_vcpu *vcpu);
>> -void (*fpu_deactivate)(struct kvm_vcpu *vcpu);
>>  
>>  void (*tlb_flush)(struct kvm_vcpu *vcpu);
>>  
>> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
>> index c0e2036217ad..1d155cc56629 100644
>> --- a/arch/x86/kvm/cpuid.c
>> +++ b/arch/x86/kvm/cpuid.c
>> @@ -123,8 +123,6 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu)
>>  if (best && (best->eax & (F(XSAVES) | F(XSAVEC
>>  best->ebx = xstate_required_size(vcpu->arch.xcr0, true);
>>  
>> -kvm_x86_ops->fpu_activate(vcpu);
>> -
>>  /*
>>   * The existing code assumes virtual address is 48-bit in the canonical
>>   * address checks; exit if it is ever changed.
>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>> index 4e5905a1ce70..d1efe2c62b3f 100644
>> --- a/arch/x86/kvm/svm.c
>> +++ b/arch/x86/kvm/svm.c
>> @@ -1157,7 +1157,6 @@ static void init_vmcb(struct vcpu_svm *svm)
>>  struct vmcb_control_area *control = &svm->vmcb->control;
>>  struct vmcb_save_area *save = &svm->vmcb->save;
>>  
>> -svm->vcpu.fpu_active = 1;
>>  svm->vcpu.arch.hflags = 0;
>>  
>>  set_cr_intercept(svm, INTERCEPT_CR0_READ);
>> @@ -1899,15 +1898,12 @@ static void update_cr0_intercept(struct vcpu_svm 
>> *svm)
>>  ulong gcr0 = svm->vcpu.arch.cr0;
>>  u64 *hcr0 = &svm->vmcb->save.cr0;
>>  
>> -if (!svm->vcpu.fpu_active)
>> -*hcr0 |= SVM_CR0_SELECTIVE_MASK;
>> -else
>> -*hcr0 = (*hcr0 & ~SVM_CR0_SELECTIVE_MASK)
>> -| (gcr0 & SVM_CR0_SELECTIVE_MASK);
>> +*hcr0 = (*hcr0 & ~SVM_CR0_SELECTIVE_MASK)
>> +| (gcr0 & SVM_CR0_SELECTIVE_MASK);
>>  
>>  mark_dirty(svm->vmcb, VMCB_CR);
>>  
>> -if (gcr0 == *hcr0 && svm->vcpu.fpu_active) {
>> +if (gcr0 == *hcr0) {
>>  clr_cr_intercept(svm, INTERCEPT_CR0_READ);
>>  clr_cr_intercept(svm, INTERCEPT_CR0_WRITE);
>>  } else {
>> @@ -1938,8 +1934,6 @@ static void svm_set_cr0(struct kvm_vcpu *vcpu, 
>> unsigned long cr0)
>>  if (!npt_enabled)
>>  cr0 |= X86_CR0_PG | X86_CR0_WP;
>>  
>> -if (!vcpu->fpu_active)
>> -cr0 |= X86_CR0_TS;
>>  /*
>>   * re-enable caching here because the QEMU bios
>>   * does not do it - this results in some delay at
>> @@ -2158,22 +2152,6 @@ static int ac_interception(struct vcpu_svm *svm)
>>  return 1;
>>  }
>>  
>> -static void svm_fpu_activate(struct kvm_vcpu *vcpu)
>> -{
>> -struct vcpu_svm *svm = to_svm(vcpu);
>> -
>> -clr_exception_intercept(svm, NM_VECTOR);
>> -
>> -svm->vcpu.fpu_active = 1;
>> -update_cr0_intercept(svm);
>> -}
>> -
>> -static int nm_interception(struct vcpu_svm *svm)
>> -{
>> -svm_fpu_activate(&svm->vcpu);
>> -return 1;
>> -}
>> -
>>  static bool is_erratum_383(void)
>>  {
>>  int err, i;
>> @@ -2571,9 +2549,6 @@ static int nested_svm_exit_special(struct vcpu_svm 
>> *svm)
>>  if (!npt_enabled && svm->apf_reason == 0)
>>  return NESTED_EXIT_HOST;
>>  break;
>> -case SVM_EXIT_EXCP_BASE + NM_VECTOR:
>> -nm_interception(svm

[PATCH] pata: remove the at91 driver

[Boris Brezillon]

This driver is orphan since commit 2e591e7b3ac2 ("ARM: at91: remove
at91sam9261/at91sam9g10 legacy board support"). Given that nobody cared
adding DT support to it, it probably means it's no longer used and is
thus a good candidate for removal.

Signed-off-by: Boris Brezillon 
---
Note that I'm removing this driver because I plan to rework the macro
definitions in atmel-smc.h, and some of them are used in this driver.
Since I can't test it, and this drivers is not used anymore, it's probably
better to remove it.
---
 drivers/ata/Kconfig |   8 -
 drivers/ata/Makefile|   1 -
 drivers/ata/pata_at91.c | 503 
 3 files changed, 512 deletions(-)
 delete mode 100644 drivers/ata/pata_at91.c

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 2c8be74f401d..cbf871dabcb5 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -877,14 +877,6 @@ config PATA_AT32
 
  If unsure, say N.
 
-config PATA_AT91
-   tristate "PATA support for AT91SAM9260"
-   depends on ARM && SOC_AT91SAM9
-   help
- This option enables support for IDE devices on the Atmel AT91SAM9260 
SoC.
-
- If unsure, say N.
-
 config PATA_CMD640_PCI
tristate "CMD640 PCI PATA support (Experimental)"
depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index a46e6b784bda..c5c09e34f2eb 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -91,7 +91,6 @@ obj-$(CONFIG_PATA_WINBOND)+= pata_sl82c105.o
 
 # SFF PIO only
 obj-$(CONFIG_PATA_AT32)+= pata_at32.o
-obj-$(CONFIG_PATA_AT91)+= pata_at91.o
 obj-$(CONFIG_PATA_CMD640_PCI)  += pata_cmd640.o
 obj-$(CONFIG_PATA_ISAPNP)  += pata_isapnp.o
 obj-$(CONFIG_PATA_IXP4XX_CF)   += pata_ixp4xx_cf.o
diff --git a/drivers/ata/pata_at91.c b/drivers/ata/pata_at91.c
deleted file mode 100644
index 1611e0e8d767..
--- a/drivers/ata/pata_at91.c
+++ /dev/null
@@ -1,503 +0,0 @@
-/*
- * PATA driver for AT91SAM9260 Static Memory Controller
- * with CompactFlash interface in True IDE mode
- *
- * Copyright (C) 2009 Matyukevich Sergey
- *   2011 Igor Plyatov
- *
- * Based on:
- *  * generic platform driver by Paul Mundt: drivers/ata/pata_platform.c
- *  * pata_at32 driver by Kristoffer Nyborg Gregertsen
- *  * at91_ide driver by Stanislaw Gruszka
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation.
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define DRV_NAME   "pata_at91"
-#define DRV_VERSION"0.3"
-
-#define CF_IDE_OFFSET  0x00c0
-#define CF_ALT_IDE_OFFSET  0x00e0
-#define CF_IDE_RES_SIZE0x08
-#define CS_PULSE_MAXIMUM   319
-#define ER_SMC_CALC1
-#define ER_SMC_RECALC  2
-
-struct at91_ide_info {
-   unsigned long mode;
-   unsigned int cs;
-   struct clk *mck;
-   void __iomem *ide_addr;
-   void __iomem *alt_addr;
-};
-
-/**
- * struct smc_range - range of valid values for SMC register.
- */
-struct smc_range {
-   int min;
-   int max;
-};
-
-struct regmap *smc;
-
-struct at91sam9_smc_generic_fields {
-   struct regmap_field *setup;
-   struct regmap_field *pulse;
-   struct regmap_field *cycle;
-   struct regmap_field *mode;
-} fields;
-
-/**
- * adjust_smc_value - adjust value for one of SMC registers.
- * @value: adjusted value
- * @range: array of SMC ranges with valid values
- * @size: SMC ranges array size
- *
- * This returns the difference between input and output value or negative
- * in case of invalid input value.
- * If negative returned, then output value = maximal possible from ranges.
- */
-static int adjust_smc_value(int *value, struct smc_range *range, int size)
-{
-   int maximum = (range + size - 1)->max;
-   int remainder;
-
-   do {
-   if (*value < range->min) {
-   remainder = range->min - *value;
-   *value = range->min; /* nearest valid value */
-   return remainder;
-   } else if ((range->min <= *value) && (*value <= range->max))
-   return 0;
-
-   range++;
-   } while (--size);
-   *value = maximum;
-
-   return -1; /* invalid value */
-}
-
-/**
- * calc_smc_vals - calculate SMC register values
- * @dev: ATA device
- * @setup: SMC_SETUP register value
- * @pulse: SMC_PULSE register value
- * @cycle: SMC_CYCLE register value
- *
- * This returns negative in case of invalid values for SMC registers:
- * -ER_SMC_RECALC - recalculation required for SMC values,
- * -ER_SMC_CALC - calculation failed (invalid input values).
- *
- * SMC use special coding sch

Re: [PATCH] KVM: race-free exit from KVM_RUN without POSIX signals

[Paolo Bonzini]

On 16/02/2017 20:26, David Hildenbrand wrote:
> As mentioned already on IRC, maybe something like "block_vcpu_run" would
> fit better now.

Hmm, the purpose of the flag is cause an immediate exit and it does do
so...  Surely incorrect (or just uncommon) usage will prevent a VCPU
from running, but that is just a side effect of the semantics, not the
intended usage.

Paolo

> But this is also ok and looks good to me.
> 
> Reviewed-by: David Hildenbrand 

Re: [PATCH v4 1/2] x86/paravirt: Change vcp_is_preempted() arg type to long

[Peter Zijlstra]

On Thu, Feb 16, 2017 at 04:02:57PM -0500, Waiman Long wrote:
> On 02/16/2017 11:09 AM, Peter Zijlstra wrote:
> > On Wed, Feb 15, 2017 at 04:37:49PM -0500, Waiman Long wrote:
> >> The cpu argument in the function prototype of vcpu_is_preempted()
> >> is changed from int to long. That makes it easier to provide a better
> >> optimized assembly version of that function.
> >>
> >> For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the
> >> downcast from long to int is not a problem as vCPU number won't exceed
> >> 32 bits.
> >>
> > Note that because of the cast in PVOP_CALL_ARG1() this patch is
> > pointless.
> >
> > Then again, it doesn't seem to affect code generation, so why not. Takes
> > away the reliance on that weird cast.
> 
> I add this patch because I am a bit uneasy about clearing the upper 32
> bits of rdi and assuming that the compiler won't have a previous use of
> those bits. It gives me peace of mind.

So currently the PVOP_CALL_ARG#() macros force cast everything to
(unsigned long) anyway, but it would be good not to rely on that I
think, so yes.

Ihre Kooperation erwünscht,

[Mr. Steve Morgan]

Hallo

Ich bin Herr Wuilan Lan, Bitte ich brauche Ihre Kooperation auf dieser Grund 
schreiben ich mit meinen private email Adresse um meine Interesse sowie 
vorhaben mit Ihnen zur Teilen. Sie sollen wissen das Sie die gleichen Nachnamen 
mit unsere verstobenen Kunden haben.Der Bank Mitarbeitern hat schon vielmals 
sich bemüht mit seine verwandten zu kontaktieren trotzenden wir haben die 
Briefe zurück bekommen.
Das Geld ist frei zu aus Händigen wenn jemand jetzt kommen würde als sein
Verwandt oder Familie angehörige.Wenn Sie mit mir Kooperieren würden, konnte 
Ich alle notwendigen Urkunde erschaffen für Sie und Sie werden das geld auf 
Ihren Private Konto bekommen. 
Sie sollen kein angst haben alle notwendigen Löcher habe ich schon Gedeck. Mehr 
Detail bekommen Sie von mir sobald ich Ihren ruck schreiben bekommen habe. 
Bitte geben Sie Ihren vollständigen Namen, Adresse und Telefonnummer.
Mit freundlichen Grüßen,
Herr Wuilan Lan.

Re: [Patch 0/2] media: ti-vpe: allow user specified stride

[Tomi Valkeinen]

On 13/02/17 15:06, Benoit Parrot wrote:
> This patch series enables user specified buffer stride to be used
> instead of always forcing the stride from the driver side.
> 
> Benoit Parrot (2):
>   media: ti-vpe: vpdma: add support for user specified stride
>   media: ti-vpe: vpe: allow use of user specified stride
> 
>  drivers/media/platform/ti-vpe/vpdma.c | 14 --
>  drivers/media/platform/ti-vpe/vpdma.h |  6 +++---
>  drivers/media/platform/ti-vpe/vpe.c   | 34 --
>  3 files changed, 31 insertions(+), 23 deletions(-)

Reviewed-by: Tomi Valkeinen 

 Tomi



signature.asc
Description: OpenPGP digital signature

[PATCH v3 1/6] staging: ks7010: fixed warning of avoiding line over 80 characters

[Chetan Sethi]

This is patch 01 to ks_wlan.h file in order to fix warning of line over
80 characters, as issued by checkpatch.pl

Signed-off-by: Chetan Sethi 
---
v2:
 - split multiple changes across different patches
v3:
 - mentioned patch revision in subject

 drivers/staging/ks7010/ks_wlan.h | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan.h b/drivers/staging/ks7010/ks_wlan.h
index 9ab80e1..668202d 100644
--- a/drivers/staging/ks7010/ks_wlan.h
+++ b/drivers/staging/ks7010/ks_wlan.h
@@ -18,10 +18,10 @@
 #include 
 #include 
 
-#include /* spinlock_t   
*/
-#include/* wait_queue_head_t
*/
-#include/* pid_t
*/
-#include/* struct net_device_stats,  struct sk_buff 
*/
+#include /* spinlock_t */
+#include/* wait_queue_head_t */
+#include/* pid_t */
+#include/* struct net_device_stats,  struct sk_buff */
 #include 
 #include 
 #include   /* struct atomic_t */
@@ -36,7 +36,8 @@
 
 #ifdef KS_WLAN_DEBUG
 #define DPRINTK(n, fmt, args...) \
- if (KS_WLAN_DEBUG > (n)) printk(KERN_NOTICE "%s: "fmt, 
__FUNCTION__, ## args)
+ if (KS_WLAN_DEBUG > (n)) \
+   printk(KERN_NOTICE "%s: "fmt, __FUNCTION__, ## args)
 #else
 #define DPRINTK(n, fmt, args...)
 #endif
-- 
2.7.4

[PATCH v3 2/6] staging: ks7010: fix coding style issue of enclosing complex macro value in parentheses

[Chetan Sethi]

This is 02nd patch to file ks_wlan.h file fixing error of enclosing
complex macro value in parentheses

Signed-off-by: Chetan Sethi 
---
v2:
 - split multiple changes across different patches
v3:
 - mentioned patch revision in subject
 - incorporated review comment of correct indentation for do statement

 drivers/staging/ks7010/ks_wlan.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan.h b/drivers/staging/ks7010/ks_wlan.h
index 668202d..33d6b28 100644
--- a/drivers/staging/ks7010/ks_wlan.h
+++ b/drivers/staging/ks7010/ks_wlan.h
@@ -36,8 +36,10 @@
 
 #ifdef KS_WLAN_DEBUG
 #define DPRINTK(n, fmt, args...) \
- if (KS_WLAN_DEBUG > (n)) \
-   printk(KERN_NOTICE "%s: "fmt, __FUNCTION__, ## args)
+do { \
+   if (KS_WLAN_DEBUG > (n)) \
+   printk(KERN_NOTICE "%s: "fmt, __FUNCTION__, ## args); \
+   } while (0)
 #else
 #define DPRINTK(n, fmt, args...)
 #endif
-- 
2.7.4

[PATCH v3 3/6] staging: ks7010: fix coding style issue of using tabs instead of spaces

[Chetan Sethi]

This is 03rd patch to file ks_wlan.h fixing coding style issue of using
tabs instead of spaces at start of line, error as issued by checkpatch.pl

Signed-off-by: Chetan Sethi 
---
v2:
 - split multiple changes across different patches
v3:
 - mentioned patch revision in subject

 drivers/staging/ks7010/ks_wlan.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks_wlan.h b/drivers/staging/ks7010/ks_wlan.h
index 33d6b28..94b648b 100644
--- a/drivers/staging/ks7010/ks_wlan.h
+++ b/drivers/staging/ks7010/ks_wlan.h
@@ -36,7 +36,7 @@
 
 #ifdef KS_WLAN_DEBUG
 #define DPRINTK(n, fmt, args...) \
-do { \
+   do { \
if (KS_WLAN_DEBUG > (n)) \
printk(KERN_NOTICE "%s: "fmt, __FUNCTION__, ## args); \
} while (0)
-- 
2.7.4

[driver core] bea5b158ff WARNING: CPU: 0 PID: 1 at drivers/ata/libata-core.c:6482 ata_port_detach

[Fengguang Wu]

Hi Rob,

We see this WARNING in both mainline and linux-next kernels.

commit bea5b158ff0da9c7246ff391f754f5f38e34577a
Author: Rob Herring 
AuthorDate: Thu Aug 11 10:20:58 2016 -0500
Commit: Greg Kroah-Hartman 
CommitDate: Wed Aug 31 15:13:55 2016 +0200

 driver core: add test of driver remove calls during probe
 
 In recent discussions on ksummit-discuss[1], it was suggested to do a
 sequence of probe, remove, probe for testing driver remove paths. This
 adds a kconfig option for said test.
 
 [1] 
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
 
 Suggested-by: Arnd Bergmann 
 Cc: Greg Kroah-Hartman 
 Signed-off-by: Rob Herring 
 Signed-off-by: Greg Kroah-Hartman 

+++++
|| 
cebf8fd169 | bea5b158ff | 8df5cf57b8 |
+++++
| boot_successes | 
63 | 0  | 0  |
| boot_failures  | 
0  | 22 | 67 |
| WARNING:at_drivers/ata/libata-core.c:#ata_port_detach  | 
0  | 22 | 67 |
| calltrace:piix_init| 
0  | 22 ||
| BUG:unable_to_handle_kernel| 
0  | 18 | 40 |
| Oops:#[##] | 
0  | 18 | 40 |
| RIP:ata_dev_next   | 
0  | 18 ||
| calltrace:async_run_entry_fn   | 
0  | 18 ||
| Kernel_panic-not_syncing:Fatal_exception   | 
0  | 18 | 47 |
| WARNING:at_drivers/gpu/drm/drm_mode_config.c:#drm_mode_config_cleanup[drm] | 
0  | 0  | 7  |
| kernel_BUG_at_include/linux/mm.h   | 
0  | 0  | 7  |
+++++

[   11.449739] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
[   11.490073] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
supports DPO and FUA
[   11.569086] [ cut here ]
[   11.569955] WARNING: CPU: 0 PID: 1 at drivers/ata/libata-core.c:6482 
ata_port_detach+0x5e/0xed
[   11.572803] Modules linked in:
[   11.573415] CPU: 0 PID: 1 Comm: swapper Not tainted 4.8.0-rc4-3-gbea5b15 
#1
[   11.574663]  81b0f132 88001d46bb68 812dec12 
88001d46bbb8
[   11.579395]  81050301  00091d464000 
81073c08
[   11.582269]  88001f1e 0282 81c8b810 

[   11.585116] Call Trace:
[   11.586307] ata2.01: NODEV after polling detection
[   11.586998] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
[   11.587916] ata2.00: configured for MWDMA2
[   11.596069]  [] dump_stack+0x19/0x1b
[   11.597928]  [] __warn+0xcb/0xe9
[   11.602263]  [] ? woken_wake_function+0xe/0xe
[   11.604794]  [] warn_slowpath_null+0x18/0x1a
[   11.606826]  [] ata_port_detach+0x5e/0xed
[   11.609136]  [] ata_host_detach+0x20/0x34
[   11.613021]  [] ata_pci_remove_one+0x10/0x12
[   11.614376]  [] piix_remove_one+0x33/0x37
[   11.615381]  [] pci_device_remove+0x38/0x9b
[   11.616559]  [] ? driver_sysfs_add+0x6e/0x94
[   11.617529]  [] really_probe+0x12f/0x2b1
[   11.618421]  [] ? _raw_spin_unlock_irq+0x2b/0x3d
[   11.619410]  [] ? pm_runtime_barrier+0x6e/0x9b
[   11.620630]  [] driver_probe_device+0x44/0x72
[   11.621646]  [] __driver_attach+0x71/0x97
[   11.623247]  [] ? driver_probe_device+0x72/0x72
[   11.624535]  [] bus_for_each_dev+0x56/0x94
[   11.625458]  [] driver_attach+0x19/0x1b
[   11.626337]  [] bus_add_driver+0xeb/0x1e3
[   11.627238]  [] driver_register+0x89/0xc1
[   11.628697]  [] __pci_register_driver+0x63/0x6a
[   11.629742]  [] ? pdc_sata_pci_driver_init+0x1b/0x1b
[   11.630876]  [] piix_init+0x19/0x29
[   11.631849]  [] do_one_initcall+0x95/0x142
[   11.632850]  [] ? kernel_init_freeable+0xd5/0x1a4
[   11.634565]  [] do_basic_setup+0xa7/0xca
[   11.63]  [] ? kernel_init_freeable+0x1a4/0x1a4
[   11.636601]  [] kernel_init_freeable+0x128/0x1a4
[   11.638202]  [] ? kernel_init+0x9/0xee
[   11.639167]  [] kernel_init+0x9/0xee
[   11.640171]  [] ret_from_fork+0x1f/0x40
[   11.641451]  [] ? rest_init+0x135/0x135
[   11.642858] ---[ end trace 4c76f43f7bd2e878 ]---
[   11.645100] ata2.00: disabled

git bise

[PATCH v3 4/6] drivers: staging: fix coding style issue of using pr_notice instead of printk

[Chetan Sethi]

This is 04th patch to ks_wlan.h fixing coding style issue of using
pr_notice instead of printk, warning as issued by checkpatch.pl

Signed-off-by: Chetan Sethi 
---
v2:
 - split multiple changes across different patches
v3:
 - mentioned patch revision in subject

 drivers/staging/ks7010/ks_wlan.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks_wlan.h b/drivers/staging/ks7010/ks_wlan.h
index 94b648b..78beca7 100644
--- a/drivers/staging/ks7010/ks_wlan.h
+++ b/drivers/staging/ks7010/ks_wlan.h
@@ -38,7 +38,7 @@
 #define DPRINTK(n, fmt, args...) \
do { \
if (KS_WLAN_DEBUG > (n)) \
-   printk(KERN_NOTICE "%s: "fmt, __FUNCTION__, ## args); \
+   pr_notice("%s: "fmt, __FUNCTION__, ## args); \
} while (0)
 #else
 #define DPRINTK(n, fmt, args...)
-- 
2.7.4

[PATCH v3 5/6] drivers: staging: fix coding style issue of using __func__ instead of __FUNCTION__

[Chetan Sethi]

This is 05th patch to file ks_wlan.h which fixes coding style issue of
using __func__ instead of gcc specific __FUNCTION__, warning as issued by
checkpatch.pl

Signed-off-by: Chetan Sethi 
---
v2:
 - split multiple changes across different patches
v3:
 - mentioned patch revision in subject

 drivers/staging/ks7010/ks_wlan.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks_wlan.h b/drivers/staging/ks7010/ks_wlan.h
index 78beca7..79737bf 100644
--- a/drivers/staging/ks7010/ks_wlan.h
+++ b/drivers/staging/ks7010/ks_wlan.h
@@ -38,7 +38,7 @@
 #define DPRINTK(n, fmt, args...) \
do { \
if (KS_WLAN_DEBUG > (n)) \
-   pr_notice("%s: "fmt, __FUNCTION__, ## args); \
+   pr_notice("%s: "fmt, __func__, ## args); \
} while (0)
 #else
 #define DPRINTK(n, fmt, args...)
-- 
2.7.4

Re: [PATCH v2] gpio: dwapb: Add support for next generation of X-Gene SoC

[Jamie Iles]

On Thu, Feb 16, 2017 at 05:01:29PM -0800, Hoan Tran wrote:
> Next generation of X-Gene SoC's GPIO hardware register map is very
> similar to DW GPIO. It only differs by a few register addresses.
> This patch modifies DW GPIO driver to accommodate the difference
> in a few register addresses.
> 
> Signed-off-by: Hoan Tran 

Reviewed-by: Jamie Iles 

[PATCH v3 6/6] drivers: staging: fix coding style issue of aligning comments properly

[Chetan Sethi]

This is 06th patch to file ks_wlan.h in order to fix coding style issue
of having block comments using a trailing */ on a separate line, warning
as issued by checkpatch.pl

Signed-off-by: Chetan Sethi 
---
v2:
 - split multiple changes across different patches
v3:
 - mentioned patch revision in subject

 drivers/staging/ks7010/ks_wlan.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks_wlan.h b/drivers/staging/ks7010/ks_wlan.h
index 79737bf..1a63704 100644
--- a/drivers/staging/ks7010/ks_wlan.h
+++ b/drivers/staging/ks7010/ks_wlan.h
@@ -359,7 +359,8 @@ struct wpa_key_t {
u8 rx_seq[IW_ENCODE_SEQ_MAX_SIZE];  /* LSB first */
struct sockaddr addr;   /* ff:ff:ff:ff:ff:ff for broadcast/multicast
 * (group) keys or unicast address for
-* individual keys */
+* individual keys
+*/
u16 alg;
u16 key_len;/* WEP: 5 or 13, TKIP: 32, CCMP: 16 */
u8 key_val[IW_ENCODING_TOKEN_MAX];
-- 
2.7.4

Re: [PATCH 1/5] KVM: change API for requests to match bit operations

[Andrew Jones]

On Fri, Feb 17, 2017 at 10:30:14AM +0100, Cornelia Huck wrote:
> On Thu, 16 Feb 2017 17:04:45 +0100
> Radim Krčmář  wrote:
> > +static inline void kvm_request_set(unsigned req, struct kvm_vcpu *vcpu)
> 
> Should we make req unsigned long as well, so that it matches the bit
> api even more?

The bitops API is inconsistent among architectures; some are int, some
are unsigned int, some are unsigned long, and x86 is long. If we want
to be consistent with something, then, IMO, we should be consistent with
asm-generic/bitops, which is int, but actually unsigned makes more sense
to me...

Thanks,
drew

[PATCH v2 00/22] PCI: Support for configurable PCI endpoint

[Kishon Vijay Abraham I]

This patch series
 *) add PCI endpoint core layer
 *) modify designware/dra7xx driver to be configured in EP mode
 *) add a PCI endpoint *test* function driver and corresponding host
driver

Changes from v1:
*) The preparation patches for adding EP support is removed and is sent
   separately
*) Added device ID for DRA74x/DRA72x and used it instead of
   using "PCI_ANY_ID"
*) Added userguide for PCI endpoint test function

Major Improvements from RFC:
 *) support multi-function devices (hw supported not virtual)
 *) Access host side buffers
 *) Raise MSI interrupts
 *) Add user space program to use the host side PCI driver
 *) Adapt all other users of designware to use the new design (only
compile tested. Since I have only dra7xx boards, the new design
has only been tested in dra7xx. I'd require the help of others
to test the platforms they have access to).

The patch series is created after applying
https://lkml.org/lkml/2017/2/16/270

I've also pushed the tree to
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/pci-endpoint.git next

Kishon Vijay Abraham I (22):
  PCI: endpoint: Add EP core layer to enable EP controller and EP
functions
  Documentation: PCI: Guide to use PCI Endpoint Core Layer
  PCI: endpoint: Introduce configfs entry for configuring EP functions
  Documentation: PCI: Guide to use pci endpoint configfs
  Documentation: PCI: Add specification for the *pci test* function
device
  PCI: endpoint: functions: Add an EP function to test PCI
  Documentation: PCI: Add binding documentation for pci-test endpoint
function
  PCI: dwc: designware: Add EP mode support
  dt-bindings: PCI: Add dt bindings for pci designware EP mode
  PCI: dwc: dra7xx: Facilitate wrapper and msi interrupts to be enabled
independently
  PCI: dwc: dra7xx: Add EP mode support
  dt-bindings: PCI: dra7xx: Add dt bindings for pci dra7xx EP mode
  PCI: dwc: dra7xx: Workaround for errata id i870
  dt-bindings: PCI: dra7xx: Add dt bindings to enable legacy mode
  PCI: Add device IDs for DRA74x and DRA72x
  misc: Add host side pci driver for pci test function device
  Documentation: misc-devices: Add Documentation for pci-endpoint-test
driver
  tools: PCI: Add a userspace tool to test PCI endpoint
  tools: PCI: Add sample test script to invoke pcitest
  Documentation: PCI: Add userguide for PCI endpoint test function
  MAINTAINERS: add PCI EP maintainer
  ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to
SW_WKUP

 Documentation/PCI/00-INDEX |8 +
 .../PCI/endpoint/function/binding/pci-test.txt |   17 +
 Documentation/PCI/endpoint/pci-endpoint-cfs.txt|   84 +++
 Documentation/PCI/endpoint/pci-endpoint.txt|  190 +++
 Documentation/PCI/endpoint/pci-test-function.txt   |   66 +++
 Documentation/PCI/endpoint/pci-test-howto.txt  |  167 ++
 .../devicetree/bindings/pci/designware-pcie.txt|   26 +-
 Documentation/devicetree/bindings/pci/ti-pci.txt   |   41 +-
 Documentation/misc-devices/pci-endpoint-test.txt   |   35 ++
 MAINTAINERS|9 +
 arch/arm/mach-omap2/clockdomains7xx_data.c |2 +-
 drivers/Makefile   |2 +
 drivers/misc/Kconfig   |7 +
 drivers/misc/Makefile  |1 +
 drivers/misc/pci_endpoint_test.c   |  534 +++
 drivers/pci/Kconfig|1 +
 drivers/pci/dwc/Kconfig|   36 +-
 drivers/pci/dwc/Makefile   |5 +-
 drivers/pci/dwc/pci-dra7xx.c   |  271 +-
 drivers/pci/dwc/pcie-designware-ep.c   |  342 
 drivers/pci/dwc/pcie-designware.c  |   51 ++
 drivers/pci/dwc/pcie-designware.h  |   79 +++
 drivers/pci/endpoint/Kconfig   |   33 ++
 drivers/pci/endpoint/Makefile  |7 +
 drivers/pci/endpoint/functions/Kconfig |   12 +
 drivers/pci/endpoint/functions/Makefile|5 +
 drivers/pci/endpoint/functions/pci-epf-test.c  |  513 ++
 drivers/pci/endpoint/pci-ep-cfs.c  |  427 +++
 drivers/pci/endpoint/pci-epc-core.c|  548 
 drivers/pci/endpoint/pci-epc-mem.c |  143 +
 drivers/pci/endpoint/pci-epf-core.c|  347 +
 include/linux/mod_devicetable.h|   10 +
 include/linux/pci-epc.h|  141 +
 include/linux/pci-epf.h|  160 ++
 include/linux/pci_ids.h|2 +
 include/uapi/linux/Kbuild  |1 +
 include/uapi/linux/pcitest.h   |   19 +
 tools/pci/pcitest.c|  186 +++
 tools/pci/pcitest.sh

[PATCH v2 10/22] PCI: dwc: dra7xx: Facilitate wrapper and msi interrupts to be enabled independently

[Kishon Vijay Abraham I]

No functional change. Split dra7xx_pcie_enable_interrupts into
dra7xx_pcie_enable_wrapper_interrupts and dra7xx_pcie_enable_msi_interrupts
so that wrapper interrupts and msi interrupts can be enabled independently.
This is in preparation for adding EP mode support to dra7xx driver since
EP mode doesn't have to enable msi_interrupts.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/dwc/pci-dra7xx.c |   24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index c6fef0a..8d2d02f 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -140,18 +140,30 @@ static int dra7xx_pcie_establish_link(struct dra7xx_pcie 
*dra7xx)
return dw_pcie_wait_for_link(pci);
 }
 
-static void dra7xx_pcie_enable_interrupts(struct dra7xx_pcie *dra7xx)
+static void dra7xx_pcie_enable_msi_interrupts(struct dra7xx_pcie *dra7xx)
 {
-   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN,
-  ~INTERRUPTS);
-   dra7xx_pcie_writel(dra7xx,
-  PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MAIN, INTERRUPTS);
dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI,
   ~LEG_EP_INTERRUPTS & ~MSI);
-   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI,
+
+   dra7xx_pcie_writel(dra7xx,
+  PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI,
   MSI | LEG_EP_INTERRUPTS);
 }
 
+static void dra7xx_pcie_enable_wrapper_interrupts(struct dra7xx_pcie *dra7xx)
+{
+   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN,
+  ~INTERRUPTS);
+   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MAIN,
+  INTERRUPTS);
+}
+
+static void dra7xx_pcie_enable_interrupts(struct dra7xx_pcie *dra7xx)
+{
+   dra7xx_pcie_enable_wrapper_interrupts(dra7xx);
+   dra7xx_pcie_enable_msi_interrupts(dra7xx);
+}
+
 static void dra7xx_pcie_host_init(struct pcie_port *pp)
 {
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
-- 
1.7.9.5

[PATCH v2 02/22] Documentation: PCI: Guide to use PCI Endpoint Core Layer

[Kishon Vijay Abraham I]

Add Documentation to help users use endpoint library to enable endpoint
mode in the PCI controller and add new PCI endpoint functions.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/00-INDEX  |2 +
 Documentation/PCI/endpoint/pci-endpoint.txt |  190 +++
 2 files changed, 192 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-endpoint.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 147231f..ba950b2 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -12,3 +12,5 @@ pci.txt
- info on the PCI subsystem for device driver authors
 pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO
+endpoint/pci-endpoint.txt
+   - guide to add endpoint controller driver and endpoint function driver.
diff --git a/Documentation/PCI/endpoint/pci-endpoint.txt 
b/Documentation/PCI/endpoint/pci-endpoint.txt
new file mode 100644
index 000..68a7839
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-endpoint.txt
@@ -0,0 +1,190 @@
+   PCI ENDPOINT FRAMEWORK
+   Kishon Vijay Abraham I 
+
+This document is a guide to use the PCI Endpoint Framework in order to create
+endpoint controller driver, endpoint function driver and using configfs
+interface to bind the function driver to the controller driver.
+
+1. Introduction
+
+*Linux* has a comprehensive PCI subsystem to support PCI controllers that
+operates in Root Complex mode. The subsystem has capability to scan PCI bus,
+assign memory resources and irq resources, load PCI driver (based on
+vendorid, deviceid), support other services like hot-plug, power management,
+advanced error reporting and virtual channels.
+
+However PCI controller IPs integrated in certain SoC is capable of operating
+either in Root Complex mode or Endpoint mode. PCI Endpoint Framework will
+add endpoint mode support in *Linux*. This will help to run Linux in an
+EP system which can have a wide variety of use cases from testing or
+validation, co-processor accelerator etc..
+
+2. PCI Endpoint Core
+
+The PCI Endpoint Core layer comprises of 3 components: the Endpoint Controller
+library, the Endpoint Function library and the configfs layer to bind the
+endpoint function with the endpoint controller.
+
+2.1 PCI Endpoint Controller(EPC) Library
+
+The EPC library provides APIs to be used by the controller that can operate
+in endpoint mode. It also provides APIs to be used by function driver/library
+in order to implement a particular endpoint function.
+
+2.1.1 APIs for the PCI controller Driver
+
+This section lists the APIs that the PCI Endpoint core provides to be used
+by the PCI controller driver.
+
+*) devm_pci_epc_create()/pci_epc_create()
+
+   The PCI controller driver should implement the following ops:
+* write_header: ops to populate configuration space header
+* set_bar: ops to configure the BAR
+* clear_bar: ops to reset the BAR
+* alloc_addr_space: ops to allocate *in* PCI controller address space
+* free_addr_space: ops to free the allocated address space
+* raise_irq: ops to raise a legacy or MSI interrupt
+* start: ops to start the PCI link
+* stop: ops to stop the PCI link
+
+   The PCI controller driver can then create a new EPC device by invoking
+   devm_pci_epc_create/pci_epc_create.
+
+*) devm_pci_epc_destroy()/pci_epc_destroy()
+
+   The PCI controller driver can destroy the EPC device created by either
+   devm_pci_epc_create or pci_epc_create using devm_pci_epc_destroy() or
+   /pci_epc_destroy()
+
+2.1.2 APIs for the PCI Endpoint Function Driver
+
+This section lists the APIs that the PCI Endpoint core provides to be used
+by the PCI endpoint function driver.
+
+*) pci_epc_write_header()
+
+   The PCI endpoint function driver should use pci_epc_write_header() to
+   write the standard configuration header to the endpoint controller.
+
+*) pci_epc_set_bar()
+
+   The PCI endpoint function driver should use pci_epc_set_bar() to configure
+   the Base Address Register in order for the host to assign PCI addr space.
+   Register space of the function driver is usually configured
+   using this API.
+
+*) pci_epc_clear_bar()
+
+   The PCI endpoint function driver should use pci_epc_clear_bar() to reset
+   the BAR.
+
+*) pci_epc_raise_irq()
+
+   The PCI endpoint function driver should use pci_epc_raise_irq() to raise
+   Legacy Interrupt or MSI Interrupt.
+
+*) pci_epc_start()
+
+   The PCI endpoint function driver should invoke pci_epc_start() once it
+   has configured the endpoint function and wants to start the PCI link.
+
+*) pci_epc_stop()
+
+   The PCI endpoint function driver should invoke pci_epc_stop() to stop
+   the PCI LINK.
+
+2.1.3 Other APIs
+
+There are other APIs provided by the EPC library. These are used for binding
+the epf device with epc device. pci-ep-cfs.c can be used as reference for
+us

Re: [PATCH 5/5] KVM: add kvm_request_pending

[Andrew Jones]

On Thu, Feb 16, 2017 at 05:04:49PM +0100, Radim Krčmář wrote:
...
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 2cc438685af8..563cf964dc5c 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1101,6 +1101,11 @@ static inline int kvm_ioeventfd(struct kvm *kvm, 
> struct kvm_ioeventfd *args)
>   * should contain kvm_vcpu_kick().
>   */
>  
> +static inline bool kvm_request_pending(struct kvm_vcpu *vcpu)
> +{
> + return vcpu->requests;

How about wrapping this with READ_ONCE for good measure?

> +}
> +
>  static inline void __kvm_request_set(unsigned req, struct kvm_vcpu *vcpu)
>  {
>   set_bit(req, &vcpu->requests);
> -- 
> 2.11.1
>

Thanks,
drew

[PATCH v2 05/22] Documentation: PCI: Add specification for the *pci test* function device

[Kishon Vijay Abraham I]

Add specification for the *pci test* virtual function device. The endpoint
function driver and the host pci driver should be created based on this
specification.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/00-INDEX   |2 +
 Documentation/PCI/endpoint/pci-test-function.txt |   66 ++
 2 files changed, 68 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-test-function.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index f84a23c..4e5a283 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -16,3 +16,5 @@ endpoint/pci-endpoint.txt
- guide to add endpoint controller driver and endpoint function driver.
 endpoint/pci-endpoint-cfs.txt
- guide to use configfs to configure the pci endpoint function.
+endpoint/pci-test-function.txt
+   - specification of *pci test* function device.
diff --git a/Documentation/PCI/endpoint/pci-test-function.txt 
b/Documentation/PCI/endpoint/pci-test-function.txt
new file mode 100644
index 000..1324376
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-test-function.txt
@@ -0,0 +1,66 @@
+   PCI TEST
+   Kishon Vijay Abraham I 
+
+Traditionally PCI RC has always been validated by using standard
+PCI cards like ethernet PCI cards or USB PCI cards or SATA PCI cards.
+However with the addition of EP-core in linux kernel, it is possible
+to configure a PCI controller that can operate in EP mode to work as
+a test device.
+
+The PCI endpoint test device is a virtual device (defined in software)
+used to test the endpoint functionality and serve as a sample driver
+for other PCI endpoint devices (to use the EP framework).
+
+The PCI endpoint test device has the following registers:
+
+   1) PCI_ENDPOINT_TEST_MAGIC
+   2) PCI_ENDPOINT_TEST_COMMAND
+   3) PCI_ENDPOINT_TEST_STATUS
+   4) PCI_ENDPOINT_TEST_SRC_ADDR
+   5) PCI_ENDPOINT_TEST_DST_ADDR
+   6) PCI_ENDPOINT_TEST_SIZE
+   7) PCI_ENDPOINT_TEST_CHECKSUM
+
+*) PCI_ENDPOINT_TEST_MAGIC
+
+This register will be used to test BAR0. A known pattern will be written
+and read back from MAGIC register to verify BAR0.
+
+*) PCI_ENDPOINT_TEST_COMMAND:
+
+This register will be used by the host driver to indicate the function
+that the endpoint device must perform.
+
+Bitfield Description:
+  Bit 0: raise legacy irq
+  Bit 1: raise MSI irq
+  Bit 2 - 7: MSI interrupt number
+  Bit 8: read command (read data from RC buffer)
+  Bit 9: write command (write data to RC buffer)
+  Bit 10   : copy command (copy data from one RC buffer to another
+ RC buffer)
+
+*) PCI_ENDPOINT_TEST_STATUS
+
+This register reflects the status of the PCI endpoint device.
+
+Bitfield Description:
+  Bit 0: read success
+  Bit 1: read fail
+  Bit 2: write success
+  Bit 3: write fail
+  Bit 4: copy success
+  Bit 5: copy fail
+  Bit 6: irq raised
+  Bit 7: source address is invalid
+  Bit 8: destination address is invalid
+
+*) PCI_ENDPOINT_TEST_SRC_ADDR
+
+This register contains the source address (RC buffer address) for the
+COPY/READ command.
+
+*) PCI_ENDPOINT_TEST_DST_ADDR
+
+This register contains the destination address (RC buffer address) for
+the COPY/WRITE command.
-- 
1.7.9.5

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

[Bryan O'Donoghue]

On 17/02/17 08:23, Kweh, Hock Leong wrote:
> And to have UEFI expand
> it capsule support and take in signed binary would be a more secured way.
> So, influencing UEFI community to have such support would be the right
> move throughout the discussion. That is my summary.

CSH stands for "Clanton Secure Header" - Clanton being the internal
code-name for Quark X1000 prior to release.

There is no chance the UEFI standard (which can be used on ARM and
potentially other architectures) will accept a SoC specific
route-of-trust prepended header.

Sure some kind of binary signed headers might become part of the
standard eventually but, definitely _not_ a CSH.

The fact is CSH exists in the real-world and a UEFI firmware supports
accepting the CSH/UEFI-capsule pair for updating itself.

I think a far more practical solution is to accommodate the defacto
implementation (the only ? current implementation). To me it defies
reason to have Quark X1000 be the only system (that I know of) capable
of doing a capsule update - have capsule code in the kernel - but _not_
support the header prepended to that capsule that the Quark
firmware/bootrom require.

Right now the capsule code is dead code on Quark x1000. Let's do the
right thing and make it usable. I fully support having a
separate/parallel conversation with the UEFI body but, I'd be amazed if
the "Clanton Secure Header" made it into the standard...

-- 
bod

[PATCH v2 03/22] PCI: endpoint: Introduce configfs entry for configuring EP functions

[Kishon Vijay Abraham I]

Introduce a new configfs entry to configure the EP function (like
configuring the standard configuration header entries) and to
bind the EP function with EP controller.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/Kconfig  |   14 +-
 drivers/pci/endpoint/Makefile |1 +
 drivers/pci/endpoint/pci-ep-cfs.c |  427 +
 3 files changed, 440 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pci/endpoint/pci-ep-cfs.c

diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
index 7eb1c79..8470f0b 100644
--- a/drivers/pci/endpoint/Kconfig
+++ b/drivers/pci/endpoint/Kconfig
@@ -6,7 +6,6 @@ menu "PCI Endpoint"
 
 config PCI_ENDPOINT
bool "PCI Endpoint Support"
-   select CONFIGFS_FS
help
   Enable this configuration option to support configurable PCI
   endpoint. This should be enabled if the platform has a PCI
@@ -14,8 +13,19 @@ config PCI_ENDPOINT
 
   Enabling this option will build the endpoint library, which
   includes endpoint controller library and endpoint function
-  library.
+  library. This will also enable the configfs entry required to
+  configure the endpoint function and used to bind the
+  function with a endpoint controller.
 
   If in doubt, say "N" to disable Endpoint support.
 
+config PCI_ENDPOINT_CONFIGFS
+   bool "PCI Endpoint Configfs Support"
+   depends on PCI_ENDPOINT
+   select CONFIGFS_FS
+   help
+  This will enable the configfs entry that can be used to
+  configure the endpoint function and used to bind the
+  function with a endpoint controller.
+
 endmenu
diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
index dc1bc16..dd9163c 100644
--- a/drivers/pci/endpoint/Makefile
+++ b/drivers/pci/endpoint/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_PCI_ENDPOINT) += pci-epc-core.o pci-epf-core.o\
   pci-epc-mem.o
+obj-$(CONFIG_PCI_ENDPOINT_CONFIGFS)+= pci-ep-cfs.o
diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
new file mode 100644
index 000..ed0f8c2
--- /dev/null
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -0,0 +1,427 @@
+/**
+ * configfs to configure the PCI endpoint
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct pci_epf_info {
+   struct config_group group;
+   struct list_head list;
+   struct pci_epf *epf;
+};
+
+struct pci_ep_info {
+   struct config_group group;
+   struct config_group pci_epf_group;
+   /* mutex to protect pci_epf list */
+   struct mutex lock;
+   struct list_head pci_epf;
+   const char *epc_name;
+   struct pci_epc *epc;
+};
+
+static inline struct pci_epf_info *to_pci_epf_info(struct config_item *item)
+{
+   return container_of(to_config_group(item), struct pci_epf_info, group);
+}
+
+static inline struct pci_ep_info *to_pci_ep_info(struct config_item *item)
+{
+   return container_of(to_config_group(item), struct pci_ep_info, group);
+}
+
+#define PCI_EPF_HEADER_R(_name)
   \
+static ssize_t pci_epf_##_name##_show(struct config_item *item,char 
*page)\
+{ \
+   struct pci_epf *epf = to_pci_epf_info(item)->epf;  \
+   if (!epf->header) {\
+   WARN_ON_ONCE("epf device not bound to function driver\n"); \
+   return 0;  \
+   }  \
+   return sprintf(page, "0x%04x\n", epf->header->_name);  \
+}
+
+#define PCI_EPF_HEADER_W_u32(_name)   \
+static ssize_t pci_epf_##_name##_store(struct config_item *item,  \
+  const char *page, size_t len)   \
+{ \
+   u32 val;   \
+  

[PATCH v2 15/22] PCI: Add device IDs for DRA74x and DRA72x

[Kishon Vijay Abraham I]

Add device IDs for DRA74x and DRA72x devices. These devices have
configurable PCI endpoint.

Signed-off-by: Kishon Vijay Abraham I 
---
 include/linux/pci_ids.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 73dda0e..e8bbc4b 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -862,6 +862,8 @@
 #define PCI_DEVICE_ID_TI_X620  0xac8d
 #define PCI_DEVICE_ID_TI_X420  0xac8e
 #define PCI_DEVICE_ID_TI_XX20_FM   0xac8f
+#define PCI_DEVICE_ID_TI_DRA74x0xb500
+#define PCI_DEVICE_ID_TI_DRA72x0xb501
 
 #define PCI_VENDOR_ID_SONY 0x104d
 
-- 
1.7.9.5

[PATCH v2 17/22] Documentation: misc-devices: Add Documentation for pci-endpoint-test driver

[Kishon Vijay Abraham I]

Add Documentation for pci-endpoint-test driver.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/misc-devices/pci-endpoint-test.txt |   35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/misc-devices/pci-endpoint-test.txt

diff --git a/Documentation/misc-devices/pci-endpoint-test.txt 
b/Documentation/misc-devices/pci-endpoint-test.txt
new file mode 100644
index 000..4385718
--- /dev/null
+++ b/Documentation/misc-devices/pci-endpoint-test.txt
@@ -0,0 +1,35 @@
+Driver for PCI Endpoint Test Function
+
+This driver should be used as a host side driver if the root complex is
+connected to a configurable pci endpoint running *pci_epf_test* function
+driver configured according to [1].
+
+The "pci_endpoint_test" driver can be used to perform the following tests.
+
+The PCI driver for the test device performs the following tests
+   *) verifying addresses programmed in BAR
+   *) raise legacy IRQ
+   *) raise MSI IRQ
+   *) read data
+   *) write data
+   *) copy data
+
+This misc driver creates /dev/pci-endpoint-test. for every
+*pci_epf_test* function connected to the root complex and "ioctls"
+should be used to perform the above tests.
+
+ioctl
+-
+ PCITEST_BAR: Tests the BAR. The number of the BAR that has to be tested
+ should be passed as argument.
+ PCITEST_LEGACY_IRQ: Tests legacy IRQ
+ PCITEST_MSI: Tests message signalled interrupts. The MSI number that has
+ to be tested should be passed as argument.
+ PCITEST_WRITE: Perform write tests. The size of the buffer should be passed
+   as argument.
+ PCITEST_READ: Perform read tests. The size of the buffer should be passed
+  as argument.
+ PCITEST_COPY: Perform read tests. The size of the buffer should be passed
+  as argument.
+
+[1] -> Documentation/PCI/endpoint/function/binding/pci-test.txt
-- 
1.7.9.5

[PATCH v2 11/22] PCI: dwc: dra7xx: Add EP mode support

[Kishon Vijay Abraham I]

The PCIe controller integrated in dra7xx SoCs is capable of operating
in endpoint mode. Add endpoint mode support to dra7xx driver.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/dwc/Kconfig   |   31 +-
 drivers/pci/dwc/Makefile  |4 +-
 drivers/pci/dwc/pci-dra7xx.c  |  197 ++---
 drivers/pci/dwc/pcie-designware.h |7 ++
 4 files changed, 221 insertions(+), 18 deletions(-)

diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
index 00335c7..96e6d17 100644
--- a/drivers/pci/dwc/Kconfig
+++ b/drivers/pci/dwc/Kconfig
@@ -16,14 +16,37 @@ config PCIE_DW_EP
 
 config PCI_DRA7XX
bool "TI DRA7xx PCIe controller"
-   depends on PCI
+   depends on (PCI && PCI_MSI_IRQ_DOMAIN) || PCI_ENDPOINT
depends on OF && HAS_IOMEM && TI_PIPE3
+   help
+Enables support for the PCIe controller in the DRA7xx SoC. There
+are two instances of PCIe controller in DRA7xx. This controller can
+work either as EP or RC. In order to enable host specific features
+PCI_DRA7XX_HOST must be selected and in order to enable device
+specific features PCI_DRA7XX_EP must be selected. This uses
+the Designware core.
+
+if PCI_DRA7XX
+
+config PCI_DRA7XX_HOST
+   bool "PCI DRA7xx Host Mode"
+   depends on PCI
depends on PCI_MSI_IRQ_DOMAIN
select PCIE_DW_HOST
+   default y
help
-Enables support for the PCIe controller in the DRA7xx SoC.  There
-are two instances of PCIe controller in DRA7xx.  This controller can
-act both as EP and RC.  This reuses the Designware core.
+Enables support for the PCIe controller in the DRA7xx SoC to work in
+host mode.
+
+config PCI_DRA7XX_EP
+   bool "PCI DRA7xx Endpoint Mode"
+   depends on PCI_ENDPOINT
+   select PCIE_DW_EP
+   help
+Enables support for the PCIe controller in the DRA7xx SoC to work in
+endpoint mode.
+
+endif
 
 config PCIE_DW_PLAT
bool "Platform bus based DesignWare PCIe Controller"
diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
index b38425d..f31a859 100644
--- a/drivers/pci/dwc/Makefile
+++ b/drivers/pci/dwc/Makefile
@@ -2,7 +2,9 @@ obj-$(CONFIG_PCIE_DW) += pcie-designware.o
 obj-$(CONFIG_PCIE_DW_HOST) += pcie-designware-host.o
 obj-$(CONFIG_PCIE_DW_EP) += pcie-designware-ep.o
 obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
-obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
+ifneq ($(filter y,$(CONFIG_PCI_DRA7XX_HOST) $(CONFIG_PCI_DRA7XX_EP)),)
+obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
+endif
 obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
 obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index 8d2d02f..47bb563 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -10,12 +10,14 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -57,6 +59,11 @@
 #defineMSI BIT(4)
 #defineLEG_EP_INTERRUPTS (INTA | INTB | INTC | INTD)
 
+#definePCIECTRL_TI_CONF_DEVICE_TYPE0x0100
+#defineDEVICE_TYPE_EP  0x0
+#defineDEVICE_TYPE_LEG_EP  0x1
+#defineDEVICE_TYPE_RC  0x4
+
 #definePCIECTRL_DRA7XX_CONF_DEVICE_CMD 0x0104
 #defineLTSSM_EN0x1
 
@@ -66,6 +73,13 @@
 
 #define EXP_CAP_ID_OFFSET  0x70
 
+#definePCIECTRL_TI_CONF_INTX_ASSERT0x0124
+#definePCIECTRL_TI_CONF_INTX_DEASSERT  0x0128
+
+#definePCIECTRL_TI_CONF_MSI_XMT0x012c
+#define MSI_REQ_GRANT  BIT(0)
+#define MSI_VECTOR_SHIFT   7
+
 struct dra7xx_pcie {
struct dw_pcie  *pci;
void __iomem*base;  /* DT ti_conf */
@@ -73,6 +87,11 @@ struct dra7xx_pcie {
struct phy  **phy;
int link_gen;
struct irq_domain   *irq_domain;
+   enum dw_pcie_device_mode mode;
+};
+
+struct dra7xx_pcie_of_data {
+   enum dw_pcie_device_mode mode;
 };
 
 #define to_dra7xx_pcie(x)  dev_get_drvdata((x)->dev)
@@ -101,9 +120,19 @@ static int dra7xx_pcie_link_up(struct dw_pcie *pci)
return !!(reg & LINK_UP);
 }
 
-static int dra7xx_pcie_establish_link(struct dra7xx_pcie *dra7xx)
+static void dra7xx_pcie_stop_link(struct dw_pcie *pci)
 {
-   struct dw_pcie *pci = dra7xx->pci;
+   struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pci);
+   u32 reg;
+
+   reg = dra7xx_pcie_readl(dra7xx, PCI

[PATCH v2 06/22] PCI: endpoint: functions: Add an EP function to test PCI

[Kishon Vijay Abraham I]

Adds a new endpoint function driver (to program the virtual
test device) making use of the EP-core library.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/Kconfig  |2 +
 drivers/pci/endpoint/Makefile |2 +-
 drivers/pci/endpoint/functions/Kconfig|   12 +
 drivers/pci/endpoint/functions/Makefile   |5 +
 drivers/pci/endpoint/functions/pci-epf-test.c |  513 +
 5 files changed, 533 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pci/endpoint/functions/Kconfig
 create mode 100644 drivers/pci/endpoint/functions/Makefile
 create mode 100644 drivers/pci/endpoint/functions/pci-epf-test.c

diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
index 8470f0b..f8455d7 100644
--- a/drivers/pci/endpoint/Kconfig
+++ b/drivers/pci/endpoint/Kconfig
@@ -28,4 +28,6 @@ config PCI_ENDPOINT_CONFIGFS
   configure the endpoint function and used to bind the
   function with a endpoint controller.
 
+source "drivers/pci/endpoint/functions/Kconfig"
+
 endmenu
diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
index dd9163c..a3d4c57 100644
--- a/drivers/pci/endpoint/Makefile
+++ b/drivers/pci/endpoint/Makefile
@@ -3,5 +3,5 @@
 #
 
 obj-$(CONFIG_PCI_ENDPOINT) += pci-epc-core.o pci-epf-core.o\
-  pci-epc-mem.o
+  pci-epc-mem.o functions/
 obj-$(CONFIG_PCI_ENDPOINT_CONFIGFS)+= pci-ep-cfs.o
diff --git a/drivers/pci/endpoint/functions/Kconfig 
b/drivers/pci/endpoint/functions/Kconfig
new file mode 100644
index 000..175edad
--- /dev/null
+++ b/drivers/pci/endpoint/functions/Kconfig
@@ -0,0 +1,12 @@
+#
+# PCI Endpoint Functions
+#
+
+config PCI_EPF_TEST
+   tristate "PCI Endpoint Test driver"
+   depends on PCI_ENDPOINT
+   help
+  Enable this configuration option to enable the test driver
+  for PCI Endpoint.
+
+  If in doubt, say "N" to disable Endpoint test driver.
diff --git a/drivers/pci/endpoint/functions/Makefile 
b/drivers/pci/endpoint/functions/Makefile
new file mode 100644
index 000..6d94a48
--- /dev/null
+++ b/drivers/pci/endpoint/functions/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for PCI Endpoint Functions
+#
+
+obj-$(CONFIG_PCI_EPF_TEST) += pci-epf-test.o
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
b/drivers/pci/endpoint/functions/pci-epf-test.c
new file mode 100644
index 000..bbac323
--- /dev/null
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -0,0 +1,513 @@
+/**
+ * Test driver to test endpoint functionality
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define COMMAND_RAISE_LEGACY_IRQ   BIT(0)
+#define COMMAND_RAISE_MSI_IRQ  BIT(1)
+#define MSI_NUMBER_SHIFT   2
+#define MSI_NUMBER_MASK(0x3f << MSI_NUMBER_SHIFT)
+#define COMMAND_READ   BIT(8)
+#define COMMAND_WRITE  BIT(9)
+#define COMMAND_COPY   BIT(10)
+
+#define STATUS_READ_SUCCESSBIT(0)
+#define STATUS_READ_FAIL   BIT(1)
+#define STATUS_WRITE_SUCCESS   BIT(2)
+#define STATUS_WRITE_FAIL  BIT(3)
+#define STATUS_COPY_SUCCESSBIT(4)
+#define STATUS_COPY_FAIL   BIT(5)
+#define STATUS_IRQ_RAISED  BIT(6)
+#define STATUS_SRC_ADDR_INVALIDBIT(7)
+#define STATUS_DST_ADDR_INVALIDBIT(8)
+
+#define TIMER_RESOLUTION   1
+
+static struct workqueue_struct *kpcitest_workqueue;
+
+struct pci_epf_test {
+   void*reg[6];
+   struct pci_epf  *epf;
+   struct delayed_work cmd_handler;
+};
+
+struct pci_epf_test_reg {
+   u32 magic;
+   u32 command;
+   u32 status;
+   u64 src_addr;
+   u64 dst_addr;
+   u32 size;
+   u32 checksum;
+} __packed;
+
+static struct pci_epf_header test_header = {
+   .vendorid   = PCI_ANY_ID,
+   .deviceid   = PCI_ANY_ID,
+   .baseclass_code = PCI_CLASS_OTHERS,
+   .interrupt_pin  = PCI_INTERRUPT_INTA,
+};
+
+static int bar_size[] = { 512, 

[PATCH v2 22/22] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP

[Kishon Vijay Abraham I]

The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should
be set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO
in RC mode. However in EP mode, the host system is not able to access the
MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.

Acked-by: Tony Lindgren 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/mach-omap2/clockdomains7xx_data.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c 
b/arch/arm/mach-omap2/clockdomains7xx_data.c
index 6c67965..67ebff8 100644
--- a/arch/arm/mach-omap2/clockdomains7xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -524,7 +524,7 @@
.dep_bit  = DRA7XX_PCIE_STATDEP_SHIFT,
.wkdep_srcs   = pcie_wkup_sleep_deps,
.sleepdep_srcs= pcie_wkup_sleep_deps,
-   .flags= CLKDM_CAN_HWSUP_SWSUP,
+   .flags= CLKDM_CAN_SWSUP,
 };
 
 static struct clockdomain atl_7xx_clkdm = {
-- 
1.7.9.5

[PATCH v2 21/22] MAINTAINERS: add PCI EP maintainer

[Kishon Vijay Abraham I]

Add maintainer for the newly introduced PCI EP framework.

Signed-off-by: Kishon Vijay Abraham I 
---
 MAINTAINERS |9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8672f18..62b86af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9407,6 +9407,15 @@ F:   include/linux/pci*
 F: arch/x86/pci/
 F: arch/x86/kernel/quirks.c
 
+PCI EP SUBSYSTEM
+M: Kishon Vijay Abraham I 
+L: linux-...@vger.kernel.org
+T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/pci-endpoint.git
+S: Supported
+F: drivers/pci/endpoint/
+F: drivers/misc/pci_endpoint_test.c
+F: tools/pci/
+
 PCI DRIVER FOR ALTERA PCIE IP
 M: Ley Foon Tan 
 L: r...@lists.rocketboards.org (moderated for non-subscribers)
-- 
1.7.9.5

[PATCH v2 20/22] Documentation: PCI: Add userguide for PCI endpoint test function

[Kishon Vijay Abraham I]

Add documentation to help users use pci-epf-test function driver
and pci_endpoint_test host driver for testing PCI.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/endpoint/pci-test-howto.txt |  167 +
 1 file changed, 167 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-test-howto.txt

diff --git a/Documentation/PCI/endpoint/pci-test-howto.txt 
b/Documentation/PCI/endpoint/pci-test-howto.txt
new file mode 100644
index 000..4141b2b
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-test-howto.txt
@@ -0,0 +1,167 @@
+   PCI TEST USERGUIDE
+   Kishon Vijay Abraham I 
+
+This document is a guide to help users use pci-epf-test function driver
+and pci_endpoint_test host driver for testing PCI. The list of steps to
+be followed in the host side and EP side is given below.
+
+1. Endpoint Device
+
+1.1 Endpoint Controller Devices
+
+To find the list of endpoint controller devices in the system:
+
+   # ls /sys/class/pci_epc/
+ 5100.pcie_ep
+
+1.2 Endpoint Function Drivers
+
+To find the list of endpoint function drivers in the system:
+
+   # ls /sys/bus/pci-epf/drivers
+ pci_epf_test
+
+1.3 Creating pci-epf-test Device
+
+PCI endpoint function device can be created using the configfs. To create
+pci-epf-test device, the following commands can be used
+
+   # mount -t configfs none /sys/kernel/config
+   # cd /sys/kernel/config/pci_ep/
+   # mkdir dev
+   # mkdir dev/epf/pci_epf_test.0
+
+The "mkdir dev/epf/pci_epf_test.0" above creates the pci-epf-test function
+device. The name given to the directory preceding '.' should match with the
+name of the driver listed in '/sys/bus/pci-epf/drivers' in order for the
+device to be bound to the driver.
+
+The PCI endpoint framework populates the directory with configurable fields.
+
+   # ls dev/epf/pci_epf_test.0/
+ baseclass_codefunctionrevid   vendorid
+ cache_line_size   interrupt_pin   subclass_code
+ deviceid  peripheral  subsys_id
+ epc   progif_code subsys_vendor_id
+
+The pci endpoint function driver populates these entries with default values
+when the device is bound to the driver. The pci-epf-test driver populates
+vendorid with 0x and interrupt_pin with 0x0001
+
+   # cat dev/epf/pci_epf_test.0/vendorid
+ 0x
+   # cat dev/epf/pci_epf_test.0/interrupt_pin
+ 0x0001
+
+1.4 Configuring pci-epf-test Device
+
+The user can configure the pci-epf-test device using configfs entry. In order
+to change the vendorid and the number of MSI interrupts used by the function
+device, the following commands can be used.
+
+   # echo 0x104c > dev/epf/pci_epf_test.0/vendorid
+   # echo 0xb500 > dev/epf/pci_epf_test.0/deviceid
+   # echo 16 >  dev/epf/pci_epf_test.0/msi_interrupts
+
+1.5 Binding pci-epf-test Device to EP Controller
+
+In order for the endpoint function device to be useful, it has to be bound to
+a PCI endpoint controller driver. Use the configfs to bind the function
+device to one of the controller driver present in the system.
+
+   # echo "5100.pcie_ep" > dev/epc
+
+Once the above step is completed, the PCI endpoint is ready to establish a link
+with the host.
+
+2. Endpoint Device
+
+2.1 lspci Output
+
+Note that the devices listed here correspond to the value populated in 1.4 
above
+
+   00:00.0 PCI bridge: Texas Instruments Device  (rev 01)
+   01:00.0 Unassigned class [ff00]: Texas Instruments Device b500
+
+2.2 Using Endpoint Test function Device
+
+pcitest.sh added in tools/pci/ can be used to run all the default PCI endpoint
+tests. Before pcitest.sh can be used pcitest.c should be compiled using the
+following commands.
+
+   cd 
+   make headers_install ARCH=arm
+   arm-linux-gnueabihf-gcc -Iusr/include tools/pci/pcitest.c -o pcitest
+   cp pcitest  /usr/sbin/
+   cp tools/pci/pcitest.sh 
+
+2.2.1 pcitest.sh Output
+   # ./pcitest.sh
+   BAR tests
+
+   BAR0:   OKAY
+   BAR1:   OKAY
+   BAR2:   OKAY
+   BAR3:   OKAY
+   BAR4:   NOT OKAY
+   BAR5:   NOT OKAY
+
+   Interrupt tests
+
+   LEGACY IRQ: NOT OKAY
+   MSI1:   OKAY
+   MSI2:   OKAY
+   MSI3:   OKAY
+   MSI4:   OKAY
+   MSI5:   OKAY
+   MSI6:   OKAY
+   MSI7:   OKAY
+   MSI8:   OKAY
+   MSI9:   OKAY
+   MSI10:  OKAY
+   MSI11:  OKAY
+   MSI12:  OKAY
+   MSI13:  OKAY
+   MSI14:  OKAY
+   MSI15:  OKAY
+   MSI16:  OKAY
+   MSI17:  NOT OKAY
+   MSI18:  NOT OKAY
+   MSI19:  NOT OKAY
+   MSI20:  NOT OKAY
+   MSI21:  NOT OKAY
+   MSI22:  

[PATCH v5 0/3] input: pwm-beeper: add feature to set volume level

[Frieder Schrempf]

Make the driver accept switching volume levels via sysfs.
This can be helpful if the beep/bell sound intensity needs
to be adapted to the environment of the device.

The number of volume levels available and their values can
be specified via device tree (similar to pwm-backlight).

The volume adjustment is done by changing the duty cycle of
the pwm signal.

Changes in v5:
 - fix renaming of max_volume_level to max_volume
 - remove needless variable declaration

Frieder Schrempf (3):
  input: pwm-beeper: add feature to set volume via sysfs
  input: pwm-beeper: add documentation for volume devicetree bindings
  input: pwm-beeper: add devicetree bindings to set volume levels

 Documentation/ABI/testing/sysfs-devices-pwm-beeper |  17 
 .../devicetree/bindings/input/pwm-beeper.txt   |  20 
 drivers/input/misc/pwm-beeper.c| 110 -
 3 files changed, 145 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-pwm-beeper

-- 
2.7.4

Re: [PATCH 1/5] KVM: change API for requests to match bit operations

[Cornelia Huck]

On Fri, 17 Feb 2017 10:49:35 +0100
Andrew Jones  wrote:

> On Fri, Feb 17, 2017 at 10:30:14AM +0100, Cornelia Huck wrote:
> > On Thu, 16 Feb 2017 17:04:45 +0100
> > Radim Krčmář  wrote:
> > > +static inline void kvm_request_set(unsigned req, struct kvm_vcpu *vcpu)
> > 
> > Should we make req unsigned long as well, so that it matches the bit
> > api even more?
> 
> The bitops API is inconsistent among architectures; some are int, some
> are unsigned int, some are unsigned long, and x86 is long. If we want
> to be consistent with something, then, IMO, we should be consistent with
> asm-generic/bitops, which is int, but actually unsigned makes more sense
> to me...

Inconsistent interfaces are great :/

Having (any) unsigned value makes the most sense to me as well.

[PATCH v2 19/22] tools: PCI: Add sample test script to invoke pcitest

[Kishon Vijay Abraham I]

Add a simple test script that invokes the pcitest userspace tool
to perform all the PCI endpoint tests (BAR tests, interrupt tests,
read tests, write tests and copy tests).

Signed-off-by: Kishon Vijay Abraham I 
---
 tools/pci/pcitest.sh |   56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 tools/pci/pcitest.sh

diff --git a/tools/pci/pcitest.sh b/tools/pci/pcitest.sh
new file mode 100644
index 000..5442bbe
--- /dev/null
+++ b/tools/pci/pcitest.sh
@@ -0,0 +1,56 @@
+#!/bin/sh
+
+echo "BAR tests"
+echo
+
+bar=0
+
+while [ $bar -lt 6 ]
+do
+   pcitest -b $bar
+   bar=`expr $bar + 1`
+done
+echo
+
+echo "Interrupt tests"
+echo
+
+pcitest -l
+msi=1
+
+while [ $msi -lt 33 ]
+do
+pcitest -m $msi
+msi=`expr $msi + 1`
+done
+echo
+
+echo "Read Tests"
+echo
+
+pcitest -r -s 1
+pcitest -r -s 1024
+pcitest -r -s 1025
+pcitest -r -s 1024000
+pcitest -r -s 1024001
+echo
+
+echo "Write Tests"
+echo
+
+pcitest -w -s 1
+pcitest -w -s 1024
+pcitest -w -s 1025
+pcitest -w -s 1024000
+pcitest -w -s 1024001
+echo
+
+echo "Copy Tests"
+echo
+
+pcitest -c -s 1
+pcitest -c -s 1024
+pcitest -c -s 1025
+pcitest -c -s 1024000
+pcitest -c -s 1024001
+echo
-- 
1.7.9.5

[PATCH v2 08/22] PCI: dwc: designware: Add EP mode support

[Kishon Vijay Abraham I]

Add endpoint mode support to designware driver. This uses the
EP Core layer introduced recently to add endpoint mode support.
*Any* function driver can now use this designware device
in order to achieve the EP functionality.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/dwc/Kconfig  |5 +
 drivers/pci/dwc/Makefile |1 +
 drivers/pci/dwc/pcie-designware-ep.c |  342 ++
 drivers/pci/dwc/pcie-designware.c|   51 +
 drivers/pci/dwc/pcie-designware.h|   72 +++
 5 files changed, 471 insertions(+)
 create mode 100644 drivers/pci/dwc/pcie-designware-ep.c

diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
index dfb8a69..00335c7 100644
--- a/drivers/pci/dwc/Kconfig
+++ b/drivers/pci/dwc/Kconfig
@@ -9,6 +9,11 @@ config PCIE_DW_HOST
depends on PCI_MSI_IRQ_DOMAIN
 select PCIE_DW
 
+config PCIE_DW_EP
+   bool
+   depends on PCI_ENDPOINT
+   select PCIE_DW
+
 config PCI_DRA7XX
bool "TI DRA7xx PCIe controller"
depends on PCI
diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
index a2df13c..b38425d 100644
--- a/drivers/pci/dwc/Makefile
+++ b/drivers/pci/dwc/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_PCIE_DW) += pcie-designware.o
 obj-$(CONFIG_PCIE_DW_HOST) += pcie-designware-host.o
+obj-$(CONFIG_PCIE_DW_EP) += pcie-designware-ep.o
 obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
 obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
 obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
b/drivers/pci/dwc/pcie-designware-ep.c
new file mode 100644
index 000..e465c5e
--- /dev/null
+++ b/drivers/pci/dwc/pcie-designware-ep.c
@@ -0,0 +1,342 @@
+/**
+ * Synopsys Designware PCIe Endpoint controller driver
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+
+#include "pcie-designware.h"
+#include 
+#include 
+
+void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
+{
+   struct pci_epc *epc = ep->epc;
+   struct pci_epf *epf;
+
+   list_for_each_entry(epf, &epc->pci_epf, list)
+   pci_epf_linkup(epf);
+}
+
+static void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)
+{
+   u32 reg;
+
+   reg = PCI_BASE_ADDRESS_0 + (4 * bar);
+   dw_pcie_write_dbi(pci, pci->dbi_base2, reg, 0x4, 0x0);
+   dw_pcie_write_dbi(pci, pci->dbi_base, reg, 0x4, 0x0);
+}
+
+static int dw_pcie_ep_write_header(struct pci_epc *epc,
+  struct pci_epf_header *hdr)
+{
+   struct dw_pcie_ep *ep = epc_get_drvdata(epc);
+   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+   void __iomem *base = pci->dbi_base;
+
+   dw_pcie_write_dbi(pci, base, PCI_VENDOR_ID, 0x2, hdr->vendorid);
+   dw_pcie_write_dbi(pci, base, PCI_DEVICE_ID, 0x2, hdr->deviceid);
+   dw_pcie_write_dbi(pci, base, PCI_REVISION_ID, 0x1, hdr->revid);
+   dw_pcie_write_dbi(pci, base, PCI_CLASS_PROG, 0x1, hdr->progif_code);
+   dw_pcie_write_dbi(pci, base, PCI_CLASS_DEVICE, 0x2,
+ hdr->subclass_code | hdr->baseclass_code << 8);
+   dw_pcie_write_dbi(pci, base, PCI_CACHE_LINE_SIZE, 0x1,
+ hdr->cache_line_size);
+   dw_pcie_write_dbi(pci, base, PCI_SUBSYSTEM_VENDOR_ID, 0x2,
+ hdr->subsys_vendor_id);
+   dw_pcie_write_dbi(pci, base, PCI_SUBSYSTEM_ID, 0x2, hdr->subsys_id);
+   dw_pcie_write_dbi(pci, base, PCI_INTERRUPT_PIN, 0x1,
+ hdr->interrupt_pin);
+
+   return 0;
+}
+
+static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum pci_barno bar,
+ dma_addr_t cpu_addr,
+ enum dw_pcie_as_type as_type)
+{
+   int ret;
+   u32 free_win;
+   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+
+   free_win = find_first_zero_bit(&ep->ib_window_map,
+  sizeof(ep->ib_window_map));
+   if (free_win >= ep->num_ib_windows) {
+   dev_err(pci->dev, "no free inbound window\n");
+   return -EINVAL;
+   }
+
+   ret = dw_pcie_prog_inbound_atu(pci, free_win, bar, cpu_addr,
+  as_type);
+   if (ret < 0) {
+   dev_err(pci->dev, "Failed to program IB window\n");
+   retu

[PATCH v2 18/22] tools: PCI: Add a userspace tool to test PCI endpoint

[Kishon Vijay Abraham I]

Add a userspace tool to invoke the ioctls exposed by the
PCI endpoint test driver to perform various PCI tests.

Signed-off-by: Kishon Vijay Abraham I 
---
 tools/pci/pcitest.c |  186 +++
 1 file changed, 186 insertions(+)
 create mode 100644 tools/pci/pcitest.c

diff --git a/tools/pci/pcitest.c b/tools/pci/pcitest.c
new file mode 100644
index 000..39b5b0b
--- /dev/null
+++ b/tools/pci/pcitest.c
@@ -0,0 +1,186 @@
+/**
+ * Userspace PCI Endpoint Test Module
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define BILLION 1E9
+
+static char *result[] = { "NOT OKAY", "OKAY" };
+
+struct pci_test {
+   char*device;
+   charbarnum;
+   boollegacyirq;
+   unsigned intmsinum;
+   boolread;
+   boolwrite;
+   boolcopy;
+   unsigned long   size;
+};
+
+static int run_test(struct pci_test *test)
+{
+   long ret;
+   int fd;
+   struct timespec start, end;
+   double time;
+
+   fd = open(test->device, O_RDWR);
+   if (fd < 0) {
+   perror("can't open PCI Endpoint Test device");
+   return fd;
+   }
+
+   if (test->barnum >= 0 && test->barnum <= 5) {
+   ret = ioctl(fd, PCITEST_BAR, test->barnum);
+   fprintf(stdout, "BAR%d:\t\t", test->barnum);
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   if (test->legacyirq) {
+   ret = ioctl(fd, PCITEST_LEGACY_IRQ, 0);
+   fprintf(stdout, "LEGACY IRQ:\t");
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   if (test->msinum > 0 && test->msinum <= 32) {
+   ret = ioctl(fd, PCITEST_MSI, test->msinum);
+   fprintf(stdout, "MSI%d:\t\t", test->msinum);
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   if (test->write) {
+   ret = ioctl(fd, PCITEST_WRITE, test->size);
+   fprintf(stdout, "WRITE (%7ld bytes):\t\t", test->size);
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   if (test->read) {
+   ret = ioctl(fd, PCITEST_READ, test->size);
+   fprintf(stdout, "READ (%7ld bytes):\t\t", test->size);
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   if (test->copy) {
+   ret = ioctl(fd, PCITEST_COPY, test->size);
+   fprintf(stdout, "COPY (%7ld bytes):\t\t", test->size);
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   fflush(stdout);
+}
+
+int main(int argc, char **argv)
+{
+   int c;
+   struct pci_test *test;
+
+   test = calloc(1, sizeof(*test));
+   if (!test) {
+   perror("Fail to allocate memory for pci_test\n");
+   return -ENOMEM;
+   }
+
+   /* since '0' is a valid BAR number, initialize it to -1 */
+   test->barnum = -1;
+
+   /* set default size as 100KB */
+   test->size = 0x19000;
+
+   /* set default endpoint device */
+   test->device = "/dev/pci-endpoint-test.0";
+
+   while ((c = getopt(argc, argv, "D:b:m:lrwcs:")) != EOF)
+   switch (c) {
+   case 'D':
+   test->device = optarg;
+   continue;
+   case 'b':
+   test->barnum = atoi(optarg);
+   if (test->barnum < 0 || test->barnum > 5)
+   goto usage;
+   continue;
+   case 'l':
+   test->legacyirq = true;
+   cont

[PATCH v5 1/3] input: pwm-beeper: add feature to set volume via sysfs

[Frieder Schrempf]

Make the driver accept switching volume levels via sysfs.
This can be helpful if the beep/bell sound intensity needs
to be adapted to the environment of the device.

The volume adjustment is done by changing the duty cycle of
the pwm signal.

This patch adds the sysfs interface with 5 default volume
levels (0 - mute, 4 - max. volume).

Signed-off-by: Frieder Schrempf 
---
Changes in v5:
 - none

 Documentation/ABI/testing/sysfs-devices-pwm-beeper | 17 +
 drivers/input/misc/pwm-beeper.c| 84 +-
 2 files changed, 100 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-pwm-beeper

diff --git a/Documentation/ABI/testing/sysfs-devices-pwm-beeper 
b/Documentation/ABI/testing/sysfs-devices-pwm-beeper
new file mode 100644
index 000..d068c58
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-pwm-beeper
@@ -0,0 +1,17 @@
+What:  /sys/devices/.../pwm-beeper/volume
+Date:  February 2017
+KernelVersion:
+Contact:   Frieder Schrempf 
+Description:
+   Control the volume of this pwm-beeper. Values
+   are between 0 and max_volume. This file will also
+   show the current volume level stored in the driver.
+
+What:  /sys/devices/.../pwm-beeper/max_volume
+Date:  February 2017
+KernelVersion:
+Contact:   Frieder Schrempf 
+Description:
+   This file shows the maximum volume level that can be
+   assigned to volume.
+
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 5f9655d..5fbc198 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -1,5 +1,9 @@
 /*
  *  Copyright (C) 2010, Lars-Peter Clausen 
+ *
+ *  Copyright (C) 2016, Frieder Schrempf 
+ *  (volume support)
+ *
  *  PWM beeper driver
  *
  *  This program is free software; you can redistribute it and/or modify it
@@ -27,16 +31,69 @@ struct pwm_beeper {
struct pwm_device *pwm;
struct work_struct work;
unsigned long period;
+   unsigned int volume;
+   unsigned int *volume_levels;
+   unsigned int max_volume;
 };
 
 #define HZ_TO_NANOSECONDS(x) (10UL/(x))
 
+static ssize_t beeper_show_volume(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct pwm_beeper *beeper = dev_get_drvdata(dev);
+
+   return sprintf(buf, "%d\n", beeper->volume);
+}
+
+static ssize_t beeper_show_max_volume(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct pwm_beeper *beeper = dev_get_drvdata(dev);
+
+   return sprintf(buf, "%d\n", beeper->max_volume);
+}
+
+static ssize_t beeper_store_volume(struct device *dev,
+   struct device_attribute *attr, const char *buf, size_t count)
+{
+   int rc;
+   struct pwm_beeper *beeper = dev_get_drvdata(dev);
+   unsigned int volume;
+
+   rc = kstrtouint(buf, 0, &volume);
+   if (rc)
+   return rc;
+
+   if (volume > beeper->max_volume)
+   return -EINVAL;
+   pr_debug("set volume to %u\n", volume);
+   beeper->volume = volume;
+
+   return count;
+}
+
+static DEVICE_ATTR(volume, 0644, beeper_show_volume, beeper_store_volume);
+static DEVICE_ATTR(max_volume, 0644, beeper_show_max_volume, NULL);
+
+static struct attribute *pwm_beeper_attributes[] = {
+   &dev_attr_volume.attr,
+   &dev_attr_max_volume.attr,
+   NULL,
+};
+
+static struct attribute_group pwm_beeper_attribute_group = {
+   .attrs = pwm_beeper_attributes,
+};
+
 static void __pwm_beeper_set(struct pwm_beeper *beeper)
 {
unsigned long period = beeper->period;
 
if (period) {
-   pwm_config(beeper->pwm, period / 2, period);
+   pwm_config(beeper->pwm,
+   period / 1000 * beeper->volume_levels[beeper->volume],
+   period);
pwm_enable(beeper->pwm);
} else
pwm_disable(beeper->pwm);
@@ -98,6 +155,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
unsigned long pwm_id = (unsigned long)dev_get_platdata(&pdev->dev);
struct pwm_beeper *beeper;
int error;
+   size_t size;
 
beeper = kzalloc(sizeof(*beeper), GFP_KERNEL);
if (!beeper)
@@ -123,6 +181,24 @@ static int pwm_beeper_probe(struct platform_device *pdev)
 
INIT_WORK(&beeper->work, pwm_beeper_work);
 
+   beeper->max_volume = 4;
+
+   size = sizeof(*beeper->volume_levels) *
+   (beeper->max_volume + 1);
+
+   beeper->volume_levels = devm_kzalloc(&(pdev->dev), size,
+   GFP_KERNEL);
+   if (!beeper->volume_levels)
+   return -ENOMEM;
+
+   beeper->volume_levels[0] = 0;
+   beeper->volume_levels[1] = 8;
+   beeper->volume_levels[2] = 20;
+   beeper->volume_levels[3] = 40;
+   beeper->volume_levels[4] = 500;
+
+   beeper->

[PATCH v5 2/3] input: pwm-beeper: add documentation for volume devicetree bindings

[Frieder Schrempf]

This patch adds the documentation for the devicetree bindings to set
the volume levels.

Signed-off-by: Frieder Schrempf 
Acked-by: Rob Herring 
---
Changes in v5:
 - none

 .../devicetree/bindings/input/pwm-beeper.txt | 20 
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..496b68f 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,23 @@ Registers a PWM device as beeper.
 Required properties:
 - compatible: should be "pwm-beeper"
 - pwms: phandle to the physical PWM device
+
+Optional properties:
+- volume-levels: Array of PWM duty cycle values that correspond to
+  linear volume levels. These need to be in the range of 0 to 500,
+  while 0 means 0% duty cycle (mute) and 500 means 50% duty cycle
+  (max volume).
+  Please note that the actual volume of most beepers is highly
+  non-linear, which means that low volume levels are probably somewhere
+  in the range of 1 to 30 (0.1-3% duty cycle).
+- default-volume-level: the default volume level (index into the
+  array defined by the "volume-levels" property)
+
+Example:
+
+   pwm-beeper {
+   compatible = "pwm-beeper";
+   pwms = <&pwm4 0 5000>;
+   volume-levels = <0 8 20 40 500>;
+   default-volume-level = <4>;
+   };
-- 
2.7.4