Re: [linux-sunxi] [PATCH 02/11] arm64: allwinner: a64: add NMI controller on A64

[Chen-Yu Tsai]

On Wed, Apr 5, 2017 at 2:11 PM, Maxime Ripard
 wrote:
> On Wed, Apr 05, 2017 at 11:51:45AM +0800, Chen-Yu Tsai wrote:
>> On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng  wrote:
>> > Allwinner A64 SoC features a NMI controller, which is usually connected
>> > to the AXP PMIC.
>> >
>> > Add support for it.
>> >
>> > Signed-off-by: Icenowy Zheng 
>>
>> This might not be the best representation of the R_INTC block. Though
>> we'd need to change it for all SoCs if we want to be accurate. For now,
>
> What do you think would be a good representation?

My gut feeling is that this is the old INTC from sun4/5i. It's supposed
to be the interrupt controller for the embedded low power core. I've not
done a thorough comparison though.

ChenYu

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Christoph Hellwig]

On Wed, Apr 05, 2017 at 06:24:50AM +0200, Mike Galbraith wrote:
> On Wed, 2017-04-05 at 06:51 +0300, Michael S. Tsirkin wrote:
> 
> > Any issues at all left with this tree?
> > In particular any regressions?
> 
> Nothing blatantly obvious in a testdrive that lasted a couple minutes. 
>  I'd have to beat on it a bit to look for things beyond the reported,
> but can't afford to do that right now.

Can you check where the issues appear?  I'd like to do a pure revert
of the shared interrupts, but that three has a lot more in it..

Re: [PATCH v6 02/11] powerpc/powernv: Autoload IMC device driver module

[Madhavan Srinivasan]

On Tuesday 04 April 2017 06:28 AM, Daniel Axtens wrote:

Hi all,

I'm trying to get my head around these patches - at this point I'm just
doing a first pass, so I may have more substantive structural comments
later on. In the mean time - here are some minor C nits:


+ * Copyright   (C) 2016 Madhavan Srinivasan, IBM Corporation.
+ * (C) 2016 Hemant K Shaw, IBM Corporation.

Should these be bumped to 2017?


Facepalm. my bad. Will fix it.

+
+   do {
+   pages = PAGE_SIZE * i;
+   pcni->vbase[i++] = (u64)phys_to_virt(pcni->pbase +
+pages);
+   } while (i < (pcni->size / PAGE_SIZE));
+   }

I had to scroll back up to the top of this function to make sure I
understood what this loop does. Would it be better to write it as:

for (i = 0; i < (pcni->size / PAGE_SIZE); i++) {
 pages = PAGE_SIZE * i;
 pcni->vbase[i] = (u64)
}

Idea is to map all of the nest counter area since event
offset could be anywhere within this region.
Will document that here.



And, just checking - this is expected to work on both 4 and 64kB pages?

Yes. thats the intended. That said, i need to fix the
IMC_NEST_MAX_PAGES value for 4K page size.
Reason being, there was a recent change in the
size of memory allocated for nest counters in the
HOMER region for the microcode.




+
+   return 0;
+err:
+   return -ENODEV;

You're not releasing any resources here - would it be better to just
replace the gotos with this return? I haven't checked to see if you
change the function later on to allocate memory - if so please ignore :)


We check in multiple places in the function and return on fail.
Thats why we made it as a generic return with goto.



+}
+
+static const struct of_device_id opal_imc_match[] = {
+   { .compatible = IMC_DTB_COMPAT },
+   {},
+};
+
+static struct platform_driver opal_imc_driver = {
+   .driver = {
+   .name = "opal-imc-counters",
+   .of_match_table = opal_imc_match,
+   },
+   .probe = opal_imc_counters_probe,
+};
+
+MODULE_DEVICE_TABLE(of, opal_imc_match);
+module_platform_driver(opal_imc_driver);
+MODULE_DESCRIPTION("PowerNV OPAL IMC driver");
+MODULE_LICENSE("GPL");
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index e0f856bfbfe8..85ea1296f030 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -30,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "powernv.h"
  
@@ -631,6 +633,15 @@ static void opal_pdev_init(const char *compatible)

of_platform_device_create(np, NULL, NULL);
  }
  
+static void opal_imc_init_dev(void)

+{
+   struct device_node *np;
+
+   np = of_find_compatible_node(NULL, NULL, IMC_DTB_COMPAT);
+   if (np)
+   of_platform_device_create(np, NULL, NULL);
+}

Should this function be tagged __init?


Yes. Thats right. Will make the changes.

Thanks for review
Maddy




+
  static int kopald(void *unused)
  {
unsigned long timeout = msecs_to_jiffies(opal_heartbeat) + 1;
@@ -704,6 +715,9 @@ static int __init opal_init(void)
/* Setup a heatbeat thread if requested by OPAL */
opal_init_heartbeat();
  
+	/* Detect IMC pmu counters support and create PMUs */

+   opal_imc_init_dev();
+
/* Create leds platform devices */
leds = of_find_node_by_path("/ibm,opal/leds");
if (leds) {
--
2.7.4

Re: [PATCH 3/9] bio-integrity: bio_integrity_advance must update integrity seed

[Hannes Reinecke]

On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> SCSI drivers do care about bip_seed so we must update it accordingly.
> 
> Signed-off-by: Dmitry Monakhov 
> ---
>  block/bio-integrity.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/block/bio-integrity.c b/block/bio-integrity.c
> index b5009a8..82a6ffb 100644
> --- a/block/bio-integrity.c
> +++ b/block/bio-integrity.c
> @@ -425,6 +425,7 @@ void bio_integrity_advance(struct bio *bio, unsigned int 
> bytes_done)
>   struct blk_integrity *bi = bdev_get_integrity(bio->bi_bdev);
>   unsigned bytes = bio_integrity_bytes(bi, bytes_done >> 9);
>  
> + bip->bip_iter.bi_sector += bytes_done >> 9;
>   bvec_iter_advance(bip->bip_vec, >bip_iter, bytes);
>  }
>  EXPORT_SYMBOL(bio_integrity_advance);
> 
Odd that we've missed that one...

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 7/9] Guard bvec iteration logic v3

[Hannes Reinecke]

On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> Currently if some one try to advance bvec beyond it's size we simply
> dump WARN_ONCE and continue to iterate beyond bvec array boundaries.
> This simply means that we endup dereferencing/corrupting random memory
> region.
> 
> Sane reaction would be to propagate error back to calling context
> But bvec_iter_advance's calling context is not always good for error
> handling. For safity reason let truncate iterator size to zero which
> will break external iteration loop which prevent us from unpredictable
> memory range corruption. And even it caller ignores an error, it will
> corrupt it's own bvecs, not others.
> 
> This patch does:
> - Return error back to caller with hope that it will react on this
> - Truncate iterator size
> 
> Code was added long time ago here 4550dd6c, luckily no one hit it
> in real life :)
> 
> changes since V1:
>  - Replace  BUG_ON with error logic.
> 
> Signed-off-by: Dmitry Monakhov 
> ---
>  drivers/nvdimm/blk.c |  4 +++-
>  drivers/nvdimm/btt.c |  4 +++-
>  include/linux/bio.h  |  8 ++--
>  include/linux/bvec.h | 11 ---
>  4 files changed, 20 insertions(+), 7 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

[PATCH v2 04/11] platform/x86: fujitsu-laptop: simplify set_lcd_level()

[Michał Kępień]

acpi_execute_simple_method() takes a method parameter which tells it to
look for the given method underneath the given handle, so calling
acpi_get_handle() beforehand is redundant.  Replace the call to
acpi_get_handle() with a call to acpi_execute_simple_method(), thus
eliminating the need for a local variable storing the handle.  Update
debug message to reflect this change.  Also do not assign a default
value to status as it has no influence on execution flow.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index 2f563aa00592..6d4a2a36716b 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -358,8 +358,7 @@ static enum led_brightness eco_led_get(struct led_classdev 
*cdev)
 
 static int set_lcd_level(int level)
 {
-   acpi_status status = AE_OK;
-   acpi_handle handle = NULL;
+   acpi_status status;
char *method;
 
switch (use_alt_lcd_levels) {
@@ -377,16 +376,14 @@ static int set_lcd_level(int level)
if (level < 0 || level >= fujitsu_bl->max_brightness)
return -EINVAL;
 
-   status = acpi_get_handle(fujitsu_bl->acpi_handle, method, );
+   status = acpi_execute_simple_method(fujitsu_bl->acpi_handle, method,
+   level);
if (ACPI_FAILURE(status)) {
-   vdbg_printk(FUJLAPTOP_DBG_ERROR, "%s not present\n", method);
+   vdbg_printk(FUJLAPTOP_DBG_ERROR, "Failed to evaluate %s\n",
+   method);
return -ENODEV;
}
 
-   status = acpi_execute_simple_method(handle, NULL, level);
-   if (ACPI_FAILURE(status))
-   return -ENODEV;
-
return 0;
 }
 
-- 
2.12.2

[PATCH v2 05/11] platform/x86: fujitsu-laptop: sync brightness in set_lcd_level()

[Michał Kępień]

When using brightness keys and backlight device's sysfs interface
alternately, an incorrect input event might be generated for a
brightness key press.  Consider the following sequence of events:

 1. Set backlight brightness to 6 using brightness keys.
 2. Write 4 to /sys/class/backlight/fujitsu-laptop/brightness.
 3. Press the "brightness up" key.

The input event generated in this scenario would be KEY_BRIGHTNESSDOWN,
because before step 3 brightness_level would still be at 6.  As the new
brightness level is established using GBLL, it would evaluate to 5
(SBLL/SBL2 sets it to 4 in step 2 and pressing the "brightness up" key
increases it by 1).  This in turn would cause acpi_fujitsu_bl_notify()
to observe a 6 -> 5 change, i.e. a decrease in brightness, while screen
brightness would in fact be increased.

Fix this by updating brightness_level in set_lcd_level.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index 6d4a2a36716b..b019060d6dc4 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -384,6 +384,8 @@ static int set_lcd_level(int level)
return -ENODEV;
}
 
+   fujitsu_bl->brightness_level = level;
+
return 0;
 }
 
-- 
2.12.2

[PATCH v2 03/11] platform/x86: fujitsu-laptop: merge set_lcd_level_alt() into set_lcd_level()

[Michał Kępień]

Depending on the value of the use_alt_lcd_levels module parameter, one
of two functions is used for setting LCD brightness level.  These
functions are almost identical and only differ in the name of the ACPI
method they call.  Instead of checking the value of use_alt_lcd_levels
at each call site, move that check to set_lcd_level() and get rid of
set_lcd_level_alt().

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 54 +++
 1 file changed, 16 insertions(+), 38 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index 59107a599d22..2f563aa00592 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -360,41 +360,26 @@ static int set_lcd_level(int level)
 {
acpi_status status = AE_OK;
acpi_handle handle = NULL;
-
-   vdbg_printk(FUJLAPTOP_DBG_TRACE, "set lcd level via SBLL [%d]\n",
-   level);
-
-   if (level < 0 || level >= fujitsu_bl->max_brightness)
-   return -EINVAL;
-
-   status = acpi_get_handle(fujitsu_bl->acpi_handle, "SBLL", );
-   if (ACPI_FAILURE(status)) {
-   vdbg_printk(FUJLAPTOP_DBG_ERROR, "SBLL not present\n");
-   return -ENODEV;
+   char *method;
+
+   switch (use_alt_lcd_levels) {
+   case 1:
+   method = "SBL2";
+   break;
+   default:
+   method = "SBLL";
+   break;
}
 
-
-   status = acpi_execute_simple_method(handle, NULL, level);
-   if (ACPI_FAILURE(status))
-   return -ENODEV;
-
-   return 0;
-}
-
-static int set_lcd_level_alt(int level)
-{
-   acpi_status status = AE_OK;
-   acpi_handle handle = NULL;
-
-   vdbg_printk(FUJLAPTOP_DBG_TRACE, "set lcd level via SBL2 [%d]\n",
-   level);
+   vdbg_printk(FUJLAPTOP_DBG_TRACE, "set lcd level via %s [%d]\n",
+   method, level);
 
if (level < 0 || level >= fujitsu_bl->max_brightness)
return -EINVAL;
 
-   status = acpi_get_handle(fujitsu_bl->acpi_handle, "SBL2", );
+   status = acpi_get_handle(fujitsu_bl->acpi_handle, method, );
if (ACPI_FAILURE(status)) {
-   vdbg_printk(FUJLAPTOP_DBG_ERROR, "SBL2 not present\n");
+   vdbg_printk(FUJLAPTOP_DBG_ERROR, "%s not present\n", method);
return -ENODEV;
}
 
@@ -463,10 +448,7 @@ static int bl_update_status(struct backlight_device *b)
"Unable to adjust backlight power, error code %i\n",
ret);
 
-   if (use_alt_lcd_levels)
-   ret = set_lcd_level_alt(b->props.brightness);
-   else
-   ret = set_lcd_level(b->props.brightness);
+   ret = set_lcd_level(b->props.brightness);
if (ret != 0)
vdbg_printk(FUJLAPTOP_DBG_ERROR,
"Unable to adjust LCD brightness, error code %i\n",
@@ -679,12 +661,8 @@ static void acpi_fujitsu_bl_notify(struct acpi_device 
*device, u32 event)
if (oldb == newb)
return;
 
-   if (disable_brightness_adjust != 1) {
-   if (use_alt_lcd_levels)
-   set_lcd_level_alt(newb);
-   else
-   set_lcd_level(newb);
-   }
+   if (disable_brightness_adjust != 1)
+   set_lcd_level(newb);
 
sparse_keymap_report_event(input, oldb < newb, 1, true);
 }
-- 
2.12.2

[PATCH v2 02/11] platform/x86: fujitsu-laptop: switch to a managed backlight device

[Michał Kępień]

Use a managed backlight device to get rid of acpi_fujitsu_bl_remove().
Change the parent of the backlight device from NULL to the FUJ02B1 ACPI
device as the latter is required for the backlight device to work.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 23 ++-
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index 722250d1aa20..59107a599d22 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -565,17 +565,18 @@ static int acpi_fujitsu_bl_input_setup(struct acpi_device 
*device)
return input_register_device(fujitsu_bl->input);
 }
 
-static int fujitsu_backlight_register(void)
+static int fujitsu_backlight_register(struct acpi_device *device)
 {
-   struct backlight_properties props = {
+   const struct backlight_properties props = {
.brightness = fujitsu_bl->brightness_level,
.max_brightness = fujitsu_bl->max_brightness - 1,
.type = BACKLIGHT_PLATFORM
};
struct backlight_device *bd;
 
-   bd = backlight_device_register("fujitsu-laptop", NULL, NULL,
-  _bl_ops, );
+   bd = devm_backlight_device_register(>dev, "fujitsu-laptop",
+   >dev, NULL,
+   _bl_ops, );
if (IS_ERR(bd))
return PTR_ERR(bd);
 
@@ -644,24 +645,13 @@ static int acpi_fujitsu_bl_add(struct acpi_device *device)
fujitsu_bl->max_brightness = FUJITSU_LCD_N_LEVELS;
get_lcd_level();
 
-   error = fujitsu_backlight_register();
+   error = fujitsu_backlight_register(device);
if (error)
return error;
 
return 0;
 }
 
-static int acpi_fujitsu_bl_remove(struct acpi_device *device)
-{
-   struct fujitsu_bl *fujitsu_bl = acpi_driver_data(device);
-
-   backlight_device_unregister(fujitsu_bl->bl_device);
-
-   fujitsu_bl->acpi_handle = NULL;
-
-   return 0;
-}
-
 /* Brightness notify */
 
 static void acpi_fujitsu_bl_notify(struct acpi_device *device, u32 event)
@@ -1092,7 +1082,6 @@ static struct acpi_driver acpi_fujitsu_bl_driver = {
.ids = fujitsu_bl_device_ids,
.ops = {
.add = acpi_fujitsu_bl_add,
-   .remove = acpi_fujitsu_bl_remove,
.notify = acpi_fujitsu_bl_notify,
},
 };
-- 
2.12.2

[PATCH v2 01/11] platform/x86: fujitsu-laptop: only handle backlight when appropriate

[Michał Kępień]

The backlight part of fujitsu-laptop is only used by laptops which are
incapable of using the standard ACPI video interface for handling
brightness changes.  Conversely, on laptops which are capable of using
the latter, no vendor-specific ACPI calls should be made unless
explicitly requested by the user.  Bail out immediately from
acpi_fujitsu_bl_add() unless using the vendor-specific interface was
either explicitly requested by the user or automatically selected by the
kernel.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index f66da4b0c31a..722250d1aa20 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -589,6 +589,9 @@ static int acpi_fujitsu_bl_add(struct acpi_device *device)
int state = 0;
int error;
 
+   if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
+   return -ENODEV;
+
if (!device)
return -EINVAL;
 
@@ -641,11 +644,9 @@ static int acpi_fujitsu_bl_add(struct acpi_device *device)
fujitsu_bl->max_brightness = FUJITSU_LCD_N_LEVELS;
get_lcd_level();
 
-   if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
-   error = fujitsu_backlight_register();
-   if (error)
-   return error;
-   }
+   error = fujitsu_backlight_register();
+   if (error)
+   return error;
 
return 0;
 }
-- 
2.12.2

Re: question about concurrent regmap i2c usage

[Michael Hennerich]

On 04.04.2017 14:26, Mark Brown wrote:

On Tue, Apr 04, 2017 at 10:28:23AM +0200, Michael Hennerich wrote:


A question came up, regarding whether it's recommended to mix regmap_i2c and
plain i2c_smbus or direct adapter transfers.



In this specific case for the i2c MUX portion we need to avoid double locks,
and therefore use un-locked direct adapter transfers.



The same time we also implement a small gpiochip, where we would like to use
regmap to avoid some boilerplate code for the register cache.


That should work fine providing nothing tries to change cached registers
underneath the regmap.  regmap won't be able to tell anything's changed
otherwise.


Hi Mark,

Thanks for confirmation!

--
Greetings,
Michael

--
Analog Devices GmbH  Otl-Aicher Strasse 60-64  80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne

Re: [PATCH 8/9] bio: add bvec_iter rewind API

[Hannes Reinecke]

On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> Some ->bi_end_io handlers (for example: pi_verify or decrypt handlers)
> need to know original data vector, but after bio traverse io-stack it may
> be advanced, splited and relocated many times so it is hard to guess
> original iterator. Let's add 'bi_done' conter which accounts number
> of bytes iterator was advanced during it's evolution. Later end_io handler
> may easily restore original iterator by rewinding iterator to
> iter->bi_done.
> 
> Note: this change makes sizeof (struct bvec_iter) multiple to 8
> Signed-off-by: Dmitry Monakhov 
> ---
>  include/linux/bio.h  | 21 +++--
>  include/linux/bvec.h | 26 ++
>  2 files changed, 45 insertions(+), 2 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 9/9] bio-integrity: Restore original iterator on verify stage

[Hannes Reinecke]

On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> Currently ->verify_fn not woks at all because at the moment it is called
> bio->bi_iter.bi_size == 0, so we do not iterate integrity bvecs at all.
> 
> In order to perform verification we need to know original data vector,
> with new bvec rewind API this is trivial.
> 
> testcase: 
> https://github.com/dmonakhov/xfstests/commit/3c6509eaa83b9c17cd0bc95d73fcdd76e1c54a85
> Signed-off-by: Dmitry Monakhov 
> ---
>  block/bio-integrity.c | 22 +++---
>  1 file changed, 15 insertions(+), 7 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

[PATCH v2 06/11] platform/x86: fujitsu-laptop: clean up use_alt_lcd_levels handling

[Michał Kępień]

The value of each module parameter can be changed on the fly via sysfs.
However, the current way of handling use_alt_lcd_levels prevents the
user from dynamically switching from a value of 0 or 1 back to
autodetection as the latter is only performed upon ACPI device
instantiation.  Fix this by moving autodetection (in a simplified form)
to set_lcd_level() and changing module parameter type to int.  Do not
announce autodetection results in a debug message as current value of
use_alt_lcd_levels can simply be read from sysfs.  Clarify module
parameter description.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index b019060d6dc4..cd2da9a02592 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -362,6 +362,12 @@ static int set_lcd_level(int level)
char *method;
 
switch (use_alt_lcd_levels) {
+   case -1:
+   if (acpi_has_method(fujitsu_bl->acpi_handle, "SBL2"))
+   method = "SBL2";
+   else
+   method = "SBLL";
+   break;
case 1:
method = "SBL2";
break;
@@ -606,21 +612,10 @@ static int acpi_fujitsu_bl_add(struct acpi_device *device)
pr_err("_INI Method failed\n");
}
 
-   if (use_alt_lcd_levels == -1) {
-   if (acpi_has_method(NULL, "\\_SB.PCI0.LPCB.FJEX.SBL2"))
-   use_alt_lcd_levels = 1;
-   else
-   use_alt_lcd_levels = 0;
-   vdbg_printk(FUJLAPTOP_DBG_TRACE, "auto-detected usealt as %i\n",
-   use_alt_lcd_levels);
-   }
-
/* do config (detect defaults) */
-   use_alt_lcd_levels = use_alt_lcd_levels == 1 ? 1 : 0;
disable_brightness_adjust = disable_brightness_adjust == 1 ? 1 : 0;
-   vdbg_printk(FUJLAPTOP_DBG_INFO,
-   "config: [alt interface: %d], [adjust disable: %d]\n",
-   use_alt_lcd_levels, disable_brightness_adjust);
+   vdbg_printk(FUJLAPTOP_DBG_INFO, "config: [adjust disable: %d]\n",
+   disable_brightness_adjust);
 
if (get_max_brightness() <= 0)
fujitsu_bl->max_brightness = FUJITSU_LCD_N_LEVELS;
@@ -1153,9 +1148,8 @@ static void __exit fujitsu_cleanup(void)
 module_init(fujitsu_init);
 module_exit(fujitsu_cleanup);
 
-module_param(use_alt_lcd_levels, uint, 0644);
-MODULE_PARM_DESC(use_alt_lcd_levels,
-"Use alternative interface for lcd_levels (needed for Lifebook 
s6410).");
+module_param(use_alt_lcd_levels, int, 0644);
+MODULE_PARM_DESC(use_alt_lcd_levels, "Interface used for setting LCD 
brightness level (-1 = auto, 0 = force SBLL, 1 = force SBL2)");
 module_param(disable_brightness_adjust, uint, 0644);
 MODULE_PARM_DESC(disable_brightness_adjust, "Disable brightness adjustment .");
 #ifdef CONFIG_FUJITSU_LAPTOP_DEBUG
-- 
2.12.2

[PATCH v2 3/3] platform/x86: fujitsu-laptop: rename call_fext_func() arguments

[Michał Kępień]

Rename call_fext_func() arguments so that each argument's name signifies
its role:

  - cmd -> func: sub-function to call (flags, buttons etc.),
  - arg0 -> op: operation to perform (get, set, get capabilities etc.),
  - arg1 -> feature: feature to act on (e.g. which LED), if relevant,
  - arg2 -> state: state to set (e.g. LED on or off), if relevant.

Adjust whitespace to make checkpatch happy.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index 8c41968d9e7f..928778ccc4c1 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -217,13 +217,13 @@ static u32 dbg_level = 0x03;
 
 /* Fujitsu ACPI interface function */
 
-static int call_fext_func(int cmd, int arg0, int arg1, int arg2)
+static int call_fext_func(int func, int op, int feature, int state)
 {
union acpi_object params[4] = {
-   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = cmd },
-   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = arg0 },
-   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = arg1 },
-   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = arg2 }
+   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = func },
+   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = op },
+   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = feature },
+   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = state }
};
struct acpi_object_list arg_list = { 4, params };
unsigned long long value;
@@ -236,9 +236,8 @@ static int call_fext_func(int cmd, int arg0, int arg1, int 
arg2)
return -ENODEV;
}
 
-   vdbg_printk(FUJLAPTOP_DBG_TRACE,
-   "FUNC 0x%x (args 0x%x, 0x%x, 0x%x) returned 0x%x\n",
-   cmd, arg0, arg1, arg2, (int)value);
+   vdbg_printk(FUJLAPTOP_DBG_TRACE, "FUNC 0x%x (args 0x%x, 0x%x, 0x%x) 
returned 0x%x\n",
+   func, op, feature, state, (int)value);
return value;
 }
 
-- 
2.12.2

[PATCH v2 1/3] platform/x86: fujitsu-laptop: clean up local variables in call_fext_func()

[Michał Kępień]

Set values of FUNC call parameters in a designated initializer.  Do not
initialize status and handle variables as the values these are
initialized to have no influence on execution flow.  Use an array
variable instead of the address of the first element of that array.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index f66da4b0c31a..ca1491ff659e 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -219,16 +219,16 @@ static u32 dbg_level = 0x03;
 
 static int call_fext_func(int cmd, int arg0, int arg1, int arg2)
 {
-   acpi_status status = AE_OK;
union acpi_object params[4] = {
-   { .type = ACPI_TYPE_INTEGER },
-   { .type = ACPI_TYPE_INTEGER },
-   { .type = ACPI_TYPE_INTEGER },
-   { .type = ACPI_TYPE_INTEGER }
+   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = cmd },
+   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = arg0 },
+   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = arg1 },
+   { .integer.type = ACPI_TYPE_INTEGER, .integer.value = arg2 }
};
-   struct acpi_object_list arg_list = { 4, [0] };
+   struct acpi_object_list arg_list = { 4, params };
unsigned long long value;
-   acpi_handle handle = NULL;
+   acpi_status status;
+   acpi_handle handle;
 
status = acpi_get_handle(fujitsu_laptop->acpi_handle, "FUNC", );
if (ACPI_FAILURE(status)) {
@@ -237,11 +237,6 @@ static int call_fext_func(int cmd, int arg0, int arg1, int 
arg2)
return -ENODEV;
}
 
-   params[0].integer.value = cmd;
-   params[1].integer.value = arg0;
-   params[2].integer.value = arg1;
-   params[3].integer.value = arg2;
-
status = acpi_evaluate_integer(handle, NULL, _list, );
if (ACPI_FAILURE(status)) {
vdbg_printk(FUJLAPTOP_DBG_WARN,
-- 
2.12.2

[PATCH v2 0/3] fujitsu-laptop: call_fext_func() cleanup

[Michał Kępień]

This series contains a few cleanups for the call_fext_func() function.
Just as a reminder, please note that v1 of this series is currently
applied in testing.

Changes from v1:

  - Update debug message logged by call_fext_func() to reflect code flow
changes introduced by patch 2/3.

 drivers/platform/x86/fujitsu-laptop.c | 39 +++
 1 file changed, 12 insertions(+), 27 deletions(-)

-- 
2.12.2

[PATCH v2 08/11] platform/x86: fujitsu-laptop: ignore errors when setting backlight power

[Michał Kępień]

Not all Fujitsu laptops support controlling backlight power through the
FUJ02E3 ACPI device.  Remove the debug message informing about a failed
attempt to set backlight power as it may be confusing and the return
value of call_fext_func() is logged anyway.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index a3e9efd1ac88..0cd58c96938c 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -445,13 +445,9 @@ static int bl_update_status(struct backlight_device *b)
 {
int ret;
if (b->props.power == FB_BLANK_POWERDOWN)
-   ret = call_fext_func(FUNC_BACKLIGHT, 0x1, 0x4, 0x3);
+   call_fext_func(FUNC_BACKLIGHT, 0x1, 0x4, 0x3);
else
-   ret = call_fext_func(FUNC_BACKLIGHT, 0x1, 0x4, 0x0);
-   if (ret != 0)
-   vdbg_printk(FUJLAPTOP_DBG_ERROR,
-   "Unable to adjust backlight power, error code %i\n",
-   ret);
+   call_fext_func(FUNC_BACKLIGHT, 0x1, 0x4, 0x0);
 
ret = set_lcd_level(b->props.brightness);
if (ret != 0)
-- 
2.12.2

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

Hi Philipp,


On 04/04/2017 06:17 PM, Philipp Zabel wrote:

Hi Vivek,

On Tue, 2017-04-04 at 16:09 +0530, Vivek Gautam wrote:
[...]

I'd prefer to mirror the gpiod API a little, and to have the number
contained in the array structure, similar to struct gpio_descs:

[...]

Alright, i can update this.
I took regulator_bulk interface as the reference, but now i see
gpio_descs has a smaller footprint.

Ok, understood.
I think the smaller footprint API is more convenient for the user.

[...]

+ * Returns 0 on success or error number on failure
+ */
+static int reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)

Can we make this count and return a pointer to the newly created array?

static struct reset_controls *
reset_control_array_get(struct device *dev, bool shared, bool optional)
{
...

That way the consumer doesn't have to care about counting and array
allocation.

Just trying to think again in line with the regulator bulk APIs.
Can't a user provide a list of reset controls as data and thus
request reset controls with a "id" and num_resets available.

e.g.
 const char * const rst_names[] = {
   "rst1", "rst2" ...
 };
 xyz_data = {
   .resets = rst_names;
   .num = ARRAY_SIZE(rst_names);
 };
and then the driver making use of reset_control_array APIs
to request this list of reset controls and assert/deassert them.

I am assuming this case when one user driver is used across a bunch
of platforms with different number of resets available.
We may not want to rely solely on the device tree entries, since
the resets can be mandatory in few cases and we may want to
return failure.

The way I understood the array API was as a method of handling a list of
anonymous resets, specified as

resets = < 1>, < 2>, < 3>;
// reset-names = "rst1", "rst2", "rst3"; /* don't care */

in the device tree.

Now if you want to handle a partial list of those as an unordered list,
with special consideration for others, that could be added as a separate
API when there is use for it. But I expect that most potential users of
this array API will not have to make such a distinction.


Alright, I will modify the array APIs as suggested to handle an
unordered list of resets passed from the device tree.
As you said, we can handle the special cases when the need arise.




@@ -85,6 +107,39 @@ static inline struct reset_control 
*__devm_reset_control_get(
return -ENOTSUPP;
   }
   
+static inline int reset_control_array_assert(int num_rsts,

+   struct reset_control_array *resets)
+{
+   return 0;
+}
+
+static inline int reset_control_array_deassert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   return 0;
+}

Is this missing a stub for reset_control_array_get?

No, that's supposed to be a static function.

Oh right, it is static. Please ignore.


Thanks


regards
Philipp



Best Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

[Mike Galbraith]

On Wed, 2017-04-05 at 08:29 +0200, Christoph Hellwig wrote:

> Can you check where the issues appear?  I'd like to do a pure revert
> of the shared interrupts, but that three has a lot more in it..

Not immediately, one of my several pots is emitting black smoke.

-Mike

[PATCH v2 09/11] platform/x86: fujitsu-laptop: do not log set_lcd_level() failures in bl_update_status()

[Michał Kępień]

Any set_lcd_level() call can fail for one of two reasons: either
requested brightness is outside the allowed range or the ACPI method
used for setting brightness level is not available.  For
bl_update_status(), the first case is handled by backlight core, which
means bl_update_status() will not even be called if requested brightness
is outside the allowed range.  The second case will be logged anyway by
set_lcd_level() itself, so there is no point in generating another
message in bl_update_status().  Remove the superfluous debug message
along with a local variable that is now redundant.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index 0cd58c96938c..a797e7890773 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -443,18 +443,12 @@ static int bl_get_brightness(struct backlight_device *b)
 
 static int bl_update_status(struct backlight_device *b)
 {
-   int ret;
if (b->props.power == FB_BLANK_POWERDOWN)
call_fext_func(FUNC_BACKLIGHT, 0x1, 0x4, 0x3);
else
call_fext_func(FUNC_BACKLIGHT, 0x1, 0x4, 0x0);
 
-   ret = set_lcd_level(b->props.brightness);
-   if (ret != 0)
-   vdbg_printk(FUJLAPTOP_DBG_ERROR,
-   "Unable to adjust LCD brightness, error code %i\n",
-   ret);
-   return ret;
+   return set_lcd_level(b->props.brightness);
 }
 
 static const struct backlight_ops fujitsu_bl_ops = {
-- 
2.12.2

[PATCH v2 2/3] platform/x86: fujitsu-laptop: simplify call_fext_func()

[Michał Kępień]

acpi_evaluate_integer() takes a pathname parameter which contains the
name of the entity to evaluate underneath the given handle, so calling
acpi_get_handle() beforehand is redundant.  Replace the call to
acpi_get_handle() with a call to acpi_evaluate_integer(), thus
eliminating the need for a local variable storing the handle.  Update
debug message to reflect this change.  Adjust whitespace to make
checkpatch happy.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index ca1491ff659e..8c41968d9e7f 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -228,20 +228,11 @@ static int call_fext_func(int cmd, int arg0, int arg1, 
int arg2)
struct acpi_object_list arg_list = { 4, params };
unsigned long long value;
acpi_status status;
-   acpi_handle handle;
 
-   status = acpi_get_handle(fujitsu_laptop->acpi_handle, "FUNC", );
+   status = acpi_evaluate_integer(fujitsu_laptop->acpi_handle, "FUNC",
+  _list, );
if (ACPI_FAILURE(status)) {
-   vdbg_printk(FUJLAPTOP_DBG_ERROR,
-   "FUNC interface is not present\n");
-   return -ENODEV;
-   }
-
-   status = acpi_evaluate_integer(handle, NULL, _list, );
-   if (ACPI_FAILURE(status)) {
-   vdbg_printk(FUJLAPTOP_DBG_WARN,
-   "FUNC 0x%x (args 0x%x, 0x%x, 0x%x) call failed\n",
-   cmd, arg0, arg1, arg2);
+   vdbg_printk(FUJLAPTOP_DBG_ERROR, "Failed to evaluate FUNC\n");
return -ENODEV;
}
 
-- 
2.12.2

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

[Mike Galbraith]

On Tue, 2017-04-04 at 22:25 -0700, Cong Wang wrote:
> On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith  wrote:
> > -   while (some_qdisc_is_busy(dev))
> > -   yield();
> > +   swait_event_timeout(swait,
> > !some_qdisc_is_busy(dev), 1);
> >  }
> 
> I don't see why this is an improvement even if I don't care about the
> hardcoded timeout for now... Why the scheduler can make a better
> decision with swait_event_timeout() than with cond_resched()?

Because sleeping gets you out of the way?  There is no other decision
the scheduler can make while a SCHED_FIFO task is trying to yield when
it is the one and only task at it's priority.  The scheduler is doing
exactly what it is supposed to do, problem is people calling yield()
tend to think it does something it does not do, which is why it is
decorated with "if you think you want yield(), think again"

Yes, yield semantics suck rocks, basically don't exist.  Hop in your
time machine and slap whoever you find claiming responsibility :)

-Mike

Re: [PATCH 10/11] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Maxime Ripard]

On Wed, Apr 05, 2017 at 02:01:44AM +0800, Icenowy Zheng wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 
> +
>  1 file changed, 109 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 2132d8e6cb3d..7da074f95065 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -106,6 +106,115 @@
>   };
>  };
>  
> +#include "axp803.dtsi"
> +
> +_aldo1 {
> + regulator-min-microvolt = <280>;
> + regulator-max-microvolt = <280>;
> + regulator-name = "vcc-csi";
> +};
> +
> +_aldo2 {
> + regulator-always-on;
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "vcc-pl";
> +};
> +
> +_aldo3 {
> + regulator-always-on;
> + regulator-min-microvolt = <270>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "vcc-pll-avcc";
> +};
> +
> +_dc1sw {
> + regulator-name = "vcc-phy";
> +};
> +
> +_dcdc1 {
> + regulator-always-on;
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "vcc-3v3";
> +};
> +
> +_dcdc2 {
> + regulator-always-on;
> + regulator-min-microvolt = <100>;
> + regulator-max-microvolt = <130>;
> + regulator-name = "vdd-cpux";
> +};
> +
> +/* DCDC3 is polyphased with DCDC2 */
> +
> +_dcdc5 {
> + regulator-always-on;
> + regulator-min-microvolt = <150>;
> + regulator-max-microvolt = <150>;
> + regulator-name = "vcc-dram";
> +};
> +
> +_dcdc6 {
> + regulator-always-on;
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <110>;
> + regulator-name = "vdd-sys";
> +};
> +
> +_dldo1 {
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "vcc-hdmi";
> +};
> +
> +_dldo2 {
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "vcc-mipi";
> +};
> +
> +_dldo3 {
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "avdd-csi";
> +};
> +
> +_dldo4 {
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "vcc-wifi";
> +};
> +
> +_eldo1 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-name = "cpvdd";
> +};
> +
> +_eldo3 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-name = "vdd-1v8-csi";
> +};
> +
> +_fldo1 {
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + regulator-name = "vcc-1v2-hsic";
> +};
> +
> +_fldo2 {
> + regulator-always-on;
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <110>;
> + regulator-name = "vdd-cpus";
> +};

Why do you need to always power the AR100 on?

Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH v4 0/6] ARM: dts: sunxi: Add CAN node and can0_pins_a pinctrl settings

[Maxime Ripard]

On Tue, Apr 04, 2017 at 08:36:26PM +0200, Patrick Menschel wrote:
> The Allwinner A10/A20 SoCs have an on-board CAN (Controller Area Network)
> controller. This patch adds the CAN core to the SoC's include files,
> sun4i-a10.dtsi and sun7i-a20.dtsi.
> 
> On linux-can mailing list was a discussion about updating the device tree 
> bindings
> https://lkml.org/lkml/2015/9/17/220
> but it did not progress past writing the documentation file.
> Documentation/devicetree/bindings/net/can/sun4i_can.txt
> 
> The CAN controller can be enabled in a board specific dts file as
> described in the documentation file or by using a device tree overlay.

Applied 1 and 4. The others were already merged.

Thanks!
Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler

[Michal Simek]

On 5.4.2017 01:36, Moritz Fischer wrote:
> On Thu, Mar 30, 2017 at 05:44:29PM -0500, Rob Herring wrote:
>> On Fri, Mar 24, 2017 at 10:33:20AM -0500, Alan Tull wrote:
>>> From: Moritz Fischer 
>>
>> Please use "dt-bindings: fpga: ..." for the subject.
>>
>>
>>>
>>> This adds the binding documentation for the Xilinx LogiCORE PR
>>> Decoupler soft core.
>>>
>>> Signed-off-by: Moritz Fischer 
>>> Signed-off-by: Michal Simek 
>>> Acked-by: Alan Tull 
>>
>> I'm confused why you are sending these instead of Moritz? If it goes
>> through you, then it should have your S-o-B too.
> 
> Do you want me to resend this Alan (with Rob's suggestions)?
>>
>>> Cc: Sören Brinkmann 
>>> Cc: linux-kernel@vger.kernel.org
>>> Cc: devicet...@vger.kernel.org
>>> ---
>>>  .../bindings/fpga/xilinx-pr-decoupler.txt  | 35 
>>> ++
>>>  1 file changed, 35 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
>>> b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>> new file mode 100644
>>> index ..2c527ac30398
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>> @@ -0,0 +1,35 @@
>>> +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
>>> +
>>> +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
>>> +decouplers / fpga bridges.
>>> +The controller can decouple/disable the bridges which prevents signal
>>> +changes from passing through the bridge.  The controller can also
>>> +couple / enable the bridges which allows traffic to pass through the
>>> +bridge normally.
>>> +
>>> +The Driver supports only MMIO handling. A PR region can have multiple
>>> +PR Decouplers which can be handled independently or chained via decouple/
>>> +decouple_status signals.
>>> +
>>> +Required properties:
>>> +- compatible : Should contain "xlnx,pr-decoupler-1.00" or 
>>> "xlnx,pr-decoupler"
>>
>> I'd drop xlnx,pr-decoupler, but in any case, it should not be OR rather
>> "followed by". Plus the example has both.
> 
> Michal wanted to have both, so I put both. Personally I don't care. I
> think they have some downstream stuff that relied on it.

Agree with Rob with using "followed by" instead of or.

M

Re: [PATCH] net: thunderx: Switch to pci_alloc_irq_vectors

[Christoph Hellwig]

On Tue, Apr 04, 2017 at 02:59:06PM +0530, dev.srinivas...@gmail.com wrote:
> From: Thanneeru Srinivasulu 
> 
> Remove deprecated pci_enable_msix API in favour of it's
> successor pci_alloc_irq_vectors.
> 
> Signed-off-by: Thanneeru Srinivasulu 
> Signed-off-by: Sunil Goutham 

Looks good.

Are you fine with me queueing this up together with the other
pci_enable_msix() removal patches?

Re: [PATCH v6 02/11] powerpc/powernv: Autoload IMC device driver module

[Madhavan Srinivasan]

On Tuesday 04 April 2017 07:18 AM, Daniel Axtens wrote:

Hi,


+   do {
+   pages = PAGE_SIZE * i;
+   pcni->vbase[i++] = (u64)phys_to_virt(pcni->pbase +
+pages);
+   } while (i < (pcni->size / PAGE_SIZE));

I also just noticed that there's no check here against
IMC_NEST_MAX_PAGES: should that be inserted? (If for no other reason
than to stop every static analysis tool complaining!)

Yes make sense. Can add that in the next version.

Thanks for review
Maddy



Daniel


+   }
+
+   return 0;
+err:
+   return -ENODEV;
+}
+
+static const struct of_device_id opal_imc_match[] = {
+   { .compatible = IMC_DTB_COMPAT },
+   {},
+};
+
+static struct platform_driver opal_imc_driver = {
+   .driver = {
+   .name = "opal-imc-counters",
+   .of_match_table = opal_imc_match,
+   },
+   .probe = opal_imc_counters_probe,
+};
+
+MODULE_DEVICE_TABLE(of, opal_imc_match);
+module_platform_driver(opal_imc_driver);
+MODULE_DESCRIPTION("PowerNV OPAL IMC driver");
+MODULE_LICENSE("GPL");
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index e0f856bfbfe8..85ea1296f030 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -30,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "powernv.h"
  
@@ -631,6 +633,15 @@ static void opal_pdev_init(const char *compatible)

of_platform_device_create(np, NULL, NULL);
  }
  
+static void opal_imc_init_dev(void)

+{
+   struct device_node *np;
+
+   np = of_find_compatible_node(NULL, NULL, IMC_DTB_COMPAT);
+   if (np)
+   of_platform_device_create(np, NULL, NULL);
+}
+
  static int kopald(void *unused)
  {
unsigned long timeout = msecs_to_jiffies(opal_heartbeat) + 1;
@@ -704,6 +715,9 @@ static int __init opal_init(void)
/* Setup a heatbeat thread if requested by OPAL */
opal_init_heartbeat();
  
+	/* Detect IMC pmu counters support and create PMUs */

+   opal_imc_init_dev();
+
/* Create leds platform devices */
leds = of_find_node_by_path("/ibm,opal/leds");
if (leds) {
--
2.7.4

Re: [PATCH 6/9] T10: Move opencoded contants to common header

[Hannes Reinecke]

On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> Signed-off-by: Dmitry Monakhov 
> ---
>  block/t10-pi.c   | 9 +++--
>  drivers/scsi/lpfc/lpfc_scsi.c| 5 +++--
>  drivers/scsi/qla2xxx/qla_isr.c   | 8 
>  drivers/target/target_core_sbc.c | 2 +-
>  include/linux/t10-pi.h   | 2 ++
>  5 files changed, 13 insertions(+), 13 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 5/9] bio-integrity: fold bio_integrity_enabled to bio_integrity_prep

[Hannes Reinecke]

On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> Currently all integrity prep hooks are open-coded, and if prepare fails
> we ignore it's code and fail bio with EIO. Let's return real error to
> upper layer, so later caller may react accordingly.
> 
> In fact no one want to use bio_integrity_prep() w/o bio_integrity_enabled,
> so it is reasonable to fold it in to one function.
> 
> Signed-off-by: Dmitry Monakhov 
> ---
>  Documentation/block/data-integrity.txt |  3 --
>  block/bio-integrity.c  | 88 
> ++
>  block/blk-core.c   |  5 +-
>  block/blk-mq.c |  8 +---
>  drivers/nvdimm/blk.c   | 13 +
>  drivers/nvdimm/btt.c   | 13 +
>  include/linux/bio.h|  6 ---
>  7 files changed, 55 insertions(+), 81 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH] net: thunderx: Switch to pci_alloc_irq_vectors

[Thanneeru Srinivasulu]

On Wed, Apr 5, 2017 at 11:57 AM, Christoph Hellwig  wrote:
> On Tue, Apr 04, 2017 at 02:59:06PM +0530, dev.srinivas...@gmail.com wrote:
>> From: Thanneeru Srinivasulu 
>>
>> Remove deprecated pci_enable_msix API in favour of it's
>> successor pci_alloc_irq_vectors.
>>
>> Signed-off-by: Thanneeru Srinivasulu 
>> Signed-off-by: Sunil Goutham 
>
> Looks good.
>
> Are you fine with me queueing this up together with the other
> pci_enable_msix() removal patches?

No issues, thanks.

Re: [linux-sunxi] [PATCH 02/11] arm64: allwinner: a64: add NMI controller on A64

[Maxime Ripard]

On Wed, Apr 05, 2017 at 02:20:31PM +0800, Chen-Yu Tsai wrote:
> On Wed, Apr 5, 2017 at 2:11 PM, Maxime Ripard
>  wrote:
> > On Wed, Apr 05, 2017 at 11:51:45AM +0800, Chen-Yu Tsai wrote:
> >> On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng  wrote:
> >> > Allwinner A64 SoC features a NMI controller, which is usually connected
> >> > to the AXP PMIC.
> >> >
> >> > Add support for it.
> >> >
> >> > Signed-off-by: Icenowy Zheng 
> >>
> >> This might not be the best representation of the R_INTC block. Though
> >> we'd need to change it for all SoCs if we want to be accurate. For now,
> >
> > What do you think would be a good representation?
> 
> My gut feeling is that this is the old INTC from sun4/5i.

Ah, that would make sense.

> It's supposed to be the interrupt controller for the embedded low
> power core. I've not done a thorough comparison though.

Do we have some documentation / code for this one?

Thanks,
Maxime

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


signature.asc
Description: PGP signature

[PATCH] drm: bridge: dw-hdmi: remove unused hdmi_bus_fmt_is_yuv420

[Neil Armstrong]

Remove usused yet hdmi_bus_fmt_is_yuv420 function.

Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and 
encodings")
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 84cc949..7dd6699 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -605,20 +605,6 @@ static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
}
 }
 
-static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
-{
-   switch (bus_format) {
-   case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
-   case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
-   case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
-   case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
-   return true;
-
-   default:
-   return false;
-   }
-}
-
 static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
 {
switch (bus_format) {
-- 
1.9.1

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

[Jan Kara]

On Wed 05-04-17 11:43:32, NeilBrown wrote:
> On Tue, Apr 04 2017, J. Bruce Fields wrote:
> 
> > On Thu, Mar 30, 2017 at 02:35:32PM -0400, Jeff Layton wrote:
> >> On Thu, 2017-03-30 at 12:12 -0400, J. Bruce Fields wrote:
> >> > On Thu, Mar 30, 2017 at 07:11:48AM -0400, Jeff Layton wrote:
> >> > > On Thu, 2017-03-30 at 08:47 +0200, Jan Kara wrote:
> >> > > > Because if above is acceptable we could make reported i_version to 
> >> > > > be a sum
> >> > > > of "superblock crash counter" and "inode i_version". We increment
> >> > > > "superblock crash counter" whenever we detect unclean filesystem 
> >> > > > shutdown.
> >> > > > That way after a crash we are guaranteed each inode will report new
> >> > > > i_version (the sum would probably have to look like "superblock crash
> >> > > > counter" * 65536 + "inode i_version" so that we avoid reusing 
> >> > > > possible
> >> > > > i_version numbers we gave away but did not write to disk but 
> >> > > > still...).
> >> > > > Thoughts?
> >> > 
> >> > How hard is this for filesystems to support?  Do they need an on-disk
> >> > format change to keep track of the crash counter?  Maybe not, maybe the
> >> > high bits of the i_version counters are all they need.
> >> > 
> >> 
> >> Yeah, I imagine we'd need a on-disk change for this unless there's
> >> something already present that we could use in place of a crash counter.
> >
> > We could consider using the current time instead.  So, put the current
> > time (or time of last boot, or this inode's ctime, or something) in the
> > high bits of the change attribute, and keep the low bits as a counter.
> 
> This is a very different proposal.
> I don't think Jan was suggesting that the i_version be split into two
> bit fields, one the change-counter and one the crash-counter.
> Rather, the crash-counter was multiplied by a large-number and added to
> the change-counter with the expectation that while not ever
> change-counter landed on disk, at least 1 in every large-number would.
> So after each crash we effectively add large-number to the
> change-counter, and can be sure that number hasn't been used already.

Yes, that was my thinking.

> To store the crash-counter in each inode (which does appeal) you would
> need to be able to remove it before adding the new crash counter, and
> that requires bit-fields.  Maybe there are enough bits.

Furthermore you'd have a potential problem that you need to change
i_version on disk just because you are reading after a crash and such
changes tend to be problematic (think of read-only mounts and stuff like
that).
 
> If you want to ensure read-only files can remain cached over a crash,
> then you would have to mark a file in some way on stable storage
> *before* allowing any change.
> e.g. you could use the lsb.  Odd i_versions might have been changed
> recently and crash-count*large-number needs to be added.
> Even i_versions have not been changed recently and nothing need be
> added.
> 
> If you want to change a file with an even i_version, you subtract
>   crash-count*large-number
> to the i_version, then set lsb.  This is written to stable storage before
> the change.
> 
> If a file has not been changed for a while, you can add
>   crash-count*large-number
> and clear lsb.
> 
> The lsb of the i_version would be for internal use only.  It would not
> be visible outside the filesystem.
> 
> It feels a bit clunky, but I think it would work and is the best
> combination of Jan's idea and your requirement.
> The biggest cost would be switching to 'odd' before an changes, and the
> unknown is when does it make sense to switch to 'even'.

Well, there is also a problem that you would need to somehow remember with
which 'crash count' the i_version has been previously reported as that is
not stored on disk with my scheme. So I don't think we can easily use your
scheme.

So the options we have are:

1) Keep i_version as is, make clients also check for i_ctime.
   Pro: No on-disk format changes.
   Cons: After a crash, i_version can go backwards (but when file changes
   i_version, i_ctime pair should be still different) or not, data can be
   old or not.

2) Fsync when reporting i_version.
   Pro: No on-disk format changes, strong consistency of i_version and
data.
   Cons: Difficult to implement for filesystems due to locking constrains.
 High performance overhead or i_version reporting.

3) Some variant of crash counter.
   Pro: i_version cannot go backwards.
   Cons: Requires on-disk format changes. After a crash data can be old
 (however i_version increased).

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: dm: move dm_table_destroy() to same header as dm_table_create()

[Enric Balletbo i Serra]

Hi,

On 05/04/17 00:35, Brian Norris wrote:
> On Tue, Mar 28, 2017 at 03:31:51PM -0400, Mike Snitzer wrote:
>> On Tue, Mar 28 2017 at  2:31pm -0400,
>> Brian Norris  wrote:
>>
>>> If anyone is going to use dm_table_create(), they probably should be
>>> able to use dm_table_destroy() too. Move the dm_table_destroy()
>>> definition outside the private header, near dm_table_create()
>>>
>>> Signed-off-by: Brian Norris 
>>
>> Not seeing why we need dm_table_create() exposed.  So I think you went
>> the wrong way with this.  Unless you have an actual need, I'd prefer to
>> see dm_table_create() moved from include/linux/device-mapper.h to
>> drivers/md/dm.h
> 
> We've been carrying code in our ChromeOS kernel to parse a cmdline arg
> for setting up early DM maps -- e.g., a dm-verity rootfs without using
> an initramfs. We currently use dm_table_create() from init/*.c (and we
> *should* be using dm_table_destroy() in the error paths). So I'm
> certainly not going to send the patch to do the reverse :)
> 
> Enric is working on cleaning up this work to send here, so if you don't
> want to see this patch now, you may well see it later.
> 

As Brian told you we have a use case that uses the dm_table_create and others
from init/*.c, I expect have a first patches during this week, if it's ok I'll
include this patch in my patchset so you have the overall of what we are talking
about.

Cheers,
 Enric

> Brian
> 

Re: [PATCH] drm: bridge: dw-hdmi: remove unused hdmi_bus_fmt_is_yuv420

[Laurent Pinchart]

Hi Neil,

Thank you for the patch.

On Wednesday 05 Apr 2017 09:32:59 Neil Armstrong wrote:
> Remove usused yet hdmi_bus_fmt_is_yuv420 function.
> 
> Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and
> encodings") Signed-off-by: Neil Armstrong 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 14 --
>  1 file changed, 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 84cc949..7dd6699 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -605,20 +605,6 @@ static bool hdmi_bus_fmt_is_yuv422(unsigned int
> bus_format) }
>  }
> 
> -static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
> -{
> - switch (bus_format) {
> - case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
> - case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
> - case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
> - case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
> - return true;
> -
> - default:
> - return false;
> - }
> -}
> -
>  static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
>  {
>   switch (bus_format) {

-- 
Regards,

Laurent Pinchart

Re: [PATCH] xen, fbfront: add support for specifying size via xenstore

[Juergen Gross]

On 23/03/17 13:53, Juergen Gross wrote:
> Today xen-fbfront supports specifying the display size via module
> parameters only. Add support for specifying the size via Xenstore in
> order to enable doing this easily via the domain's Xen configuration.
> 
> Add an error message in case the configured display size conflicts
> with video memory size.
> 
> Signed-off-by: Juergen Gross 

Bartlomiej, any comments? Can you please take this patch or should I
carry it through the Xen tree?


Juergen

> ---
>  drivers/video/fbdev/xen-fbfront.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/video/fbdev/xen-fbfront.c 
> b/drivers/video/fbdev/xen-fbfront.c
> index 3ee309c..46f6396 100644
> --- a/drivers/video/fbdev/xen-fbfront.c
> +++ b/drivers/video/fbdev/xen-fbfront.c
> @@ -18,6 +18,8 @@
>   * frame buffer.
>   */
>  
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
>  #include 
>  #include 
>  #include 
> @@ -380,10 +382,18 @@ static int xenfb_probe(struct xenbus_device *dev,
>   video[KPARAM_MEM] = val;
>   }
>  
> + video[KPARAM_WIDTH] = xenbus_read_unsigned(dev->otherend, "width",
> +video[KPARAM_WIDTH]);
> + video[KPARAM_HEIGHT] = xenbus_read_unsigned(dev->otherend, "height",
> + video[KPARAM_HEIGHT]);
> +
>   /* If requested res does not fit in available memory, use default */
>   fb_size = video[KPARAM_MEM] * 1024 * 1024;
>   if (video[KPARAM_WIDTH] * video[KPARAM_HEIGHT] * XENFB_DEPTH / 8
>   > fb_size) {
> + pr_warn("display parameters %d,%d,%d invalid, use defaults\n",
> + video[KPARAM_MEM], video[KPARAM_WIDTH],
> + video[KPARAM_HEIGHT]);
>   video[KPARAM_WIDTH] = XENFB_WIDTH;
>   video[KPARAM_HEIGHT] = XENFB_HEIGHT;
>   fb_size = XENFB_DEFAULT_FB_LEN;
> 

Re: [PATCH] xen, fbfront: fix connecting to backend

[Juergen Gross]

On 23/03/17 13:52, Juergen Gross wrote:
> Connecting to the backend isn't working reliably in xen-fbfront: in
> case XenbusStateInitWait of the backend has been missed the backend
> transition to XenbusStateConnected will trigger the connected state
> only without doing the actions required when the backend has
> connected.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross 

Bartlomiej, any comments? Can you please take this patch or should I
carry it through the Xen tree?


Juergen

> ---
>  drivers/video/fbdev/xen-fbfront.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbdev/xen-fbfront.c 
> b/drivers/video/fbdev/xen-fbfront.c
> index d0115a7..3ee309c 100644
> --- a/drivers/video/fbdev/xen-fbfront.c
> +++ b/drivers/video/fbdev/xen-fbfront.c
> @@ -643,7 +643,6 @@ static void xenfb_backend_changed(struct xenbus_device 
> *dev,
>   break;
>  
>   case XenbusStateInitWait:
> -InitWait:
>   xenbus_switch_state(dev, XenbusStateConnected);
>   break;
>  
> @@ -654,7 +653,8 @@ static void xenfb_backend_changed(struct xenbus_device 
> *dev,
>* get Connected twice here.
>*/
>   if (dev->state != XenbusStateConnected)
> - goto InitWait; /* no InitWait seen yet, fudge it */
> + /* no InitWait seen yet, fudge it */
> + xenbus_switch_state(dev, XenbusStateConnected);
>  
>   if (xenbus_read_unsigned(info->xbdev->otherend,
>"request-update", 0))
> 

Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask

[Sebastian Andrzej Siewior]

On 2017-04-05 09:39:43 [+0200], Ingo Molnar wrote:
> 
> So maybe we could add the following facility:
> 
>   ptr = sched_migrate_to_cpu_save(cpu);
> 
>   ...
> 
>   sched_migrate_to_cpu_restore(ptr);
> 
> ... and use it in the cpufreq code. Then -rt could simply define 
> migrate_disable() 
> to be:
> 
>   ptr = sched_migrate_to_cpu_save(raw_smp_processor_id());
> 
> and define migrate_enable() as:
> 
>   sched_migrate_to_cpu_restore(ptr);
> 
> ... or such.
> 
> In the cpu == current_cpu case it would be super fast - otherwise it would 
> migrate 
> over to the target CPU first. Also note that this facility is strictly a 
> special 
> case for single-CPU masks and migrations - i.e. the constant pointer cpumask 
> optimization would always apply.
> 
> Note that due to the use of the 'ptr' local variable the interface nests 
> naturally, so this would be a legitimate use:
>   
>   ptr = sched_migrate_to_cpu_save(cpu);
> 
>   ...
>   migrate_disable();
>   ...
>   migrate_enable();
>   ...
> 
>   sched_migrate_to_cpu_restore(ptr);
> 
> I.e. my proposal would be to essentially upstream the -rt migrate_disable() 
> facility in a slightly more generic form that would fit the cpufreq usecase.
> 
> I bet a number of the current driver's mucking with cpumask would also fit 
> this 
> new API.
> 
> Does this make sense?

It kind of does. If you want to allow migration to different CPU then it
will might make things little complicated because we need to supported
nested migrate_disable() and we can't (must not) change the mask while
nesting.
Other than that, I am not sure the cpufreq usecase is valid.
schedule_work_on() looks better but maybe not as fast as the proposed
sched_migrate_to_cpu_save(). Also, some users look wrong:
[PATCH] CPUFREQ: Loongson2: drop set_cpus_allowed_ptr()
https://www.linux-mips.org/archives/linux-mips/2017-04/msg00042.html

and I received offlist mail pointing to the other cpufreq users. So here
I am waiting for some feedback from the cpufreq maintainer.

But I get your point. Other than super-fast switching to a specific CPU
for $reason we could replace a few preempt_disable() invocation which
are only there due to per-CPU variables. So let me hack this into -RT
and come back…

> Thanks,
> 
>   Ingo

Sebastian

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

[Sergey Senozhatsky]

On (04/05/17 15:29), Ye Xiaolong wrote:
[..]
> >>does this patch make it any better?
> >
> >I am trying it and will post the result once I get it.
> 
> Sorry for the late. I applied the patch of on top of the fbc14616f4 ("printk: 
> enable printk offloading") 
> and the "reboot-without-waring" issue is gone for 6 times of tests.
> 
> testcase/path_params/tbox_group/run: trinity/300s/vm-kbuild-yocto-ia32
> 
> fbc14616f483788a  a75384abd8885080d6923d7036  
>   --  
>   4:4 -100%0:6 
> dmesg.BUG:kernel_reboot-without-warning_in_test_stage

thanks!

-ss

[PATCH v1] mtd: mtk-nor: set controller's address width according to nor flas

[Guochun Mao]

Guochun Mao (1):
  mtd: mtk-nor: set controller's address width according to nor flash

 drivers/mtd/spi-nor/mtk-quadspi.c | 27 +++
 1 file changed, 27 insertions(+)

-- 
1.9.1

[PATCH v5 6/7] ARM: dts: sun8i: sina33: enable battery power supply subnode

[Quentin Schulz]

The Sinlinx SinA33 has an AXP223 PMIC and a battery connector, thus, we
enable the battery power supply subnode in its Device Tree.

Signed-off-by: Quentin Schulz 
Acked-by: Maxime Ripard 
Acked-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts 
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index e34e092..7afe7fe 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -182,6 +182,10 @@
status = "okay";
 };
 
+_power_supply {
+   status = "okay";
+};
+
 _aldo1 {
regulator-always-on;
regulator-min-microvolt = <300>;
-- 
2.9.3

[PATCH -mm -v2] mm, swap: Sort swap entries before free

[Huang, Ying]

From: Huang Ying 

To reduce the lock contention of swap_info_struct->lock when freeing
swap entry.  The freed swap entries will be collected in a per-CPU
buffer firstly, and be really freed later in batch.  During the batch
freeing, if the consecutive swap entries in the per-CPU buffer belongs
to same swap device, the swap_info_struct->lock needs to be
acquired/released only once, so that the lock contention could be
reduced greatly.  But if there are multiple swap devices, it is
possible that the lock may be unnecessarily released/acquired because
the swap entries belong to the same swap device are non-consecutive in
the per-CPU buffer.

To solve the issue, the per-CPU buffer is sorted according to the swap
device before freeing the swap entries.  Test shows that the time
spent by swapcache_free_entries() could be reduced after the patch.

Test the patch via measuring the run time of swap_cache_free_entries()
during the exit phase of the applications use much swap space.  The
results shows that the average run time of swap_cache_free_entries()
reduced about 20% after applying the patch.

Signed-off-by: Huang Ying 
Acked-by: Tim Chen 
Cc: Hugh Dickins 
Cc: Shaohua Li 
Cc: Minchan Kim 
Cc: Rik van Riel 

v2:

- Avoid sort swap entries if there is only one swap device.
---
 mm/swapfile.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 90054f3c2cdc..b91b0b0088c5 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1065,6 +1066,13 @@ void swapcache_free(swp_entry_t entry)
}
 }
 
+static int swp_entry_cmp(const void *ent1, const void *ent2)
+{
+   const swp_entry_t *e1 = ent1, *e2 = ent2;
+
+   return (long)(swp_type(*e1) - swp_type(*e2));
+}
+
 void swapcache_free_entries(swp_entry_t *entries, int n)
 {
struct swap_info_struct *p, *prev;
@@ -1075,6 +1083,8 @@ void swapcache_free_entries(swp_entry_t *entries, int n)
 
prev = NULL;
p = NULL;
+   if (nr_swapfiles > 1)
+   sort(entries, n, sizeof(entries[0]), swp_entry_cmp, NULL);
for (i = 0; i < n; ++i) {
p = swap_info_get_cont(entries[i], prev);
if (p)
-- 
2.11.0

Re: [PATCH 04/17] pci: Add arch_can_pci_mmap_wc() macro

[David Woodhouse]

On Tue, 2017-04-04 at 16:36 -0500, Bjorn Helgaas wrote:
> > --- a/arch/xtensa/kernel/pci.c
> > +++ b/arch/xtensa/kernel/pci.c
> > @@ -345,7 +345,7 @@ __pci_mmap_set_pgprot(struct pci_dev *dev, struct 
> > vm_area_struct *vma,
> >  
> >     /* Set to write-through */
> >     prot = (prot & _PAGE_CA_MASK) | _PAGE_CA_WT;
> > -#if 0
> > +#ifdef arch_can_pci_mmap_wc
>
> This hunk seems like maybe it should be a separate patch.
> 
> ...
>
> This part seems different -- it changes the way pci_mmap_page_range()
> works.

It doesn't, because arch_can_pci_map_wc isn't defined on xtensa. So
it's just a trivial cleanup for future-proofing, turning that 'if 0'
into 'if '.

> > diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
> > index dc8912e..c49be71 100644
> > --- a/drivers/pci/proc.c
> > +++ b/drivers/pci/proc.c
> > @@ -209,15 +209,18 @@ static long proc_bus_pci_ioctl(struct file *file, 
> > unsigned int cmd,
> >     fpriv->mmap_state = pci_mmap_mem;
> >     break;
> >  
> > +#ifdef arch_can_pci_mmap_wc
> Can we get rid of these #ifdefs in the code by adding this to linux/pci.h?
> 
>   #ifndef arch_can_pci_mmap_wc
>   #define arch_can_pci_mmap_wc()  0
>   #endif

Er at the time, that was non-trivial because there was something
that actually needed to be *removed* with the preprocessor instead of
just not being called. But after I settled on the incremental approach
of having pci_mmap_resource_range() be a wrapper for
pci_mmap_page_range() *and* vice versa I think that requirement went
away. I'll take another look and see if I can do that now; thanks.

Are you happy with the suggestion that we use HAVE_PCI_MMAP *only* to
control mmap on /proc/bus/pci, and we present mmap through sysfs on all
platforms via the generic code?

smime.p7s
Description: S/MIME cryptographic signature

Re: linux-next: build failure after merge of the tip tree

[Mikko Perttunen]

On 05.04.2017 06:36, Stephen Rothwell wrote:

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/gpu/built-in.o:(__tracepoints+0x64): multiple definition of 
`__tracepoint_remove_device_from_group'
drivers/iommu/built-in.o:(__tracepoints+0x64): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x3c): multiple definition of 
`__tracepoint_detach_device_from_domain'
drivers/iommu/built-in.o:(__tracepoints+0x3c): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x0): multiple definition of 
`__tracepoint_io_page_fault'
drivers/iommu/built-in.o:(__tracepoints+0x0): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x78): multiple definition of 
`__tracepoint_add_device_to_group'
drivers/iommu/built-in.o:(__tracepoints+0x78): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x14): multiple definition of 
`__tracepoint_unmap'
drivers/iommu/built-in.o:(__tracepoints+0x14): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x28): multiple definition of 
`__tracepoint_map'
drivers/iommu/built-in.o:(__tracepoints+0x28): first defined here
drivers/gpu/built-in.o:(__tracepoints+0x50): multiple definition of 
`__tracepoint_attach_device_to_domain'
drivers/iommu/built-in.o:(__tracepoints+0x50): first defined here

The tip tree has not changed since yesterday.  However, reverting
the drm-tegra tree fixes the build problem.  So there is some interaction
between the tip tree and today's drm-tegra tree.

So for now, I have reverted the merge of the drm-tegra tree.



Looks like this is caused by my patch to add IOMMU support to Host1x. 
I'm confused by how it doesn't appear on ARMv8, though. The cause is 
that host1x/dev.c defines CREATE_TRACE_POINTS and includes 
trace/events/host1x.h, which is fine. However, it then also includes, 
among other local files, dev.h. This used to be fine, but my patch adds 
an include of linux/iommu.h to dev.h, so we get this failure. I'll post 
a fix shortly.


Thanks,
Mikko.

Re: [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts

[Maxime Ripard]

On Wed, Apr 05, 2017 at 03:17:19PM +0800, Icenowy Zheng wrote:
> 
> 
> 在 2017年04月05日 15:15, Maxime Ripard 写道:
> > On Wed, Apr 05, 2017 at 02:45:17AM +0800, Icenowy Zheng wrote:
> > > As we added USB0 route auto switching support for A64, add related
> > > device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the
> > > pmu0 memory area for PHY).
> > > 
> > > Signed-off-by: Icenowy Zheng 
> > > ---
> > >  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 
> > > 
> > >  1 file changed, 24 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
> > > b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > index 1c64ea2d23f9..a8916df99048 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > @@ -179,8 +179,10 @@
> > >   usbphy: phy@01c19400 {
> > >   compatible = "allwinner,sun50i-a64-usb-phy";
> > >   reg = <0x01c19400 0x14>,
> > > +   <0x01c1a800 0x4>,
> > > <0x01c1b800 0x4>;
> > >   reg-names = "phy_ctrl",
> > > + "pmu0",
> > 
> > This breaks the older DTs, and that property isn't documented.
> 
> It's already documented.
> 
> In the H3 dual-route patchset I have already added this.
> 
> ("  * "pmu0" for H3, V3s and A64")

This is not in linux-next then, sorry.

> P.S. to be compatible with older DTs, I think I should adjust
> the phy driver, make it enable dual-route function only when
> pmu0 is present.

That, or if we're quick enough, we can still add it to 4.11. There's a
bit of time left.

Maxime

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


signature.asc
Description: PGP signature

Re: linux-next: build warning after merge of the drm-misc tree

[Neil Armstrong]

On 04/05/2017 02:41 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-misc tree, today's linux-next build
> (arm_multi_v7_defconfig) produced this warning:
> 
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:608:13: warning: 
> 'hdmi_bus_fmt_is_yuv420' defined but not used [-Wunused-function]
>  static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
>  ^
> 
> Introduced by commit
> 
>   def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and 
> encodings")
> 

Hi,

I'm preparing a fix for that, sorry for the noise.

Thanks,
Neil

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

[Ye Xiaolong]

On 03/31, Ye Xiaolong wrote:
>On 03/31, Sergey Senozhatsky wrote:
>>On (03/31/17 11:35), Sergey Senozhatsky wrote:
>>[..]
>>> > [   21.009531] VFS: Warning: trinity-c2 using old stat() call. Recompile 
>>> > your binary.
>>> > [   21.148898] VFS: Warning: trinity-c0 using old stat() call. Recompile 
>>> > your binary.
>>> > [   22.298208] warning: process `trinity-c2' used the deprecated sysctl 
>>> > system call with 
>>> > 
>>> > Elapsed time: 310
>>> > BUG: kernel reboot-without-warning in test stage
>>> 
>>> so as far as I understand, this is the "missing kernel messages"
>>> type of bug report. a worst case scenario.
>>
>>panic() should have called console_flush_on_panic(), which sould have
>>flushed the messages regardless the printk_kthread state. so it probably
>>was not panic() that rebooted the kernel. (probably).
>>
>>kernel_restart() and kernel_halt() have pr_emerg() messages, printk switches
>>to printk_emergency mode the first time it sees EMERG level message. (may be
>>we switch to late).
>>
>>on the other hand, there is a emergency_restart(), where we don't switch
>>to printk_emergency mode and don't flush the existing kernel messages.
>>there is a bunch of places that call emergency_restart(), including sysrq.
>>
>>may I ask you, how do you usually restart the vm after the test?
>>`echo X > /proc/sysrq-trigger'?
>
>Yes.
>
>>
>>does this patch make it any better?
>
>I am trying it and will post the result once I get it.

Sorry for the late. I applied the patch of on top of the fbc14616f4 ("printk: 
enable printk offloading") 
and the "reboot-without-waring" issue is gone for 6 times of tests.

testcase/path_params/tbox_group/run: trinity/300s/vm-kbuild-yocto-ia32

fbc14616f483788a  a75384abd8885080d6923d7036  
  --  
  4:4 -100%0:6 
dmesg.BUG:kernel_reboot-without-warning_in_test_stage

Thanks,
Xiaolong

>
>Thanks,
>Xiaolong
>>
>>---
>> drivers/tty/sysrq.c | 8 ++--
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>>
>>diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
>>index 817dfb69914d..069f5540be36 100644
>>--- a/drivers/tty/sysrq.c
>>+++ b/drivers/tty/sysrq.c
>>@@ -240,7 +240,6 @@ static DECLARE_WORK(sysrq_showallcpus, 
>>sysrq_showregs_othercpus);
>> 
>> static void sysrq_handle_showallcpus(int key)
>> {
>>- printk_emergency_begin();
>>  /*
>>   * Fall back to the workqueue based printing if the
>>   * backtrace printing did not succeed or the
>>@@ -255,7 +254,6 @@ static void sysrq_handle_showallcpus(int key)
>>  }
>>  schedule_work(_showallcpus);
>>  }
>>- printk_emergency_end();
>> }
>> 
>> static struct sysrq_key_op sysrq_showallcpus_op = {
>>@@ -282,10 +280,8 @@ static struct sysrq_key_op sysrq_showregs_op = {
>> 
>> static void sysrq_handle_showstate(int key)
>> {
>>- printk_emergency_begin();
>>  show_state();
>>  show_workqueue_state();
>>- printk_emergency_end();
>> }
>> static struct sysrq_key_op sysrq_showstate_op = {
>>  .handler= sysrq_handle_showstate,
>>@@ -296,9 +292,7 @@ static struct sysrq_key_op sysrq_showstate_op = {
>> 
>> static void sysrq_handle_showstate_blocked(int key)
>> {
>>- printk_emergency_begin();
>>  show_state_filter(TASK_UNINTERRUPTIBLE);
>>- printk_emergency_end();
>> }
>> static struct sysrq_key_op sysrq_showstate_blocked_op = {
>>  .handler= sysrq_handle_showstate_blocked,
>>@@ -537,6 +531,7 @@ void __handle_sysrq(int key, bool check_mask)
>>  int orig_log_level;
>>  int i;
>> 
>>+ printk_emergency_begin();
>>  rcu_sysrq_start();
>>  rcu_read_lock();
>>  /*
>>@@ -582,6 +577,7 @@ void __handle_sysrq(int key, bool check_mask)
>>  }
>>  rcu_read_unlock();
>>  rcu_sysrq_end();
>>+ printk_emergency_end();
>> }
>> 
>> void handle_sysrq(int key)
>>-- 
>>2.12.2
>>

Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask

[Ingo Molnar]

* Sebastian Andrzej Siewior  wrote:

> In commit 4b53a3412d66 ("sched/core: Remove the tsk_nr_cpus_allowed()
> wrapper") the tsk_nr_cpus_allowed() wrapper was removed. There was not
> much difference in !RT but in RT we used this to implement
> migrate_disable(). Within a migrate_disable() section the CPU mask is
> restricted to single CPU while the "normal" CPU mask remains untouched.
> 
> As an alternative implementation Ingo suggested to use
>   struct task_struct {
>   const cpumask_t *cpus_ptr;
>   cpumask_t   cpus_mask;
> };
> with
>   t->cpus_allowed_ptr = >cpus_allowed;
> 
> In -RT we then can switch the cpus_ptr to
>   t->cpus_allowed_ptr = _of(task_cpu(p));
> 
> in a migration disabled region. The rules are simple:
> - Code that 'uses' ->cpus_allowed would use the pointer.
> - Code that 'modifies' ->cpus_allowed would use the direct mask.
> 
> While converting the existing users I tried to stick with the rules
> above however… well mostly CPUFREQ tries to temporary switch the CPU
> mask to do something on a certain CPU and then switches the mask back it
> its original value. So in theory `cpus_ptr' could or should be used.
> However if this is invoked in a migration disabled region (which is not
> the case because it would require something like preempt_disable() and
> set_cpus_allowed_ptr() might sleep so it can't be) then the "restore"
> part would restore the wrong mask. So it only looks strange and I go for
> the pointer…

So maybe we could add the following facility:

ptr = sched_migrate_to_cpu_save(cpu);

...

sched_migrate_to_cpu_restore(ptr);

... and use it in the cpufreq code. Then -rt could simply define 
migrate_disable() 
to be:

ptr = sched_migrate_to_cpu_save(raw_smp_processor_id());

and define migrate_enable() as:

sched_migrate_to_cpu_restore(ptr);

... or such.

In the cpu == current_cpu case it would be super fast - otherwise it would 
migrate 
over to the target CPU first. Also note that this facility is strictly a 
special 
case for single-CPU masks and migrations - i.e. the constant pointer cpumask 
optimization would always apply.

Note that due to the use of the 'ptr' local variable the interface nests 
naturally, so this would be a legitimate use:

ptr = sched_migrate_to_cpu_save(cpu);

...
migrate_disable();
...
migrate_enable();
...

sched_migrate_to_cpu_restore(ptr);

I.e. my proposal would be to essentially upstream the -rt migrate_disable() 
facility in a slightly more generic form that would fit the cpufreq usecase.

I bet a number of the current driver's mucking with cpumask would also fit this 
new API.

Does this make sense?

Thanks,

Ingo

Re: [RFC PATCH] raid1: reset 'bi_next' before reuse the bio

[Michael Wang]

On 04/05/2017 12:17 AM, NeilBrown wrote:
[snip]
>> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
>> index 7d67235..0554110 100644
>> --- a/drivers/md/raid1.c
>> +++ b/drivers/md/raid1.c
>> @@ -1986,11 +1986,13 @@ static int fix_sync_read_error(struct r1bio *r1_bio)
>>  /* Don't try recovering from here - just fail it
>>   * ... unless it is the last working device of course */
>>  md_error(mddev, rdev);
>> -if (test_bit(Faulty, >flags))
>> +if (test_bit(Faulty, >flags)) {
>>  /* Don't try to read from here, but make sure
>>   * put_buf does it's thing
>>   */
>>  bio->bi_end_io = end_sync_write;
>> +bio->bi_next = NULL;
>> +}
>>  }
>>  
>>  while(sectors) {
> 
> 
> Ah - I see what is happening now.  I was looking at the vanilla 4.4
> code, which doesn't have the failfast changes.

My bad to forgot mention... yes our md stuff is very much close to the
upstream.

> 
> I don't think your patch is correct though.  We really shouldn't be
> re-using that bio, and setting bi_next to NULL just hides the bug.  It
> doesn't fix it.
> As the rdev is now Faulty, it doesn't make sense for
> sync_request_write() to submit a write request to it.

Make sense, while still have concerns regarding the design:
  * in this case since the read_disk already abandoned, is it fine to
keep r1_bio->read_disk recording the faulty device index?
  * we assign the 'end_sync_write' to the original read bio in this
case, but when is this supposed to be called?

> 
> Can you confirm that this works please.

Yes, it works.

Tested-by: Michael Wang 

Regards,
Michael Wang

> 
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index d2d8b8a5bd56..219f1e1f1d1d 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -2180,6 +2180,8 @@ static void sync_request_write(struct mddev *mddev, 
> struct r1bio *r1_bio)
>(i == r1_bio->read_disk ||
> !test_bit(MD_RECOVERY_SYNC, >recovery
>   continue;
> + if (test_bit(Faulty, >mirrors[i].rdev->flags))
> + continue;
>  
>   bio_set_op_attrs(wbio, REQ_OP_WRITE, 0);
>   if (test_bit(FailFast, >mirrors[i].rdev->flags))
> 
> 
> Thanks,
> NeilBrown
> 

[PATCH 3/4] treewide: convert PF_MEMALLOC manipulations to new helpers

[Vlastimil Babka]

We now have memalloc_noreclaim_{save,restore} helpers for robust setting and
clearing of PF_MEMALLOC. Let's convert the code which was using the generic
tsk_restore_flags(). No functional change.

Signed-off-by: Vlastimil Babka 
Cc: Josef Bacik 
Cc: Lee Duncan 
Cc: Chris Leech 
Cc: "David S. Miller" 
Cc: Eric Dumazet 
---
 drivers/block/nbd.c  | 7 ---
 drivers/scsi/iscsi_tcp.c | 7 ---
 net/core/dev.c   | 7 ---
 net/core/sock.c  | 7 ---
 4 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 03ae72985c79..929fc548c7fb 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -210,7 +211,7 @@ static int sock_xmit(struct nbd_device *nbd, int index, int 
send,
struct socket *sock = nbd->socks[index]->sock;
int result;
struct msghdr msg;
-   unsigned long pflags = current->flags;
+   unsigned int noreclaim_flag;
 
if (unlikely(!sock)) {
dev_err_ratelimited(disk_to_dev(nbd->disk),
@@ -221,7 +222,7 @@ static int sock_xmit(struct nbd_device *nbd, int index, int 
send,
 
msg.msg_iter = *iter;
 
-   current->flags |= PF_MEMALLOC;
+   noreclaim_flag = memalloc_noreclaim_save();
do {
sock->sk->sk_allocation = GFP_NOIO | __GFP_MEMALLOC;
msg.msg_name = NULL;
@@ -244,7 +245,7 @@ static int sock_xmit(struct nbd_device *nbd, int index, int 
send,
*sent += result;
} while (msg_data_left());
 
-   tsk_restore_flags(current, pflags, PF_MEMALLOC);
+   memalloc_noreclaim_restore(noreclaim_flag);
 
return result;
 }
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 4228aba1f654..4842fc0e809d 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -371,10 +372,10 @@ static inline int iscsi_sw_tcp_xmit_qlen(struct 
iscsi_conn *conn)
 static int iscsi_sw_tcp_pdu_xmit(struct iscsi_task *task)
 {
struct iscsi_conn *conn = task->conn;
-   unsigned long pflags = current->flags;
+   unsigned int noreclaim_flag;
int rc = 0;
 
-   current->flags |= PF_MEMALLOC;
+   noreclaim_flag = memalloc_noreclaim_save();
 
while (iscsi_sw_tcp_xmit_qlen(conn)) {
rc = iscsi_sw_tcp_xmit(conn);
@@ -387,7 +388,7 @@ static int iscsi_sw_tcp_pdu_xmit(struct iscsi_task *task)
rc = 0;
}
 
-   tsk_restore_flags(current, pflags, PF_MEMALLOC);
+   memalloc_noreclaim_restore(noreclaim_flag);
return rc;
 }
 
diff --git a/net/core/dev.c b/net/core/dev.c
index fde8b3f7136b..e0705a126b24 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -81,6 +81,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -4227,7 +4228,7 @@ static int __netif_receive_skb(struct sk_buff *skb)
int ret;
 
if (sk_memalloc_socks() && skb_pfmemalloc(skb)) {
-   unsigned long pflags = current->flags;
+   unsigned int noreclaim_flag;
 
/*
 * PFMEMALLOC skbs are special, they should
@@ -4238,9 +4239,9 @@ static int __netif_receive_skb(struct sk_buff *skb)
 * Use PF_MEMALLOC as this saves us from propagating the 
allocation
 * context down to all allocation sites.
 */
-   current->flags |= PF_MEMALLOC;
+   noreclaim_flag = memalloc_noreclaim_save();
ret = __netif_receive_skb_core(skb, true);
-   tsk_restore_flags(current, pflags, PF_MEMALLOC);
+   memalloc_noreclaim_restore(noreclaim_flag);
} else
ret = __netif_receive_skb_core(skb, false);
 
diff --git a/net/core/sock.c b/net/core/sock.c
index 392f9b6f96e2..0b2d06b4c308 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -102,6 +102,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -372,14 +373,14 @@ EXPORT_SYMBOL_GPL(sk_clear_memalloc);
 int __sk_backlog_rcv(struct sock *sk, struct sk_buff *skb)
 {
int ret;
-   unsigned long pflags = current->flags;
+   unsigned int noreclaim_flag;
 
/* these should have been dropped before queueing */
BUG_ON(!sock_flag(sk, SOCK_MEMALLOC));
 
-   current->flags |= PF_MEMALLOC;
+   noreclaim_flag = memalloc_noreclaim_save();
ret = sk->sk_backlog_rcv(sk, skb);
-   tsk_restore_flags(current, pflags, PF_MEMALLOC);
+   memalloc_noreclaim_restore(noreclaim_flag);
 
return ret;
 }
-- 
2.12.2

[PATCH 4/4] mtd: nand: nandsim: convert to memalloc_noreclaim_*()

[Vlastimil Babka]

Nandsim has own functions set_memalloc() and clear_memalloc() for robust
setting and clearing of PF_MEMALLOC. Replace them by the new generic helpers.
No functional change.

Signed-off-by: Vlastimil Babka 
Cc: Boris Brezillon 
Cc: Richard Weinberger 
---
 drivers/mtd/nand/nandsim.c | 29 +
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/nand/nandsim.c b/drivers/mtd/nand/nandsim.c
index cef818f535ed..03a0d057bf2f 100644
--- a/drivers/mtd/nand/nandsim.c
+++ b/drivers/mtd/nand/nandsim.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1368,31 +1369,18 @@ static int get_pages(struct nandsim *ns, struct file 
*file, size_t count, loff_t
return 0;
 }
 
-static int set_memalloc(void)
-{
-   if (current->flags & PF_MEMALLOC)
-   return 0;
-   current->flags |= PF_MEMALLOC;
-   return 1;
-}
-
-static void clear_memalloc(int memalloc)
-{
-   if (memalloc)
-   current->flags &= ~PF_MEMALLOC;
-}
-
 static ssize_t read_file(struct nandsim *ns, struct file *file, void *buf, 
size_t count, loff_t pos)
 {
ssize_t tx;
-   int err, memalloc;
+   int err;
+   unsigned int noreclaim_flag;
 
err = get_pages(ns, file, count, pos);
if (err)
return err;
-   memalloc = set_memalloc();
+   noreclaim_flag = memalloc_noreclaim_save();
tx = kernel_read(file, pos, buf, count);
-   clear_memalloc(memalloc);
+   memalloc_noreclaim_restore(noreclaim_flag);
put_pages(ns);
return tx;
 }
@@ -1400,14 +1388,15 @@ static ssize_t read_file(struct nandsim *ns, struct 
file *file, void *buf, size_
 static ssize_t write_file(struct nandsim *ns, struct file *file, void *buf, 
size_t count, loff_t pos)
 {
ssize_t tx;
-   int err, memalloc;
+   int err;
+   unsigned int noreclaim_flag;
 
err = get_pages(ns, file, count, pos);
if (err)
return err;
-   memalloc = set_memalloc();
+   noreclaim_flag = memalloc_noreclaim_save();
tx = kernel_write(file, buf, count, pos);
-   clear_memalloc(memalloc);
+   memalloc_noreclaim_restore(noreclaim_flag);
put_pages(ns);
return tx;
 }
-- 
2.12.2

[PATCH 1/4] mm: prevent potential recursive reclaim due to clearing PF_MEMALLOC

[Vlastimil Babka]

The function __alloc_pages_direct_compact() sets PF_MEMALLOC to prevent
deadlock during page migration by lock_page() (see the comment in
__unmap_and_move()). Then it unconditionally clears the flag, which can clear a
pre-existing PF_MEMALLOC flag and result in recursive reclaim. This was not a
problem until commit a8161d1ed609 ("mm, page_alloc: restructure direct
compaction handling in slowpath"), because direct compation was called only
after direct reclaim, which was skipped when PF_MEMALLOC flag was set.

Even now it's only a theoretical issue, as the new callsite of
__alloc_pages_direct_compact() is reached only for costly orders and when
gfp_pfmemalloc_allowed() is true, which means either __GFP_NOMEMALLOC is in
gfp_flags or in_interrupt() is true. There is no such known context, but let's
play it safe and make __alloc_pages_direct_compact() robust for cases where
PF_MEMALLOC is already set.

Fixes: a8161d1ed609 ("mm, page_alloc: restructure direct compaction handling in 
slowpath")
Reported-by: Andrey Ryabinin 
Signed-off-by: Vlastimil Babka 
Cc: 
---
 mm/page_alloc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3589f8be53be..b84e6ffbe756 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3288,6 +3288,7 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int 
order,
enum compact_priority prio, enum compact_result *compact_result)
 {
struct page *page;
+   unsigned int noreclaim_flag = current->flags & PF_MEMALLOC;
 
if (!order)
return NULL;
@@ -3295,7 +3296,7 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int 
order,
current->flags |= PF_MEMALLOC;
*compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
prio);
-   current->flags &= ~PF_MEMALLOC;
+   current->flags = (current->flags & ~PF_MEMALLOC) | noreclaim_flag;
 
if (*compact_result <= COMPACT_INACTIVE)
return NULL;
-- 
2.12.2

[PATCH 2/4] mm: introduce memalloc_noreclaim_{save,restore}

[Vlastimil Babka]

The previous patch has shown that simply setting and clearing PF_MEMALLOC in
current->flags can result in wrongly clearing a pre-existing PF_MEMALLOC flag
and potentially lead to recursive reclaim. Let's introduce helpers that support
proper nesting by saving the previous stat of the flag, similar to the existing
memalloc_noio_* and memalloc_nofs_* helpers. Convert existing setting/clearing
of PF_MEMALLOC within mm to the new helpers.

There are no known issues with the converted code, but the change makes it more
robust.

Suggested-by: Michal Hocko 
Signed-off-by: Vlastimil Babka 
---
 include/linux/sched/mm.h | 12 
 mm/page_alloc.c  | 11 ++-
 mm/vmscan.c  | 17 +++--
 3 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index 9daabe138c99..2b24a6974847 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -191,4 +191,16 @@ static inline void memalloc_nofs_restore(unsigned int 
flags)
current->flags = (current->flags & ~PF_MEMALLOC_NOFS) | flags;
 }
 
+static inline unsigned int memalloc_noreclaim_save(void)
+{
+   unsigned int flags = current->flags & PF_MEMALLOC;
+   current->flags |= PF_MEMALLOC;
+   return flags;
+}
+
+static inline void memalloc_noreclaim_restore(unsigned int flags)
+{
+   current->flags = (current->flags & ~PF_MEMALLOC) | flags;
+}
+
 #endif /* _LINUX_SCHED_MM_H */
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b84e6ffbe756..037e32dccd7a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3288,15 +3288,15 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned 
int order,
enum compact_priority prio, enum compact_result *compact_result)
 {
struct page *page;
-   unsigned int noreclaim_flag = current->flags & PF_MEMALLOC;
+   unsigned int noreclaim_flag;
 
if (!order)
return NULL;
 
-   current->flags |= PF_MEMALLOC;
+   noreclaim_flag = memalloc_noreclaim_save();
*compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
prio);
-   current->flags = (current->flags & ~PF_MEMALLOC) | noreclaim_flag;
+   memalloc_noreclaim_restore(noreclaim_flag);
 
if (*compact_result <= COMPACT_INACTIVE)
return NULL;
@@ -3443,12 +3443,13 @@ __perform_reclaim(gfp_t gfp_mask, unsigned int order,
 {
struct reclaim_state reclaim_state;
int progress;
+   unsigned int noreclaim_flag;
 
cond_resched();
 
/* We now go into synchronous reclaim */
cpuset_memory_pressure_bump();
-   current->flags |= PF_MEMALLOC;
+   noreclaim_flag = memalloc_noreclaim_save();
lockdep_set_current_reclaim_state(gfp_mask);
reclaim_state.reclaimed_slab = 0;
current->reclaim_state = _state;
@@ -3458,7 +3459,7 @@ __perform_reclaim(gfp_t gfp_mask, unsigned int order,
 
current->reclaim_state = NULL;
lockdep_clear_current_reclaim_state();
-   current->flags &= ~PF_MEMALLOC;
+   memalloc_noreclaim_restore(noreclaim_flag);
 
cond_resched();
 
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 58615bb27f2f..ff63b91a0f48 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2992,6 +2992,7 @@ unsigned long try_to_free_mem_cgroup_pages(struct 
mem_cgroup *memcg,
struct zonelist *zonelist;
unsigned long nr_reclaimed;
int nid;
+   unsigned int noreclaim_flag;
struct scan_control sc = {
.nr_to_reclaim = max(nr_pages, SWAP_CLUSTER_MAX),
.gfp_mask = (current_gfp_context(gfp_mask) & GFP_RECLAIM_MASK) |
@@ -3018,9 +3019,9 @@ unsigned long try_to_free_mem_cgroup_pages(struct 
mem_cgroup *memcg,
sc.gfp_mask,
sc.reclaim_idx);
 
-   current->flags |= PF_MEMALLOC;
+   noreclaim_flag = memalloc_noreclaim_save();
nr_reclaimed = do_try_to_free_pages(zonelist, );
-   current->flags &= ~PF_MEMALLOC;
+   memalloc_noreclaim_restore(noreclaim_flag);
 
trace_mm_vmscan_memcg_reclaim_end(nr_reclaimed);
 
@@ -3544,8 +3545,9 @@ unsigned long shrink_all_memory(unsigned long 
nr_to_reclaim)
struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask);
struct task_struct *p = current;
unsigned long nr_reclaimed;
+   unsigned int noreclaim_flag;
 
-   p->flags |= PF_MEMALLOC;
+   noreclaim_flag = memalloc_noreclaim_save();
lockdep_set_current_reclaim_state(sc.gfp_mask);
reclaim_state.reclaimed_slab = 0;
p->reclaim_state = _state;
@@ -3554,7 +3556,7 @@ unsigned long shrink_all_memory(unsigned long 
nr_to_reclaim)
 
p->reclaim_state = NULL;
lockdep_clear_current_reclaim_state();
-   p->flags &= ~PF_MEMALLOC;
+   

[tip:efi/urgent] efi/libstub: Skip GOP with PIXEL_BLT_ONLY format

[tip-bot for Cohen, Eugene]

Commit-ID:  540f4c0e894f7e46a66dfa424b16424cbdc12c38
Gitweb: http://git.kernel.org/tip/540f4c0e894f7e46a66dfa424b16424cbdc12c38
Author: Cohen, Eugene 
AuthorDate: Tue, 4 Apr 2017 16:27:43 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 09:20:18 +0200

efi/libstub: Skip GOP with PIXEL_BLT_ONLY format

The UEFI Specification permits Graphics Output Protocol (GOP) instances
without direct framebuffer access. This is indicated in the Mode structure
with a PixelFormat enumeration value of PIXEL_BLT_ONLY. Given that the
kernel does not know how to drive a Blt() only framebuffer (which is only
permitted before ExitBootServices() anyway), we should disregard such
framebuffers when looking for a GOP instance that is suitable for use as
the boot console.

So modify the EFI GOP initialization to not use a PIXEL_BLT_ONLY instance,
preventing attempts later in boot to use an invalid screen_info.lfb_base
address.

Signed-off-by: Eugene Cohen 
[ Moved the Blt() only check into the loop and clarified that Blt() only GOPs 
are unusable by the kernel. ]
Signed-off-by: Ard Biesheuvel 
Cc:  # v4.7+
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: leif.lindh...@linaro.org
Cc: linux-...@vger.kernel.org
Cc: lorenzo.pieral...@arm.com
Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...")
Link: http://lkml.kernel.org/r/20170404152744.26687-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/firmware/efi/libstub/gop.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/libstub/gop.c 
b/drivers/firmware/efi/libstub/gop.c
index 932742e..24c461d 100644
--- a/drivers/firmware/efi/libstub/gop.c
+++ b/drivers/firmware/efi/libstub/gop.c
@@ -149,7 +149,8 @@ setup_gop32(efi_system_table_t *sys_table_arg, struct 
screen_info *si,
 
status = __gop_query32(sys_table_arg, gop32, , ,
   _fb_base);
-   if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
+   if (status == EFI_SUCCESS && (!first_gop || conout_found) &&
+   info->pixel_format != PIXEL_BLT_ONLY) {
/*
 * Systems that use the UEFI Console Splitter may
 * provide multiple GOP devices, not all of which are
@@ -266,7 +267,8 @@ setup_gop64(efi_system_table_t *sys_table_arg, struct 
screen_info *si,
 
status = __gop_query64(sys_table_arg, gop64, , ,
   _fb_base);
-   if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
+   if (status == EFI_SUCCESS && (!first_gop || conout_found) &&
+   info->pixel_format != PIXEL_BLT_ONLY) {
/*
 * Systems that use the UEFI Console Splitter may
 * provide multiple GOP devices, not all of which are

Re: [tip:locking/core] rtmutex: Deboost before waking up the top waiter

[Mike Galbraith]

locking/rtmutex: Fix preempt leak in __rt_mutex_futex_unlock()

mark_wakeup_next_waiter() already disables preemption, doing so
again leaves us with an unpaired preempt_disable().

Signed-off-by: Mike Galbraith 
---
 kernel/locking/rtmutex.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1581,13 +1581,13 @@ bool __sched __rt_mutex_futex_unlock(str
return false; /* done */
}
 
-   mark_wakeup_next_waiter(wake_q, lock);
/*
-* We've already deboosted, retain preempt_disabled when dropping
-* the wait_lock to avoid inversion until the wakeup. Matched
-* by rt_mutex_postunlock();
+* We've already deboosted, mark_wakeup_next_waiter() will
+* retain preempt_disabled when we drop the wait_lock, to
+* avoid inversion prior to the wakeup.  preempt_disable()
+* therein pairs with rt_mutex_postunlock().
 */
-   preempt_disable();
+   mark_wakeup_next_waiter(wake_q, lock);
 
return true; /* call postunlock() */
 }

Re: [PATCH] arm64: perf: Count EL2 events if either of kernel and hyp are not excluded

[Will Deacon]

On Wed, Apr 05, 2017 at 09:29:32AM +0530, Ganapatrao Kulkarni wrote:
> On Tue, Apr 4, 2017 at 5:56 PM, Will Deacon  wrote:
> > On Tue, Apr 04, 2017 at 05:37:10PM +0530, Ganapatrao Kulkarni wrote:
> >> On Tue, Apr 4, 2017 at 4:48 PM, Will Deacon  wrote:
> >> > On Tue, Apr 04, 2017 at 04:10:55PM +0530, Ganapatrao Kulkarni wrote:
> >> >> commit d98ecda (arm64: perf: Count EL2 events if the kernel is running 
> >> >> in HYP)
> >> >> is returning error for perf syscall with mixed attribute set for 
> >> >> exclude_kernel
> >> >> and exlude_hv.
> >> >>
> >> >> This change is breaking some applications (observed with hhvm) when
> >> >> ran with VHE enabled. Adding change to enable EL2 event counting,
> >> >> if either of or both of exclude_kernel and exlude_hv are not set.
> >> >>
> >> >> Signed-off-by: Ganapatrao Kulkarni 
> >> >> ---
> >> >>  arch/arm64/kernel/perf_event.c | 19 ---
> >> >>  1 file changed, 12 insertions(+), 7 deletions(-)
> >> >
> >> > Hmm. When we have VHE, we can't distinguish between hypervisor and 
> >> > kernel,
> >> > so this patch doesn't seem right to me. The code currently requires
> >> > both exclude_kernel and exclude_hv to be clear before we enable profiling
> >> > EL2, otherwise we're failing to exclude samples that were asked to be
> >> > excluded.
> >>
> >> The application cant differentiate that kernel is running in EL2/VHE or in 
> >> EL1
> >> when VHE=1, is it makes sense to enable EL2 event counting when there
> >> is request from application to either include kernel or hypervisor
> >> event count, since both are same.
> >
> > You can make exactly the same argument against your proposal by saying that
> > it makes sense to disable EL2 event counting when there is a request from
> > an application to either exclude kernel or hypervisor event counting.
> 
> yes, the argument is equally valid on either side.
> 
> >
> >> IMO, it is not appropriate to have different application behaviour
> >> when kernel booted with VHE=0/1
> >
> > Then find another solution to that. How about a mechanism to advertise
> > that exclude_hv is effectively always set if the kernel is running at EL2?
> 
> I am not sure, how we can advertise to user that kernel is running at EL2.
> we may add a note to man page of perf_event_open?
> "exclude_hv is always set, if host kernel and hypervisor are running
> at same privilege level",

I was thinking of putting something into sysfs, alongside the other things
we have in there. For example, a file that describes whether any of the
perf_event_attr behave as though they are fixed to a certain value. We
should involve the perf maintainers (and perf tool developers) in this,
but perhaps something like an attr directory, where we could have a file
called exclude_hv that contains the value 1.

Will

[PATCH v5 5/7] ARM: dtsi: axp22x: add battery power supply subnode

[Quentin Schulz]

The X-Powers AXP22X PMIC exposes battery supply various data such as
the battery status (charging, discharging, full, dead), current max
limit, current current, battery capacity (in percentage), voltage max
limit, current voltage, and battery capacity (in Ah).

This adds the battery power supply subnode for AXP22X PMIC.

Signed-off-by: Quentin Schulz 
Acked-by: Maxime Ripard 
Acked-by: Chen-Yu Tsai 
---

v2:
 - changed DT node name from battery_power_supply to
 battery-power-supply,
 - removed io-channels and io-channel-names from DT (the IIO mapping is
 done in the IIO ADC driver now),

 arch/arm/boot/dts/axp22x.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/axp22x.dtsi b/arch/arm/boot/dts/axp22x.dtsi
index 67331c5..87fb08e 100644
--- a/arch/arm/boot/dts/axp22x.dtsi
+++ b/arch/arm/boot/dts/axp22x.dtsi
@@ -57,6 +57,11 @@
status = "disabled";
};
 
+   battery_power_supply: battery-power-supply {
+   compatible = "x-powers,axp221-battery-power-supply";
+   status = "disabled";
+   };
+
regulators {
/* Default work frequency for buck regulators */
x-powers,dcdc-freq = <3000>;
-- 
2.9.3

[PATCH v3 0/9] drm: rockchip: Fix rockchip drm unbind crash error

[Jeffy Chen]

Verified on rk3399 chromebook kevin:
1/ stop ui && pkill -9 frecon
2/ unbind/bind drm

Changes in v3:
Address Sean Paul 's comments.
Update commit message.
Address Sean Paul 's comments.
Update commit message.
Address Daniel Vetter 's comments.
Update commit message.
Address Daniel Vetter 's comments.
Update commit message.
Update commit message.

Changes in v2:
Fix some commit messages.

Jeffy Chen (9):
  drm: bridge: analogix: Detach panel when unbinding analogix dp
  drm: bridge: analogix: Unregister dp aux when unbinding
  drm: bridge: analogix: Destroy connector when unbinding
  drm/rockchip: cdn-dp: Don't try to release firmware when not loaded
  drm/rockchip: vop: Enable pm domain before vop_initial
  drm/rockchip: Reoder drm bind/unbind sequence
  drm/rockchip: Shutdown all crtcs when unbinding drm
  drm/rockchip: gem: Don't alloc/free gem buf when dev_private is
invalid
  drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  4 ++
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 10 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 50 --
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  8 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 29 +
 5 files changed, 66 insertions(+), 35 deletions(-)

-- 
2.1.4

[PATCH v3 6/9] drm/rockchip: Reoder drm bind/unbind sequence

[Jeffy Chen]

Current drm bind/unbind sequence would cause some memory issues.
For example we should not cleanup iommu before cleanup mode config.

Reorder bind/unbind sequence, follow exynos drm.

Signed-off-by: Jeffy Chen 
---

Changes in v3:
Address Sean Paul 's comments.
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 49 +++--
 1 file changed, 26 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index cd7d02e1..f24968f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -136,21 +136,24 @@ static int rockchip_drm_bind(struct device *dev)
INIT_LIST_HEAD(>psr_list);
spin_lock_init(>psr_list_lock);
 
+   ret = rockchip_drm_init_iommu(drm_dev);
+   if (ret)
+   goto err_free;
+
drm_mode_config_init(drm_dev);
 
rockchip_drm_mode_config_init(drm_dev);
 
-   ret = rockchip_drm_init_iommu(drm_dev);
-   if (ret)
-   goto err_config_cleanup;
-
/* Try to bind all sub drivers. */
ret = component_bind_all(dev, drm_dev);
if (ret)
-   goto err_iommu_cleanup;
+   goto err_mode_config_cleanup;
 
-   /* init kms poll for handling hpd */
-   drm_kms_helper_poll_init(drm_dev);
+   ret = drm_vblank_init(drm_dev, drm_dev->mode_config.num_crtc);
+   if (ret)
+   goto err_unbind_all;
+
+   drm_mode_config_reset(drm_dev);
 
/*
 * enable drm irq mode.
@@ -158,15 +161,12 @@ static int rockchip_drm_bind(struct device *dev)
 */
drm_dev->irq_enabled = true;
 
-   ret = drm_vblank_init(drm_dev, ROCKCHIP_MAX_CRTC);
-   if (ret)
-   goto err_kms_helper_poll_fini;
-
-   drm_mode_config_reset(drm_dev);
+   /* init kms poll for handling hpd */
+   drm_kms_helper_poll_init(drm_dev);
 
ret = rockchip_drm_fbdev_init(drm_dev);
if (ret)
-   goto err_vblank_cleanup;
+   goto err_kms_helper_poll_fini;
 
ret = drm_dev_register(drm_dev, 0);
if (ret)
@@ -175,17 +175,17 @@ static int rockchip_drm_bind(struct device *dev)
return 0;
 err_fbdev_fini:
rockchip_drm_fbdev_fini(drm_dev);
-err_vblank_cleanup:
-   drm_vblank_cleanup(drm_dev);
 err_kms_helper_poll_fini:
drm_kms_helper_poll_fini(drm_dev);
+   drm_vblank_cleanup(drm_dev);
+err_unbind_all:
component_unbind_all(dev, drm_dev);
-err_iommu_cleanup:
-   rockchip_iommu_cleanup(drm_dev);
-err_config_cleanup:
+err_mode_config_cleanup:
drm_mode_config_cleanup(drm_dev);
-   drm_dev->dev_private = NULL;
+   rockchip_iommu_cleanup(drm_dev);
 err_free:
+   drm_dev->dev_private = NULL;
+   dev_set_drvdata(dev, NULL);
drm_dev_unref(drm_dev);
return ret;
 }
@@ -194,16 +194,19 @@ static void rockchip_drm_unbind(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
 
+   drm_dev_unregister(drm_dev);
+
rockchip_drm_fbdev_fini(drm_dev);
-   drm_vblank_cleanup(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
+
+   drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
-   rockchip_iommu_cleanup(drm_dev);
drm_mode_config_cleanup(drm_dev);
+   rockchip_iommu_cleanup(drm_dev);
+
drm_dev->dev_private = NULL;
-   drm_dev_unregister(drm_dev);
-   drm_dev_unref(drm_dev);
dev_set_drvdata(dev, NULL);
+   drm_dev_unref(drm_dev);
 }
 
 static void rockchip_drm_lastclose(struct drm_device *dev)
-- 
2.1.4

[PATCH v3 7/9] drm/rockchip: Shutdown all crtcs when unbinding drm

[Jeffy Chen]

Signed-off-by: Jeffy Chen 
---

Changes in v3:
Address Daniel Vetter 's comments.
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index f24968f..c6b1b7f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -199,6 +199,7 @@ static void rockchip_drm_unbind(struct device *dev)
rockchip_drm_fbdev_fini(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
 
+   drm_atomic_helper_shutdown(drm_dev);
drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
drm_mode_config_cleanup(drm_dev);
-- 
2.1.4

[PATCH v3 1/9] drm: bridge: analogix: Detach panel when unbinding analogix dp

[Jeffy Chen]

The panel is attached when binding analogix dp.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2:
Fix some commit messages.

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index c26997a..28144a1 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1443,6 +1443,8 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
DRM_ERROR("failed to turnoff the panel\n");
+   if (drm_panel_detach(dp->plat_data->panel))
+   DRM_ERROR("failed to detach the panel\n");
}
 
pm_runtime_disable(dev);
-- 
2.1.4

[PATCH v3 5/9] drm/rockchip: vop: Enable pm domain before vop_initial

[Jeffy Chen]

We're trying to access vop registers here, so need to make sure
the pm domain is on.

Normally it should be enabled by the bootloader, but there's no
guarantee of it. And if we wanna do unbind/bind, it would also
cause the device to hang.

And this patch also does these:
1/ move vop_initial to the end of vop_bind for eaiser error handling.
2/ correct the err_put_pm_runtime of vop_enable.

Signed-off-by: Jeffy Chen 
---

Changes in v3:
Address Sean Paul 's comments.
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2151e1c..b65b296 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -506,7 +506,7 @@ static int vop_enable(struct drm_crtc *crtc)
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
-   goto err_put_pm_runtime;
+   return ret;
}
 
ret = clk_enable(vop->hclk);
@@ -1405,10 +1405,16 @@ static int vop_initial(struct vop *vop)
return PTR_ERR(vop->dclk);
}
 
+   ret = pm_runtime_get_sync(vop->dev);
+   if (ret < 0) {
+   dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
+   return ret;
+   }
+
ret = clk_prepare(vop->dclk);
if (ret < 0) {
dev_err(vop->dev, "failed to prepare dclk\n");
-   return ret;
+   goto err_put_pm_runtime;
}
 
/* Enable both the hclk and aclk to setup the vop */
@@ -1468,6 +1474,8 @@ static int vop_initial(struct vop *vop)
 
vop->is_enabled = false;
 
+   pm_runtime_put_sync(vop->dev);
+
return 0;
 
 err_disable_aclk:
@@ -1476,6 +1484,8 @@ static int vop_initial(struct vop *vop)
clk_disable_unprepare(vop->hclk);
 err_unprepare_dclk:
clk_unprepare(vop->dclk);
+err_put_pm_runtime:
+   pm_runtime_put_sync(vop->dev);
return ret;
 }
 
@@ -1576,12 +1586,6 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
if (!vop->regsbak)
return -ENOMEM;
 
-   ret = vop_initial(vop);
-   if (ret < 0) {
-   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
-   return ret;
-   }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(dev, "cannot find irq for vop\n");
@@ -1608,8 +1612,17 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
 
pm_runtime_enable(>dev);
 
+   ret = vop_initial(vop);
+   if (ret < 0) {
+   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
+   goto err_disable_pm_runtime;
+   }
+
return 0;
 
+err_disable_pm_runtime:
+   pm_runtime_disable(>dev);
+   vop_destroy_crtc(vop);
 err_enable_irq:
enable_irq(vop->irq); /* To balance out the disable_irq above */
return ret;
-- 
2.1.4

[PATCH v3 8/9] drm/rockchip: gem: Don't alloc/free gem buf when dev_private is invalid

[Jeffy Chen]

After unbinding drm, the userspace may still has a chance to access
gem buf.

Add a sanity check for a NULL dev_private to prevent that from
happening.

Signed-off-by: Jeffy Chen 
---

Changes in v3:
Address Daniel Vetter 's comments.
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e570..205a3dc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -184,6 +184,9 @@ static int rockchip_gem_alloc_buf(struct 
rockchip_gem_object *rk_obj,
struct drm_device *drm = obj->dev;
struct rockchip_drm_private *private = drm->dev_private;
 
+   if (!private)
+   return -ENODEV;
+
if (private->domain)
return rockchip_gem_alloc_iommu(rk_obj, alloc_kmap);
else
@@ -208,6 +211,11 @@ static void rockchip_gem_free_dma(struct 
rockchip_gem_object *rk_obj)
 
 static void rockchip_gem_free_buf(struct rockchip_gem_object *rk_obj)
 {
+   struct drm_device *drm = rk_obj->base.dev;
+
+   if (!drm->dev_private)
+   return;
+
if (rk_obj->pages)
rockchip_gem_free_iommu(rk_obj);
else
-- 
2.1.4

Re: [PATCH v5 14/24] dt-bindings: mfd: syscon: Add documentation for #syscon-cells property

[Kishon Vijay Abraham I]

Hi Rob,

On Saturday 01 April 2017 12:36 AM, Rob Herring wrote:
> On Fri, Mar 31, 2017 at 01:58:52PM -0500, Rob Herring wrote:
>> On Mon, Mar 27, 2017 at 03:15:10PM +0530, Kishon Vijay Abraham I wrote:
>>> Add documentation for the optional #syscon-cells property to determine
>>> the number of cells that should be given in the phandle while
>>> referencing the syscon-node.
>>>
>>> Suggested-by: Rob Herring 
>>
>> I did? When?
>>
>> I'm not remembering why we need this. Generally, phandles to a syscon 
>> are for a single defined purpose. When do we need a list of them?
> 
> Ah, I remember now the context. I suggested using standard parsing 
> function rather than open coding. I wasn't suggesting changing the 
> binding. Instead of of_parse_phandle_with_args, can't 
> of_parse_phandle_with_fixed_args work?

yes, it can be used. Will change it my next revision.

Thanks
Kishon

[PATCH] net: davinci_mdio: add GPIO reset logic

[Roger Quadros]

Some boards [1] leave the PHYs at an invalid state
during system power-up or reset thus causing unreliability
issues with the PHY like not being detected by the mdio bus
or link not functional. To work around these boards have
a GPIO connected to the PHY's reset pin.

Implement GPIO reset handling for such cases.

[1] - am572x-idk, am571x-idk, a437x-idk.

Signed-off-by: Roger Quadros 
Signed-off-by: Sekhar Nori 
---
 .../devicetree/bindings/net/davinci-mdio.txt   |  2 +
 drivers/net/ethernet/ti/davinci_mdio.c | 68 +++---
 2 files changed, 62 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/davinci-mdio.txt 
b/Documentation/devicetree/bindings/net/davinci-mdio.txt
index 621156c..fd6ebe7 100644
--- a/Documentation/devicetree/bindings/net/davinci-mdio.txt
+++ b/Documentation/devicetree/bindings/net/davinci-mdio.txt
@@ -12,6 +12,8 @@ Required properties:
 
 Optional properties:
 - ti,hwmods: Must be "davinci_mdio"
+- reset-gpios  : array of GPIO specifier for PHY hardware reset control
+- reset-delay-us   : reset assertion time [in microseconds]
 
 Note: "ti,hwmods" field is used to fetch the base address and irq
 resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c 
b/drivers/net/ethernet/ti/davinci_mdio.c
index 33df340..c6f9e55 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -40,6 +40,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 /*
  * This timeout definition is a worst-case ultra defensive measure against
@@ -53,6 +56,8 @@
 
 #define DEF_OUT_FREQ   220 /* 2.2 MHz */
 
+#define DEFAULT_GPIO_RESET_DELAY   10  /* in microseconds */
+
 struct davinci_mdio_of_param {
int autosuspend_delay_ms;
 };
@@ -104,6 +109,9 @@ struct davinci_mdio_data {
 */
boolskip_scan;
u32 clk_div;
+   struct gpio_desc **gpio_reset;
+   int num_gpios;
+   int reset_delay_us;
 };
 
 static void davinci_mdio_init_clk(struct davinci_mdio_data *data)
@@ -142,6 +150,20 @@ static void davinci_mdio_enable(struct davinci_mdio_data 
*data)
__raw_writel(data->clk_div | CONTROL_ENABLE, >regs->control);
 }
 
+static void __davinci_gpio_reset(struct davinci_mdio_data *data)
+{
+   int i;
+
+   for (i = 0; i < data->num_gpios; i++) {
+   if (!data->gpio_reset[i])
+   continue;
+
+   gpiod_set_value_cansleep(data->gpio_reset[i], 1);
+   udelay(data->reset_delay_us);
+   gpiod_set_value_cansleep(data->gpio_reset[i], 0);
+   }
+}
+
 static int davinci_mdio_reset(struct mii_bus *bus)
 {
struct davinci_mdio_data *data = bus->priv;
@@ -317,20 +339,50 @@ static int davinci_mdio_write(struct mii_bus *bus, int 
phy_id,
 }
 
 #if IS_ENABLED(CONFIG_OF)
-static int davinci_mdio_probe_dt(struct mdio_platform_data *data,
-struct platform_device *pdev)
+static int davinci_mdio_probe_dt(struct davinci_mdio_data *data,
+struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
u32 prop;
-
-   if (!node)
-   return -EINVAL;
+   int error;
+   int i;
+   struct gpio_desc *gpiod;
 
if (of_property_read_u32(node, "bus_freq", )) {
dev_err(>dev, "Missing bus_freq property in the DT.\n");
-   return -EINVAL;
+   data->pdata = default_pdata;
+   } else {
+   data->pdata.bus_freq = prop;
+   }
+
+   i = of_gpio_named_count(node, "reset-gpios");
+   if (i > 0) {
+   data->num_gpios = i;
+   data->gpio_reset = devm_kcalloc(>dev, i,
+   sizeof(struct gpio_desc *),
+   GFP_KERNEL);
+   if (!data->gpio_reset)
+   return -ENOMEM;
+
+   for (i = 0; i < data->num_gpios; i++) {
+   gpiod = devm_gpiod_get_index(>dev, "reset", i,
+GPIOD_OUT_LOW);
+   if (IS_ERR(gpiod)) {
+   error = PTR_ERR(gpiod);
+   if (error == -ENOENT)
+   continue;
+   else
+   return error;
+   }
+   data->gpio_reset[i] = gpiod;
+   }
+
+   if (of_property_read_u32(node, "reset-delay-us",
+>reset_delay_us))
+   data->reset_delay_us = DEFAULT_GPIO_RESET_DELAY;
+
+   __davinci_gpio_reset(data);
}
-   

Re: [PATCH v3 1/3] usb: udc: allow adding and removing the same gadget device

[Felipe Balbi]

Hi,

Alan Stern  writes:
>> >> allow usb_del_gadget_udc() and usb add_gadget_udc() to be called
>> >> repeatedly on the same gadget->dev structure.
>> >> 
>> >> We need to clear the gadget->dev structure so that kobject_init()
>> >> doesn't complain about already initialized object.
>> >> 
>> >> Signed-off-by: Roger Quadros 
>> >> ---
>> >>  drivers/usb/gadget/udc/core.c | 1 +
>> >>  1 file changed, 1 insertion(+)
>> >> 
>> >> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
>> >> index d685d82..efce68e 100644
>> >> --- a/drivers/usb/gadget/udc/core.c
>> >> +++ b/drivers/usb/gadget/udc/core.c
>> >> @@ -1273,6 +1273,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
>> >>   flush_work(>work);
>> >>   device_unregister(>dev);
>> >>   device_unregister(>dev);
>> >> + memset(>dev, 0x00, sizeof(gadget->dev));
>> >>  }
>> >>  EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
>> >
>> > Isn't this dangerous?  It's quite possible that the device_unregister() 
>> 
>> not on the gadget API, no.
>> 
>> > call on the previous line invokes the gadget->dev.release callback, 
>> > which might deallocate gadget.  If that happens, your new memset will 
>> > oops.
>> 
>> that won't happen. struct usb_gadget is a member of the UDC's private
>> structure, like this:
>> 
>> struct dwc3 {
>>  [...]
>>  struct usb_gadget   gadget;
>>  struct usb_gadget_driver *gadget_driver;
>>  [...]
>> };
>
> Yes.  So what?  Can't the UDC driver use the refcount inside struct 
> usb_gadget to control the lifetime of its private structure?

nope, not being used. At least not yet.

> (By the way, can you tell what's going on in net2280.c?  I must be
> missing something; it looks like gadget_release() would quickly run
> into problems because it calls dev_get_drvdata() for >dev, but
> net2280_probe() never calls dev_set_drvdata() for that device.  
> Furthermore, net2280_remove() continues to reference the net2280 struct
> after calling usb_del_gadget_udc(), and it never does seem to do a
> final put.)

static int net2280_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct net2280  *dev;
unsigned long   resource, len;
void__iomem *base = NULL;
int retval, i;

/* alloc, and start init */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (dev == NULL) {
retval = -ENOMEM;
goto done;
}

pci_set_drvdata(pdev, dev);
^^^

>> I'm actually thinking that struct usb_gadget shouldn't have a struct
>> device at all. Just a pointer to a device, that would solve all these
>> issues.
>
> A pointer to which device?  The UDC?  That would change the directory 
> layout in sysfs.

indeed. Would that be a problem?

> Or a pointer to a separate dynamically allocated device (the way struct 
> usb_hcd contains a pointer to the root hub device)?  That would work.  
> If the UDC driver wanted to re-register the gadget, it would have to 
> allocate a new device.

That could be done as well, if maintaining the directory structure is a
must.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 0/2] ARM: am335x-icev2: Add ethernet support

[Roger Quadros]

On 04/04/17 19:01, Tony Lindgren wrote:
> * Roger Quadros  [170330 05:37]:
>> Hi Tony & Dave,
>>
>> On 13/03/17 15:42, Roger Quadros wrote:
>>> Hi,
>>>
>>> This series adds ethernet support to am335x-icev2 board.
>>>
>>> The ethernet PHYs on the board need an explicit GPIO reset pulse
>>> to ensure they bootstrap to the correct mode. Without the
>>> GPIO reset they just don't work.
>>>
>>> cheers,
>>> -roger
>>
>> Any comments on this series. Patch 1 is at version 2.
> 
> I think you meant patch 2/3 is at version2. I've picked
> patches 2 and 3 for v4.12 into dt and defconfig branches.

Thanks Tony.

> 
> You may need to resend the davinci_mdio.c patch alone
> for Dave as he usually won't pick individual patches I
> think.

OK, I'll send that one separately.

cheers,
-roger

> 
> Regards,
> 
> Tony
> 
>>> Roger Quadros (2):
>>>   net: davinci_mdio: add GPIO reset logic
>>>   ARM: dts: am335x-icev2: Add CPSW ethernet0 and ethernet1
>>>
>>>  .../devicetree/bindings/net/davinci-mdio.txt   |   2 +
>>>  arch/arm/boot/dts/am335x-icev2.dts | 113 
>>> +
>>>  drivers/net/ethernet/ti/davinci_mdio.c |  68 +++--
>>>  3 files changed, 175 insertions(+), 8 deletions(-)
>>>
>>

Re: [PATCH v1] checkpatch: test missing initial blank line in block comment

[Joe Perches]

On Wed, 2017-04-05 at 08:23 +, Hugues FRUCHET wrote:
> Hi Joe, thanks for reviewing,

Hello Hugues

> I have run the command you advice on the entire kernel code, modifying 
> the script to only match the newly introduced check case.
> There was 14389 hits, quite huge, so I cannot 100% certify that there 
> are no false positives, but I have checked the output carefully and 
> found 2 limit cases:
> 
> 1) space character placed just after "/*"
> WARNING: Block comments starts with an empty /*
> #330: FILE: arch/alpha/kernel/core_irongate.c:330:
> + /*
> +  * Check for within the AGP aperture...
> => 146 hits (grep -c -n -E "\/\* $" /tmp/check.txt)
> 
> 2) // style comment followed by pointer dereference
> WARNING: Block comments starts with an empty /*
> #426: FILE: drivers/media/dvb-core/dvb_ca_en50221.c:426:
> + // success
> + *tupleType = _tupleType;
> => 4 hits
> 
> Anyway this reveal comment style related issues, so I would say that we 
> can keep script as it is, what do you think about ?

Glancing at the output, there is also the comment
in a multiline macro case:

WARNING: Block comments starts with an empty /*
#354: FILE: arch/mips/include/asm/processor.h:354:
+   /*  \
+    * Other stuff associated with the process  \

Dunno how common that is, but maybe the test
should be changed to avoid those.

[PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash

[Guochun Mao]

When nor's size larger than 16MByte, nor's address width maybe
set to 3 or 4, and controller should change address width according
to nor's setting.

Signed-off-by: Guochun Mao 
---
 drivers/mtd/spi-nor/mtk-quadspi.c |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c 
b/drivers/mtd/spi-nor/mtk-quadspi.c
index e661877..b637770 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -104,6 +104,8 @@
 #define MTK_NOR_MAX_RX_TX_SHIFT6
 /* can shift up to 56 bits (7 bytes) transfer by MTK_NOR_PRG_CMD */
 #define MTK_NOR_MAX_SHIFT  7
+/* nor controller 4-byte address mode enable bit */
+#define MTK_NOR_4B_ADDR_EN BIT(4)
 
 /* Helpers for accessing the program data / shift data registers */
 #define MTK_NOR_PRG_REG(n) (MTK_NOR_PRGDATA0_REG + 4 * (n))
@@ -230,10 +232,35 @@ static int mt8173_nor_write_buffer_disable(struct 
mt8173_nor *mt8173_nor)
  1);
 }
 
+static void mt8173_nor_set_addr_width(struct mt8173_nor *mt8173_nor)
+{
+   u8 val;
+   struct spi_nor *nor = _nor->nor;
+
+   val = readb(mt8173_nor->base + MTK_NOR_DUAL_REG);
+
+   switch (nor->addr_width) {
+   case 3:
+   val &= ~MTK_NOR_4B_ADDR_EN;
+   break;
+   case 4:
+   val |= MTK_NOR_4B_ADDR_EN;
+   break;
+   default:
+   dev_warn(mt8173_nor->dev, "Unexpected address width %u.\n",
+nor->addr_width);
+   break;
+   }
+
+   writeb(val, mt8173_nor->base + MTK_NOR_DUAL_REG);
+}
+
 static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
 {
int i;
 
+   mt8173_nor_set_addr_width(mt8173_nor);
+
for (i = 0; i < 3; i++) {
writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG + i * 
4);
addr >>= 8;
-- 
1.7.9.5

[PATCH v6 02/23] 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 
Acked-By: Joao Pinto 
Signed-off-by: Bjorn Helgaas 
---
 Documentation/PCI/00-INDEX  |   2 +
 Documentation/PCI/endpoint/pci-endpoint.txt | 215 
 2 files changed, 217 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-endpoint.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 147231f1613e..ba950b296bd8 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 ..9b1d66829290
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-endpoint.txt
@@ -0,0 +1,215 @@
+   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
+vendor ID, device ID), support other services like hot-plug, power management,
+advanced error reporting and virtual channels.
+
+However the PCI controller IP integrated in some SoCs 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 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().
+
+*) pci_epc_linkup()
+
+   In order to notify all the function devices that the EPC device to which
+   they are linked has established a link with the host, the PCI controller
+   driver should invoke pci_epc_linkup().
+
+*) pci_epc_mem_init()
+
+   Initialize the pci_epc_mem structure used for allocating EPC addr space.
+
+*) pci_epc_mem_exit()
+
+   Cleanup the pci_epc_mem structure allocated during pci_epc_mem_init().
+
+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()
+
+   

Re: in_irq_or_nmi() and RFC patch

[Mel Gorman]

On Mon, Apr 03, 2017 at 01:05:06PM +0100, Mel Gorman wrote:
> > Started performance benchmarking:
> >  163 cycles = current state
> >  183 cycles = with BH disable + in_irq
> >  218 cycles = with BH disable + in_irq + irqs_disabled
> > 
> > Thus, the performance numbers unfortunately looks bad, once we add the
> > test for irqs_disabled().  The slowdown by replacing preempt_disable
> > with BH-disable is still a win (we saved 29 cycles before, and loose
> > 20, I was expecting regression to be only 10 cycles).
> > 
> 
> This surprises me because I'm not seeing the same severity of problems
> with irqs_disabled. Your path is slower than what's currently upstream
> but it's still far better than a revert. The softirq column in the
> middle is your patch versus a full revert which is the last columnm
> 

Any objection to resending the local_bh_enable/disable patch with the
in_interrupt() check based on this data or should I post the revert and
go back to the drawing board?

-- 
Mel Gorman
SUSE Labs

[PATCH v6 19/23] 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 
Signed-off-by: Bjorn Helgaas 
---
 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 ..ad54a58d7dda
--- /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;
+

[PATCH v6 09/23] 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 
Signed-off-by: Bjorn Helgaas 
---
 drivers/pci/dwc/Kconfig  |   5 +
 drivers/pci/dwc/Makefile |   1 +
 drivers/pci/dwc/pcie-designware-ep.c | 342 +++
 drivers/pci/dwc/pcie-designware.c| 125 +
 drivers/pci/dwc/pcie-designware.h| 105 +++
 5 files changed, 578 insertions(+)
 create mode 100644 drivers/pci/dwc/pcie-designware-ep.c

diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
index d2d2ba5b8a68..d37ea72a846a 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 a2df13c28798..b38425d36200 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 ..398406393f37
--- /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;
+
+   pci_epc_linkup(epc);
+}
+
+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_writel_dbi2(pci, reg, 0x0);
+   dw_pcie_writel_dbi(pci, reg, 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);
+
+   dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid);
+   dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid);
+   dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid);
+   dw_pcie_writeb_dbi(pci, PCI_CLASS_PROG, hdr->progif_code);
+   dw_pcie_writew_dbi(pci, PCI_CLASS_DEVICE,
+  hdr->subclass_code | hdr->baseclass_code << 8);
+   dw_pcie_writeb_dbi(pci, PCI_CACHE_LINE_SIZE,
+  hdr->cache_line_size);
+   dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_VENDOR_ID,
+  hdr->subsys_vendor_id);
+   dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_ID, hdr->subsys_id);
+   dw_pcie_writeb_dbi(pci, PCI_INTERRUPT_PIN,
+  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(>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");
+   return ret;
+   }
+
+   ep->bar_to_atu[bar] = free_win;
+   set_bit(free_win, >ib_window_map);
+
+   return 0;
+}
+
+static int 

[PATCH v6 22/23] MAINTAINERS: Add PCI Endpoint maintainer

[Kishon Vijay Abraham I]

Add maintainer for the newly introduced PCI Endpoint framework.

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

diff --git a/MAINTAINERS b/MAINTAINERS
index c265a5fe4848..15ed84389092 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9581,6 +9581,15 @@ F:   include/linux/pci*
 F: arch/x86/pci/
 F: arch/x86/kernel/quirks.c
 
+PCI ENDPOINT 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)
-- 
2.11.0

[PATCH -mm] mm, swap: Remove unused function prototype

[Huang, Ying]

From: Huang Ying 

This is a code cleanup patch, no functionality changes.  There are 2
unused function prototype in swap.h, they are removed.

Signed-off-by: "Huang, Ying" 
Cc: Tim Chen 
---
 include/linux/swap.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index 486494e6b2fc..ba5882419a7d 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -411,9 +411,6 @@ struct backing_dev_info;
 extern int init_swap_address_space(unsigned int type, unsigned long nr_pages);
 extern void exit_swap_address_space(unsigned int type);
 
-extern int get_swap_slots(int n, swp_entry_t *slots);
-extern void swapcache_free_batch(swp_entry_t *entries, int n);
-
 #else /* CONFIG_SWAP */
 
 #define swap_address_space(entry)  (NULL)
-- 
2.11.0

[PATCH -mm -v2] mm, swap: Use kvzalloc to allocate some swap data structure

[Huang, Ying]

From: Huang Ying 

Now vzalloc() is used in swap code to allocate various data
structures, such as swap cache, swap slots cache, cluster info, etc.
Because the size may be too large on some system, so that normal
kzalloc() may fail.  But using kzalloc() has some advantages, for
example, less memory fragmentation, less TLB pressure, etc.  So change
the data structure allocation in swap code to use kvzalloc() which
will try kzalloc() firstly, and fallback to vzalloc() if kzalloc()
failed.

In general, kmalloc() will have less memory fragmentation than
vmalloc().  From Dave Hansen: For example, we have a two-page data
structure.  vmalloc() takes two effectively random order-0 pages,
probably from two different 2M pages and pins them.  That "kills" two
2M pages.  kmalloc(), allocating two *contiguous* pages, is very
unlikely to cross a 2M boundary (it theoretically could).  That means
it will only "kill" the possibility of a single 2M page.  More 2M
pages == less fragmentation.

The allocation in this patch occurs during swap on time, which is
usually done during system boot, so usually we have high opportunity
to allocate the contiguous pages successfully.

The allocation for swap_map[] in struct swap_info_struct is not
changed, because that is usually quite large and vmalloc_to_page() is
used for it.  That makes it a little harder to change.

Signed-off-by: Huang Ying 
Acked-by: Tim Chen 
Acked-by: Michal Hocko 
Cc: Dave Hansen 
Cc: Hugh Dickins 
Cc: Shaohua Li 
Cc: Minchan Kim 
Cc: Rik van Riel 

v2:

- Use common kvzalloc() instead of self-made swap_kvzalloc().
---
 mm/swap_slots.c | 19 +++
 mm/swap_state.c |  2 +-
 mm/swapfile.c   | 10 ++
 3 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/mm/swap_slots.c b/mm/swap_slots.c
index aa1c415f4abd..58f6c78f1dad 100644
--- a/mm/swap_slots.c
+++ b/mm/swap_slots.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_SWAP
 
@@ -119,16 +120,18 @@ static int alloc_swap_slot_cache(unsigned int cpu)
 
/*
 * Do allocation outside swap_slots_cache_mutex
-* as vzalloc could trigger reclaim and get_swap_page,
+* as kvzalloc could trigger reclaim and get_swap_page,
 * which can lock swap_slots_cache_mutex.
 */
-   slots = vzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE);
+   slots = kvzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE,
+GFP_KERNEL);
if (!slots)
return -ENOMEM;
 
-   slots_ret = vzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE);
+   slots_ret = kvzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE,
+GFP_KERNEL);
if (!slots_ret) {
-   vfree(slots);
+   kvfree(slots);
return -ENOMEM;
}
 
@@ -152,9 +155,9 @@ static int alloc_swap_slot_cache(unsigned int cpu)
 out:
mutex_unlock(_slots_cache_mutex);
if (slots)
-   vfree(slots);
+   kvfree(slots);
if (slots_ret)
-   vfree(slots_ret);
+   kvfree(slots_ret);
return 0;
 }
 
@@ -171,7 +174,7 @@ static void drain_slots_cache_cpu(unsigned int cpu, 
unsigned int type,
cache->cur = 0;
cache->nr = 0;
if (free_slots && cache->slots) {
-   vfree(cache->slots);
+   kvfree(cache->slots);
cache->slots = NULL;
}
mutex_unlock(>alloc_lock);
@@ -186,7 +189,7 @@ static void drain_slots_cache_cpu(unsigned int cpu, 
unsigned int type,
}
spin_unlock_irq(>free_lock);
if (slots)
-   vfree(slots);
+   kvfree(slots);
}
 }
 
diff --git a/mm/swap_state.c b/mm/swap_state.c
index 7bfb9bd1ca21..539b8885e3d1 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -523,7 +523,7 @@ int init_swap_address_space(unsigned int type, unsigned 
long nr_pages)
unsigned int i, nr;
 
nr = DIV_ROUND_UP(nr_pages, SWAP_ADDRESS_SPACE_PAGES);
-   spaces = vzalloc(sizeof(struct address_space) * nr);
+   spaces = kvzalloc(sizeof(struct address_space) * nr, GFP_KERNEL);
if (!spaces)
return -ENOMEM;
for (i = 0; i < nr; i++) {
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 53b5881ee0d6..90054f3c2cdc 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -2272,8 +2272,8 @@ SYSCALL_DEFINE1(swapoff, const char __user *, specialfile)
free_percpu(p->percpu_cluster);
p->percpu_cluster = NULL;
vfree(swap_map);
-   vfree(cluster_info);
-   vfree(frontswap_map);
+   kvfree(cluster_info);
+   kvfree(frontswap_map);
/* Destroy 

Re: [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts

[Maxime Ripard]

On Wed, Apr 05, 2017 at 02:45:17AM +0800, Icenowy Zheng wrote:
> As we added USB0 route auto switching support for A64, add related
> device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the
> pmu0 memory area for PHY).
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 1c64ea2d23f9..a8916df99048 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -179,8 +179,10 @@
>   usbphy: phy@01c19400 {
>   compatible = "allwinner,sun50i-a64-usb-phy";
>   reg = <0x01c19400 0x14>,
> +   <0x01c1a800 0x4>,
> <0x01c1b800 0x4>;
>   reg-names = "phy_ctrl",
> + "pmu0",

This breaks the older DTs, and that property isn't documented.

Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH v2] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[Michal Hocko]

On Wed 05-04-17 14:33:50, NeilBrown wrote:
> 
> When a filesystem is mounted from a loop device, writes are
> throttled by balance_dirty_pages() twice: once when writing
> to the filesystem and once when the loop_handle_cmd() writes
> to the backing file.  This double-throttling can trigger
> positive feedback loops that create significant delays.  The
> throttling at the lower level is seen by the upper level as
> a slow device, so it throttles extra hard.
> 
> The PF_LESS_THROTTLE flag was created to handle exactly this
> circumstance, though with an NFS filesystem mounted from a
> local NFS server.  It reduces the throttling on the lower
> layer so that it can proceed largely unthrottled.
> 
> To demonstrate this, create a filesystem on a loop device
> and write (e.g. with dd) several large files which combine
> to consume significantly more than the limit set by
> /proc/sys/vm/dirty_ratio or dirty_bytes.  Measure the total
> time taken.
> 
> When I do this directly on a device (no loop device) the
> total time for several runs (mkfs, mount, write 200 files,
> umount) is fairly stable: 28-35 seconds.
> When I do this over a loop device the times are much worse
> and less stable.  52-460 seconds.  Half below 100seconds,
> half above.
> When I apply this patch, the times become stable again,
> though not as fast as the no-loop-back case: 53-72 seconds.
> 
> There may be room for further improvement as the total overhead still
> seems too high, but this is a big improvement.
> 
> Reviewed-by: Christoph Hellwig 
> Acked-by: Michal Hocko 
> Signed-off-by: NeilBrown 
> ---
> 
> I moved where the flag is set, thanks to suggestion from
> Ming Lei.
> I've preserved the *-by: tags I was offered despite the code
> being different, as the concept is identical.
> 
> Thanks,
> NeilBrown
> 
> 
>  drivers/block/loop.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 0ecb6461ed81..44b3506fd086 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -852,6 +852,7 @@ static int loop_prepare_queue(struct loop_device *lo)
>   if (IS_ERR(lo->worker_task))
>   return -ENOMEM;
>   set_user_nice(lo->worker_task, MIN_NICE);
> + lo->worker_task->flags |= PF_LESS_THROTTLE;
>   return 0;

As mentioned elsewhere, PF flags should be updated only on the current
task otherwise there is potential rmw race. Is this safe? The code runs
concurrently with the worker thread.


-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] loop: Add PF_LESS_THROTTLE to block/loop device thread.

[Michal Hocko]

On Wed 05-04-17 09:19:27, Michal Hocko wrote:
> On Wed 05-04-17 14:33:50, NeilBrown wrote:
[...]
> > diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> > index 0ecb6461ed81..44b3506fd086 100644
> > --- a/drivers/block/loop.c
> > +++ b/drivers/block/loop.c
> > @@ -852,6 +852,7 @@ static int loop_prepare_queue(struct loop_device *lo)
> > if (IS_ERR(lo->worker_task))
> > return -ENOMEM;
> > set_user_nice(lo->worker_task, MIN_NICE);
> > +   lo->worker_task->flags |= PF_LESS_THROTTLE;
> > return 0;
> 
> As mentioned elsewhere, PF flags should be updated only on the current
> task otherwise there is potential rmw race. Is this safe? The code runs
> concurrently with the worker thread.

I believe you need something like this instead
---
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index f347285c67ec..07b2a909e4fb 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -844,10 +844,16 @@ static void loop_unprepare_queue(struct loop_device *lo)
kthread_stop(lo->worker_task);
 }
 
+int loop_kthread_worker_fn(void *worker_ptr)
+{
+   current->flags |= PF_LESS_THROTTLE;
+   return kthread_worker_fn(worker_ptr);
+}
+
 static int loop_prepare_queue(struct loop_device *lo)
 {
kthread_init_worker(>worker);
-   lo->worker_task = kthread_run(kthread_worker_fn,
+   lo->worker_task = kthread_run(loop_kthread_worker_fn,
>worker, "loop%d", lo->lo_number);
if (IS_ERR(lo->worker_task))
return -ENOMEM;
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts

[Icenowy Zheng]

在 2017年04月05日 15:26, Maxime Ripard 写道:

On Wed, Apr 05, 2017 at 03:17:19PM +0800, Icenowy Zheng wrote:



在 2017年04月05日 15:15, Maxime Ripard 写道:

On Wed, Apr 05, 2017 at 02:45:17AM +0800, Icenowy Zheng wrote:

As we added USB0 route auto switching support for A64, add related
device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the
pmu0 memory area for PHY).

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1c64ea2d23f9..a8916df99048 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -179,8 +179,10 @@
usbphy: phy@01c19400 {
compatible = "allwinner,sun50i-a64-usb-phy";
reg = <0x01c19400 0x14>,
+ <0x01c1a800 0x4>,
  <0x01c1b800 0x4>;
reg-names = "phy_ctrl",
+   "pmu0",


This breaks the older DTs, and that property isn't documented.


It's already documented.

In the H3 dual-route patchset I have already added this.

("  * "pmu0" for H3, V3s and A64")


This is not in linux-next then, sorry.


It's already in next-20160405.




P.S. to be compatible with older DTs, I think I should adjust
the phy driver, make it enable dual-route function only when
pmu0 is present.


That, or if we're quick enough, we can still add it to 4.11. There's a
bit of time left.


Thus the device tree binding patch and the DT part of this patchset
should be all pushed to 4.11 .

The device tree binding patch is commit ee73fd7dfc86 ("dt: bindings: add 
pmu0 regs for USB PHYs on Allwinner H3/V3s/A64").




Maxime

Re: [1/2] wireless: ath9k_htc: fix NULL-deref at probe

[Kalle Valo]

Johan Hovold  wrote:
> Make sure to check the number of endpoints to avoid dereferencing a
> NULL-pointer or accessing memory beyond the endpoint array should a
> malicious device lack the expected endpoints.
> 
> Fixes: 36bcce430657 ("ath9k_htc: Handle storage devices")
> Cc: Sujith Manoharan 
> Signed-off-by: Johan Hovold 

Patch applied to ath-next branch of ath.git, thanks.

ebeb36670eca ath9k_htc: fix NULL-deref at probe

-- 
https://patchwork.kernel.org/patch/9620723/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[PATCH] fixup! gpu: host1x: Add IOMMU support

[Mikko Perttunen]

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/dev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index f8fda446a6a6..f05ebb14fa63 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -27,6 +27,7 @@
 
 #define CREATE_TRACE_POINTS
 #include 
+#undef CREATE_TRACE_POINTS
 
 #include "bus.h"
 #include "channel.h"
-- 
2.11.1

RE: [PATCH kernel v8 2/4] virtio-balloon: VIRTIO_BALLOON_F_CHUNK_TRANSFER

[Wang, Wei W]

On Wednesday, April 5, 2017 12:31 PM, Wei Wang wrote:
> On Wednesday, April 5, 2017 11:54 AM, Michael S. Tsirkin wrote:
> > On Wed, Apr 05, 2017 at 03:31:36AM +, Wang, Wei W wrote:
> > > On Thursday, March 16, 2017 3:09 PM Wei Wang wrote:
> > > > The implementation of the current virtio-balloon is not very
> > > > efficient, because the ballooned pages are transferred to the host
> > > > one by one. Here is the breakdown of the time in percentage spent
> > > > on each step of the balloon inflating process (inflating 7GB of an 8GB 
> > > > idle
> guest).
> > > >
> > > > 1) allocating pages (6.5%)
> > > > 2) sending PFNs to host (68.3%)
> > > > 3) address translation (6.1%)
> > > > 4) madvise (19%)
> > > >
> > > > It takes about 4126ms for the inflating process to complete.
> > > > The above profiling shows that the bottlenecks are stage 2) and stage 
> > > > 4).
> > > >
> > > > This patch optimizes step 2) by transferring pages to the host in
> > > > chunks. A chunk consists of guest physically continuous pages, and
> > > > it is offered to the host via a base PFN (i.e. the start PFN of
> > > > those physically continuous pages) and the size (i.e. the total
> > > > number of the
> > pages). A chunk is formated as below:
> > > >
> > > > 
> > > > | Base (52 bit)| Rsvd (12 bit) |
> > > > 
> > > > 
> > > > | Size (52 bit)| Rsvd (12 bit) |
> > > > 
> > > >
> > > > By doing so, step 4) can also be optimized by doing address
> > > > translation and
> > > > madvise() in chunks rather than page by page.
> > > >
> > > > This optimization requires the negotiation of a new feature bit,
> > > > VIRTIO_BALLOON_F_CHUNK_TRANSFER.
> > > >
> > > > With this new feature, the above ballooning process takes ~590ms
> > > > resulting in an improvement of ~85%.
> > > >
> > > > TODO: optimize stage 1) by allocating/freeing a chunk of pages
> > > > instead of a single page each time.
> > > >
> > > > Signed-off-by: Liang Li 
> > > > Signed-off-by: Wei Wang 
> > > > Suggested-by: Michael S. Tsirkin 
> > > > ---
> > > >  drivers/virtio/virtio_balloon.c | 371
> > +-
> > > > --
> > > >  include/uapi/linux/virtio_balloon.h |   9 +
> > > >  2 files changed, 353 insertions(+), 27 deletions(-)
> > > >
> > > > diff --git a/drivers/virtio/virtio_balloon.c
> > > > b/drivers/virtio/virtio_balloon.c index
> > > > f59cb4f..3f4a161 100644
> > > > --- a/drivers/virtio/virtio_balloon.c
> > > > +++ b/drivers/virtio/virtio_balloon.c
> > > > @@ -42,6 +42,10 @@
> > > >  #define OOM_VBALLOON_DEFAULT_PAGES 256  #define
> > > > VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> > > >
> > > > +#define PAGE_BMAP_SIZE (8 * PAGE_SIZE)
> > > > +#define PFNS_PER_PAGE_BMAP (PAGE_BMAP_SIZE * BITS_PER_BYTE)
> > > > +#define PAGE_BMAP_COUNT_MAX32
> > > > +
> > > >  static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
> > > > module_param(oom_pages, int, S_IRUSR | S_IWUSR);
> > > > MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); @@ -50,6
> > +54,14
> > > > @@ MODULE_PARM_DESC(oom_pages, "pages to free on OOM");  static
> > > > struct vfsmount *balloon_mnt;  #endif
> > > >
> > > > +#define BALLOON_CHUNK_BASE_SHIFT 12 #define
> > > > +BALLOON_CHUNK_SIZE_SHIFT 12 struct balloon_page_chunk {
> > > > +   __le64 base;
> > > > +   __le64 size;
> > > > +};
> > > > +
> > > > +typedef __le64 resp_data_t;
> > > >  struct virtio_balloon {
> > > > struct virtio_device *vdev;
> > > > struct virtqueue *inflate_vq, *deflate_vq, *stats_vq; @@ -67,6
> > > > +79,31 @@ struct virtio_balloon {
> > > >
> > > > /* Number of balloon pages we've told the Host we're not using. 
> > > > */
> > > > unsigned int num_pages;
> > > > +   /* Pointer to the response header. */
> > > > +   struct virtio_balloon_resp_hdr *resp_hdr;
> > > > +   /* Pointer to the start address of response data. */
> > > > +   resp_data_t *resp_data;
> > >
> > > I think the implementation has an issue here - both the balloon
> > > pages and the
> > unused pages use the same buffer ("resp_data" above) to store chunks.
> > It would cause a race in this case: live migration starts while ballooning 
> > is also
> in progress.
> > I plan to use separate buffers for CHUNKS_OF_BALLOON_PAGES and
> > CHUNKS_OF_UNUSED_PAGES. Please let me know if you have a different
> > suggestion. Thanks.
> > >
> > > Best,
> > > Wei
> >
> > Is only one resp data ever in flight for each kind?
> > If not you want as many buffers as vq allows.
> >
> 
> No, all the kinds were using only one resp_data. I will make it one resp_data 
> for
> each kind.
> 

Just in case it wasn't well explained - it is one resp data in flight for each 

[PATCH 0/4] more robust PF_MEMALLOC handling

[Vlastimil Babka]

Hi,

this series aims to unify the setting and clearing of PF_MEMALLOC, which
prevents recursive reclaim. There are some places that clear the flag
unconditionally from current->flags, which may result in clearing a
pre-existing flag. This already resulted in a bug report that Patch 1 fixes
(without the new helpers, to make backporting easier). Patch 2 introduces the
new helpers, modelled after existing memalloc_noio_* and memalloc_nofs_*
helpers, and converts mm core to use them. Patches 3 and 4 convert non-mm code.

Based on next-20170404.

Vlastimil Babka (4):
  mm: prevent potential recursive reclaim due to clearing PF_MEMALLOC
  mm: introduce memalloc_noreclaim_{save,restore}
  treewide: convert PF_MEMALLOC manipulations to new helpers
  mtd: nand: nandsim: convert to memalloc_noreclaim_*()

 drivers/block/nbd.c|  7 ---
 drivers/mtd/nand/nandsim.c | 29 +
 drivers/scsi/iscsi_tcp.c   |  7 ---
 include/linux/sched/mm.h   | 12 
 mm/page_alloc.c| 10 ++
 mm/vmscan.c| 17 +++--
 net/core/dev.c |  7 ---
 net/core/sock.c|  7 ---
 8 files changed, 54 insertions(+), 42 deletions(-)

-- 
2.12.2

Re: [PATCH v2 2/4] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend

[Lucas Stach]

Am Dienstag, den 04.04.2017, 20:04 +0300 schrieb Leonard Crestez:
> If the cpufreq driver tries to modify voltage/freq during suspend/resume
> it might need to control an external PMIC via I2C or SPI but those
> devices might be already suspended. This issue is likely to happen
> whenever the LDOs have their vin-supply set.
> 
> To avoid this scenario we just increase cpufreq to the maximum before
> suspend.
> 
> Signed-off-by: Leonard Crestez 

Reviewed-by: Lucas Stach 

> ---
>  drivers/cpufreq/imx6q-cpufreq.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> index be90ee3..786122e 100644
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -161,8 +161,13 @@ static int imx6q_set_target(struct cpufreq_policy 
> *policy, unsigned int index)
>  
>  static int imx6q_cpufreq_init(struct cpufreq_policy *policy)
>  {
> + int ret;
> +
>   policy->clk = arm_clk;
> - return cpufreq_generic_init(policy, freq_table, transition_latency);
> + ret = cpufreq_generic_init(policy, freq_table, transition_latency);
> + policy->suspend_freq = policy->max;
> +
> + return ret;
>  }
>  
>  static struct cpufreq_driver imx6q_cpufreq_driver = {
> @@ -173,6 +178,7 @@ static struct cpufreq_driver imx6q_cpufreq_driver = {
>   .init = imx6q_cpufreq_init,
>   .name = "imx6q-cpufreq",
>   .attr = cpufreq_generic_attr,
> + .suspend = cpufreq_generic_suspend,
>  };
>  
>  static int imx6q_cpufreq_probe(struct platform_device *pdev)

[tip:efi/urgent] efi/fb: Avoid reconfiguration of BAR that covers the framebuffer

[tip-bot for Ard Biesheuvel]

Commit-ID:  5a8997342183bb792fe2c15cecf371665d784dd7
Gitweb: http://git.kernel.org/tip/5a8997342183bb792fe2c15cecf371665d784dd7
Author: Ard Biesheuvel 
AuthorDate: Tue, 4 Apr 2017 16:27:44 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 5 Apr 2017 09:20:18 +0200

efi/fb: Avoid reconfiguration of BAR that covers the framebuffer

On UEFI systems, the PCI subsystem is enumerated by the firmware,
and if a graphical framebuffer is exposed via a PCI device, its base
address and size are exposed to the OS via the Graphics Output
Protocol (GOP).

On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
scratch at boot. This may result in the GOP framebuffer address to
become stale, if the BAR covering the framebuffer is modified. This
will cause the framebuffer to become unresponsive, and may in some
cases result in unpredictable behavior if the range is reassigned to
another device.

So add a non-x86 quirk to the EFI fb driver to find the BAR associated
with the GOP base address, and claim the BAR resource so that the PCI
core will not move it.

Signed-off-by: Ard Biesheuvel 
Cc:  # v4.7+
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: leif.lindh...@linaro.org
Cc: linux-...@vger.kernel.org
Cc: lorenzo.pieral...@arm.com
Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...")
Link: http://lkml.kernel.org/r/20170404152744.26687-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
---
 drivers/video/fbdev/efifb.c | 66 -
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 8c4dc1e..758960b 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -143,6 +144,8 @@ static struct attribute *efifb_attrs[] = {
 };
 ATTRIBUTE_GROUPS(efifb);
 
+static bool pci_dev_disabled;  /* FB base matches BAR of a disabled device */
+
 static int efifb_probe(struct platform_device *dev)
 {
struct fb_info *info;
@@ -152,7 +155,7 @@ static int efifb_probe(struct platform_device *dev)
unsigned int size_total;
char *option = NULL;
 
-   if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+   if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
return -ENODEV;
 
if (fb_get_options("efifb", ))
@@ -360,3 +363,64 @@ static struct platform_driver efifb_driver = {
 };
 
 builtin_platform_driver(efifb_driver);
+
+#ifndef CONFIG_X86
+
+static bool pci_bar_found; /* did we find a BAR matching the efifb base? */
+
+static void claim_efifb_bar(struct pci_dev *dev, int idx)
+{
+   u16 word;
+
+   pci_bar_found = true;
+
+   pci_read_config_word(dev, PCI_COMMAND, );
+   if (!(word & PCI_COMMAND_MEMORY)) {
+   pci_dev_disabled = true;
+   dev_err(>dev,
+   "BAR %d: assigned to efifb but device is disabled!\n",
+   idx);
+   return;
+   }
+
+   if (pci_claim_resource(dev, idx)) {
+   pci_dev_disabled = true;
+   dev_err(>dev,
+   "BAR %d: failed to claim resource for efifb!\n", idx);
+   return;
+   }
+
+   dev_info(>dev, "BAR %d: assigned to efifb\n", idx);
+}
+
+static void efifb_fixup_resources(struct pci_dev *dev)
+{
+   u64 base = screen_info.lfb_base;
+   u64 size = screen_info.lfb_size;
+   int i;
+
+   if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+   return;
+
+   if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
+   base |= (u64)screen_info.ext_lfb_base << 32;
+
+   if (!base)
+   return;
+
+   for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
+   struct resource *res = >resource[i];
+
+   if (!(res->flags & IORESOURCE_MEM))
+   continue;
+
+   if (res->start <= base && res->end >= base + size - 1) {
+   claim_efifb_bar(dev, i);
+   break;
+   }
+   }
+}
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY,
+  16, efifb_fixup_resources);
+
+#endif

Re: [linux-sunxi] Re: [PATCH 10/11] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Maxime Ripard]

On Wed, Apr 05, 2017 at 02:15:43PM +0800, Icenowy Zheng wrote:
> 
> 2017年4月5日 14:13于 Maxime Ripard 写道：
> >
> > On Wed, Apr 05, 2017 at 02:01:44AM +0800, Icenowy Zheng wrote: 
> > > Add support of AXP803 regulators in the Pine64 device tree, in order to 
> > > enable many future functionalities, e.g. Wi-Fi. 
> > > 
> > > Signed-off-by: Icenowy Zheng  
> > > --- 
> > >  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 
> > >+ 
> > >  1 file changed, 109 insertions(+) 
> > > 
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
> > > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
> > > index 2132d8e6cb3d..7da074f95065 100644 
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
> > > @@ -106,6 +106,115 @@ 
> > >  }; 
> > >  }; 
> > >  
> > > +#include "axp803.dtsi" 
> > > + 
> > > +_aldo1 { 
> > > + regulator-min-microvolt = <280>; 
> > > + regulator-max-microvolt = <280>; 
> > > + regulator-name = "vcc-csi"; 
> > > +}; 
> > > + 
> > > +_aldo2 { 
> > > + regulator-always-on; 
> > > + regulator-min-microvolt = <180>; 
> > > + regulator-max-microvolt = <330>; 
> > > + regulator-name = "vcc-pl"; 
> > > +}; 
> > > + 
> > > +_aldo3 { 
> > > + regulator-always-on; 
> > > + regulator-min-microvolt = <270>; 
> > > + regulator-max-microvolt = <330>; 
> > > + regulator-name = "vcc-pll-avcc"; 
> > > +}; 
> > > + 
> > > +_dc1sw { 
> > > + regulator-name = "vcc-phy"; 
> > > +}; 
> > > + 
> > > +_dcdc1 { 
> > > + regulator-always-on; 
> > > + regulator-min-microvolt = <330>; 
> > > + regulator-max-microvolt = <330>; 
> > > + regulator-name = "vcc-3v3"; 
> > > +}; 
> > > + 
> > > +_dcdc2 { 
> > > + regulator-always-on; 
> > > + regulator-min-microvolt = <100>; 
> > > + regulator-max-microvolt = <130>; 
> > > + regulator-name = "vdd-cpux"; 
> > > +}; 
> > > + 
> > > +/* DCDC3 is polyphased with DCDC2 */ 
> > > + 
> > > +_dcdc5 { 
> > > + regulator-always-on; 
> > > + regulator-min-microvolt = <150>; 
> > > + regulator-max-microvolt = <150>; 
> > > + regulator-name = "vcc-dram"; 
> > > +}; 
> > > + 
> > > +_dcdc6 { 
> > > + regulator-always-on; 
> > > + regulator-min-microvolt = <110>; 
> > > + regulator-max-microvolt = <110>; 
> > > + regulator-name = "vdd-sys"; 
> > > +}; 
> > > + 
> > > +_dldo1 { 
> > > + regulator-min-microvolt = <330>; 
> > > + regulator-max-microvolt = <330>; 
> > > + regulator-name = "vcc-hdmi"; 
> > > +}; 
> > > + 
> > > +_dldo2 { 
> > > + regulator-min-microvolt = <330>; 
> > > + regulator-max-microvolt = <330>; 
> > > + regulator-name = "vcc-mipi"; 
> > > +}; 
> > > + 
> > > +_dldo3 { 
> > > + regulator-min-microvolt = <330>; 
> > > + regulator-max-microvolt = <330>; 
> > > + regulator-name = "avdd-csi"; 
> > > +}; 
> > > + 
> > > +_dldo4 { 
> > > + regulator-min-microvolt = <330>; 
> > > + regulator-max-microvolt = <330>; 
> > > + regulator-name = "vcc-wifi"; 
> > > +}; 
> > > + 
> > > +_eldo1 { 
> > > + regulator-min-microvolt = <180>; 
> > > + regulator-max-microvolt = <180>; 
> > > + regulator-name = "cpvdd"; 
> > > +}; 
> > > + 
> > > +_eldo3 { 
> > > + regulator-min-microvolt = <180>; 
> > > + regulator-max-microvolt = <180>; 
> > > + regulator-name = "vdd-1v8-csi"; 
> > > +}; 
> > > + 
> > > +_fldo1 { 
> > > + regulator-min-microvolt = <120>; 
> > > + regulator-max-microvolt = <120>; 
> > > + regulator-name = "vcc-1v2-hsic"; 
> > > +}; 
> > > + 
> > > +_fldo2 { 
> > > + regulator-always-on; 
> > > + regulator-min-microvolt = <110>; 
> > > + regulator-max-microvolt = <110>; 
> > > + regulator-name = "vdd-cpus"; 
> > > +}; 
> >
> > Why do you need to always power the AR100 on? 
> 
> It's for CPUS power domain, not the AR100 processor.
> 
> Kill it will lead to instantly system hang.

What are you calling CPUS then?

Maxime

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


signature.asc
Description: PGP signature

Re: ia64 exceptions (Re: [RFC][CFT][PATCHSET v1] uaccess unification)

[Al Viro]

On Wed, Apr 05, 2017 at 06:05:08AM +0100, Al Viro wrote:

> Speaking of ia64: copy_user.S contains the following oddity:
> 2:
> EX(.failure_in3,(p16) ld8 val1[0]=[src1],16)
> (p16)   ld8 val2[0]=[src2],16
> 
> src1 is 16-byte aligned, src2 is src1 + 8.
> 
> What guarantees that we can't race with e.g. TLB shootdown from a thread on
> another CPU, ending up with the second insn taking a fault and oopsing?
> 
> AFAICS, other places where we have such pairs of loads or stores (e.g.
> EX(.ex_handler, (p16)   ld8 r34=[src0],16)
> EK(.ex_handler, (p16)   ld8 r38=[src1],16)
> in the memcpy_mck.S counterpart of that code) both have exception table
> entries associated with them.
> 
> Is that one intentional and correct for some subtle reason, or is it a very
> narrow race on the hardware nobody gives a damn anymore?  It is pre-mckinley
> stuff, after all...

Actually, the piece immediately after that one is worse.  By that point,
we have
* checked that len is large enough to be worth bothering with word
copies.  Fine.
* checked that src and dst have the same remainder modulo 8.
* copied until src is a multiple of 16, incrementing src and dst
by the same amount.
* prepared for copying in multiples of 16 bytes
* set src2 and dst2 8 bytes past src1 and dst1 resp.
and now we have a pipelined loop with
EX(.failure_in3,(p16) ld8 val1[0]=[src1],16)
(p16)   ld8 val2[0]=[src2],16

EX(.failure_out, (EPI)  st8 [dst1]=val1[PIPE_DEPTH-1],16)
(EPI)   st8 [dst2]=val2[PIPE_DEPTH-1],16
for body.  Now, consider the following case:

* to is 8 bytes before the end of user page, next page is unmapped
* from is at the beginning of kernel page
* len is simply PAGE_SIZE

and we call copy_to_user().  All the preparation work won't read or write
anything - all alignments are fine.  src1 and src2 are kernel page and
kernel page + 8 resp.; dst1 is 8 bytes before the end of user page, dst2
is at the beginning of unmapped user page.  No loads are going to fail;
the first store into dst1 won't fail either.  The *second* store - one to
dst2 will not just fail, it'll oops.



... and sure enough, on generic kernel (CONFIG_ITANIUM) that yields a nice
shiny oops at precisely that insn.

We really need tests for uaccess primitives.  That's not a recent regression,
BTW - it had been that way since 2.3.48-pre2, as far as I can see.

Re: [PATCH] sched: Fix numabalancing to work with isolated cpus

[Mel Gorman]

On Wed, Apr 05, 2017 at 07:20:06AM +0530, Srikar Dronamraju wrote:
> > > 
> > > To avoid this, please check for isolated cpus before choosing a target
> > > cpu.
> > > 
> > 
> > Hmm, would this also prevent a task running inside a cgroup that is
> > allowed accessed to isolated CPUs from balancing? I severely doubt it
> 
> Scheduler doesn't do any kind of load balancing for isolated cpus.
> 

I was referring specifically to numa balancing, not load balancing but I
should have been clearer.

> > matters because if a process is isolated from interference then it
> > follows that automatic NUMA balancing should not be involved. If
> 
> Yes, as an extension of the above, numa balancing should not be
> involved.
> 

If anything, it arguably is a more sensible fix. If tasks on isolated CPUs
should not be interfered with then that should include the NUMA scanner
running in task context. IIf the PTEs are not updated then the faults are
not incurred which would be a much larger saving in overhead overall. There
would be a potential corner case where two threads in the same address
space run in separate cpusets but it would be somewhat of an odd cornercase.

-- 
Mel Gorman
SUSE Labs

Re: [linux-sunxi] Re: [PATCH v3 04/11] drm/sun4i: abstract the layer type

[Maxime Ripard]

On Wed, Apr 05, 2017 at 01:23:15PM +0800, Icenowy Zheng wrote:
> 
> 2017年4月5日 10:27于 Chen-Yu Tsai 写道：
> >
> > On Wed, Apr 5, 2017 at 3:53 AM, Icenowy Zheng  wrote: 
> > > 
> > > 
> > > 在 2017年04月05日 03:28, Sean Paul 写道: 
> > >> 
> > >> On Thu, Mar 30, 2017 at 03:46:06AM +0800, Icenowy Zheng wrote: 
> > >>> 
> > >>> As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm 
> > >>> driver, we will finally have two types of layer. 
> > >>> 
> > >>> Abstract the layer type to void * and a ops struct, which contains the 
> > >>> only function used by crtc -- get the drm_plane struct of the layer. 
> > >>> 
> > >>> Signed-off-by: Icenowy Zheng  
> > >>> --- 
> > >>> Refactored patch in v3. 
> > >>> 
> > >>>  drivers/gpu/drm/sun4i/sun4i_crtc.c  | 19 +++ 
> > >>>  drivers/gpu/drm/sun4i/sun4i_crtc.h  |  3 ++- 
> > >>>  drivers/gpu/drm/sun4i/sun4i_layer.c | 19 ++- 
> > >>>  drivers/gpu/drm/sun4i/sun4i_layer.h |  2 +- 
> > >>>  drivers/gpu/drm/sun4i/sunxi_layer.h | 17 + 
> > >>>  5 files changed, 49 insertions(+), 11 deletions(-) 
> > >>>  create mode 100644 drivers/gpu/drm/sun4i/sunxi_layer.h 
> > >>> 
> > >>> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c 
> > >>> b/drivers/gpu/drm/sun4i/sun4i_crtc.c 
> > >>> index 3c876c3a356a..33854ee7f636 100644 
> > >>> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c 
> > >>> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c 
> > >>> @@ -29,6 +29,7 @@ 
> > >>>  #include "sun4i_crtc.h" 
> > >>>  #include "sun4i_drv.h" 
> > >>>  #include "sun4i_layer.h" 
> > >>> +#include "sunxi_layer.h" 
> > >>>  #include "sun4i_tcon.h" 
> > >>> 
> > >>>  static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc, 
> > >>> @@ -149,7 +150,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct 
> > >>> drm_device 
> > >>> *drm, 
> > >>> scrtc->tcon = tcon; 
> > >>> 
> > >>> /* Create our layers */ 
> > >>> -   scrtc->layers = sun4i_layers_init(drm, scrtc->backend); 
> > >>> +   scrtc->layers = (void **)sun4i_layers_init(drm, scrtc); 
> > >>> if (IS_ERR(scrtc->layers)) { 
> > >>> dev_err(drm->dev, "Couldn't create the planes\n"); 
> > >>> return NULL; 
> > >>> @@ -157,14 +158,15 @@ struct sun4i_crtc *sun4i_crtc_init(struct 
> > >>> drm_device *drm, 
> > >>> 
> > >>> /* find primary and cursor planes for drm_crtc_init_with_planes 
> > >>> */ 
> > >>> for (i = 0; scrtc->layers[i]; i++) { 
> > >>> -   struct sun4i_layer *layer = scrtc->layers[i]; 
> > >>> +   void *layer = scrtc->layers[i]; 
> > >>> +   struct drm_plane *plane = 
> > >>> scrtc->layer_ops->get_plane(layer); 
> > >>> 
> > >>> -   switch (layer->plane.type) { 
> > >>> +   switch (plane->type) { 
> > >>> case DRM_PLANE_TYPE_PRIMARY: 
> > >>> -   primary = >plane; 
> > >>> +   primary = plane; 
> > >>> break; 
> > >>> case DRM_PLANE_TYPE_CURSOR: 
> > >>> -   cursor = >plane; 
> > >>> +   cursor = plane; 
> > >>> break; 
> > >>> default: 
> > >>> break; 
> > >>> @@ -190,10 +192,11 @@ struct sun4i_crtc *sun4i_crtc_init(struct 
> > >>> drm_device *drm, 
> > >>> /* Set possible_crtcs to this crtc for overlay planes */ 
> > >>> for (i = 0; scrtc->layers[i]; i++) { 
> > >>> uint32_t possible_crtcs = 
> > >>> BIT(drm_crtc_index(>crtc)); 
> > >>> -   struct sun4i_layer *layer = scrtc->layers[i]; 
> > >>> +   void *layer = scrtc->layers[i]; 
> > >>> +   struct drm_plane *plane = 
> > >>> scrtc->layer_ops->get_plane(layer); 
> > >>> 
> > >>> -   if (layer->plane.type == DRM_PLANE_TYPE_OVERLAY) 
> > >>> -   layer->plane.possible_crtcs = possible_crtcs; 
> > >>> +   if (plane->type == DRM_PLANE_TYPE_OVERLAY) 
> > >>> +   plane->possible_crtcs = possible_crtcs; 
> > >>> } 
> > >>> 
> > >>> return scrtc; 
> > >>> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.h 
> > >>> b/drivers/gpu/drm/sun4i/sun4i_crtc.h 
> > >>> index 230cb8f0d601..a4036ee44cf8 100644 
> > >>> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.h 
> > >>> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.h 
> > >>> @@ -19,7 +19,8 @@ struct sun4i_crtc { 
> > >>> 
> > >>> struct sun4i_backend    *backend; 
> > >>> struct sun4i_tcon   *tcon; 
> > >>> -   struct sun4i_layer  **layers; 
> > >>> +   void    **layers; 
> > >>> +   const struct sunxi_layer_ops    *layer_ops; 
> > >> 
> > >> 
> > >> I think you should probably take a different approach to abstract the 
> > >> layer 
> > >> type. How about creating 
> > >> 
> > >> struct sunxi_layer { 
> > >> 

Re: [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts

[Maxime Ripard]

On Wed, Apr 05, 2017 at 03:33:09PM +0800, Icenowy Zheng wrote:
> > > P.S. to be compatible with older DTs, I think I should adjust
> > > the phy driver, make it enable dual-route function only when
> > > pmu0 is present.
> > 
> > That, or if we're quick enough, we can still add it to 4.11. There's a
> > bit of time left.
> 
> Thus the device tree binding patch and the DT part of this patchset
> should be all pushed to 4.11 .
> 
> The device tree binding patch is commit ee73fd7dfc86 ("dt: bindings:
> add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64").

It should have always been there. If there is a register for the PHY
somewhere, it must be in the DT node. Period. There's not relation to
whether the driver actually uses it or not.

Please send a patch to add that range for 4.11.

Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH v1 1/6] mm: get rid of zone_is_initialized

[Michal Hocko]

On Fri 31-03-17 09:39:54, Michal Hocko wrote:
> Fixed screw ups during the initial patch split up as per Hillf
> ---
> From 8be6c5e47de66210e47710c80e72e8abd899017b Mon Sep 17 00:00:00 2001
> From: Michal Hocko 
> Date: Wed, 29 Mar 2017 15:11:30 +0200
> Subject: [PATCH] mm: get rid of zone_is_initialized
> 
> There shouldn't be any reason to add initialized when we can tell the
> same thing from checking whether there are any pages spanned to the
> zone. Remove zone_is_initialized() and replace it by zone_is_empty
> which can be used for the same set of tests.
> 
> This shouldn't have any visible effect

I've decided to drop this patch. My main motivation was to simplify
the hotplug workflow/ The situation is more hairy than I expected,
though. On one hand all zones should be initialized early during the
hotplug in add_memory_resource but direct users of arch_add_memory will
need this to be called I suspect. Let's just keep the current status quo
and clean up it later. It is not really needed for this series.

> Signed-off-by: Michal Hocko 
> ---
>  include/linux/mmzone.h | 7 ---
>  mm/memory_hotplug.c| 6 +++---
>  mm/page_alloc.c| 3 +--
>  3 files changed, 4 insertions(+), 12 deletions(-)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 618499159a7c..3bac3ed71c7a 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -442,8 +442,6 @@ struct zone {
>   seqlock_t   span_seqlock;
>  #endif
>  
> - int initialized;
> -
>   /* Write-intensive fields used from the page allocator */
>   ZONE_PADDING(_pad1_)
>  
> @@ -520,11 +518,6 @@ static inline bool zone_spans_pfn(const struct zone 
> *zone, unsigned long pfn)
>   return zone->zone_start_pfn <= pfn && pfn < zone_end_pfn(zone);
>  }
>  
> -static inline bool zone_is_initialized(struct zone *zone)
> -{
> - return zone->initialized;
> -}
> -
>  static inline bool zone_is_empty(struct zone *zone)
>  {
>   return zone->spanned_pages == 0;
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 6fb6bd2df787..699f5a2a8efd 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -348,7 +348,7 @@ static void fix_zone_id(struct zone *zone, unsigned long 
> start_pfn,
>  static int __ref ensure_zone_is_initialized(struct zone *zone,
>   unsigned long start_pfn, unsigned long num_pages)
>  {
> - if (!zone_is_initialized(zone))
> + if (zone_is_empty(zone))
>   return init_currently_empty_zone(zone, start_pfn, num_pages);
>  
>   return 0;
> @@ -1051,7 +1051,7 @@ bool zone_can_shift(unsigned long pfn, unsigned long 
> nr_pages,
>  
>   /* no zones in use between current zone and target */
>   for (i = idx + 1; i < target; i++)
> - if (zone_is_initialized(zone - idx + i))
> + if (!zone_is_empty(zone - idx + i))
>   return false;
>   }
>  
> @@ -1062,7 +1062,7 @@ bool zone_can_shift(unsigned long pfn, unsigned long 
> nr_pages,
>  
>   /* no zones in use between current zone and target */
>   for (i = target + 1; i < idx; i++)
> - if (zone_is_initialized(zone - idx + i))
> + if (!zone_is_empty(zone - idx + i))
>   return false;
>   }
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 5ee8a26fa383..756353d1e293 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -795,7 +795,7 @@ static inline void __free_one_page(struct page *page,
>  
>   max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
>  
> - VM_BUG_ON(!zone_is_initialized(zone));
> + VM_BUG_ON(zone_is_empty(zone));
>   VM_BUG_ON_PAGE(page->flags & PAGE_FLAGS_CHECK_AT_PREP, page);
>  
>   VM_BUG_ON(migratetype == -1);
> @@ -5535,7 +5535,6 @@ int __meminit init_currently_empty_zone(struct zone 
> *zone,
>   zone_start_pfn, (zone_start_pfn + size));
>  
>   zone_init_free_lists(zone);
> - zone->initialized = 1;
>  
>   return 0;
>  }
> -- 
> 2.11.0
> 
> -- 
> Michal Hocko
> SUSE Labs

-- 
Michal Hocko
SUSE Labs

[PATCH v6 08/23] Documentation: PCI: Add binding documentation for pci-test endpoint function

[Kishon Vijay Abraham I]

Add binding documentation for pci-test endpoint function that helps in
adding and configuring pci-test endpoint function.

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

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index ab35e4bbdb1c..2fc901a1c32e 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -18,3 +18,5 @@ 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.
+endpoint/function/binding/
+   - binding documentation for PCI endpoint function
diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
b/Documentation/PCI/endpoint/function/binding/pci-test.txt
new file mode 100644
index ..3b68b955fb50
--- /dev/null
+++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
@@ -0,0 +1,17 @@
+PCI TEST ENDPOINT FUNCTION
+
+name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
+
+Configurable Fields:
+vendorid: should be 0x104c
+deviceid: should be 0xb500 for DRA74x and 0xb501 for DRA72x
+revid   : don't care
+progif_code : don't care
+subclass_code   : don't care
+baseclass_code  : should be 0xff
+cache_line_size : don't care
+subsys_vendor_id : don't care
+subsys_id   : don't care
+interrupt_pin   : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
+msi_interrupts  : Should be 1 to 32 depending on the number of MSI interrupts
+  to test
-- 
2.11.0

[PATCH v6 12/23] 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 
Signed-off-by: Bjorn Helgaas 
---
 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 d37ea72a846a..b7e15526d676 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 b38425d36200..f31a8596442a 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 d78974d20360..35c18534469c 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 

[PATCH v6 03/23] 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 
Signed-off-by: Bjorn Helgaas 
---
 drivers/pci/endpoint/Kconfig  |   9 +
 drivers/pci/endpoint/Makefile |   1 +
 drivers/pci/endpoint/pci-ep-cfs.c | 509 ++
 include/linux/pci-ep-cfs.h|  41 +++
 4 files changed, 560 insertions(+)
 create mode 100644 drivers/pci/endpoint/pci-ep-cfs.c
 create mode 100644 include/linux/pci-ep-cfs.h

diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
index a5442ace7077..c86bca9b7de3 100644
--- a/drivers/pci/endpoint/Kconfig
+++ b/drivers/pci/endpoint/Kconfig
@@ -17,4 +17,13 @@ config PCI_ENDPOINT
 
   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 dc1bc16491e6..7219d51bb401 100644
--- a/drivers/pci/endpoint/Makefile
+++ b/drivers/pci/endpoint/Makefile
@@ -2,5 +2,6 @@
 # Makefile for PCI Endpoint Support
 #
 
+obj-$(CONFIG_PCI_ENDPOINT_CONFIGFS)+= pci-ep-cfs.o
 obj-$(CONFIG_PCI_ENDPOINT) += pci-epc-core.o pci-epf-core.o\
   pci-epc-mem.o
diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
new file mode 100644
index ..424fdd6ed1ca
--- /dev/null
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -0,0 +1,509 @@
+/**
+ * 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 
+
+static struct config_group *functions_group;
+static struct config_group *controllers_group;
+
+struct pci_epf_group {
+   struct config_group group;
+   struct pci_epf *epf;
+};
+
+struct pci_epc_group {
+   struct config_group group;
+   struct pci_epc *epc;
+   bool start;
+   unsigned long function_num_map;
+};
+
+static inline struct pci_epf_group *to_pci_epf_group(struct config_item *item)
+{
+   return container_of(to_config_group(item), struct pci_epf_group, group);
+}
+
+static inline struct pci_epc_group *to_pci_epc_group(struct config_item *item)
+{
+   return container_of(to_config_group(item), struct pci_epc_group, group);
+}
+
+static ssize_t pci_epc_start_store(struct config_item *item, const char *page,
+  size_t len)
+{
+   int ret;
+   bool start;
+   struct pci_epc *epc;
+   struct pci_epc_group *epc_group = to_pci_epc_group(item);
+
+   epc = epc_group->epc;
+
+   ret = kstrtobool(page, );
+   if (ret)
+   return ret;
+
+   if (!start) {
+   pci_epc_stop(epc);
+   return len;
+   }
+
+   ret = pci_epc_start(epc);
+   if (ret) {
+   dev_err(>dev, "failed to start endpoint controller\n");
+   return -EINVAL;
+   }
+
+   epc_group->start = start;
+
+   return len;
+}
+
+static ssize_t pci_epc_start_show(struct config_item *item, char *page)
+{
+   return sprintf(page, "%d\n",
+  to_pci_epc_group(item)->start);
+}
+
+CONFIGFS_ATTR(pci_epc_, start);
+
+static struct configfs_attribute *pci_epc_attrs[] = {
+   _epc_attr_start,
+   NULL,
+};
+
+static int pci_epc_epf_link(struct config_item *epc_item,
+   struct config_item *epf_item)
+{
+   int ret;
+   u32 func_no = 0;
+   struct pci_epc *epc;
+   struct pci_epf *epf;
+   struct pci_epf_group *epf_group = to_pci_epf_group(epf_item);
+   struct pci_epc_group *epc_group = to_pci_epc_group(epc_item);
+
+   epc = epc_group->epc;
+   epf = epf_group->epf;
+   ret = pci_epc_add_epf(epc, epf);
+   if (ret)
+   goto err_add_epf;
+
+   func_no = find_first_zero_bit(_group->function_num_map,
+ 

[PATCH v6 13/23] dt-bindings: PCI: dra7xx: Add DT bindings for PCI dra7xx EP mode

[Kishon Vijay Abraham I]

Add device tree binding documentation for PCI dra7xx EP mode.

Acked-by: Rob Herring 
Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Bjorn Helgaas 
---
 Documentation/devicetree/bindings/pci/ti-pci.txt | 37 +++-
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 60e25161f351..60c3cccefabc 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -1,17 +1,22 @@
 TI PCI Controllers
 
 PCIe Designware Controller
- - compatible: Should be "ti,dra7-pcie""
- - reg : Two register ranges as listed in the reg-names property
- - reg-names : The first entry must be "ti-conf" for the TI specific registers
-  The second entry must be "rc-dbics" for the designware pcie
-  registers
-  The third entry must be "config" for the PCIe configuration space
+ - compatible: Should be "ti,dra7-pcie" for RC
+  Should be "ti,dra7-pcie-ep" for EP
  - phys : list of PHY specifiers (used by generic PHY framework)
  - phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
   number of PHYs as specified in *phys* property.
  - ti,hwmods : Name of the hwmod associated to the pcie, "pcie",
   where  is the instance number of the pcie from the HW spec.
+ - num-lanes as specified in ../designware-pcie.txt
+
+HOST MODE
+=
+ - reg : Two register ranges as listed in the reg-names property
+ - reg-names : The first entry must be "ti-conf" for the TI specific registers
+  The second entry must be "rc-dbics" for the DesignWare PCIe
+  registers
+  The third entry must be "config" for the PCIe configuration space
  - interrupts : Two interrupt entries must be specified. The first one is for
main interrupt line and the second for MSI interrupt line.
  - #address-cells,
@@ -19,13 +24,31 @@ PCIe Designware Controller
#interrupt-cells,
device_type,
ranges,
-   num-lanes,
interrupt-map-mask,
interrupt-map : as specified in ../designware-pcie.txt
 
+DEVICE MODE
+===
+ - reg : Four register ranges as listed in the reg-names property
+ - reg-names : "ti-conf" for the TI specific registers
+  "ep_dbics" for the standard configuration registers as
+   they are locally accessed within the DIF CS space
+  "ep_dbics2" for the standard configuration registers as
+   they are locally accessed within the DIF CS2 space
+  "addr_space" used to map remote RC address space
+ - interrupts : one interrupt entries must be specified for main interrupt.
+ - num-ib-windows : number of inbound address translation windows
+ - num-ob-windows : number of outbound address translation windows
+
 Optional Property:
  - gpios : Should be added if a gpio line is required to drive PERST# line
 
+NOTE: Two DT nodes may be added for each PCI controller; one for host
+mode and another for device mode. So in order for PCI to
+work in host mode, EP mode DT node should be disabled and in order to PCI to
+work in EP mode, host mode DT node should be disabled. Host mode and EP
+mode are mutually exclusive.
+
 Example:
 axi {
compatible = "simple-bus";
-- 
2.11.0

[PATCH v6 23/23] 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 
Signed-off-by: Bjorn Helgaas 
---
 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 6c679659cda5..67ebff829cf2 100644
--- a/arch/arm/mach-omap2/clockdomains7xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -524,7 +524,7 @@ static struct clockdomain pcie_7xx_clkdm = {
.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 = {
-- 
2.11.0

[PATCH v6 14/23] PCI: dwc: dra7xx: Workaround for errata id i870

[Kishon Vijay Abraham I]

According to errata i870, access to the PCIe slave port that are not 32-bit
aligned will result in incorrect mapping to TLP Address and Byte enable
fields.

Accessing non 32-bit aligned data causes incorrect data in the target
buffer if memcpy is used. Implement the workaround for this errata here.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Bjorn Helgaas 
---
 drivers/pci/dwc/pci-dra7xx.c | 49 
 1 file changed, 49 insertions(+)

diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index 35c18534469c..8decf46cf525 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "pcie-designware.h"
 
@@ -528,6 +530,48 @@ static const struct of_device_id of_dra7xx_pcie_match[] = {
{},
 };
 
+/*
+ * dra7xx_pcie_ep_unaligned_memaccess: workaround for AM572x/AM571x Errata i870
+ * @dra7xx: the dra7xx device where the workaround should be applied
+ *
+ * Access to the PCIe slave port that are not 32-bit aligned will result
+ * in incorrect mapping to TLP Address and Byte enable fields. Therefore,
+ * byte and half-word accesses are not possible to byte offset 0x1, 0x2, or
+ * 0x3.
+ *
+ * To avoid this issue set PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE to 1.
+ */
+static int dra7xx_pcie_ep_unaligned_memaccess(struct device *dev)
+{
+   int ret;
+   struct device_node *np = dev->of_node;
+   struct of_phandle_args args;
+   struct regmap *regmap;
+
+   regmap = syscon_regmap_lookup_by_phandle(np,
+"ti,syscon-unaligned-access");
+   if (IS_ERR(regmap)) {
+   dev_dbg(dev, "can't get ti,syscon-unaligned-access\n");
+   return -EINVAL;
+   }
+
+   ret = of_parse_phandle_with_fixed_args(np, "ti,syscon-unaligned-access",
+  2, 0, );
+   if (ret) {
+   dev_err(dev, "failed to parse ti,syscon-unaligned-access\n");
+   return ret;
+   }
+
+   ret = regmap_update_bits(regmap, args.args[0], args.args[1],
+args.args[1]);
+   if (ret)
+   dev_err(dev, "failed to enable unaligned access\n");
+
+   of_node_put(args.np);
+
+   return ret;
+}
+
 static int __init dra7xx_pcie_probe(struct platform_device *pdev)
 {
u32 reg;
@@ -644,6 +688,11 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
case DW_PCIE_EP_TYPE:
dra7xx_pcie_writel(dra7xx, PCIECTRL_TI_CONF_DEVICE_TYPE,
   DEVICE_TYPE_EP);
+
+   ret = dra7xx_pcie_ep_unaligned_memaccess(dev);
+   if (ret)
+   goto err_gpio;
+
ret = dra7xx_add_pcie_ep(dra7xx, pdev);
if (ret < 0)
goto err_gpio;
-- 
2.11.0

[PATCH v5 4/7] ARM: dtsi: axp209: add battery power supply subnode

[Quentin Schulz]

The X-Powers AXP209 PMIC exposes battery supply various data such as
the battery status (charging, discharging, full, dead), current max
limit, current current, battery capacity (in percentage), voltage max
and min limits, current voltage, and battery capacity (in Ah).

This adds the battery power supply subnode for AXP20X PMIC.

Signed-off-by: Quentin Schulz 
Acked-by: Maxime Ripard 
Acked-by: Chen-Yu Tsai 
---

v2:
 - changed DT node name from battery_power_supply to
 battery-power-supply,
 - removed io-channels and io-channel-names from DT (the IIO mapping is
 done in the IIO ADC driver now),

 arch/arm/boot/dts/axp209.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index 9677dd5..3c8fa26 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -64,6 +64,11 @@
#gpio-cells = <2>;
};
 
+   battery_power_supply: battery-power-supply {
+   compatible = "x-powers,axp209-battery-power-supply";
+   status = "disabled";
+   };
+
regulators {
/* Default work frequency for buck regulators */
x-powers,dcdc-freq = <1500>;
-- 
2.9.3