Re: [PATCH v3 1/2] arm64/efi: report unexpected errors when determining Secure Boot status

[Ard Biesheuvel]

On 3 March 2016 at 22:45, Linn Crosetto  wrote:
> Certain code in the boot path may require the ability to determine whether
> UEFI Secure Boot is definitely enabled, for example printing status to the
> console. Other code may need to know when UEFI Secure Boot is definitely
> disabled, for example restricting use of kernel parameters.
>
> If an unexpected error is returned from GetVariable() when querying the
> status of UEFI Secure Boot, return an error to the caller. This allows the
> caller to determine the definite state, and to take appropriate action if
> an expected error is returned.
>
> Signed-off-by: Linn Crosetto 

Reviewed-by: Ard Biesheuvel 

> ---
> v2:
>  - Maintain existing behavior to allow 'dtb=' parameter only when UEFI
>Secure Boot is disabled and not in an unknown state. (Mark Rutland)
>
> v3:
>  - Add prints to inform the user in the following two cases: failure to
>determine Secure Boot status, ignoring "dtb=" kernel parameter (Ard
>Biesheuvel)
>
>  drivers/firmware/efi/libstub/arm-stub.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
> b/drivers/firmware/efi/libstub/arm-stub.c
> index 3397902..1e98fb7 100644
> --- a/drivers/firmware/efi/libstub/arm-stub.c
> +++ b/drivers/firmware/efi/libstub/arm-stub.c
> @@ -18,7 +18,7 @@
>
>  #include "efistub.h"
>
> -static int efi_secureboot_enabled(efi_system_table_t *sys_table_arg)
> +static int efi_get_secureboot(efi_system_table_t *sys_table_arg)
>  {
> static efi_guid_t const var_guid = EFI_GLOBAL_VARIABLE_GUID;
> static efi_char16_t const var_name[] = {
> @@ -37,8 +37,12 @@ static int efi_secureboot_enabled(efi_system_table_t 
> *sys_table_arg)
> return val;
> case EFI_NOT_FOUND:
> return 0;
> +   case EFI_DEVICE_ERROR:
> +   return -EIO;
> +   case EFI_SECURITY_VIOLATION:
> +   return -EACCES;
> default:
> -   return 1;
> +   return -EINVAL;
> }
>  }
>
> @@ -183,6 +187,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
> *sys_table,
> efi_guid_t loaded_image_proto = LOADED_IMAGE_PROTOCOL_GUID;
> unsigned long reserve_addr = 0;
> unsigned long reserve_size = 0;
> +   int secure_boot = 0;
>
> /* Check if we were booted by the EFI firmware */
> if (sys_table->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE)
> @@ -231,12 +236,21 @@ unsigned long efi_entry(void *handle, 
> efi_system_table_t *sys_table,
> if (status != EFI_SUCCESS)
> pr_efi_err(sys_table, "Failed to parse EFI cmdline 
> options\n");
>
> +   secure_boot = efi_get_secureboot(sys_table);
> +   if (secure_boot > 0)
> +   pr_efi(sys_table, "UEFI Secure Boot is enabled.\n");
> +
> +   if (secure_boot < 0) {
> +   pr_efi_err(sys_table,
> +   "could not determine UEFI Secure Boot status.\n");
> +   }
> +
> /*
>  * Unauthenticated device tree data is a security hazard, so
>  * ignore 'dtb=' unless UEFI Secure Boot is disabled.
>  */
> -   if (efi_secureboot_enabled(sys_table)) {
> -   pr_efi(sys_table, "UEFI Secure Boot is enabled.\n");
> +   if (secure_boot != 0 && strstr(cmdline_ptr, "dtb=")) {
> +   pr_efi(sys_table, "Ignoring DTB from command line.\n");
> } else {
> status = handle_cmdline_files(sys_table, image, cmdline_ptr,
>   "dtb=",
> --
> 2.1.4
>

Re: [PATCH v3 1/2] arm64/efi: report unexpected errors when determining Secure Boot status

[Ard Biesheuvel]

On 3 March 2016 at 22:45, Linn Crosetto  wrote:
> Certain code in the boot path may require the ability to determine whether
> UEFI Secure Boot is definitely enabled, for example printing status to the
> console. Other code may need to know when UEFI Secure Boot is definitely
> disabled, for example restricting use of kernel parameters.
>
> If an unexpected error is returned from GetVariable() when querying the
> status of UEFI Secure Boot, return an error to the caller. This allows the
> caller to determine the definite state, and to take appropriate action if
> an expected error is returned.
>
> Signed-off-by: Linn Crosetto 

Reviewed-by: Ard Biesheuvel 

> ---
> v2:
>  - Maintain existing behavior to allow 'dtb=' parameter only when UEFI
>Secure Boot is disabled and not in an unknown state. (Mark Rutland)
>
> v3:
>  - Add prints to inform the user in the following two cases: failure to
>determine Secure Boot status, ignoring "dtb=" kernel parameter (Ard
>Biesheuvel)
>
>  drivers/firmware/efi/libstub/arm-stub.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
> b/drivers/firmware/efi/libstub/arm-stub.c
> index 3397902..1e98fb7 100644
> --- a/drivers/firmware/efi/libstub/arm-stub.c
> +++ b/drivers/firmware/efi/libstub/arm-stub.c
> @@ -18,7 +18,7 @@
>
>  #include "efistub.h"
>
> -static int efi_secureboot_enabled(efi_system_table_t *sys_table_arg)
> +static int efi_get_secureboot(efi_system_table_t *sys_table_arg)
>  {
> static efi_guid_t const var_guid = EFI_GLOBAL_VARIABLE_GUID;
> static efi_char16_t const var_name[] = {
> @@ -37,8 +37,12 @@ static int efi_secureboot_enabled(efi_system_table_t 
> *sys_table_arg)
> return val;
> case EFI_NOT_FOUND:
> return 0;
> +   case EFI_DEVICE_ERROR:
> +   return -EIO;
> +   case EFI_SECURITY_VIOLATION:
> +   return -EACCES;
> default:
> -   return 1;
> +   return -EINVAL;
> }
>  }
>
> @@ -183,6 +187,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
> *sys_table,
> efi_guid_t loaded_image_proto = LOADED_IMAGE_PROTOCOL_GUID;
> unsigned long reserve_addr = 0;
> unsigned long reserve_size = 0;
> +   int secure_boot = 0;
>
> /* Check if we were booted by the EFI firmware */
> if (sys_table->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE)
> @@ -231,12 +236,21 @@ unsigned long efi_entry(void *handle, 
> efi_system_table_t *sys_table,
> if (status != EFI_SUCCESS)
> pr_efi_err(sys_table, "Failed to parse EFI cmdline 
> options\n");
>
> +   secure_boot = efi_get_secureboot(sys_table);
> +   if (secure_boot > 0)
> +   pr_efi(sys_table, "UEFI Secure Boot is enabled.\n");
> +
> +   if (secure_boot < 0) {
> +   pr_efi_err(sys_table,
> +   "could not determine UEFI Secure Boot status.\n");
> +   }
> +
> /*
>  * Unauthenticated device tree data is a security hazard, so
>  * ignore 'dtb=' unless UEFI Secure Boot is disabled.
>  */
> -   if (efi_secureboot_enabled(sys_table)) {
> -   pr_efi(sys_table, "UEFI Secure Boot is enabled.\n");
> +   if (secure_boot != 0 && strstr(cmdline_ptr, "dtb=")) {
> +   pr_efi(sys_table, "Ignoring DTB from command line.\n");
> } else {
> status = handle_cmdline_files(sys_table, image, cmdline_ptr,
>   "dtb=",
> --
> 2.1.4
>

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

[Roman Kagan]

On Thu, Mar 03, 2016 at 05:46:15PM +, Dr. David Alan Gilbert wrote:
> * Liang Li (liang.z...@intel.com) wrote:
> > The current QEMU live migration implementation mark the all the
> > guest's RAM pages as dirtied in the ram bulk stage, all these pages
> > will be processed and that takes quit a lot of CPU cycles.
> > 
> > From guest's point of view, it doesn't care about the content in free
> > pages. We can make use of this fact and skip processing the free
> > pages in the ram bulk stage, it can save a lot CPU cycles and reduce
> > the network traffic significantly while speed up the live migration
> > process obviously.
> > 
> > This patch set is the QEMU side implementation.
> > 
> > The virtio-balloon is extended so that QEMU can get the free pages
> > information from the guest through virtio.
> > 
> > After getting the free pages information (a bitmap), QEMU can use it
> > to filter out the guest's free pages in the ram bulk stage. This make
> > the live migration process much more efficient.
> 
> Hi,
>   An interesting solution; I know a few different people have been looking
> at how to speed up ballooned VM migration.
> 
>   I wonder if it would be possible to avoid the kernel changes by
> parsing /proc/self/pagemap - if that can be used to detect unmapped/zero
> mapped pages in the guest ram, would it achieve the same result?

Yes I was about to suggest the same thing: it's simple and makes use of
the existing infrastructure.  And you wouldn't need to care if the pages
were unmapped by ballooning or anything else (alternative balloon
implementations, not yet touched by the guest, etc.).  Besides, you
wouldn't need to synchronize with the guest.

Roman.

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

[Roman Kagan]

On Thu, Mar 03, 2016 at 05:46:15PM +, Dr. David Alan Gilbert wrote:
> * Liang Li (liang.z...@intel.com) wrote:
> > The current QEMU live migration implementation mark the all the
> > guest's RAM pages as dirtied in the ram bulk stage, all these pages
> > will be processed and that takes quit a lot of CPU cycles.
> > 
> > From guest's point of view, it doesn't care about the content in free
> > pages. We can make use of this fact and skip processing the free
> > pages in the ram bulk stage, it can save a lot CPU cycles and reduce
> > the network traffic significantly while speed up the live migration
> > process obviously.
> > 
> > This patch set is the QEMU side implementation.
> > 
> > The virtio-balloon is extended so that QEMU can get the free pages
> > information from the guest through virtio.
> > 
> > After getting the free pages information (a bitmap), QEMU can use it
> > to filter out the guest's free pages in the ram bulk stage. This make
> > the live migration process much more efficient.
> 
> Hi,
>   An interesting solution; I know a few different people have been looking
> at how to speed up ballooned VM migration.
> 
>   I wonder if it would be possible to avoid the kernel changes by
> parsing /proc/self/pagemap - if that can be used to detect unmapped/zero
> mapped pages in the guest ram, would it achieve the same result?

Yes I was about to suggest the same thing: it's simple and makes use of
the existing infrastructure.  And you wouldn't need to care if the pages
were unmapped by ballooning or anything else (alternative balloon
implementations, not yet touched by the guest, etc.).  Besides, you
wouldn't need to synchronize with the guest.

Roman.

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

[Jacek Anaszewski]

On 03/04/2016 01:45 AM, David Rivshin (Allworx) wrote:

On Thu, 03 Mar 2016 15:51:32 +0100
Jacek Anaszewski  wrote:


Hi David,

Thanks for the update. Two remarks in the code.

On 03/03/2016 04:01 AM, David Rivshin (Allworx) wrote:

From: David Rivshin 

The IS31FL32xx family of LED controllers are I2C devices with multiple
constant-current channels, each with independent 256-level PWM control.

Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml

This has been tested on the IS31FL3236 and IS31FL3216, on an ARM
(TI am335x) platform.

The programming paradigm of these devices is similar in the following
ways:
   - All registers are 8 bit
   - All LED control registers are write-only
   - Each LED channel has a PWM register (0-255)
   - PWM register writes are shadowed until an Update register is poked
   - All have a concept of Software Shutdown, which disables output

However, there are some differences in devices:
   - 3236/3235 have a separate Control register for each LED,
 (3218/3216 pack the enable bits into fewer registers)
   - 3236/3235 have a per-channel current divisor setting
   - 3236/3235 have a Global Control register that can turn off all LEDs
   - 3216 is unique in a number of ways
  - OUT9-OUT16 can be configured as GPIOs instead of LED controls
  - LEDs can be programmed with an 8-frame animation, with
programmable delay between frames
  - LEDs can be modulated by an input audio signal
  - Max output current can be adjusted from 1/4 to 2x globally
  - Has a Configuration register instead of a Shutdown register

This driver currently only supports the base PWM control function
of these devices. The following features of these devices are not
implemented, although it should be possible to add them in the future:
   - All devices are capable of going into a lower-power "software
 shutdown" mode.
   - The is31fl3236 and is31fl3235 can reduce the max output current
 per-channel with a divisor of 1, 2, 3, or 4.
   - The is31fl3216 can use some LED channels as GPIOs instead.
   - The is31fl3216 can animate LEDs in hardware.
   - The is31fl3216 can modulate LEDs according to an audio input.
   - The is31fl3216 can reduce/increase max output current globally.

Signed-off-by: David Rivshin 
---

You may see two instances of this warning:
"passing argument 1 of 'of_property_read_string' discards 'const'
 qualifier from pointer target type"
That is a result of of_property_read_string() taking a non-const
struct device_node pointer parameter. I have separately submitted a
patch to fix that [1], and a few related functions which had the same
issue. I'm hoping that will get into linux-next before this does, so
that the warnings never show up there.


Please adjust the patch so that it compiles without warnings on
current linux-next. Your patch for DT API hasn't been reviewed yet
AFICS, and I can imagine that there will be some resistance against.


Since the DT API patch was just accepted by Rob [1], would it be OK
to wait for the results of Stefan's testing (and any other reviews)
before making a decision on this? From Stefan's note, it won't be
until this weekend that he will have a chance to test, and I'm
guessing the DT API patch will make its way through Rob's tree to
linux-next by then.


OK.


FYI, the warning workaround would be to make the second parameter to
is31fl32xx_parse_child_dt() non-const.

[1] https://lkml.org/lkml/2016/3/3/924


Changes from RFC:
   - Removed max-brightness DT property.
   - Refer to these devices as "LED controllers" in Kconfig.
   - Removed redundant last sentence from Kconfig entry
   - Removed unnecessary debug code.
   - Do not set led_classdev.brightness to 0 explicitly, as it is
 already initialized to 0 by devm_kzalloc().
   - Used of_property_read_string() instead of of_get_property().
   - Fail immediately on DT parsing error in a child node, rather than
 continuing on with the non-faulty ones.
   - Added additional comments for some things that might be non-obvious.
   - Added constants for the location of the SSD bit in the SHUTDOWN
 register, and the 3216's CONFIG register.
   - Added special sw_shutdown_func for the 3216 device, as that bit
 is in a different register, at a different position, and has reverse
 polarity compared to all the other devices.
   - Refactored is31fl32xx_init_regs() to separate out some logic into
 is31fl32xx_reset_regs() and is31fl32xx_software_shutdown().

[1] https://lkml.org/lkml/2016/3/2/746

   drivers/leds/Kconfig   |   8 +
   drivers/leds/Makefile  |   1 +
   drivers/leds/leds-is31fl32xx.c | 505 
+
   3 files changed, 514 insertions(+)
   create mode 100644 drivers/leds/leds-is31fl32xx.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1034696..9c63ba4 100644
--- a/drivers/leds/Kconfig
+++ 

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

[Jacek Anaszewski]

On 03/04/2016 01:45 AM, David Rivshin (Allworx) wrote:

On Thu, 03 Mar 2016 15:51:32 +0100
Jacek Anaszewski  wrote:


Hi David,

Thanks for the update. Two remarks in the code.

On 03/03/2016 04:01 AM, David Rivshin (Allworx) wrote:

From: David Rivshin 

The IS31FL32xx family of LED controllers are I2C devices with multiple
constant-current channels, each with independent 256-level PWM control.

Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml

This has been tested on the IS31FL3236 and IS31FL3216, on an ARM
(TI am335x) platform.

The programming paradigm of these devices is similar in the following
ways:
   - All registers are 8 bit
   - All LED control registers are write-only
   - Each LED channel has a PWM register (0-255)
   - PWM register writes are shadowed until an Update register is poked
   - All have a concept of Software Shutdown, which disables output

However, there are some differences in devices:
   - 3236/3235 have a separate Control register for each LED,
 (3218/3216 pack the enable bits into fewer registers)
   - 3236/3235 have a per-channel current divisor setting
   - 3236/3235 have a Global Control register that can turn off all LEDs
   - 3216 is unique in a number of ways
  - OUT9-OUT16 can be configured as GPIOs instead of LED controls
  - LEDs can be programmed with an 8-frame animation, with
programmable delay between frames
  - LEDs can be modulated by an input audio signal
  - Max output current can be adjusted from 1/4 to 2x globally
  - Has a Configuration register instead of a Shutdown register

This driver currently only supports the base PWM control function
of these devices. The following features of these devices are not
implemented, although it should be possible to add them in the future:
   - All devices are capable of going into a lower-power "software
 shutdown" mode.
   - The is31fl3236 and is31fl3235 can reduce the max output current
 per-channel with a divisor of 1, 2, 3, or 4.
   - The is31fl3216 can use some LED channels as GPIOs instead.
   - The is31fl3216 can animate LEDs in hardware.
   - The is31fl3216 can modulate LEDs according to an audio input.
   - The is31fl3216 can reduce/increase max output current globally.

Signed-off-by: David Rivshin 
---

You may see two instances of this warning:
"passing argument 1 of 'of_property_read_string' discards 'const'
 qualifier from pointer target type"
That is a result of of_property_read_string() taking a non-const
struct device_node pointer parameter. I have separately submitted a
patch to fix that [1], and a few related functions which had the same
issue. I'm hoping that will get into linux-next before this does, so
that the warnings never show up there.


Please adjust the patch so that it compiles without warnings on
current linux-next. Your patch for DT API hasn't been reviewed yet
AFICS, and I can imagine that there will be some resistance against.


Since the DT API patch was just accepted by Rob [1], would it be OK
to wait for the results of Stefan's testing (and any other reviews)
before making a decision on this? From Stefan's note, it won't be
until this weekend that he will have a chance to test, and I'm
guessing the DT API patch will make its way through Rob's tree to
linux-next by then.


OK.


FYI, the warning workaround would be to make the second parameter to
is31fl32xx_parse_child_dt() non-const.

[1] https://lkml.org/lkml/2016/3/3/924


Changes from RFC:
   - Removed max-brightness DT property.
   - Refer to these devices as "LED controllers" in Kconfig.
   - Removed redundant last sentence from Kconfig entry
   - Removed unnecessary debug code.
   - Do not set led_classdev.brightness to 0 explicitly, as it is
 already initialized to 0 by devm_kzalloc().
   - Used of_property_read_string() instead of of_get_property().
   - Fail immediately on DT parsing error in a child node, rather than
 continuing on with the non-faulty ones.
   - Added additional comments for some things that might be non-obvious.
   - Added constants for the location of the SSD bit in the SHUTDOWN
 register, and the 3216's CONFIG register.
   - Added special sw_shutdown_func for the 3216 device, as that bit
 is in a different register, at a different position, and has reverse
 polarity compared to all the other devices.
   - Refactored is31fl32xx_init_regs() to separate out some logic into
 is31fl32xx_reset_regs() and is31fl32xx_software_shutdown().

[1] https://lkml.org/lkml/2016/3/2/746

   drivers/leds/Kconfig   |   8 +
   drivers/leds/Makefile  |   1 +
   drivers/leds/leds-is31fl32xx.c | 505 
+
   3 files changed, 514 insertions(+)
   create mode 100644 drivers/leds/leds-is31fl32xx.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1034696..9c63ba4 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -580,6 +580,14 @@ config LEDS_SN3218
  

Re: [PATCH 0/3] OOM detection rework v4

[Joonsoo Kim]

On Thu, Mar 03, 2016 at 01:54:43AM -0800, Hugh Dickins wrote:
> On Tue, 1 Mar 2016, Michal Hocko wrote:
> > [Adding Vlastimil and Joonsoo for compaction related things - this was a
> > large thread but the more interesting part starts with
> > http://lkml.kernel.org/r/alpine.LSU.2.11.1602241832160.15564@eggly.anvils]
> > 
> > On Mon 29-02-16 23:29:06, Hugh Dickins wrote:
> > > On Mon, 29 Feb 2016, Michal Hocko wrote:
> > > > On Wed 24-02-16 19:47:06, Hugh Dickins wrote:
> > > > [...]
> > > > > Boot with mem=1G (or boot your usual way, and do something to occupy
> > > > > most of the memory: I think /proc/sys/vm/nr_hugepages provides a great
> > > > > way to gobble up most of the memory, though it's not how I've done 
> > > > > it).
> > > > > 
> > > > > Make sure you have swap: 2G is more than enough.  Copy the v4.5-rc5
> > > > > kernel source tree into a tmpfs: size=2G is more than enough.
> > > > > make defconfig there, then make -j20.
> > > > > 
> > > > > On a v4.5-rc5 kernel that builds fine, on mmotm it is soon OOM-killed.
> > > > > 
> > > > > Except that you'll probably need to fiddle around with that j20,
> > > > > it's true for my laptop but not for my workstation.  j20 just happens
> > > > > to be what I've had there for years, that I now see breaking down
> > > > > (I can lower to j6 to proceed, perhaps could go a bit higher,
> > > > > but it still doesn't exercise swap very much).
> > > > 
> > > > I have tried to reproduce and failed in a virtual on my laptop. I
> > > > will try with another host with more CPUs (because my laptop has only
> > > > two). Just for the record I did: boot 1G machine in kvm, I have 2G swap
> 
> I've found that the number of CPUs makes quite a difference - I have 4.
> 
> And another difference between us may be in our configs: on this laptop
> I had lots of debug options on (including DEBUG_VM, DEBUG_SPINLOCK and
> PROVE_LOCKING, though not DEBUG_PAGEALLOC), which approximately doubles
> the size of each shmem_inode (and those of course are not swappable).
> 
> I found that I could avoid the OOM if I ran the "make -j20" on a
> kernel without all those debug options, and booted with nr_cpus=2.
> And currently I'm booting the kernel with the debug options in,
> but with nr_cpus=2, which does still OOM (whereas not if nr_cpus=1).
> 
> Maybe in the OOM rework, threads are cancelling each other's progress
> more destructively, where before they co-operated to some extent?
> 
> (All that is on the laptop.  The G5 is still busy full-time bisecting
> a powerpc issue: I know it was OOMing with the rework, but I have not
> verified the effect of nr_cpus on it.  My x86 workstation has not been
> OOMing with the rework - I think that means that I've not been exerting
> as much memory pressure on it as I'd thought, that it copes with the load
> better, and would only show the difference if I loaded it more heavily.)
> 
> > > > and reserve 800M for hugetlb pages (I got 445 of them). Then I extract
> > > > the kernel source to tmpfs (-o size=2G), make defconfig and make -j20
> > > > (16, 10 no difference really). I was also collecting vmstat in the
> > > > background. The compilation takes ages but the behavior seems consistent
> > > > and stable.
> > > 
> > > Thanks a lot for giving it a go.
> > > 
> > > I'm puzzled.  445 hugetlb pages in 800M surprises me: some of them
> > > are less than 2M big??  But probably that's just a misunderstanding
> > > or typo somewhere.
> > 
> > A typo. 445 was from 900M test which I was doing while writing the
> > email. Sorry about the confusion.
> 
> That makes more sense!  Though I'm still amazed that you got anywhere,
> taking so much of the usable memory out.
> 
> > 
> > > Ignoring that, you're successfully doing a make -20 defconfig build
> > > in tmpfs, with only 224M of RAM available, plus 2G of swap?  I'm not
> > > at all surprised that it takes ages, but I am very surprised that it
> > > does not OOM.  I suppose by rights it ought not to OOM, the built
> > > tree occupies only a little more than 1G, so you do have enough swap;
> > > but I wouldn't get anywhere near that myself without OOMing - I give
> > > myself 1G of RAM (well, minus whatever the booted system takes up)
> > > to do that build in, four times your RAM, yet in my case it OOMs.
> > >
> > > That source tree alone occupies more than 700M, so just copying it
> > > into your tmpfs would take a long time. 
> > 
> > OK, I just found out that I was cheating a bit. I was building
> > linux-3.7-rc5.tar.bz2 which is smaller:
> > $ du -sh /mnt/tmpfs/linux-3.7-rc5/
> > 537M/mnt/tmpfs/linux-3.7-rc5/
> 
> Right, I have a habit like that too; but my habitual testing still
> uses the 2.6.24 source tree, which is rather too old to ask others
> to reproduce with - but we both find that the kernel source tree
> keeps growing, and prefer to stick with something of a fixed size.
> 
> > 
> > and after the defconfig build:
> > $ free
> >  total   used   free shared

Re: [PATCH 0/3] OOM detection rework v4

[Joonsoo Kim]

On Thu, Mar 03, 2016 at 01:54:43AM -0800, Hugh Dickins wrote:
> On Tue, 1 Mar 2016, Michal Hocko wrote:
> > [Adding Vlastimil and Joonsoo for compaction related things - this was a
> > large thread but the more interesting part starts with
> > http://lkml.kernel.org/r/alpine.LSU.2.11.1602241832160.15564@eggly.anvils]
> > 
> > On Mon 29-02-16 23:29:06, Hugh Dickins wrote:
> > > On Mon, 29 Feb 2016, Michal Hocko wrote:
> > > > On Wed 24-02-16 19:47:06, Hugh Dickins wrote:
> > > > [...]
> > > > > Boot with mem=1G (or boot your usual way, and do something to occupy
> > > > > most of the memory: I think /proc/sys/vm/nr_hugepages provides a great
> > > > > way to gobble up most of the memory, though it's not how I've done 
> > > > > it).
> > > > > 
> > > > > Make sure you have swap: 2G is more than enough.  Copy the v4.5-rc5
> > > > > kernel source tree into a tmpfs: size=2G is more than enough.
> > > > > make defconfig there, then make -j20.
> > > > > 
> > > > > On a v4.5-rc5 kernel that builds fine, on mmotm it is soon OOM-killed.
> > > > > 
> > > > > Except that you'll probably need to fiddle around with that j20,
> > > > > it's true for my laptop but not for my workstation.  j20 just happens
> > > > > to be what I've had there for years, that I now see breaking down
> > > > > (I can lower to j6 to proceed, perhaps could go a bit higher,
> > > > > but it still doesn't exercise swap very much).
> > > > 
> > > > I have tried to reproduce and failed in a virtual on my laptop. I
> > > > will try with another host with more CPUs (because my laptop has only
> > > > two). Just for the record I did: boot 1G machine in kvm, I have 2G swap
> 
> I've found that the number of CPUs makes quite a difference - I have 4.
> 
> And another difference between us may be in our configs: on this laptop
> I had lots of debug options on (including DEBUG_VM, DEBUG_SPINLOCK and
> PROVE_LOCKING, though not DEBUG_PAGEALLOC), which approximately doubles
> the size of each shmem_inode (and those of course are not swappable).
> 
> I found that I could avoid the OOM if I ran the "make -j20" on a
> kernel without all those debug options, and booted with nr_cpus=2.
> And currently I'm booting the kernel with the debug options in,
> but with nr_cpus=2, which does still OOM (whereas not if nr_cpus=1).
> 
> Maybe in the OOM rework, threads are cancelling each other's progress
> more destructively, where before they co-operated to some extent?
> 
> (All that is on the laptop.  The G5 is still busy full-time bisecting
> a powerpc issue: I know it was OOMing with the rework, but I have not
> verified the effect of nr_cpus on it.  My x86 workstation has not been
> OOMing with the rework - I think that means that I've not been exerting
> as much memory pressure on it as I'd thought, that it copes with the load
> better, and would only show the difference if I loaded it more heavily.)
> 
> > > > and reserve 800M for hugetlb pages (I got 445 of them). Then I extract
> > > > the kernel source to tmpfs (-o size=2G), make defconfig and make -j20
> > > > (16, 10 no difference really). I was also collecting vmstat in the
> > > > background. The compilation takes ages but the behavior seems consistent
> > > > and stable.
> > > 
> > > Thanks a lot for giving it a go.
> > > 
> > > I'm puzzled.  445 hugetlb pages in 800M surprises me: some of them
> > > are less than 2M big??  But probably that's just a misunderstanding
> > > or typo somewhere.
> > 
> > A typo. 445 was from 900M test which I was doing while writing the
> > email. Sorry about the confusion.
> 
> That makes more sense!  Though I'm still amazed that you got anywhere,
> taking so much of the usable memory out.
> 
> > 
> > > Ignoring that, you're successfully doing a make -20 defconfig build
> > > in tmpfs, with only 224M of RAM available, plus 2G of swap?  I'm not
> > > at all surprised that it takes ages, but I am very surprised that it
> > > does not OOM.  I suppose by rights it ought not to OOM, the built
> > > tree occupies only a little more than 1G, so you do have enough swap;
> > > but I wouldn't get anywhere near that myself without OOMing - I give
> > > myself 1G of RAM (well, minus whatever the booted system takes up)
> > > to do that build in, four times your RAM, yet in my case it OOMs.
> > >
> > > That source tree alone occupies more than 700M, so just copying it
> > > into your tmpfs would take a long time. 
> > 
> > OK, I just found out that I was cheating a bit. I was building
> > linux-3.7-rc5.tar.bz2 which is smaller:
> > $ du -sh /mnt/tmpfs/linux-3.7-rc5/
> > 537M/mnt/tmpfs/linux-3.7-rc5/
> 
> Right, I have a habit like that too; but my habitual testing still
> uses the 2.6.24 source tree, which is rather too old to ask others
> to reproduce with - but we both find that the kernel source tree
> keeps growing, and prefer to stick with something of a fixed size.
> 
> > 
> > and after the defconfig build:
> > $ free
> >  total   used   free shared

linux-next: manual merge of the akpm-current tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/huge_memory.c

between commit:

  ff20c2e0acc5 ("mm: Some arch may want to use HPAGE_PMD related values as 
variables")

from the powerpc tree and commit:

  82fdbe051e29 ("mm: make optimistic check for swapin readahead")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc mm/huge_memory.c
index 43b11a695113,5b38aa24566f..
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -98,7 -100,8 +100,8 @@@ static DECLARE_WAIT_QUEUE_HEAD(khugepag
   * it would have happened if the vma was large enough during page
   * fault.
   */
 -static unsigned int khugepaged_max_ptes_none __read_mostly = HPAGE_PMD_NR-1;
 -static unsigned int khugepaged_max_ptes_swap __read_mostly = HPAGE_PMD_NR/8;
 +static unsigned int khugepaged_max_ptes_none __read_mostly;
++static unsigned int khugepaged_max_ptes_swap __read_mostly;
  
  static int khugepaged(void *none);
  static int khugepaged_slab_init(void);
@@@ -660,18 -691,6 +691,19 @@@ static int __init hugepage_init(void
return -EINVAL;
}
  
 +  khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
 +  khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
++  khugepaged_max_ptes_swap = HPAGE_PMD_NR / 8;
 +  /*
 +   * hugepages can't be allocated by the buddy allocator
 +   */
 +  MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER);
 +  /*
 +   * we use page->mapping and page->index in second tail page
 +   * as list_head: assuming THP order >= 2
 +   */
 +  MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER < 2);
 +
err = hugepage_init_sysfs(_kobj);
if (err)
goto err_sysfs;

linux-next: manual merge of the akpm-current tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/huge_memory.c

between commit:

  ff20c2e0acc5 ("mm: Some arch may want to use HPAGE_PMD related values as 
variables")

from the powerpc tree and commit:

  82fdbe051e29 ("mm: make optimistic check for swapin readahead")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc mm/huge_memory.c
index 43b11a695113,5b38aa24566f..
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -98,7 -100,8 +100,8 @@@ static DECLARE_WAIT_QUEUE_HEAD(khugepag
   * it would have happened if the vma was large enough during page
   * fault.
   */
 -static unsigned int khugepaged_max_ptes_none __read_mostly = HPAGE_PMD_NR-1;
 -static unsigned int khugepaged_max_ptes_swap __read_mostly = HPAGE_PMD_NR/8;
 +static unsigned int khugepaged_max_ptes_none __read_mostly;
++static unsigned int khugepaged_max_ptes_swap __read_mostly;
  
  static int khugepaged(void *none);
  static int khugepaged_slab_init(void);
@@@ -660,18 -691,6 +691,19 @@@ static int __init hugepage_init(void
return -EINVAL;
}
  
 +  khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
 +  khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
++  khugepaged_max_ptes_swap = HPAGE_PMD_NR / 8;
 +  /*
 +   * hugepages can't be allocated by the buddy allocator
 +   */
 +  MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER);
 +  /*
 +   * we use page->mapping and page->index in second tail page
 +   * as list_head: assuming THP order >= 2
 +   */
 +  MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER < 2);
 +
err = hugepage_init_sysfs(_kobj);
if (err)
goto err_sysfs;

4.4.3: OOPS when running "stress-ng --sock 5"

[Holger Schurig]

Hi,

on my system I can reproduce reliably a kernel OOPS when I run stress-ng
("apt-get install stress-ng"). Any help on how to track this down would
be appreciated, networking code is outside of my comfort zone (I'm just
a dilettante at device drivers ...).

It takes only a minute or two to get the OOPS:

root@ptxc:~# stress-ng --sock 5
stress-ng: info: [361] dispatching hogs: 0 I/O-Sync, 0 CPU, 0 VM-mmap, 0 
HDD-Write, 0 Fork, 0 Context-switch, 0 Pipe, 0 Cache, 5 Socket, 0 Yield, 0 
Fallocate, 0 Flock, 0 Affinity, 0 Timer, 0 Dentry, 0 Urandom, 0 Float, 0 Int, 0 
Semaphore, 0 Open, 0 SigQueue, 0 Poll
Unable to handle kernel NULL pointer dereference at virtual address 0104
pgd = ee0d8000
[0104] *pgd=3e17c831, *pte=, *ppte=
Internal error: Oops: 817 [#1] SMP ARM
Modules linked in: bnep smsc95xx usbnet mii usbhid imx_sdma flexcan btusb btrtl 
btbcm btintel bluetooth
CPU: 2 PID: 362 Comm: stress-ng-socke Not tainted 4.4.3 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: eeb30a00 ti: eea0a000 task.ti: eea0a000
PC is at __rmqueue+0x74/0x308
LR is at 0x3
pc : []lr : [<0003>]psr: 60030093
sp : eea0bc08  ip : 0200  fp : eea0bc54
r10: efd80b14  r9 : 0008  r8 : 
r7 : 0003  r6 :   r5 : c050bff8  r4 : 0100
r3 : c05ce36c  r2 : 006c  r1 : 0200  r0 : 0100
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 3e0d804a  DAC: 0051
Process stress-ng-socke (pid: 362, stack limit = 0xeea0a210)
Stack: (0xeea0bc08 to 0xeea0c000)
bc00:    c05ca780 ed93dd80 ed93dd80 eea0bc5c c05ce280
bc20: c03d5838 c03d3b00 c05b04f8 eea0bd5c c050bff8 c050bfe4 c050bfe4 ed93de38
bc40: 0008 c05ce280 eea0bcec eea0bc58 c0097cb4 c0097294 0141 0002c26d
bc60: c03d59c4 0018 c05ced00 c05b0100 acd4 c0439bb0 000a c05d19c0
bc80:  c05b0080 0100 c05ce490 c05ced08 c05ce3a8 c05cee15 0128
bca0: 0141 020252c0  fff8  eea0bd5c 60030013 0003
bcc0: eea0bcf4 020052c0 0003 c05ced00 ffcb ed93de38 eea0be84 
bce0: eea0bda4 eea0bcf0 c0098084 c009759c c006caf8 80100010 0fcfc2fc 40030013
bd00: eea0bd24 ed93dd80 ed93dd80 0004 ed999e00 ed93dd80 eea0bd8c eea0bd28
bd20: c03ee130 c03ebcac 0002 ef001c00  024102c0  000346db
bd40: c05b0100  0002 ed93e114 0005   c05ced00
bd60:  c05ce280     eea0be84 eeb30eb4
bd80: 024000c0 05d0 ffcb ed93de38 eea0be84  eea0bdbc eea0bda8
bda0: c0389650 c0097fb8 ed93dd80 ed93dd80 eea0bdd4 eea0bdc0 c03896c8 c03895ec
bdc0: ed999e00 ed93dd80 eea0be4c eea0bdd8 c03e14d4 c03896b8 ffcb 0014
bde0: 14bf 0001 eeb30eb4 0001 0001  eea0a018 
be00: eeb30eb4 0001 ffcb 0560 c0434ca8 ffcb 7fff 7fff
be20: ed958000 ed93dd80    eea6c000 eea0a000 
be40: eea0be6c eea0be50 c0407cbc c03e131c ee98c1a0 ed93dd80 eea0beec 
be60: eea0be7c eea0be70 c0385784 c0407c34 eea0bed4 eea0be80 c0385820 c0385774
be80: c00e6220   0001 0560 05d0 eea0bee4 0001
bea0:    eea0bf00  eea6c000 eea0bf80 
bec0:  c000fae4 eea0bf3c eea0bed8 c00c9b2c c03857a0 0b30 0004
bee0: eea0bf1c bea359bc 0b30 0001  0b30 eea0bee4 0001
bf00: eea6c000       
bf20: eea6c000 0b30 bea359bc eea0bf80 eea0bf4c eea0bf40 c00c9b84 c00c9ab0
bf40: eea0bf7c eea0bf50 c00ca330 c00c9b5c   eea0bf7c eea6c000
bf60: eea6c000 0b30 bea359bc c000fae4 eea0bfa4 eea0bf80 c00cac0c c00ca2a4
bf80:   0004 0002a1e8 b6f6f140 0004  eea0bfa8
bfa0: c000f920 c00cabcc 0004 0002a1e8 0004 bea359bc 0b30 bea379bc
bfc0: 0004 0002a1e8 b6f6f140 0004 0b30 016f 0002a1f0 0003
bfe0:  bea358f4 00014a57 b6eaa4d6 40030030 0004  
Backtrace: 
[] (__rmqueue) from [] (get_page_from_freelist+0x724/0x914)
 r10:c05ce280 r9:0008 r8:ed93de38 r7:c050bfe4 r6:c050bfe4 r5:c050bff8
 r4:eea0bd5c
[] (get_page_from_freelist) from [] 
(__alloc_pages_nodemask+0xd8/0x898)
 r10: r9:eea0be84 r8:ed93de38 r7:ffcb r6:c05ced00 r5:0003
 r4:020052c0
[] (__alloc_pages_nodemask) from [] 
(skb_page_frag_refill+0x70/0xcc)
 r10: r9:eea0be84 r8:ed93de38 r7:ffcb r6:05d0 r5:024000c0
 r4:eeb30eb4
[] (skb_page_frag_refill) from [] 
(sk_page_frag_refill+0x1c/0x74)
 r5:ed93dd80 r4:ed93dd80
[] (sk_page_frag_refill) from [] (tcp_sendmsg+0x1c4/0xa58)
 r5:ed93dd80 r4:ed999e00
[] (tcp_sendmsg) from [] (inet_sendmsg+0x94/0xc8)
 r10: r9:eea0a000 r8:eea6c000 r7: r6: r5:
 r4:ed93dd80
[] (inet_sendmsg) from [] (sock_sendmsg+0x1c/0x2c)
 r5: r4:eea0beec
[] (sock_sendmsg) from [] (sock_write_iter+0x8c/0xc0)
[] 

4.4.3: OOPS when running "stress-ng --sock 5"

[Holger Schurig]

Hi,

on my system I can reproduce reliably a kernel OOPS when I run stress-ng
("apt-get install stress-ng"). Any help on how to track this down would
be appreciated, networking code is outside of my comfort zone (I'm just
a dilettante at device drivers ...).

It takes only a minute or two to get the OOPS:

root@ptxc:~# stress-ng --sock 5
stress-ng: info: [361] dispatching hogs: 0 I/O-Sync, 0 CPU, 0 VM-mmap, 0 
HDD-Write, 0 Fork, 0 Context-switch, 0 Pipe, 0 Cache, 5 Socket, 0 Yield, 0 
Fallocate, 0 Flock, 0 Affinity, 0 Timer, 0 Dentry, 0 Urandom, 0 Float, 0 Int, 0 
Semaphore, 0 Open, 0 SigQueue, 0 Poll
Unable to handle kernel NULL pointer dereference at virtual address 0104
pgd = ee0d8000
[0104] *pgd=3e17c831, *pte=, *ppte=
Internal error: Oops: 817 [#1] SMP ARM
Modules linked in: bnep smsc95xx usbnet mii usbhid imx_sdma flexcan btusb btrtl 
btbcm btintel bluetooth
CPU: 2 PID: 362 Comm: stress-ng-socke Not tainted 4.4.3 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: eeb30a00 ti: eea0a000 task.ti: eea0a000
PC is at __rmqueue+0x74/0x308
LR is at 0x3
pc : []lr : [<0003>]psr: 60030093
sp : eea0bc08  ip : 0200  fp : eea0bc54
r10: efd80b14  r9 : 0008  r8 : 
r7 : 0003  r6 :   r5 : c050bff8  r4 : 0100
r3 : c05ce36c  r2 : 006c  r1 : 0200  r0 : 0100
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 3e0d804a  DAC: 0051
Process stress-ng-socke (pid: 362, stack limit = 0xeea0a210)
Stack: (0xeea0bc08 to 0xeea0c000)
bc00:    c05ca780 ed93dd80 ed93dd80 eea0bc5c c05ce280
bc20: c03d5838 c03d3b00 c05b04f8 eea0bd5c c050bff8 c050bfe4 c050bfe4 ed93de38
bc40: 0008 c05ce280 eea0bcec eea0bc58 c0097cb4 c0097294 0141 0002c26d
bc60: c03d59c4 0018 c05ced00 c05b0100 acd4 c0439bb0 000a c05d19c0
bc80:  c05b0080 0100 c05ce490 c05ced08 c05ce3a8 c05cee15 0128
bca0: 0141 020252c0  fff8  eea0bd5c 60030013 0003
bcc0: eea0bcf4 020052c0 0003 c05ced00 ffcb ed93de38 eea0be84 
bce0: eea0bda4 eea0bcf0 c0098084 c009759c c006caf8 80100010 0fcfc2fc 40030013
bd00: eea0bd24 ed93dd80 ed93dd80 0004 ed999e00 ed93dd80 eea0bd8c eea0bd28
bd20: c03ee130 c03ebcac 0002 ef001c00  024102c0  000346db
bd40: c05b0100  0002 ed93e114 0005   c05ced00
bd60:  c05ce280     eea0be84 eeb30eb4
bd80: 024000c0 05d0 ffcb ed93de38 eea0be84  eea0bdbc eea0bda8
bda0: c0389650 c0097fb8 ed93dd80 ed93dd80 eea0bdd4 eea0bdc0 c03896c8 c03895ec
bdc0: ed999e00 ed93dd80 eea0be4c eea0bdd8 c03e14d4 c03896b8 ffcb 0014
bde0: 14bf 0001 eeb30eb4 0001 0001  eea0a018 
be00: eeb30eb4 0001 ffcb 0560 c0434ca8 ffcb 7fff 7fff
be20: ed958000 ed93dd80    eea6c000 eea0a000 
be40: eea0be6c eea0be50 c0407cbc c03e131c ee98c1a0 ed93dd80 eea0beec 
be60: eea0be7c eea0be70 c0385784 c0407c34 eea0bed4 eea0be80 c0385820 c0385774
be80: c00e6220   0001 0560 05d0 eea0bee4 0001
bea0:    eea0bf00  eea6c000 eea0bf80 
bec0:  c000fae4 eea0bf3c eea0bed8 c00c9b2c c03857a0 0b30 0004
bee0: eea0bf1c bea359bc 0b30 0001  0b30 eea0bee4 0001
bf00: eea6c000       
bf20: eea6c000 0b30 bea359bc eea0bf80 eea0bf4c eea0bf40 c00c9b84 c00c9ab0
bf40: eea0bf7c eea0bf50 c00ca330 c00c9b5c   eea0bf7c eea6c000
bf60: eea6c000 0b30 bea359bc c000fae4 eea0bfa4 eea0bf80 c00cac0c c00ca2a4
bf80:   0004 0002a1e8 b6f6f140 0004  eea0bfa8
bfa0: c000f920 c00cabcc 0004 0002a1e8 0004 bea359bc 0b30 bea379bc
bfc0: 0004 0002a1e8 b6f6f140 0004 0b30 016f 0002a1f0 0003
bfe0:  bea358f4 00014a57 b6eaa4d6 40030030 0004  
Backtrace: 
[] (__rmqueue) from [] (get_page_from_freelist+0x724/0x914)
 r10:c05ce280 r9:0008 r8:ed93de38 r7:c050bfe4 r6:c050bfe4 r5:c050bff8
 r4:eea0bd5c
[] (get_page_from_freelist) from [] 
(__alloc_pages_nodemask+0xd8/0x898)
 r10: r9:eea0be84 r8:ed93de38 r7:ffcb r6:c05ced00 r5:0003
 r4:020052c0
[] (__alloc_pages_nodemask) from [] 
(skb_page_frag_refill+0x70/0xcc)
 r10: r9:eea0be84 r8:ed93de38 r7:ffcb r6:05d0 r5:024000c0
 r4:eeb30eb4
[] (skb_page_frag_refill) from [] 
(sk_page_frag_refill+0x1c/0x74)
 r5:ed93dd80 r4:ed93dd80
[] (sk_page_frag_refill) from [] (tcp_sendmsg+0x1c4/0xa58)
 r5:ed93dd80 r4:ed999e00
[] (tcp_sendmsg) from [] (inet_sendmsg+0x94/0xc8)
 r10: r9:eea0a000 r8:eea6c000 r7: r6: r5:
 r4:ed93dd80
[] (inet_sendmsg) from [] (sock_sendmsg+0x1c/0x2c)
 r5: r4:eea0beec
[] (sock_sendmsg) from [] (sock_write_iter+0x8c/0xc0)
[] 

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Fri, 04 Mar 2016, Russel Winder  wrote:
> On Thu, 2016-03-03 at 15:23 -0800, Keith Packard wrote:
>>   1) the python version (asciidoc) appears to have been abandoned in
>>  favor of the ruby version. 
>
> This is I think true, however the Java-based tool chain Asciidoctor is
> I believe the standard bearer for ASCIIdoc these days, albeit called
> ASCIIdoctor.

If we're talking about the same asciidoctor (http://asciidoctor.org/)
it's written in ruby but you can apparently run it in JVM using
JRuby. Calling it Java-based is misleading.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Fri, 04 Mar 2016, Russel Winder  wrote:
> On Thu, 2016-03-03 at 15:23 -0800, Keith Packard wrote:
>>   1) the python version (asciidoc) appears to have been abandoned in
>>  favor of the ruby version. 
>
> This is I think true, however the Java-based tool chain Asciidoctor is
> I believe the standard bearer for ASCIIdoc these days, albeit called
> ASCIIdoctor.

If we're talking about the same asciidoctor (http://asciidoctor.org/)
it's written in ruby but you can apparently run it in JVM using
JRuby. Calling it Java-based is misleading.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 0/3] OOM detection rework v4

[Vlastimil Babka]

On 03/03/2016 09:57 PM, Hugh Dickins wrote:
> 
>>
>> I do not have an explanation why it would cause oom sooner but this
>> turned out to be incomplete. There is another wmaark check deeper in the
>> compaction path. Could you try the one from
>> http://lkml.kernel.org/r/20160302130022.gg26...@dhcp22.suse.cz
> 
> I've now added that in: it corrects the "sooner", but does not make
> any difference to the fact of OOMing for me.

Could you try producing a trace with
echo 1 > /debug/tracing/events/compaction/enable
echo 1 > /debug/tracing/events/migrate/mm_migrate_pages/enable

Hopefully it will hint at what's wrong with:
compact_migrate_scanned 424920
compact_free_scanned 9278408
compact_isolated 469472
compact_stall 377
compact_fail 297
compact_success 80
compact_kcompatd_wake 0

Re: [PATCH 0/3] OOM detection rework v4

[Vlastimil Babka]

On 03/03/2016 09:57 PM, Hugh Dickins wrote:
> 
>>
>> I do not have an explanation why it would cause oom sooner but this
>> turned out to be incomplete. There is another wmaark check deeper in the
>> compaction path. Could you try the one from
>> http://lkml.kernel.org/r/20160302130022.gg26...@dhcp22.suse.cz
> 
> I've now added that in: it corrects the "sooner", but does not make
> any difference to the fact of OOMing for me.

Could you try producing a trace with
echo 1 > /debug/tracing/events/compaction/enable
echo 1 > /debug/tracing/events/migrate/mm_migrate_pages/enable

Hopefully it will hint at what's wrong with:
compact_migrate_scanned 424920
compact_free_scanned 9278408
compact_isolated 469472
compact_stall 377
compact_fail 297
compact_success 80
compact_kcompatd_wake 0

[PATCH v5 2/3] gpio: designware: add acpi binding

[qiujiang]

This patch adds acpi binding for designware gpio driver,
because it is used to support power button on hisilicon
d02 board.

These two bindings, DT and acpi, are compatible in this
driver.

Reviewed-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
Signed-off-by: qiujiang 
---
 drivers/gpio/gpio-dwapb.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 49f6e5d..2ae506f 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -7,6 +7,7 @@
  *
  * All enquiries to supp...@picochip.com
  */
+#include 
 #include 
 /* FIXME: for gpio_get_value(), replace this with direct register read */
 #include 
@@ -449,7 +450,7 @@ static void dwapb_gpio_unregister(struct dwapb_gpio *gpio)
 }
 
 static struct dwapb_platform_data *
-dwapb_gpio_get_pdata_of(struct device *dev)
+dwapb_gpio_get_pdata(struct device *dev)
 {
struct fwnode_handle *fwnode;
struct dwapb_platform_data *pdata;
@@ -502,9 +503,17 @@ dwapb_gpio_get_pdata_of(struct device *dev)
}
}
 
+   if (has_acpi_companion(dev) && pp->idx == 0)
+   pp->irq = platform_get_irq(to_platform_device(dev), 0);
+
pp->irq_shared  = false;
pp->gpio_base   = -1;
-   pp->name= to_of_node(fwnode)->full_name;
+
+   if (dev->of_node)
+   pp->name = to_of_node(fwnode)->full_name;
+
+   if (has_acpi_companion(dev))
+   pp->name = acpi_dev_name(to_acpi_device_node(fwnode));
}
 
return pdata;
@@ -520,7 +529,7 @@ static int dwapb_gpio_probe(struct platform_device *pdev)
struct dwapb_platform_data *pdata = dev_get_platdata(dev);
 
if (!pdata) {
-   pdata = dwapb_gpio_get_pdata_of(dev);
+   pdata = dwapb_gpio_get_pdata(dev);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
}
@@ -577,6 +586,12 @@ static const struct of_device_id dwapb_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, dwapb_of_match);
 
+static const struct acpi_device_id dwapb_acpi_match[] = {
+   {"HISI0181", 0},
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, dwapb_acpi_match);
+
 #ifdef CONFIG_PM_SLEEP
 static int dwapb_gpio_suspend(struct device *dev)
 {
@@ -671,6 +686,7 @@ static struct platform_driver dwapb_gpio_driver = {
.name   = "gpio-dwapb",
.pm = _gpio_pm_ops,
.of_match_table = of_match_ptr(dwapb_of_match),
+   .acpi_match_table = ACPI_PTR(dwapb_acpi_match),
},
.probe  = dwapb_gpio_probe,
.remove = dwapb_gpio_remove,
-- 
1.9.1

[PATCH v5 3/3] gpio: designware: add gpio-signaled acpi event support

[qiujiang]

This patch adds the support for the gpio-signaled acpi event.
This is used for power button on hisilicon D02 board, which
is an arm64 platform.

To support this function, _AEI and _Exx objects must be
defined in the corresponding GPIO device as follows:

Name (_AEI, ResourceTemplate () {
GpioInt(Edge, ActiveLow, ExclusiveAndWake, PullUp,
, " \\_SB.GPI0") {8}
})
Method (_E08, 0x0, NotSerialized) {
Notify (\_SB.PWRB, 0x80)
}

Acked-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Signed-off-by: qiujiang 
---
 drivers/gpio/gpio-dwapb.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 2ae506f..043e1c2 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 
+#include "gpiolib.h"
+
 #define GPIO_SWPORTA_DR0x00
 #define GPIO_SWPORTA_DDR   0x04
 #define GPIO_SWPORTB_DR0x0c
@@ -437,6 +439,10 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
else
port->is_registered = true;
 
+   /* Add GPIO-signaled ACPI event support */
+   if (pp->irq)
+   acpi_gpiochip_request_interrupts(>gc);
+
return err;
 }
 
-- 
1.9.1

[PATCH v5 2/3] gpio: designware: add acpi binding

[qiujiang]

This patch adds acpi binding for designware gpio driver,
because it is used to support power button on hisilicon
d02 board.

These two bindings, DT and acpi, are compatible in this
driver.

Reviewed-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
Signed-off-by: qiujiang 
---
 drivers/gpio/gpio-dwapb.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 49f6e5d..2ae506f 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -7,6 +7,7 @@
  *
  * All enquiries to supp...@picochip.com
  */
+#include 
 #include 
 /* FIXME: for gpio_get_value(), replace this with direct register read */
 #include 
@@ -449,7 +450,7 @@ static void dwapb_gpio_unregister(struct dwapb_gpio *gpio)
 }
 
 static struct dwapb_platform_data *
-dwapb_gpio_get_pdata_of(struct device *dev)
+dwapb_gpio_get_pdata(struct device *dev)
 {
struct fwnode_handle *fwnode;
struct dwapb_platform_data *pdata;
@@ -502,9 +503,17 @@ dwapb_gpio_get_pdata_of(struct device *dev)
}
}
 
+   if (has_acpi_companion(dev) && pp->idx == 0)
+   pp->irq = platform_get_irq(to_platform_device(dev), 0);
+
pp->irq_shared  = false;
pp->gpio_base   = -1;
-   pp->name= to_of_node(fwnode)->full_name;
+
+   if (dev->of_node)
+   pp->name = to_of_node(fwnode)->full_name;
+
+   if (has_acpi_companion(dev))
+   pp->name = acpi_dev_name(to_acpi_device_node(fwnode));
}
 
return pdata;
@@ -520,7 +529,7 @@ static int dwapb_gpio_probe(struct platform_device *pdev)
struct dwapb_platform_data *pdata = dev_get_platdata(dev);
 
if (!pdata) {
-   pdata = dwapb_gpio_get_pdata_of(dev);
+   pdata = dwapb_gpio_get_pdata(dev);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
}
@@ -577,6 +586,12 @@ static const struct of_device_id dwapb_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, dwapb_of_match);
 
+static const struct acpi_device_id dwapb_acpi_match[] = {
+   {"HISI0181", 0},
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, dwapb_acpi_match);
+
 #ifdef CONFIG_PM_SLEEP
 static int dwapb_gpio_suspend(struct device *dev)
 {
@@ -671,6 +686,7 @@ static struct platform_driver dwapb_gpio_driver = {
.name   = "gpio-dwapb",
.pm = _gpio_pm_ops,
.of_match_table = of_match_ptr(dwapb_of_match),
+   .acpi_match_table = ACPI_PTR(dwapb_acpi_match),
},
.probe  = dwapb_gpio_probe,
.remove = dwapb_gpio_remove,
-- 
1.9.1

[PATCH v5 3/3] gpio: designware: add gpio-signaled acpi event support

[qiujiang]

This patch adds the support for the gpio-signaled acpi event.
This is used for power button on hisilicon D02 board, which
is an arm64 platform.

To support this function, _AEI and _Exx objects must be
defined in the corresponding GPIO device as follows:

Name (_AEI, ResourceTemplate () {
GpioInt(Edge, ActiveLow, ExclusiveAndWake, PullUp,
, " \\_SB.GPI0") {8}
})
Method (_E08, 0x0, NotSerialized) {
Notify (\_SB.PWRB, 0x80)
}

Acked-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Signed-off-by: qiujiang 
---
 drivers/gpio/gpio-dwapb.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 2ae506f..043e1c2 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 
+#include "gpiolib.h"
+
 #define GPIO_SWPORTA_DR0x00
 #define GPIO_SWPORTA_DDR   0x04
 #define GPIO_SWPORTB_DR0x0c
@@ -437,6 +439,10 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
else
port->is_registered = true;
 
+   /* Add GPIO-signaled ACPI event support */
+   if (pp->irq)
+   acpi_gpiochip_request_interrupts(>gc);
+
return err;
 }
 
-- 
1.9.1

[PATCH v5 0/3] "gpio: designware: add gpio-signaled acpi event support for power button"

[qiujiang]

This patchset adds gpio-signaled acpi events support for power button on 
hisilicon
D02 board.

The three patches respectively:
- convert device node to fwnode
- add acpi binding
- add gpio-signaled acpi event support

   This patchset is based on
   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
   branch "devel"

Changes v4 -> v5:
   - split into three patchs
   - add Andy's ACKs
   
Changes v3 -> v4:
   - re-organize this two patchs by Andy's suggestion

Changes v2 -> v3:
   - fixed the build error reported by Kbuild test robot

Changes v1 -> v2: 
   - rebase to branch "devel" of Linus Walleij's repository
   - split in two patch as suggested by Andy S
   - add Mika's ACKs

qiujiang (3):
  gpio: designware: convert device node to fwnode
  gpio: designware: add acpi binding
  gpio: designware: add gpio-signaled acpi event support

 drivers/gpio/gpio-dwapb.c| 69 
 drivers/mfd/intel_quark_i2c_gpio.c   |  2 +-
 include/linux/platform_data/gpio-dwapb.h |  2 +-
 3 files changed, 46 insertions(+), 27 deletions(-)

-- 
1.9.1

[PATCH v5 1/3] gpio: designware: convert device node to fwnode

[qiujiang]

This patch converts device node to fwnode in
dwapb_port_property for designware gpio driver,
so as to provide a unified data structure for DT
and ACPI bindings.

Acked-by: Andy Shevchenko 
Signed-off-by: qiujiang 
---
 drivers/gpio/gpio-dwapb.c| 43 +++-
 drivers/mfd/intel_quark_i2c_gpio.c   |  2 +-
 include/linux/platform_data/gpio-dwapb.h |  2 +-
 3 files changed, 22 insertions(+), 25 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 597de1e..49f6e5d 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -290,14 +291,14 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
 struct dwapb_port_property *pp)
 {
struct gpio_chip *gc = >gc;
-   struct device_node *node = pp->node;
+   struct fwnode_handle  *fwnode = pp->fwnode;
struct irq_chip_generic *irq_gc = NULL;
unsigned int hwirq, ngpio = gc->ngpio;
struct irq_chip_type *ct;
int err, i;
 
-   gpio->domain = irq_domain_add_linear(node, ngpio,
-_generic_chip_ops, gpio);
+   gpio->domain = irq_domain_create_linear(fwnode, ngpio,
+_generic_chip_ops, gpio);
if (!gpio->domain)
return;
 
@@ -415,7 +416,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
}
 
 #ifdef CONFIG_OF_GPIO
-   port->gc.of_node = pp->node;
+   port->gc.of_node = is_of_node(pp->fwnode) ?
+   to_of_node(pp->fwnode) : NULL;
 #endif
port->gc.ngpio = pp->ngpio;
port->gc.base = pp->gpio_base;
@@ -449,17 +451,13 @@ static void dwapb_gpio_unregister(struct dwapb_gpio *gpio)
 static struct dwapb_platform_data *
 dwapb_gpio_get_pdata_of(struct device *dev)
 {
-   struct device_node *node, *port_np;
+   struct fwnode_handle *fwnode;
struct dwapb_platform_data *pdata;
struct dwapb_port_property *pp;
int nports;
int i;
 
-   node = dev->of_node;
-   if (!IS_ENABLED(CONFIG_OF_GPIO) || !node)
-   return ERR_PTR(-ENODEV);
-
-   nports = of_get_child_count(node);
+   nports = device_get_child_node_count(dev);
if (nports == 0)
return ERR_PTR(-ENODEV);
 
@@ -474,21 +472,19 @@ dwapb_gpio_get_pdata_of(struct device *dev)
pdata->nports = nports;
 
i = 0;
-   for_each_child_of_node(node, port_np) {
+   device_for_each_child_node(dev, fwnode)  {
pp = >properties[i++];
-   pp->node = port_np;
+   pp->fwnode = fwnode;
 
-   if (of_property_read_u32(port_np, "reg", >idx) ||
+   if (fwnode_property_read_u32(fwnode, "reg", >idx) ||
pp->idx >= DWAPB_MAX_PORTS) {
-   dev_err(dev, "missing/invalid port index for %s\n",
-   port_np->full_name);
+   dev_err(dev, "missing/invalid port index\n");
return ERR_PTR(-EINVAL);
}
 
-   if (of_property_read_u32(port_np, "snps,nr-gpios",
+   if (fwnode_property_read_u32(fwnode, "snps,nr-gpios",
 >ngpio)) {
-   dev_info(dev, "failed to get number of gpios for %s\n",
-port_np->full_name);
+   dev_info(dev, "failed to get number of gpios\n");
pp->ngpio = 32;
}
 
@@ -496,18 +492,19 @@ dwapb_gpio_get_pdata_of(struct device *dev)
 * Only port A can provide interrupts in all configurations of
 * the IP.
 */
-   if (pp->idx == 0 &&
-   of_property_read_bool(port_np, "interrupt-controller")) {
-   pp->irq = irq_of_parse_and_map(port_np, 0);
+   if (dev->of_node && pp->idx == 0 &&
+   of_property_read_bool(to_of_node(fwnode),
+   "interrupt-controller")) {
+   pp->irq = irq_of_parse_and_map(to_of_node(fwnode), 0);
if (!pp->irq) {
dev_warn(dev, "no irq for bank %s\n",
-port_np->full_name);
+to_of_node(fwnode)->full_name);
}
}
 
pp->irq_shared  = false;
pp->gpio_base   = -1;
-   pp->name= port_np->full_name;
+   pp->name= to_of_node(fwnode)->full_name;
}
 
return pdata;
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c 
b/drivers/mfd/intel_quark_i2c_gpio.c
index 0421374..265bd3c 100644

[PATCH v5 0/3] "gpio: designware: add gpio-signaled acpi event support for power button"

[qiujiang]

This patchset adds gpio-signaled acpi events support for power button on 
hisilicon
D02 board.

The three patches respectively:
- convert device node to fwnode
- add acpi binding
- add gpio-signaled acpi event support

   This patchset is based on
   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
   branch "devel"

Changes v4 -> v5:
   - split into three patchs
   - add Andy's ACKs
   
Changes v3 -> v4:
   - re-organize this two patchs by Andy's suggestion

Changes v2 -> v3:
   - fixed the build error reported by Kbuild test robot

Changes v1 -> v2: 
   - rebase to branch "devel" of Linus Walleij's repository
   - split in two patch as suggested by Andy S
   - add Mika's ACKs

qiujiang (3):
  gpio: designware: convert device node to fwnode
  gpio: designware: add acpi binding
  gpio: designware: add gpio-signaled acpi event support

 drivers/gpio/gpio-dwapb.c| 69 
 drivers/mfd/intel_quark_i2c_gpio.c   |  2 +-
 include/linux/platform_data/gpio-dwapb.h |  2 +-
 3 files changed, 46 insertions(+), 27 deletions(-)

-- 
1.9.1

[PATCH v5 1/3] gpio: designware: convert device node to fwnode

[qiujiang]

This patch converts device node to fwnode in
dwapb_port_property for designware gpio driver,
so as to provide a unified data structure for DT
and ACPI bindings.

Acked-by: Andy Shevchenko 
Signed-off-by: qiujiang 
---
 drivers/gpio/gpio-dwapb.c| 43 +++-
 drivers/mfd/intel_quark_i2c_gpio.c   |  2 +-
 include/linux/platform_data/gpio-dwapb.h |  2 +-
 3 files changed, 22 insertions(+), 25 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 597de1e..49f6e5d 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -290,14 +291,14 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
 struct dwapb_port_property *pp)
 {
struct gpio_chip *gc = >gc;
-   struct device_node *node = pp->node;
+   struct fwnode_handle  *fwnode = pp->fwnode;
struct irq_chip_generic *irq_gc = NULL;
unsigned int hwirq, ngpio = gc->ngpio;
struct irq_chip_type *ct;
int err, i;
 
-   gpio->domain = irq_domain_add_linear(node, ngpio,
-_generic_chip_ops, gpio);
+   gpio->domain = irq_domain_create_linear(fwnode, ngpio,
+_generic_chip_ops, gpio);
if (!gpio->domain)
return;
 
@@ -415,7 +416,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
}
 
 #ifdef CONFIG_OF_GPIO
-   port->gc.of_node = pp->node;
+   port->gc.of_node = is_of_node(pp->fwnode) ?
+   to_of_node(pp->fwnode) : NULL;
 #endif
port->gc.ngpio = pp->ngpio;
port->gc.base = pp->gpio_base;
@@ -449,17 +451,13 @@ static void dwapb_gpio_unregister(struct dwapb_gpio *gpio)
 static struct dwapb_platform_data *
 dwapb_gpio_get_pdata_of(struct device *dev)
 {
-   struct device_node *node, *port_np;
+   struct fwnode_handle *fwnode;
struct dwapb_platform_data *pdata;
struct dwapb_port_property *pp;
int nports;
int i;
 
-   node = dev->of_node;
-   if (!IS_ENABLED(CONFIG_OF_GPIO) || !node)
-   return ERR_PTR(-ENODEV);
-
-   nports = of_get_child_count(node);
+   nports = device_get_child_node_count(dev);
if (nports == 0)
return ERR_PTR(-ENODEV);
 
@@ -474,21 +472,19 @@ dwapb_gpio_get_pdata_of(struct device *dev)
pdata->nports = nports;
 
i = 0;
-   for_each_child_of_node(node, port_np) {
+   device_for_each_child_node(dev, fwnode)  {
pp = >properties[i++];
-   pp->node = port_np;
+   pp->fwnode = fwnode;
 
-   if (of_property_read_u32(port_np, "reg", >idx) ||
+   if (fwnode_property_read_u32(fwnode, "reg", >idx) ||
pp->idx >= DWAPB_MAX_PORTS) {
-   dev_err(dev, "missing/invalid port index for %s\n",
-   port_np->full_name);
+   dev_err(dev, "missing/invalid port index\n");
return ERR_PTR(-EINVAL);
}
 
-   if (of_property_read_u32(port_np, "snps,nr-gpios",
+   if (fwnode_property_read_u32(fwnode, "snps,nr-gpios",
 >ngpio)) {
-   dev_info(dev, "failed to get number of gpios for %s\n",
-port_np->full_name);
+   dev_info(dev, "failed to get number of gpios\n");
pp->ngpio = 32;
}
 
@@ -496,18 +492,19 @@ dwapb_gpio_get_pdata_of(struct device *dev)
 * Only port A can provide interrupts in all configurations of
 * the IP.
 */
-   if (pp->idx == 0 &&
-   of_property_read_bool(port_np, "interrupt-controller")) {
-   pp->irq = irq_of_parse_and_map(port_np, 0);
+   if (dev->of_node && pp->idx == 0 &&
+   of_property_read_bool(to_of_node(fwnode),
+   "interrupt-controller")) {
+   pp->irq = irq_of_parse_and_map(to_of_node(fwnode), 0);
if (!pp->irq) {
dev_warn(dev, "no irq for bank %s\n",
-port_np->full_name);
+to_of_node(fwnode)->full_name);
}
}
 
pp->irq_shared  = false;
pp->gpio_base   = -1;
-   pp->name= port_np->full_name;
+   pp->name= to_of_node(fwnode)->full_name;
}
 
return pdata;
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c 
b/drivers/mfd/intel_quark_i2c_gpio.c
index 0421374..265bd3c 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ 

Re: Suspicious error for CMA stress test

[Hanjun Guo]

On 2016/3/4 14:38, Joonsoo Kim wrote:
> On Fri, Mar 04, 2016 at 02:05:09PM +0800, Hanjun Guo wrote:
>> On 2016/3/4 12:32, Joonsoo Kim wrote:
>>> On Fri, Mar 04, 2016 at 11:02:33AM +0900, Joonsoo Kim wrote:
 On Thu, Mar 03, 2016 at 08:49:01PM +0800, Hanjun Guo wrote:
> On 2016/3/3 15:42, Joonsoo Kim wrote:
>> 2016-03-03 10:25 GMT+09:00 Laura Abbott :
>>> (cc -mm and Joonsoo Kim)
>>>
>>>
>>> On 03/02/2016 05:52 AM, Hanjun Guo wrote:
 Hi,

 I came across a suspicious error for CMA stress test:

 Before the test, I got:
 -bash-4.3# cat /proc/meminfo | grep Cma
 CmaTotal: 204800 kB
 CmaFree:  195044 kB


 After running the test:
 -bash-4.3# cat /proc/meminfo | grep Cma
 CmaTotal: 204800 kB
 CmaFree: 6602584 kB

 So the freed CMA memory is more than total..

 Also the the MemFree is more than mem total:

 -bash-4.3# cat /proc/meminfo
 MemTotal:   16342016 kB
 MemFree:22367268 kB
 MemAvailable:   22370528 kB
> [...]
>>> I played with this a bit and can see the same problem. The sanity
>>> check of CmaFree < CmaTotal generally triggers in
>>> __move_zone_freepage_state in unset_migratetype_isolate.
>>> This also seems to be present as far back as v4.0 which was the
>>> first version to have the updated accounting from Joonsoo.
>>> Were there known limitations with the new freepage accounting,
>>> Joonsoo?
>> I don't know. I also played with this and looks like there is
>> accounting problem, however, for my case, number of free page is 
>> slightly less
>> than total. I will take a look.
>>
>> Hanjun, could you tell me your malloc_size? I tested with 1 and it 
>> doesn't
>> look like your case.
> I tested with malloc_size with 2M, and it grows much bigger than 1M, also 
> I
> did some other test:
 Thanks! Now, I can re-generate erronous situation you mentioned.

>  - run with single thread with 10 times, everything is fine.
>
>  - I hack the cam_alloc() and free as below [1] to see if it's lock 
> issue, with
>the same test with 100 multi-thread, then I got:
 [1] would not be sufficient to close this race.

 Try following things [A]. And, for more accurate test, I changed code a 
 bit more
 to prevent kernel page allocation from cma area [B]. This will prevent 
 kernel
 page allocation from cma area completely so we can focus cma_alloc/release 
 race.

 Although, this is not correct fix, it could help that we can guess
 where the problem is.
>>> More correct fix is something like below.
>>> Please test it.
>> Hmm, this is not working:
> Sad to hear that.
>
> Could you tell me your system's MAX_ORDER and pageblock_order?
>

MAX_ORDER is 11, pageblock_order is 9, thanks for your help!

Hanjun

Re: Suspicious error for CMA stress test

[Hanjun Guo]

On 2016/3/4 14:38, Joonsoo Kim wrote:
> On Fri, Mar 04, 2016 at 02:05:09PM +0800, Hanjun Guo wrote:
>> On 2016/3/4 12:32, Joonsoo Kim wrote:
>>> On Fri, Mar 04, 2016 at 11:02:33AM +0900, Joonsoo Kim wrote:
 On Thu, Mar 03, 2016 at 08:49:01PM +0800, Hanjun Guo wrote:
> On 2016/3/3 15:42, Joonsoo Kim wrote:
>> 2016-03-03 10:25 GMT+09:00 Laura Abbott :
>>> (cc -mm and Joonsoo Kim)
>>>
>>>
>>> On 03/02/2016 05:52 AM, Hanjun Guo wrote:
 Hi,

 I came across a suspicious error for CMA stress test:

 Before the test, I got:
 -bash-4.3# cat /proc/meminfo | grep Cma
 CmaTotal: 204800 kB
 CmaFree:  195044 kB


 After running the test:
 -bash-4.3# cat /proc/meminfo | grep Cma
 CmaTotal: 204800 kB
 CmaFree: 6602584 kB

 So the freed CMA memory is more than total..

 Also the the MemFree is more than mem total:

 -bash-4.3# cat /proc/meminfo
 MemTotal:   16342016 kB
 MemFree:22367268 kB
 MemAvailable:   22370528 kB
> [...]
>>> I played with this a bit and can see the same problem. The sanity
>>> check of CmaFree < CmaTotal generally triggers in
>>> __move_zone_freepage_state in unset_migratetype_isolate.
>>> This also seems to be present as far back as v4.0 which was the
>>> first version to have the updated accounting from Joonsoo.
>>> Were there known limitations with the new freepage accounting,
>>> Joonsoo?
>> I don't know. I also played with this and looks like there is
>> accounting problem, however, for my case, number of free page is 
>> slightly less
>> than total. I will take a look.
>>
>> Hanjun, could you tell me your malloc_size? I tested with 1 and it 
>> doesn't
>> look like your case.
> I tested with malloc_size with 2M, and it grows much bigger than 1M, also 
> I
> did some other test:
 Thanks! Now, I can re-generate erronous situation you mentioned.

>  - run with single thread with 10 times, everything is fine.
>
>  - I hack the cam_alloc() and free as below [1] to see if it's lock 
> issue, with
>the same test with 100 multi-thread, then I got:
 [1] would not be sufficient to close this race.

 Try following things [A]. And, for more accurate test, I changed code a 
 bit more
 to prevent kernel page allocation from cma area [B]. This will prevent 
 kernel
 page allocation from cma area completely so we can focus cma_alloc/release 
 race.

 Although, this is not correct fix, it could help that we can guess
 where the problem is.
>>> More correct fix is something like below.
>>> Please test it.
>> Hmm, this is not working:
> Sad to hear that.
>
> Could you tell me your system's MAX_ORDER and pageblock_order?
>

MAX_ORDER is 11, pageblock_order is 9, thanks for your help!

Hanjun

Re: Kernel docs: muddying the waters a bit

[Russel Winder]

On Thu, 2016-03-03 at 15:23 -0800, Keith Packard wrote:
> 
[…]
> However, I think asciidoc has two serious problems:
> 
>   1) the python version (asciidoc) appears to have been abandoned in
>  favor of the ruby version. 

This is I think true, however the Java-based tool chain Asciidoctor is
I believe the standard bearer for ASCIIdoc these days, albeit called
ASCIIdoctor.

>   2) It really is just a docbook pre-processor. Native html/latex
> output
>  is poorly supported at best, and exposes only a small subset of
> the
>  full capabilities of the input language.

This is not true. Yes ASCIIDoc started as a DocBook/XML frontend so as
to use a sane :-) markup language rather than XML (XML is a notation
for consenting computers only), but the current ASCIIDoctor toolchain
deals very well in direct HTML and PDF generation, without needing a
DocBook/XML toolchain. 

> As such, we would have to commit to using the ruby version and either
> committing to fixing the native html output backend or continuing to
> use
> the rest of the docbook toolchain.

Or trial the JVM-based ASCIIdoctor which is what the projects I am
involved with chose to use. Perhaps as an example I can give you http:/
/gpars.website (it's a redirector) all the HTML and PDF is generated
from ASCIIDoc source using ASCIIDoctor driven with a Gradle build
system. This is still very much a work in progress (by Jim Northrop,
not me currently), but I like it.

> We could insist on using the python version, of course. I spent a bit
> of
> time hacking that up to add 'real' support for a table-of-contents in
> the native HTML backend and it looks like getting those changes
> upstreamed would be reasonably straightforward. However, we'd end up
> 'owning' the code, and I'm not sure we want to.

If the Python version is really not being maintained, I would suggest
that unless you want to take over the project and be it's maintainer,
you would be better advised to use a different version.

-- 
Russel.=Dr
 Russel Winder  t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net41 
Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.ukLondon SW11 
1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Kernel docs: muddying the waters a bit

[Russel Winder]

On Thu, 2016-03-03 at 15:23 -0800, Keith Packard wrote:
> 
[…]
> However, I think asciidoc has two serious problems:
> 
>   1) the python version (asciidoc) appears to have been abandoned in
>  favor of the ruby version. 

This is I think true, however the Java-based tool chain Asciidoctor is
I believe the standard bearer for ASCIIdoc these days, albeit called
ASCIIdoctor.

>   2) It really is just a docbook pre-processor. Native html/latex
> output
>  is poorly supported at best, and exposes only a small subset of
> the
>  full capabilities of the input language.

This is not true. Yes ASCIIDoc started as a DocBook/XML frontend so as
to use a sane :-) markup language rather than XML (XML is a notation
for consenting computers only), but the current ASCIIDoctor toolchain
deals very well in direct HTML and PDF generation, without needing a
DocBook/XML toolchain. 

> As such, we would have to commit to using the ruby version and either
> committing to fixing the native html output backend or continuing to
> use
> the rest of the docbook toolchain.

Or trial the JVM-based ASCIIdoctor which is what the projects I am
involved with chose to use. Perhaps as an example I can give you http:/
/gpars.website (it's a redirector) all the HTML and PDF is generated
from ASCIIDoc source using ASCIIDoctor driven with a Gradle build
system. This is still very much a work in progress (by Jim Northrop,
not me currently), but I like it.

> We could insist on using the python version, of course. I spent a bit
> of
> time hacking that up to add 'real' support for a table-of-contents in
> the native HTML backend and it looks like getting those changes
> upstreamed would be reasonably straightforward. However, we'd end up
> 'owning' the code, and I'm not sure we want to.

If the Python version is really not being maintained, I would suggest
that unless you want to take over the project and be it's maintainer,
you would be better advised to use a different version.

-- 
Russel.=Dr
 Russel Winder  t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net41 
Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.ukLondon SW11 
1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

[Lan Tianyu]

On 2016年03月04日 15:21, Thomas Gleixner wrote:
> On Fri, 4 Mar 2016, Lan Tianyu wrote:
> 
>> The following kvm_flush_remote_tlbs() will call smp_mb() inside and so
>> remove smp_mb() here.
>>
>> Signed-off-by: Lan Tianyu 
>> ---
>>  arch/x86/kvm/mmu.c | 6 --
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
>> index a54ecd9..6315416 100644
>> --- a/arch/x86/kvm/mmu.c
>> +++ b/arch/x86/kvm/mmu.c
>> @@ -2383,12 +2383,6 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
>>  return;
>>  
>>  /*
>> - * wmb: make sure everyone sees our modifications to the page tables
>> - * rmb: make sure we see changes to vcpu->mode
> 
> You want to leave the comment explaining the memory barriers and tell that
> kvm_flush_remote_tlbs() contains the smp_mb().

That sounds more reasonable. Will update. Thanks.

> 
>> - */
>> -smp_mb();
>> -
>> -/*
>>   * Wait for all vcpus to exit guest mode and/or lockless shadow
>>   * page table walks.
>>   */
>> -- 
>> 1.8.4.rc0.1.g8f6a3e5.dirty
>>
>>


-- 
Best regards
Tianyu Lan

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

[Lan Tianyu]

On 2016年03月04日 15:21, Thomas Gleixner wrote:
> On Fri, 4 Mar 2016, Lan Tianyu wrote:
> 
>> The following kvm_flush_remote_tlbs() will call smp_mb() inside and so
>> remove smp_mb() here.
>>
>> Signed-off-by: Lan Tianyu 
>> ---
>>  arch/x86/kvm/mmu.c | 6 --
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
>> index a54ecd9..6315416 100644
>> --- a/arch/x86/kvm/mmu.c
>> +++ b/arch/x86/kvm/mmu.c
>> @@ -2383,12 +2383,6 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
>>  return;
>>  
>>  /*
>> - * wmb: make sure everyone sees our modifications to the page tables
>> - * rmb: make sure we see changes to vcpu->mode
> 
> You want to leave the comment explaining the memory barriers and tell that
> kvm_flush_remote_tlbs() contains the smp_mb().

That sounds more reasonable. Will update. Thanks.

> 
>> - */
>> -smp_mb();
>> -
>> -/*
>>   * Wait for all vcpus to exit guest mode and/or lockless shadow
>>   * page table walks.
>>   */
>> -- 
>> 1.8.4.rc0.1.g8f6a3e5.dirty
>>
>>


-- 
Best regards
Tianyu Lan

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

[Thomas Gleixner]

On Fri, 4 Mar 2016, Lan Tianyu wrote:

> The following kvm_flush_remote_tlbs() will call smp_mb() inside and so
> remove smp_mb() here.
> 
> Signed-off-by: Lan Tianyu 
> ---
>  arch/x86/kvm/mmu.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index a54ecd9..6315416 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -2383,12 +2383,6 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
>   return;
>  
>   /*
> -  * wmb: make sure everyone sees our modifications to the page tables
> -  * rmb: make sure we see changes to vcpu->mode

You want to leave the comment explaining the memory barriers and tell that
kvm_flush_remote_tlbs() contains the smp_mb().

> -  */
> - smp_mb();
> -
> - /*
>* Wait for all vcpus to exit guest mode and/or lockless shadow
>* page table walks.
>*/
> -- 
> 1.8.4.rc0.1.g8f6a3e5.dirty
> 
> 

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

[Thomas Gleixner]

On Fri, 4 Mar 2016, Lan Tianyu wrote:

> The following kvm_flush_remote_tlbs() will call smp_mb() inside and so
> remove smp_mb() here.
> 
> Signed-off-by: Lan Tianyu 
> ---
>  arch/x86/kvm/mmu.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index a54ecd9..6315416 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -2383,12 +2383,6 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
>   return;
>  
>   /*
> -  * wmb: make sure everyone sees our modifications to the page tables
> -  * rmb: make sure we see changes to vcpu->mode

You want to leave the comment explaining the memory barriers and tell that
kvm_flush_remote_tlbs() contains the smp_mb().

> -  */
> - smp_mb();
> -
> - /*
>* Wait for all vcpus to exit guest mode and/or lockless shadow
>* page table walks.
>*/
> -- 
> 1.8.4.rc0.1.g8f6a3e5.dirty
> 
> 

Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function

[Felipe Balbi]

Hi,

"Felipe F. Tonello"  writes:
> [ text/plain ]
> Since f_midi_transmit is called by both ALSA and USB frameworks, it can
> potentially cause a race condition between both calls. This is bad because the
> way f_midi_transmit is implemented can't handle concurrent calls. This is due
> to the fact that the usb request fifo looks for the next element and only if
> it has data to process it enqueues the request, otherwise re-uses it. If both
> (ALSA and USB) frameworks calls this function at the same time, the
> kfifo_seek() will return the same usb_request, which will cause a race
> condition.
>
> To solve this problem a syncronization mechanism is necessary. In this case it
> is used a spinlock since f_midi_transmit is also called by 
> usb_request->complete
> callback in interrupt context.
>
> On benchmarks realized by me, spinlocks were more efficient then scheduling
> the f_midi_transmit tasklet in process context and using a mutex to
> synchronize. Also it performs better then previous implementation that
> allocated a usb_request for every new transmit made.

behaves better in what way ? Also, previous implementation would not
suffer from this concurrency problem, right ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function

[Felipe Balbi]

Hi,

"Felipe F. Tonello"  writes:
> [ text/plain ]
> Since f_midi_transmit is called by both ALSA and USB frameworks, it can
> potentially cause a race condition between both calls. This is bad because the
> way f_midi_transmit is implemented can't handle concurrent calls. This is due
> to the fact that the usb request fifo looks for the next element and only if
> it has data to process it enqueues the request, otherwise re-uses it. If both
> (ALSA and USB) frameworks calls this function at the same time, the
> kfifo_seek() will return the same usb_request, which will cause a race
> condition.
>
> To solve this problem a syncronization mechanism is necessary. In this case it
> is used a spinlock since f_midi_transmit is also called by 
> usb_request->complete
> callback in interrupt context.
>
> On benchmarks realized by me, spinlocks were more efficient then scheduling
> the f_midi_transmit tasklet in process context and using a mutex to
> synchronize. Also it performs better then previous implementation that
> allocated a usb_request for every new transmit made.

behaves better in what way ? Also, previous implementation would not
suffer from this concurrency problem, right ?

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] stmmac: Fix type of local variable in stmmac_xmit

[Andrzej Hajda]

Variable entry holds result of jumbo_frm callback. It can be negative,
so the variable should be signed. The patch changes also type of related
first_entry variable to make code compact and coherent.

The problem has been detected using patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci.

Signed-off-by: Andrzej Hajda 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4c5ce98..cd31a3c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1955,7 +1955,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, 
struct net_device *dev)
unsigned int nopaged_len = skb_headlen(skb);
int i, csum_insertion = 0, is_jumbo = 0;
int nfrags = skb_shinfo(skb)->nr_frags;
-   unsigned int entry, first_entry;
+   int entry, first_entry;
struct dma_desc *desc, *first;
unsigned int enh_desc;
 
-- 
1.9.1

[PATCH] stmmac: Fix type of local variable in stmmac_xmit

[Andrzej Hajda]

Variable entry holds result of jumbo_frm callback. It can be negative,
so the variable should be signed. The patch changes also type of related
first_entry variable to make code compact and coherent.

The problem has been detected using patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci.

Signed-off-by: Andrzej Hajda 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4c5ce98..cd31a3c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1955,7 +1955,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, 
struct net_device *dev)
unsigned int nopaged_len = skb_headlen(skb);
int i, csum_insertion = 0, is_jumbo = 0;
int nfrags = skb_shinfo(skb)->nr_frags;
-   unsigned int entry, first_entry;
+   int entry, first_entry;
struct dma_desc *desc, *first;
unsigned int enh_desc;
 
-- 
1.9.1

Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

[Felipe Balbi]

Hi,

"Felipe F. Tonello"  writes:
> [ text/plain ]
> This gadget uses a bmAttributes and MaxPower that requires the USB bus to be
> powered from the host, which is not correct because this configuration is 
> device
> specific, not a USB-MIDI requirement.
>
> This patch adds two modules parameters, bmAttributes and MaxPower, that allows
> the user to set those flags. The default values are what the gadget used to 
> use
> for backward compatibility.
>
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/legacy/gmidi.c 
> b/drivers/usb/gadget/legacy/gmidi.c
> index fc2ac150f5ff..0553435cc360 100644
> --- a/drivers/usb/gadget/legacy/gmidi.c
> +++ b/drivers/usb/gadget/legacy/gmidi.c
> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>  module_param(out_ports, uint, S_IRUGO);
>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>  
> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
> +module_param(bmAttributes, uint, S_IRUGO);
> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's bmAttributes 
> parameter");
> +
> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
> +module_param(MaxPower, uint, S_IRUGO);
> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration Descriptor's 
> bMaxPower parameter");

you didn't run checkpatch, did you ? Also, are you sure you will need to
change this by simply reloading the module ? I'm not convinced.

> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>   .label  = "MIDI Gadget",
>   .bConfigurationValue = 1,
>   /* .iConfiguration = DYNAMIC */
> - .bmAttributes   = USB_CONFIG_ATT_ONE,

nack, nackety nack nack nack :-)

USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
give users the oportunity to violate USB spec.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

[Felipe Balbi]

Hi,

"Felipe F. Tonello"  writes:
> [ text/plain ]
> This gadget uses a bmAttributes and MaxPower that requires the USB bus to be
> powered from the host, which is not correct because this configuration is 
> device
> specific, not a USB-MIDI requirement.
>
> This patch adds two modules parameters, bmAttributes and MaxPower, that allows
> the user to set those flags. The default values are what the gadget used to 
> use
> for backward compatibility.
>
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/legacy/gmidi.c 
> b/drivers/usb/gadget/legacy/gmidi.c
> index fc2ac150f5ff..0553435cc360 100644
> --- a/drivers/usb/gadget/legacy/gmidi.c
> +++ b/drivers/usb/gadget/legacy/gmidi.c
> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>  module_param(out_ports, uint, S_IRUGO);
>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>  
> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
> +module_param(bmAttributes, uint, S_IRUGO);
> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's bmAttributes 
> parameter");
> +
> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
> +module_param(MaxPower, uint, S_IRUGO);
> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration Descriptor's 
> bMaxPower parameter");

you didn't run checkpatch, did you ? Also, are you sure you will need to
change this by simply reloading the module ? I'm not convinced.

> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>   .label  = "MIDI Gadget",
>   .bConfigurationValue = 1,
>   /* .iConfiguration = DYNAMIC */
> - .bmAttributes   = USB_CONFIG_ATT_ONE,

nack, nackety nack nack nack :-)

USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
give users the oportunity to violate USB spec.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 4/5] usb: gadget: f_midi: cleanups and typos fixes

[Felipe Balbi]

"Felipe F. Tonello"  writes:
> [ text/plain ]
> Signed-off-by: Felipe F. Tonello 

no commit log == no commit

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 4/5] usb: gadget: f_midi: cleanups and typos fixes

[Felipe Balbi]

"Felipe F. Tonello"  writes:
> [ text/plain ]
> Signed-off-by: Felipe F. Tonello 

no commit log == no commit

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 5/5] usb: gadget: f_midi: updated copyright

[Felipe Balbi]

"Felipe F. Tonello"  writes:
> [ text/plain ]
> Signed-off-by: Felipe F. Tonello 

no commit log == no commit

> ---
>  drivers/usb/gadget/function/f_midi.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index 9a9e6112e224..5c7f5c780fda 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -5,6 +5,9 @@
>   * Developed for Thumtronics by Grey Innovation
>   * Ben Williamson 
>   *
> + * Copyright (C) 2015,2016 ROLI Ltd.
> + * Felipe F. Tonello 

Did you check with your company's lawyer that your changes are enough to
justify a copyright ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 5/5] usb: gadget: f_midi: updated copyright

[Felipe Balbi]

"Felipe F. Tonello"  writes:
> [ text/plain ]
> Signed-off-by: Felipe F. Tonello 

no commit log == no commit

> ---
>  drivers/usb/gadget/function/f_midi.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index 9a9e6112e224..5c7f5c780fda 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -5,6 +5,9 @@
>   * Developed for Thumtronics by Grey Innovation
>   * Ben Williamson 
>   *
> + * Copyright (C) 2015,2016 ROLI Ltd.
> + * Felipe F. Tonello 

Did you check with your company's lawyer that your changes are enough to
justify a copyright ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 0/5] MIDI USB Gadget improvements

[Felipe Balbi]

Hi,

"Felipe F. Tonello"  writes:
> [ text/plain ]
> Patches are pretty much self-described.
>
> Patch 1 is revised from comments.

you really need to describe what you changed. This also should have v2
on subject line.

I guess it's too late to get this in v4.6 merge window as I'm already
applying the last few patches and plan to send a pull request in a few
minutes.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 0/5] MIDI USB Gadget improvements

[Felipe Balbi]

Hi,

"Felipe F. Tonello"  writes:
> [ text/plain ]
> Patches are pretty much self-described.
>
> Patch 1 is revised from comments.

you really need to describe what you changed. This also should have v2
on subject line.

I guess it's too late to get this in v4.6 merge window as I'm already
applying the last few patches and plan to send a pull request in a few
minutes.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v4 18/18] i2c-mux: relax locking of the top i2c adapter during i2c controlled muxing

[Peter Rosin]

Hi!

Here's a fixup for a problem found by the test robot. Sorry for the
inconvenience.

Cheers,
Peter

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 40a4e0397826..b73c42eddca3 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -226,6 +226,7 @@ struct i2c_adapter *i2c_root_adapter(struct device *dev)
 
return i2c_root;
 }
+EXPORT_SYMBOL_GPL(i2c_root_adapter);
 
 int i2c_mux_reserve_adapters(struct i2c_mux_core *muxc, int adapters)
 {
-- 
2.1.4

Re: [PATCH v4 18/18] i2c-mux: relax locking of the top i2c adapter during i2c controlled muxing

[Peter Rosin]

Hi!

Here's a fixup for a problem found by the test robot. Sorry for the
inconvenience.

Cheers,
Peter

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 40a4e0397826..b73c42eddca3 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -226,6 +226,7 @@ struct i2c_adapter *i2c_root_adapter(struct device *dev)
 
return i2c_root;
 }
+EXPORT_SYMBOL_GPL(i2c_root_adapter);
 
 int i2c_mux_reserve_adapters(struct i2c_mux_core *muxc, int adapters)
 {
-- 
2.1.4

Re: [PATCH 0/3] OOM detection rework v4

[Joonsoo Kim]

On Thu, Mar 03, 2016 at 04:50:16PM +0100, Vlastimil Babka wrote:
> On 03/03/2016 03:10 PM, Joonsoo Kim wrote:
> > 
> >> [...]
> > At least, reset no_progress_loops when did_some_progress. High
> > order allocation up to PAGE_ALLOC_COSTLY_ORDER is as important
> > as order 0. And, reclaim something would increase probability of
> > compaction success.
> 
>  This is something I still do not understand. Why would reclaiming
>  random order-0 pages help compaction? Could you clarify this please?
> >>>
> >>> I just can tell simple version. Please check the link from me on another 
> >>> reply.
> >>> Compaction could scan more range of memory if we have more freepage.
> >>> This is due to algorithm limitation. Anyway, so, reclaiming random
> >>> order-0 pages helps compaction.
> >>
> >> I will have a look at that code but this just doesn't make any sense.
> >> The compaction should be reshuffling pages, this shouldn't be a function
> >> of free memory.
> > 
> > Please refer the link I mentioned before. There is a reason why more free
> > memory would help compaction success. Compaction doesn't work
> > like as random reshuffling. It has an algorithm to reduce system overall
> > fragmentation so there is limitation.
> 
> I proposed another way to get better results from direct compaction -
> don't scan for free pages but get them directly from freelists:
> 
> https://lkml.org/lkml/2015/12/3/60
> 

I think that major problem of this approach is that there is no way
to prevent other parallel compacting thread from taking freepage on
targetted aligned block. So, if there are parallel compaction requestors,
they would disturb each others. However, it would not be a problem for order
up to PAGE_ALLOC_COSTLY_ORDER which would be finished so soon.

In fact, for quick allocation, migration scanner is also unnecessary.
There would be a lot of pageblock we cannot do migration. Scanning
all of them in this situation is unnecessary and costly. Moreover, scanning
only half of zone due to limitation of compaction algorithm also looks
not good. Instead, we can get base page on lru list and migrate
neighborhood pages. I named this idea as "lumpy compaction" but didn't
try it. If we only focus on quick allocation, this would be a better way.
Any thought?

Thanks.

Re: [PATCH 0/3] OOM detection rework v4

[Joonsoo Kim]

On Thu, Mar 03, 2016 at 04:50:16PM +0100, Vlastimil Babka wrote:
> On 03/03/2016 03:10 PM, Joonsoo Kim wrote:
> > 
> >> [...]
> > At least, reset no_progress_loops when did_some_progress. High
> > order allocation up to PAGE_ALLOC_COSTLY_ORDER is as important
> > as order 0. And, reclaim something would increase probability of
> > compaction success.
> 
>  This is something I still do not understand. Why would reclaiming
>  random order-0 pages help compaction? Could you clarify this please?
> >>>
> >>> I just can tell simple version. Please check the link from me on another 
> >>> reply.
> >>> Compaction could scan more range of memory if we have more freepage.
> >>> This is due to algorithm limitation. Anyway, so, reclaiming random
> >>> order-0 pages helps compaction.
> >>
> >> I will have a look at that code but this just doesn't make any sense.
> >> The compaction should be reshuffling pages, this shouldn't be a function
> >> of free memory.
> > 
> > Please refer the link I mentioned before. There is a reason why more free
> > memory would help compaction success. Compaction doesn't work
> > like as random reshuffling. It has an algorithm to reduce system overall
> > fragmentation so there is limitation.
> 
> I proposed another way to get better results from direct compaction -
> don't scan for free pages but get them directly from freelists:
> 
> https://lkml.org/lkml/2015/12/3/60
> 

I think that major problem of this approach is that there is no way
to prevent other parallel compacting thread from taking freepage on
targetted aligned block. So, if there are parallel compaction requestors,
they would disturb each others. However, it would not be a problem for order
up to PAGE_ALLOC_COSTLY_ORDER which would be finished so soon.

In fact, for quick allocation, migration scanner is also unnecessary.
There would be a lot of pageblock we cannot do migration. Scanning
all of them in this situation is unnecessary and costly. Moreover, scanning
only half of zone due to limitation of compaction algorithm also looks
not good. Instead, we can get base page on lru list and migrate
neighborhood pages. I named this idea as "lumpy compaction" but didn't
try it. If we only focus on quick allocation, this would be a better way.
Any thought?

Thanks.

Re: [PATCH v2] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM

[Krzysztof Kozlowski]

On 04.03.2016 16:03, Holger Schurig wrote:
> Krzysztof Kozlowski  writes:
> 
>> +depends on HAS_IOMEM# For MFD_SYSCON
> 
> 
> I think this comment is not necessary, it's also highly unusual. On
> other words: other patches like this don't add such comments.
> 
> You can always use "git blame" to find out why some line has changed the
> way it changed ...

No problem, I can remove it. I thought it might be useful since this
dependency is not for the driver but for selected item.

Best regards,
Krzysztof

Re: [PATCH v2] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM

[Krzysztof Kozlowski]

On 04.03.2016 16:03, Holger Schurig wrote:
> Krzysztof Kozlowski  writes:
> 
>> +depends on HAS_IOMEM# For MFD_SYSCON
> 
> 
> I think this comment is not necessary, it's also highly unusual. On
> other words: other patches like this don't add such comments.
> 
> You can always use "git blame" to find out why some line has changed the
> way it changed ...

No problem, I can remove it. I thought it might be useful since this
dependency is not for the driver but for selected item.

Best regards,
Krzysztof

Re: [PATCH v2] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM

[Holger Schurig]

Krzysztof Kozlowski  writes:

> + depends on HAS_IOMEM# For MFD_SYSCON


I think this comment is not necessary, it's also highly unusual. On
other words: other patches like this don't add such comments.

You can always use "git blame" to find out why some line has changed the
way it changed ...

Re: [PATCH v2] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM

[Holger Schurig]

Krzysztof Kozlowski  writes:

> + depends on HAS_IOMEM# For MFD_SYSCON


I think this comment is not necessary, it's also highly unusual. On
other words: other patches like this don't add such comments.

You can always use "git blame" to find out why some line has changed the
way it changed ...

Re: Suspicious error for CMA stress test

[Hanjun Guo]

On 2016/3/4 10:02, Joonsoo Kim wrote:
> On Thu, Mar 03, 2016 at 08:49:01PM +0800, Hanjun Guo wrote:
>> On 2016/3/3 15:42, Joonsoo Kim wrote:
>>> 2016-03-03 10:25 GMT+09:00 Laura Abbott :
 (cc -mm and Joonsoo Kim)


 On 03/02/2016 05:52 AM, Hanjun Guo wrote:
> Hi,
>
> I came across a suspicious error for CMA stress test:
>
> Before the test, I got:
> -bash-4.3# cat /proc/meminfo | grep Cma
> CmaTotal: 204800 kB
> CmaFree:  195044 kB
>
>
> After running the test:
> -bash-4.3# cat /proc/meminfo | grep Cma
> CmaTotal: 204800 kB
> CmaFree: 6602584 kB
>
> So the freed CMA memory is more than total..
>
> Also the the MemFree is more than mem total:
>
> -bash-4.3# cat /proc/meminfo
> MemTotal:   16342016 kB
> MemFree:22367268 kB
> MemAvailable:   22370528 kB
>> [...]
 I played with this a bit and can see the same problem. The sanity
 check of CmaFree < CmaTotal generally triggers in
 __move_zone_freepage_state in unset_migratetype_isolate.
 This also seems to be present as far back as v4.0 which was the
 first version to have the updated accounting from Joonsoo.
 Were there known limitations with the new freepage accounting,
 Joonsoo?
>>> I don't know. I also played with this and looks like there is
>>> accounting problem, however, for my case, number of free page is slightly 
>>> less
>>> than total. I will take a look.
>>>
>>> Hanjun, could you tell me your malloc_size? I tested with 1 and it doesn't
>>> look like your case.
>> I tested with malloc_size with 2M, and it grows much bigger than 1M, also I
>> did some other test:
> Thanks! Now, I can re-generate erronous situation you mentioned.
>
>>  - run with single thread with 10 times, everything is fine.
>>
>>  - I hack the cam_alloc() and free as below [1] to see if it's lock issue, 
>> with
>>the same test with 100 multi-thread, then I got:
> [1] would not be sufficient to close this race.
>
> Try following things [A]. And, for more accurate test, I changed code a bit 
> more
> to prevent kernel page allocation from cma area [B]. This will prevent kernel
> page allocation from cma area completely so we can focus cma_alloc/release 
> race.
>
> Although, this is not correct fix, it could help that we can guess
> where the problem is.
>
> Thanks.
>
> [A]
> diff --git a/mm/cma.c b/mm/cma.c
> index c003274..43ed02d 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -496,7 +496,9 @@ bool cma_release(struct cma *cma, const struct page 
> *pages, unsigned int count)
>  
> VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
>  
> +   mutex_lock(_mutex);
> free_contig_range(pfn, count);
> +   mutex_unlock(_mutex);
> cma_clear_bitmap(cma, pfn, count);
> trace_cma_release(pfn, pages, count);
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c6c38ed..1ce8a59 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2192,7 +2192,8 @@ void free_hot_cold_page(struct page *page, bool cold)
>  * excessively into the page allocator
>  */
> if (migratetype >= MIGRATE_PCPTYPES) {
> -   if (unlikely(is_migrate_isolate(migratetype))) {
> +   if (is_migrate_cma(migratetype) ||
> +   unlikely(is_migrate_isolate(migratetype))) {
> free_one_page(zone, page, pfn, 0, migratetype);
> goto out;
> }

As I replied in previous email, the solution will fix the problem, the Cma 
freed memory and
system freed memory is in sane state after apply above patch.

I also tested this situation which only apply the code below:

if (migratetype >= MIGRATE_PCPTYPES) {
-   if (unlikely(is_migrate_isolate(migratetype))) {
+   if (is_migrate_cma(migratetype) ||
+   unlikely(is_migrate_isolate(migratetype))) {
free_one_page(zone, page, pfn, 0, migratetype);
goto out;
}


This will not fix the problem, but will reduce the errorous freed number of 
memory,
hope this helps.

>
>
> [B]
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f2dccf9..c6c38ed 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1493,6 +1493,7 @@ static int prep_new_page(struct page *page, unsigned 
> int order, gfp_t gfp_flags,
> int 
> alloc_flags)
>  {
> int i;
> +   bool cma = false;
>  
> for (i = 0; i < (1 << order); i++) {
> struct page *p = page + i;
> @@ -1500,6 +1501,9 @@ static int prep_new_page(struct page *page, unsigned 
> int order, gfp_t gfp_flags,
> return 1;
> }
>  
> +   if (is_migrate_cma(get_pcppage_migratetype(page)))
> +   cma = true;
> +
> 

Re: Suspicious error for CMA stress test

[Hanjun Guo]

On 2016/3/4 10:02, Joonsoo Kim wrote:
> On Thu, Mar 03, 2016 at 08:49:01PM +0800, Hanjun Guo wrote:
>> On 2016/3/3 15:42, Joonsoo Kim wrote:
>>> 2016-03-03 10:25 GMT+09:00 Laura Abbott :
 (cc -mm and Joonsoo Kim)


 On 03/02/2016 05:52 AM, Hanjun Guo wrote:
> Hi,
>
> I came across a suspicious error for CMA stress test:
>
> Before the test, I got:
> -bash-4.3# cat /proc/meminfo | grep Cma
> CmaTotal: 204800 kB
> CmaFree:  195044 kB
>
>
> After running the test:
> -bash-4.3# cat /proc/meminfo | grep Cma
> CmaTotal: 204800 kB
> CmaFree: 6602584 kB
>
> So the freed CMA memory is more than total..
>
> Also the the MemFree is more than mem total:
>
> -bash-4.3# cat /proc/meminfo
> MemTotal:   16342016 kB
> MemFree:22367268 kB
> MemAvailable:   22370528 kB
>> [...]
 I played with this a bit and can see the same problem. The sanity
 check of CmaFree < CmaTotal generally triggers in
 __move_zone_freepage_state in unset_migratetype_isolate.
 This also seems to be present as far back as v4.0 which was the
 first version to have the updated accounting from Joonsoo.
 Were there known limitations with the new freepage accounting,
 Joonsoo?
>>> I don't know. I also played with this and looks like there is
>>> accounting problem, however, for my case, number of free page is slightly 
>>> less
>>> than total. I will take a look.
>>>
>>> Hanjun, could you tell me your malloc_size? I tested with 1 and it doesn't
>>> look like your case.
>> I tested with malloc_size with 2M, and it grows much bigger than 1M, also I
>> did some other test:
> Thanks! Now, I can re-generate erronous situation you mentioned.
>
>>  - run with single thread with 10 times, everything is fine.
>>
>>  - I hack the cam_alloc() and free as below [1] to see if it's lock issue, 
>> with
>>the same test with 100 multi-thread, then I got:
> [1] would not be sufficient to close this race.
>
> Try following things [A]. And, for more accurate test, I changed code a bit 
> more
> to prevent kernel page allocation from cma area [B]. This will prevent kernel
> page allocation from cma area completely so we can focus cma_alloc/release 
> race.
>
> Although, this is not correct fix, it could help that we can guess
> where the problem is.
>
> Thanks.
>
> [A]
> diff --git a/mm/cma.c b/mm/cma.c
> index c003274..43ed02d 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -496,7 +496,9 @@ bool cma_release(struct cma *cma, const struct page 
> *pages, unsigned int count)
>  
> VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
>  
> +   mutex_lock(_mutex);
> free_contig_range(pfn, count);
> +   mutex_unlock(_mutex);
> cma_clear_bitmap(cma, pfn, count);
> trace_cma_release(pfn, pages, count);
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c6c38ed..1ce8a59 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2192,7 +2192,8 @@ void free_hot_cold_page(struct page *page, bool cold)
>  * excessively into the page allocator
>  */
> if (migratetype >= MIGRATE_PCPTYPES) {
> -   if (unlikely(is_migrate_isolate(migratetype))) {
> +   if (is_migrate_cma(migratetype) ||
> +   unlikely(is_migrate_isolate(migratetype))) {
> free_one_page(zone, page, pfn, 0, migratetype);
> goto out;
> }

As I replied in previous email, the solution will fix the problem, the Cma 
freed memory and
system freed memory is in sane state after apply above patch.

I also tested this situation which only apply the code below:

if (migratetype >= MIGRATE_PCPTYPES) {
-   if (unlikely(is_migrate_isolate(migratetype))) {
+   if (is_migrate_cma(migratetype) ||
+   unlikely(is_migrate_isolate(migratetype))) {
free_one_page(zone, page, pfn, 0, migratetype);
goto out;
}


This will not fix the problem, but will reduce the errorous freed number of 
memory,
hope this helps.

>
>
> [B]
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f2dccf9..c6c38ed 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1493,6 +1493,7 @@ static int prep_new_page(struct page *page, unsigned 
> int order, gfp_t gfp_flags,
> int 
> alloc_flags)
>  {
> int i;
> +   bool cma = false;
>  
> for (i = 0; i < (1 << order); i++) {
> struct page *p = page + i;
> @@ -1500,6 +1501,9 @@ static int prep_new_page(struct page *page, unsigned 
> int order, gfp_t gfp_flags,
> return 1;
> }
>  
> +   if (is_migrate_cma(get_pcppage_migratetype(page)))
> +   cma = true;
> +
> set_page_private(page, 0);
>  

[PATCH] ASoC: rt5616: allow to build with CONFIG_SND_SOC_RT5616

[Caesar Wang]

This patch fixes that hasn't built the rt5616 driver with
'CONFIG_SND_SOC_RT5616=y' in .config.

The tristate is the prompt on the 'make menuconfig',
in other words, that can't show the prompt and select it
if we don't say what's the tristate.

Signed-off-by: Caesar Wang 
---

 sound/soc/codecs/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 4383966..14eb5f3 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -623,7 +623,7 @@ config SND_SOC_RT5514
tristate
 
 config SND_SOC_RT5616
-   tristate
+   tristate "Realtek RT5616 CODEC"
 
 config SND_SOC_RT5631
tristate "Realtek ALC5631/RT5631 CODEC"
-- 
1.9.1

[PATCH] ASoC: rt5616: allow to build with CONFIG_SND_SOC_RT5616

[Caesar Wang]

This patch fixes that hasn't built the rt5616 driver with
'CONFIG_SND_SOC_RT5616=y' in .config.

The tristate is the prompt on the 'make menuconfig',
in other words, that can't show the prompt and select it
if we don't say what's the tristate.

Signed-off-by: Caesar Wang 
---

 sound/soc/codecs/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 4383966..14eb5f3 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -623,7 +623,7 @@ config SND_SOC_RT5514
tristate
 
 config SND_SOC_RT5616
-   tristate
+   tristate "Realtek RT5616 CODEC"
 
 config SND_SOC_RT5631
tristate "Realtek ALC5631/RT5631 CODEC"
-- 
1.9.1

Re: [PATCH 1/4] scatterlist: Introduce some helper functions

[Baolin Wang]

>>> + **/
>>> +static inline bool sg_is_contiguous(struct scatterlist *sga,
>>> + struct scatterlist *sgb)
>>> +{
>>> + return ((sga->page_link & ~0x3UL) + sga->offset + sga->length ==
>>> + (sgb->page_link & ~0x3UL));
>>> +}
>> I don't understand that one.
>> sga->page_link is a pointer to a "struct page *". How can it be added to an
>> offset within a page ???
>
>
> Ah, sorry that's a mistake. It should check as below:
> static inline bool sg_is_contiguous(struct scatterlist *sga, struct
> scatterlist *sgb)
> {
> return (unsigned int)sg_virt(sga) + sga->length == (unsigned
> int)sg_virt(sgb);
> }

sorry, it should be:
static inline bool sg_is_contiguous(struct scatterlist *sga,
   struct scatterlist *sgb)
{
return (unsigned long)sg_virt(sga) + sga->length ==
   (unsigned long)sg_virt(sgb);
}

-- 
Baolin.wang
Best Regards

Re: [PATCH 1/4] scatterlist: Introduce some helper functions

[Baolin Wang]

>>> + **/
>>> +static inline bool sg_is_contiguous(struct scatterlist *sga,
>>> + struct scatterlist *sgb)
>>> +{
>>> + return ((sga->page_link & ~0x3UL) + sga->offset + sga->length ==
>>> + (sgb->page_link & ~0x3UL));
>>> +}
>> I don't understand that one.
>> sga->page_link is a pointer to a "struct page *". How can it be added to an
>> offset within a page ???
>
>
> Ah, sorry that's a mistake. It should check as below:
> static inline bool sg_is_contiguous(struct scatterlist *sga, struct
> scatterlist *sgb)
> {
> return (unsigned int)sg_virt(sga) + sga->length == (unsigned
> int)sg_virt(sgb);
> }

sorry, it should be:
static inline bool sg_is_contiguous(struct scatterlist *sga,
   struct scatterlist *sgb)
{
return (unsigned long)sg_virt(sga) + sga->length ==
   (unsigned long)sg_virt(sgb);
}

-- 
Baolin.wang
Best Regards

Re: [PATCH v2 2/2] mmc: sdhci-tegra: Specify valid DMA mask

[Alexandre Courbot]

On Fri, Mar 4, 2016 at 3:08 PM, Alexandre Courbot  wrote:
> On Wed, Mar 2, 2016 at 8:25 PM, Arnd Bergmann  wrote:
>> On Wednesday 02 March 2016 19:36:23 Alexandre Courbot wrote:
>>> On Wed, Mar 2, 2016 at 6:34 AM, Arnd Bergmann  wrote:
>>> > On Tuesday 01 March 2016 13:32:44 Alexandre Courbot wrote:
>>> >> On T210, the sdhci controller can address more than 32 bits of address
>>> >> space. Failing to express this fact results in the use of bounce
>>> >> buffers and affects performance.
>>> >>
>>> >> Signed-off-by: Alexandre Courbot 
>>> >
>>> > I don't get this one. Why don't you just set the (SDHCI_USE_SDMA | 
>>> > SDHCI_USE_ADMA)
>>> > flags that are checked in the first patch?
>>>
>>> The test is against (!(host->flags & (SDHCI_USE_SDMA |
>>> SDHCI_USE_ADMA))), (see the '!') so it will be true (and the DMA mask
>>> will be set) if both flags are *not* set (why we set the mask to 64
>>> bits here in that case, I don't know).
>>>
>>> T210 is capable of SDMA, so we cannot use this condition for that
>>> purpose (maybe you missed the '!', in which case I understand why you
>>> were surprised).
>>
>> Ok, I see now that this code was just setting a fake mask in case
>> of PIO mode, which doesn't apply here. That in turn means that
>> your first patch is wrong though:
>>
>> For a device that is not DMA capable (neither SDMA nor ADMA
>> claimed to be supported), we should not call dma_set_mask_and_coherent()
>> because that is likely to fail as well. It's an ugly hack to
>> just override the mask in that case, and I'd say it requires
>> a comment explaining what is going on.
>
> Yeah, I'm not too sure what is the point of setting the fake mask to
> be honest, but you are definitely right that it is a contradiction to
> call a DMA function on a device that is not DMA-capable.

Ah, I finally got it - we are just setting it to the *address* of
host->dma_mask so the device's DMA mask does not end up being a NULL
pointer.

That actually changes things a bit. DMA-capable devices are clearly
expected to set the mask themselves, but the only one to do it is
host/mtk-sd.c. And dma_set_mask() is only called in dw_mmc and
sdhci-acpi's enable_dma callback.

This means most DMA-capable devices (including Tegra, but not only)
are simply left with no DMA setup at all.

Probably we can detect when the host did not do any DMA setup in the
probe function and attempt some sane defaults depending on what the
hardware says it is capable of?

Re: [PATCH v2 2/2] mmc: sdhci-tegra: Specify valid DMA mask

[Alexandre Courbot]

On Fri, Mar 4, 2016 at 3:08 PM, Alexandre Courbot  wrote:
> On Wed, Mar 2, 2016 at 8:25 PM, Arnd Bergmann  wrote:
>> On Wednesday 02 March 2016 19:36:23 Alexandre Courbot wrote:
>>> On Wed, Mar 2, 2016 at 6:34 AM, Arnd Bergmann  wrote:
>>> > On Tuesday 01 March 2016 13:32:44 Alexandre Courbot wrote:
>>> >> On T210, the sdhci controller can address more than 32 bits of address
>>> >> space. Failing to express this fact results in the use of bounce
>>> >> buffers and affects performance.
>>> >>
>>> >> Signed-off-by: Alexandre Courbot 
>>> >
>>> > I don't get this one. Why don't you just set the (SDHCI_USE_SDMA | 
>>> > SDHCI_USE_ADMA)
>>> > flags that are checked in the first patch?
>>>
>>> The test is against (!(host->flags & (SDHCI_USE_SDMA |
>>> SDHCI_USE_ADMA))), (see the '!') so it will be true (and the DMA mask
>>> will be set) if both flags are *not* set (why we set the mask to 64
>>> bits here in that case, I don't know).
>>>
>>> T210 is capable of SDMA, so we cannot use this condition for that
>>> purpose (maybe you missed the '!', in which case I understand why you
>>> were surprised).
>>
>> Ok, I see now that this code was just setting a fake mask in case
>> of PIO mode, which doesn't apply here. That in turn means that
>> your first patch is wrong though:
>>
>> For a device that is not DMA capable (neither SDMA nor ADMA
>> claimed to be supported), we should not call dma_set_mask_and_coherent()
>> because that is likely to fail as well. It's an ugly hack to
>> just override the mask in that case, and I'd say it requires
>> a comment explaining what is going on.
>
> Yeah, I'm not too sure what is the point of setting the fake mask to
> be honest, but you are definitely right that it is a contradiction to
> call a DMA function on a device that is not DMA-capable.

Ah, I finally got it - we are just setting it to the *address* of
host->dma_mask so the device's DMA mask does not end up being a NULL
pointer.

That actually changes things a bit. DMA-capable devices are clearly
expected to set the mask themselves, but the only one to do it is
host/mtk-sd.c. And dma_set_mask() is only called in dw_mmc and
sdhci-acpi's enable_dma callback.

This means most DMA-capable devices (including Tegra, but not only)
are simply left with no DMA setup at all.

Probably we can detect when the host did not do any DMA setup in the
probe function and attempt some sane defaults depending on what the
hardware says it is capable of?

[PATCH v5 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI

[Shannon Zhao]

From: Shannon Zhao 

When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d94f726..807a93e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -278,6 +279,35 @@ void __init xen_early_init(void)
add_preferred_console("hvc", 0, NULL);
 }
 
+static void __init xen_acpi_guest_init(void)
+{
+#ifdef CONFIG_ACPI
+   struct xen_hvm_param a;
+   int interrupt, trigger, polarity;
+
+   a.domid = DOMID_SELF;
+   a.index = HVM_PARAM_CALLBACK_IRQ;
+   xen_events_irq = 0;
+
+   if (!HYPERVISOR_hvm_op(HVMOP_get_param, )) {
+   if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_EVENT) {
+   interrupt = a.value & 0xff;
+   trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
+: ACPI_LEVEL_SENSITIVE;
+   polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
+ : ACPI_ACTIVE_HIGH;
+   xen_events_irq = acpi_register_gsi(NULL, interrupt,
+  trigger, polarity);
+   }
+   }
+#endif
+}
+
+static void __init xen_dt_guest_init(void)
+{
+   xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+}
+
 static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
@@ -286,7 +316,11 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
 
-   xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+   if (!acpi_disabled)
+   xen_acpi_guest_init();
+   else
+   xen_dt_guest_init();
+
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
return -ENODEV;
-- 
2.0.4

[PATCH v5 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn

[Shannon Zhao]

From: Shannon Zhao 

Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
refer to 4K pages.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 drivers/xen/xlate_mmu.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 9692656..28f728b 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, 
void **virt,
void *vaddr;
int rc;
unsigned int i;
+   unsigned long nr_pages;
+   xen_pfn_t xen_pfn = 0;
 
BUG_ON(nr_grant_frames == 0);
-   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+   nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
+   pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
if (!pages)
return -ENOMEM;
 
@@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t 
**gfns, void **virt,
kfree(pages);
return -ENOMEM;
}
-   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+   rc = alloc_xenballooned_pages(nr_pages, pages);
if (rc) {
-   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
+   pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
+   nr_pages, rc);
kfree(pages);
kfree(pfns);
return rc;
}
-   for (i = 0; i < nr_grant_frames; i++)
-   pfns[i] = page_to_pfn(pages[i]);
+   for (i = 0; i < nr_grant_frames; i++) {
+   if ((i % XEN_PFN_PER_PAGE) == 0)
+   xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
+   pfns[i] = pfn_to_gfn(xen_pfn++);
+   }
 
-   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+   vaddr = vmap(pages, nr_pages, 0, PAGE_KERNEL);
if (!vaddr) {
-   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   free_xenballooned_pages(nr_grant_frames, pages);
+   pr_warn("%s Couldn't map %ld pages rc:%d\n", __func__,
+   nr_pages, rc);
+   free_xenballooned_pages(nr_pages, pages);
kfree(pages);
kfree(pfns);
return -ENOMEM;
-- 
2.0.4

[PATCH v5 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn

[Shannon Zhao]

From: Shannon Zhao 

Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
refer to 4K pages.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 drivers/xen/xlate_mmu.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 9692656..28f728b 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, 
void **virt,
void *vaddr;
int rc;
unsigned int i;
+   unsigned long nr_pages;
+   xen_pfn_t xen_pfn = 0;
 
BUG_ON(nr_grant_frames == 0);
-   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+   nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
+   pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
if (!pages)
return -ENOMEM;
 
@@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t 
**gfns, void **virt,
kfree(pages);
return -ENOMEM;
}
-   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+   rc = alloc_xenballooned_pages(nr_pages, pages);
if (rc) {
-   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
+   pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
+   nr_pages, rc);
kfree(pages);
kfree(pfns);
return rc;
}
-   for (i = 0; i < nr_grant_frames; i++)
-   pfns[i] = page_to_pfn(pages[i]);
+   for (i = 0; i < nr_grant_frames; i++) {
+   if ((i % XEN_PFN_PER_PAGE) == 0)
+   xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
+   pfns[i] = pfn_to_gfn(xen_pfn++);
+   }
 
-   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+   vaddr = vmap(pages, nr_pages, 0, PAGE_KERNEL);
if (!vaddr) {
-   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   free_xenballooned_pages(nr_grant_frames, pages);
+   pr_warn("%s Couldn't map %ld pages rc:%d\n", __func__,
+   nr_pages, rc);
+   free_xenballooned_pages(nr_pages, pages);
kfree(pages);
kfree(pfns);
return -ENOMEM;
-- 
2.0.4

[PATCH v5 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI

[Shannon Zhao]

From: Shannon Zhao 

When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d94f726..807a93e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -278,6 +279,35 @@ void __init xen_early_init(void)
add_preferred_console("hvc", 0, NULL);
 }
 
+static void __init xen_acpi_guest_init(void)
+{
+#ifdef CONFIG_ACPI
+   struct xen_hvm_param a;
+   int interrupt, trigger, polarity;
+
+   a.domid = DOMID_SELF;
+   a.index = HVM_PARAM_CALLBACK_IRQ;
+   xen_events_irq = 0;
+
+   if (!HYPERVISOR_hvm_op(HVMOP_get_param, )) {
+   if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_EVENT) {
+   interrupt = a.value & 0xff;
+   trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
+: ACPI_LEVEL_SENSITIVE;
+   polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
+ : ACPI_ACTIVE_HIGH;
+   xen_events_irq = acpi_register_gsi(NULL, interrupt,
+  trigger, polarity);
+   }
+   }
+#endif
+}
+
+static void __init xen_dt_guest_init(void)
+{
+   xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+}
+
 static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
@@ -286,7 +316,11 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
 
-   xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+   if (!acpi_disabled)
+   xen_acpi_guest_init();
+   else
+   xen_dt_guest_init();
+
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
return -ENODEV;
-- 
2.0.4

[PATCH v5 06/17] Xen: ARM: Add support for mapping platform device mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a bus_notifier for platform bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 drivers/xen/Makefile |   1 +
 drivers/xen/arm-device.c | 141 +++
 2 files changed, 142 insertions(+)
 create mode 100644 drivers/xen/arm-device.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9b7a35c..415f286 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,6 +9,7 @@ CFLAGS_features.o   := $(nostackp)
 
 CFLAGS_efi.o   += -fshort-wchar
 
+dom0-$(CONFIG_ARM64) += arm-device.o
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
 dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
new file mode 100644
index 000..76e26e5
--- /dev/null
+++ b/drivers/xen/arm-device.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+static int xen_unmap_device_mmio(struct resource *resource, unsigned int count)
+{
+   unsigned int i, j, nr;
+   int rc = 0;
+   struct resource *r;
+   struct xen_remove_from_physmap xrp;
+
+   for (i = 0; i < count; i++) {
+   r = [i];
+   nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+   if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+   continue;
+
+   for (j = 0; j < nr; j++) {
+   xrp.domid = DOMID_SELF;
+   xrp.gpfn = XEN_PFN_DOWN(r->start) + j;
+   rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap,
+ );
+   if (rc)
+   return rc;
+   }
+   }
+
+   return rc;
+}
+
+static int xen_map_device_mmio(struct resource *resource, unsigned int count)
+{
+   unsigned int i, j, nr;
+   int rc = 0;
+   struct resource *r;
+   xen_pfn_t *gpfns;
+   xen_ulong_t *idxs;
+   int *errs;
+   struct xen_add_to_physmap_range xatp;
+
+   for (i = 0; i < count; i++) {
+   r = [i];
+   nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+   if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+   continue;
+
+   gpfns = kzalloc(sizeof(xen_pfn_t) * nr, GFP_KERNEL);
+   idxs = kzalloc(sizeof(xen_ulong_t) * nr, GFP_KERNEL);
+   errs = kzalloc(sizeof(int) * nr, GFP_KERNEL);
+   if (!gpfns || !idxs || !errs) {
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   return -ENOMEM;
+   }
+
+   for (j = 0; j < nr; j++) {
+   gpfns[j] = XEN_PFN_DOWN(r->start) + j;
+   idxs[j] = XEN_PFN_DOWN(r->start) + j;
+   }
+
+   xatp.domid = DOMID_SELF;
+   xatp.size = nr;
+   xatp.space = XENMAPSPACE_dev_mmio;
+
+   set_xen_guest_handle(xatp.gpfns, gpfns);
+   set_xen_guest_handle(xatp.idxs, idxs);
+   set_xen_guest_handle(xatp.errs, errs);
+
+   rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, );
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   if (rc)
+   return rc;
+   }
+
+   return rc;
+}
+
+static int xen_platform_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   struct platform_device *pdev = to_platform_device(data);
+   int r = 0;
+
+   if (pdev->num_resources == 0 || pdev->resource == NULL)
+   return NOTIFY_OK;
+
+   switch (action) {
+   case BUS_NOTIFY_ADD_DEVICE:
+   r = xen_map_device_mmio(pdev->resource, pdev->num_resources);
+   break;
+   case BUS_NOTIFY_DEL_DEVICE:
+   r = xen_unmap_device_mmio(pdev->resource, pdev->num_resources);
+   break;
+   

[PATCH v5 06/17] Xen: ARM: Add support for mapping platform device mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a bus_notifier for platform bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 drivers/xen/Makefile |   1 +
 drivers/xen/arm-device.c | 141 +++
 2 files changed, 142 insertions(+)
 create mode 100644 drivers/xen/arm-device.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9b7a35c..415f286 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,6 +9,7 @@ CFLAGS_features.o   := $(nostackp)
 
 CFLAGS_efi.o   += -fshort-wchar
 
+dom0-$(CONFIG_ARM64) += arm-device.o
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
 dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
new file mode 100644
index 000..76e26e5
--- /dev/null
+++ b/drivers/xen/arm-device.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+static int xen_unmap_device_mmio(struct resource *resource, unsigned int count)
+{
+   unsigned int i, j, nr;
+   int rc = 0;
+   struct resource *r;
+   struct xen_remove_from_physmap xrp;
+
+   for (i = 0; i < count; i++) {
+   r = [i];
+   nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+   if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+   continue;
+
+   for (j = 0; j < nr; j++) {
+   xrp.domid = DOMID_SELF;
+   xrp.gpfn = XEN_PFN_DOWN(r->start) + j;
+   rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap,
+ );
+   if (rc)
+   return rc;
+   }
+   }
+
+   return rc;
+}
+
+static int xen_map_device_mmio(struct resource *resource, unsigned int count)
+{
+   unsigned int i, j, nr;
+   int rc = 0;
+   struct resource *r;
+   xen_pfn_t *gpfns;
+   xen_ulong_t *idxs;
+   int *errs;
+   struct xen_add_to_physmap_range xatp;
+
+   for (i = 0; i < count; i++) {
+   r = [i];
+   nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+   if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+   continue;
+
+   gpfns = kzalloc(sizeof(xen_pfn_t) * nr, GFP_KERNEL);
+   idxs = kzalloc(sizeof(xen_ulong_t) * nr, GFP_KERNEL);
+   errs = kzalloc(sizeof(int) * nr, GFP_KERNEL);
+   if (!gpfns || !idxs || !errs) {
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   return -ENOMEM;
+   }
+
+   for (j = 0; j < nr; j++) {
+   gpfns[j] = XEN_PFN_DOWN(r->start) + j;
+   idxs[j] = XEN_PFN_DOWN(r->start) + j;
+   }
+
+   xatp.domid = DOMID_SELF;
+   xatp.size = nr;
+   xatp.space = XENMAPSPACE_dev_mmio;
+
+   set_xen_guest_handle(xatp.gpfns, gpfns);
+   set_xen_guest_handle(xatp.idxs, idxs);
+   set_xen_guest_handle(xatp.errs, errs);
+
+   rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, );
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   if (rc)
+   return rc;
+   }
+
+   return rc;
+}
+
+static int xen_platform_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   struct platform_device *pdev = to_platform_device(data);
+   int r = 0;
+
+   if (pdev->num_resources == 0 || pdev->resource == NULL)
+   return NOTIFY_OK;
+
+   switch (action) {
+   case BUS_NOTIFY_ADD_DEVICE:
+   r = xen_map_device_mmio(pdev->resource, pdev->num_resources);
+   break;
+   case BUS_NOTIFY_DEL_DEVICE:
+   r = xen_unmap_device_mmio(pdev->resource, pdev->num_resources);
+   break;
+   default:
+   return NOTIFY_DONE;
+   }
+   if (r)
+   

[PATCH v5 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Shannon Zhao]

From: Shannon Zhao 

Add a new function to parse DT parameters for Xen specific UEFI just
like the way for normal UEFI. Then it could reuse the existing codes.

If Xen supports EFI, initialize runtime services.

Signed-off-by: Shannon Zhao 
Reviewed-by: Matt Fleming 
Reviewed-by: Stefano Stabellini 
---
CC: Matt Fleming 
---
 arch/arm/xen/enlighten.c   |  6 +
 drivers/firmware/efi/arm-runtime.c | 17 +-
 drivers/firmware/efi/efi.c | 45 --
 3 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e542b8..026b5a7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,6 +261,12 @@ static int __init fdt_find_hyper_node(unsigned long node, 
const char *uname,
!strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
hyper_node.version = s + strlen(hyper_node.prefix);
 
+   if (IS_ENABLED(CONFIG_XEN_EFI)) {
+   /* Check if Xen supports EFI */
+   if (of_get_flat_dt_subnode_by_name(node, "uefi") > 0)
+   set_bit(EFI_PARAVIRT, );
+   }
+
return 0;
 }
 
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 6ae21e4..ac609b9 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern u64 efi_system_table;
 
@@ -107,13 +108,19 @@ static int __init arm_enable_runtime_services(void)
}
set_bit(EFI_SYSTEM_TABLES, );
 
-   if (!efi_virtmap_init()) {
-   pr_err("No UEFI virtual mapping was installed -- runtime 
services will not be available\n");
-   return -ENOMEM;
+   if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+   /* Set up runtime services function pointers for Xen Dom0 */
+   xen_efi_runtime_setup();
+   } else {
+   if (!efi_virtmap_init()) {
+   pr_err("No UEFI virtual mapping was installed -- 
runtime services will not be available\n");
+   return -ENOMEM;
+   }
+
+   /* Set up runtime services function pointers */
+   efi_native_runtime_setup();
}
 
-   /* Set up runtime services function pointers */
-   efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, );
 
efi.runtime_version = efi.systab->hdr.revision;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37da..1328cb7 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -500,12 +500,14 @@ device_initcall(efi_load_efivars);
FIELD_SIZEOF(struct efi_fdt_params, field) \
}
 
-static __initdata struct {
+struct params {
const char name[32];
const char propname[32];
int offset;
int size;
-} dt_params[] = {
+};
+
+static struct params fdt_params[] __initdata = {
UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -513,24 +515,45 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
+static struct params xen_fdt_params[] __initdata = {
+   UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
+   UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
+   UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
+   UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
+   UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
+};
+
 struct param_info {
int found;
void *params;
+   struct params *dt_params;
+   int size;
 };
 
 static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
   int depth, void *data)
 {
struct param_info *info = data;
+   struct params *dt_params = info->dt_params;
const void *prop;
void *dest;
u64 val;
-   int i, len;
+   int i, len, offset;
 
-   if (depth != 1 || strcmp(uname, "chosen") != 0)
-   return 0;
+   if (efi_enabled(EFI_PARAVIRT)) {
+   if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+   return 0;
 
-   for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+   offset = of_get_flat_dt_subnode_by_name(node, "uefi");
+   if (offset < 0)
+   return 0;
+   node = offset;
+   } else {
+   if (depth != 1 || strcmp(uname, "chosen") != 0)
+   return 

[PATCH v5 11/17] ARM: XEN: Move xen_early_init() before efi_init()

[Shannon Zhao]

From: Shannon Zhao 

Move xen_early_init() before efi_init(), then when calling efi_init()
could initialize Xen specific UEFI.

Check if it runs on Xen hypervisor through the flat dts.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c  | 56 ++-
 arch/arm64/kernel/setup.c |  2 +-
 2 files changed, 42 insertions(+), 16 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 807a93e..0e542b8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -53,8 +54,6 @@ struct xen_memory_region 
xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 
 static __read_mostly unsigned int xen_events_irq;
 
-static __initdata struct device_node *xen_node;
-
 int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
   unsigned long addr,
   xen_pfn_t *gfn, int nr,
@@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
return IRQ_HANDLED;
 }
 
+static __initdata struct {
+   const char *compat;
+   const char *prefix;
+   const char *version;
+   bool found;
+} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
+
+static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+   const void *s = NULL;
+   int len;
+
+   if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+   return 0;
+
+   if (of_flat_dt_is_compatible(node, hyper_node.compat))
+   hyper_node.found = true;
+
+   s = of_get_flat_dt_prop(node, "compatible", );
+   if (strlen(hyper_node.prefix) + 3  < len &&
+   !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
+   hyper_node.version = s + strlen(hyper_node.prefix);
+
+   return 0;
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
@@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
 #define GRANT_TABLE_PHYSADDR 0
 void __init xen_early_init(void)
 {
-   int len;
-   const char *s = NULL;
-   const char *version = NULL;
-   const char *xen_prefix = "xen,xen-";
-
-   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
-   if (!xen_node) {
+   of_scan_flat_dt(fdt_find_hyper_node, NULL);
+   if (!hyper_node.found) {
pr_debug("No Xen support\n");
return;
}
-   s = of_get_property(xen_node, "compatible", );
-   if (strlen(xen_prefix) + 3  < len &&
-   !strncmp(xen_prefix, s, strlen(xen_prefix)))
-   version = s + strlen(xen_prefix);
-   if (version == NULL) {
+
+   if (hyper_node.version == NULL) {
pr_debug("Xen version not found\n");
return;
}
 
-   pr_info("Xen %s support found\n", version);
+   pr_info("Xen %s support found\n", hyper_node.version);
 
xen_domain_type = XEN_HVM_DOMAIN;
 
@@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
 
 static void __init xen_dt_guest_init(void)
 {
+   struct device_node *xen_node;
+
+   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!xen_node) {
+   pr_err("Xen support was detected before, but it has 
disappeared\n");
+   return;
+   }
+
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
 }
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..a4a2878 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
 */
local_async_enable();
 
+   xen_early_init();
efi_init();
arm64_memblock_init();
 
@@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
} else {
psci_acpi_init();
}
-   xen_early_init();
 
cpu_read_bootcpu_ops();
smp_init_cpus();
-- 
2.0.4

[PATCH v5 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Shannon Zhao]

From: Shannon Zhao 

Add a new function to parse DT parameters for Xen specific UEFI just
like the way for normal UEFI. Then it could reuse the existing codes.

If Xen supports EFI, initialize runtime services.

Signed-off-by: Shannon Zhao 
Reviewed-by: Matt Fleming 
Reviewed-by: Stefano Stabellini 
---
CC: Matt Fleming 
---
 arch/arm/xen/enlighten.c   |  6 +
 drivers/firmware/efi/arm-runtime.c | 17 +-
 drivers/firmware/efi/efi.c | 45 --
 3 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e542b8..026b5a7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,6 +261,12 @@ static int __init fdt_find_hyper_node(unsigned long node, 
const char *uname,
!strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
hyper_node.version = s + strlen(hyper_node.prefix);
 
+   if (IS_ENABLED(CONFIG_XEN_EFI)) {
+   /* Check if Xen supports EFI */
+   if (of_get_flat_dt_subnode_by_name(node, "uefi") > 0)
+   set_bit(EFI_PARAVIRT, );
+   }
+
return 0;
 }
 
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 6ae21e4..ac609b9 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern u64 efi_system_table;
 
@@ -107,13 +108,19 @@ static int __init arm_enable_runtime_services(void)
}
set_bit(EFI_SYSTEM_TABLES, );
 
-   if (!efi_virtmap_init()) {
-   pr_err("No UEFI virtual mapping was installed -- runtime 
services will not be available\n");
-   return -ENOMEM;
+   if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+   /* Set up runtime services function pointers for Xen Dom0 */
+   xen_efi_runtime_setup();
+   } else {
+   if (!efi_virtmap_init()) {
+   pr_err("No UEFI virtual mapping was installed -- 
runtime services will not be available\n");
+   return -ENOMEM;
+   }
+
+   /* Set up runtime services function pointers */
+   efi_native_runtime_setup();
}
 
-   /* Set up runtime services function pointers */
-   efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, );
 
efi.runtime_version = efi.systab->hdr.revision;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37da..1328cb7 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -500,12 +500,14 @@ device_initcall(efi_load_efivars);
FIELD_SIZEOF(struct efi_fdt_params, field) \
}
 
-static __initdata struct {
+struct params {
const char name[32];
const char propname[32];
int offset;
int size;
-} dt_params[] = {
+};
+
+static struct params fdt_params[] __initdata = {
UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -513,24 +515,45 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
+static struct params xen_fdt_params[] __initdata = {
+   UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
+   UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
+   UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
+   UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
+   UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
+};
+
 struct param_info {
int found;
void *params;
+   struct params *dt_params;
+   int size;
 };
 
 static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
   int depth, void *data)
 {
struct param_info *info = data;
+   struct params *dt_params = info->dt_params;
const void *prop;
void *dest;
u64 val;
-   int i, len;
+   int i, len, offset;
 
-   if (depth != 1 || strcmp(uname, "chosen") != 0)
-   return 0;
+   if (efi_enabled(EFI_PARAVIRT)) {
+   if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+   return 0;
 
-   for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+   offset = of_get_flat_dt_subnode_by_name(node, "uefi");
+   if (offset < 0)
+   return 0;
+   node = offset;
+   } else {
+   if (depth != 1 || strcmp(uname, "chosen") != 0)
+   return 0;
+   }
+
+   for (i = 0; i < info->size; i++) {
prop = of_get_flat_dt_prop(node, dt_params[i].propname, );

[PATCH v5 11/17] ARM: XEN: Move xen_early_init() before efi_init()

[Shannon Zhao]

From: Shannon Zhao 

Move xen_early_init() before efi_init(), then when calling efi_init()
could initialize Xen specific UEFI.

Check if it runs on Xen hypervisor through the flat dts.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c  | 56 ++-
 arch/arm64/kernel/setup.c |  2 +-
 2 files changed, 42 insertions(+), 16 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 807a93e..0e542b8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -53,8 +54,6 @@ struct xen_memory_region 
xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 
 static __read_mostly unsigned int xen_events_irq;
 
-static __initdata struct device_node *xen_node;
-
 int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
   unsigned long addr,
   xen_pfn_t *gfn, int nr,
@@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
return IRQ_HANDLED;
 }
 
+static __initdata struct {
+   const char *compat;
+   const char *prefix;
+   const char *version;
+   bool found;
+} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
+
+static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+   const void *s = NULL;
+   int len;
+
+   if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+   return 0;
+
+   if (of_flat_dt_is_compatible(node, hyper_node.compat))
+   hyper_node.found = true;
+
+   s = of_get_flat_dt_prop(node, "compatible", );
+   if (strlen(hyper_node.prefix) + 3  < len &&
+   !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
+   hyper_node.version = s + strlen(hyper_node.prefix);
+
+   return 0;
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
@@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
 #define GRANT_TABLE_PHYSADDR 0
 void __init xen_early_init(void)
 {
-   int len;
-   const char *s = NULL;
-   const char *version = NULL;
-   const char *xen_prefix = "xen,xen-";
-
-   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
-   if (!xen_node) {
+   of_scan_flat_dt(fdt_find_hyper_node, NULL);
+   if (!hyper_node.found) {
pr_debug("No Xen support\n");
return;
}
-   s = of_get_property(xen_node, "compatible", );
-   if (strlen(xen_prefix) + 3  < len &&
-   !strncmp(xen_prefix, s, strlen(xen_prefix)))
-   version = s + strlen(xen_prefix);
-   if (version == NULL) {
+
+   if (hyper_node.version == NULL) {
pr_debug("Xen version not found\n");
return;
}
 
-   pr_info("Xen %s support found\n", version);
+   pr_info("Xen %s support found\n", hyper_node.version);
 
xen_domain_type = XEN_HVM_DOMAIN;
 
@@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
 
 static void __init xen_dt_guest_init(void)
 {
+   struct device_node *xen_node;
+
+   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!xen_node) {
+   pr_err("Xen support was detected before, but it has 
disappeared\n");
+   return;
+   }
+
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
 }
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..a4a2878 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
 */
local_async_enable();
 
+   xen_early_init();
efi_init();
arm64_memblock_init();
 
@@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
} else {
psci_acpi_init();
}
-   xen_early_init();
 
cpu_read_bootcpu_ops();
smp_init_cpus();
-- 
2.0.4

[PATCH v5 08/17] Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen

[Shannon Zhao]

From: Shannon Zhao 

Sync the changes of HVM_PARAM_CALLBACK_VIA ABI introduced by
Xen commit  (public/hvm: export the HVM_PARAM_CALLBACK_VIA
ABI in the API).

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 include/xen/interface/hvm/params.h | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/include/xen/interface/hvm/params.h 
b/include/xen/interface/hvm/params.h
index a6c7991..70ad208 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -27,16 +27,31 @@
  * Parameter space for HVMOP_{set,get}_param.
  */
 
+#define HVM_PARAM_CALLBACK_IRQ 0
 /*
  * How should CPU0 event-channel notifications be delivered?
- * val[63:56] == 0: val[55:0] is a delivery GSI (Global System Interrupt).
- * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
- *  Domain = val[47:32], Bus  = val[31:16],
- *  DevFn  = val[15: 8], IntX = val[ 1: 0]
- * val[63:56] == 2: val[7:0] is a vector number.
+ *
  * If val == 0 then CPU0 event-channel notifications are not delivered.
+ * If val != 0, val[63:56] encodes the type, as follows:
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_GSI  0
+/*
+ * val[55:0] is a delivery GSI.  GSI 0 cannot be used, as it aliases val == 0,
+ * and disables all notifications.
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1
+/*
+ * val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_VECTOR   2
+/*
+ * val[7:0] is a vector number.  Check for XENFEAT_hvm_callback_vector to know
+ * if this delivery method is available.
  */
-#define HVM_PARAM_CALLBACK_IRQ 0
 
 #define HVM_PARAM_STORE_PFN1
 #define HVM_PARAM_STORE_EVTCHN 2
-- 
2.0.4

[PATCH v5 07/17] Xen: ARM: Add support for mapping AMBA device mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a bus_notifier for AMBA bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 drivers/xen/arm-device.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
index 76e26e5..3854043 100644
--- a/drivers/xen/arm-device.c
+++ b/drivers/xen/arm-device.c
@@ -139,3 +139,46 @@ static int __init register_xen_platform_notifier(void)
 }
 
 arch_initcall(register_xen_platform_notifier);
+
+#ifdef CONFIG_ARM_AMBA
+#include 
+
+static int xen_amba_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   struct amba_device *adev = to_amba_device(data);
+   int r = 0;
+
+   switch (action) {
+   case BUS_NOTIFY_ADD_DEVICE:
+   r = xen_map_device_mmio(>res, 1);
+   break;
+   case BUS_NOTIFY_DEL_DEVICE:
+   r = xen_unmap_device_mmio(>res, 1);
+   break;
+   default:
+   return NOTIFY_DONE;
+   }
+   if (r)
+   dev_err(>dev, "AMBA: Failed to %s device %s MMIO!\n",
+   action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+   (action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+   adev->dev.init_name);
+
+   return NOTIFY_OK;
+}
+
+static struct notifier_block amba_device_nb = {
+   .notifier_call = xen_amba_notifier,
+};
+
+static int __init register_xen_amba_notifier(void)
+{
+   if (!xen_initial_domain() || acpi_disabled)
+   return 0;
+
+   return bus_register_notifier(_bustype, _device_nb);
+}
+
+arch_initcall(register_xen_amba_notifier);
+#endif
-- 
2.0.4

[PATCH v5 07/17] Xen: ARM: Add support for mapping AMBA device mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a bus_notifier for AMBA bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 drivers/xen/arm-device.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
index 76e26e5..3854043 100644
--- a/drivers/xen/arm-device.c
+++ b/drivers/xen/arm-device.c
@@ -139,3 +139,46 @@ static int __init register_xen_platform_notifier(void)
 }
 
 arch_initcall(register_xen_platform_notifier);
+
+#ifdef CONFIG_ARM_AMBA
+#include 
+
+static int xen_amba_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   struct amba_device *adev = to_amba_device(data);
+   int r = 0;
+
+   switch (action) {
+   case BUS_NOTIFY_ADD_DEVICE:
+   r = xen_map_device_mmio(>res, 1);
+   break;
+   case BUS_NOTIFY_DEL_DEVICE:
+   r = xen_unmap_device_mmio(>res, 1);
+   break;
+   default:
+   return NOTIFY_DONE;
+   }
+   if (r)
+   dev_err(>dev, "AMBA: Failed to %s device %s MMIO!\n",
+   action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+   (action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+   adev->dev.init_name);
+
+   return NOTIFY_OK;
+}
+
+static struct notifier_block amba_device_nb = {
+   .notifier_call = xen_amba_notifier,
+};
+
+static int __init register_xen_amba_notifier(void)
+{
+   if (!xen_initial_domain() || acpi_disabled)
+   return 0;
+
+   return bus_register_notifier(_bustype, _device_nb);
+}
+
+arch_initcall(register_xen_amba_notifier);
+#endif
-- 
2.0.4

[PATCH v5 08/17] Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen

[Shannon Zhao]

From: Shannon Zhao 

Sync the changes of HVM_PARAM_CALLBACK_VIA ABI introduced by
Xen commit  (public/hvm: export the HVM_PARAM_CALLBACK_VIA
ABI in the API).

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 include/xen/interface/hvm/params.h | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/include/xen/interface/hvm/params.h 
b/include/xen/interface/hvm/params.h
index a6c7991..70ad208 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -27,16 +27,31 @@
  * Parameter space for HVMOP_{set,get}_param.
  */
 
+#define HVM_PARAM_CALLBACK_IRQ 0
 /*
  * How should CPU0 event-channel notifications be delivered?
- * val[63:56] == 0: val[55:0] is a delivery GSI (Global System Interrupt).
- * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
- *  Domain = val[47:32], Bus  = val[31:16],
- *  DevFn  = val[15: 8], IntX = val[ 1: 0]
- * val[63:56] == 2: val[7:0] is a vector number.
+ *
  * If val == 0 then CPU0 event-channel notifications are not delivered.
+ * If val != 0, val[63:56] encodes the type, as follows:
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_GSI  0
+/*
+ * val[55:0] is a delivery GSI.  GSI 0 cannot be used, as it aliases val == 0,
+ * and disables all notifications.
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1
+/*
+ * val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_VECTOR   2
+/*
+ * val[7:0] is a vector number.  Check for XENFEAT_hvm_callback_vector to know
+ * if this delivery method is available.
  */
-#define HVM_PARAM_CALLBACK_IRQ 0
 
 #define HVM_PARAM_STORE_PFN1
 #define HVM_PARAM_STORE_EVTCHN 2
-- 
2.0.4

Re: [PATCH] sound/usb: Use meaninful names for goto labels

[Dan Carpenter]

Thanks!

regards,
dan carpenter

[PATCH v5 14/17] XEN: EFI: Move x86 specific codes to architecture directory

[Shannon Zhao]

From: Shannon Zhao 

Move x86 specific codes to architecture directory and export those EFI
runtime service functions. This will be useful for initializing runtime
service on ARM later.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/x86/xen/efi.c| 112 
 drivers/xen/efi.c | 174 ++
 include/xen/xen-ops.h |  30 ++---
 3 files changed, 168 insertions(+), 148 deletions(-)

diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index be14cc3..86527f1 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -20,10 +20,122 @@
 #include 
 #include 
 
+#include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
+
+static efi_char16_t vendor[100] __initdata;
+
+static efi_system_table_t efi_systab_xen __initdata = {
+   .hdr = {
+   .signature  = EFI_SYSTEM_TABLE_SIGNATURE,
+   .revision   = 0, /* Initialized later. */
+   .headersize = 0, /* Ignored by Linux Kernel. */
+   .crc32  = 0, /* Ignored by Linux Kernel. */
+   .reserved   = 0
+   },
+   .fw_vendor  = EFI_INVALID_TABLE_ADDR, /* Initialized later. */
+   .fw_revision= 0,  /* Initialized later. */
+   .con_in_handle  = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_in = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_out_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_out= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .stderr_handle  = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .stderr = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .runtime= (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+   .boottime   = (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+   .nr_tables  = 0,  /* Initialized later. */
+   .tables = EFI_INVALID_TABLE_ADDR  /* Initialized later. */
+};
+
+static const struct efi efi_xen __initconst = {
+   .systab   = NULL, /* Initialized later. */
+   .runtime_version  = 0,/* Initialized later. */
+   .mps  = EFI_INVALID_TABLE_ADDR,
+   .acpi = EFI_INVALID_TABLE_ADDR,
+   .acpi20   = EFI_INVALID_TABLE_ADDR,
+   .smbios   = EFI_INVALID_TABLE_ADDR,
+   .smbios3  = EFI_INVALID_TABLE_ADDR,
+   .sal_systab   = EFI_INVALID_TABLE_ADDR,
+   .boot_info= EFI_INVALID_TABLE_ADDR,
+   .hcdp = EFI_INVALID_TABLE_ADDR,
+   .uga  = EFI_INVALID_TABLE_ADDR,
+   .uv_systab= EFI_INVALID_TABLE_ADDR,
+   .fw_vendor= EFI_INVALID_TABLE_ADDR,
+   .runtime  = EFI_INVALID_TABLE_ADDR,
+   .config_table = EFI_INVALID_TABLE_ADDR,
+   .get_time = xen_efi_get_time,
+   .set_time = xen_efi_set_time,
+   .get_wakeup_time  = xen_efi_get_wakeup_time,
+   .set_wakeup_time  = xen_efi_set_wakeup_time,
+   .get_variable = xen_efi_get_variable,
+   .get_next_variable= xen_efi_get_next_variable,
+   .set_variable = xen_efi_set_variable,
+   .query_variable_info  = xen_efi_query_variable_info,
+   .update_capsule   = xen_efi_update_capsule,
+   .query_capsule_caps   = xen_efi_query_capsule_caps,
+   .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+   .reset_system = NULL, /* Functionality provided by Xen. */
+   .set_virtual_address_map  = NULL, /* Not used under Xen. */
+   .memmap   = NULL, /* Not used under Xen. */
+   .flags= 0 /* Initialized later. */
+};
+
+static efi_system_table_t __init *xen_efi_probe(void)
+{
+   struct xen_platform_op op = {
+   .cmd = XENPF_firmware_info,
+   .u.firmware_info = {
+   .type = XEN_FW_EFI_INFO,
+   .index = XEN_FW_EFI_CONFIG_TABLE
+   }
+   };
+   union xenpf_efi_info *info = _info.u.efi_info;
+
+   if (!xen_initial_domain() || HYPERVISOR_platform_op() < 0)
+   return NULL;
+
+   /* Here we know that Xen runs on EFI platform. */
+
+   efi = efi_xen;
+
+   efi_systab_xen.tables = info->cfg.addr;
+   efi_systab_xen.nr_tables = info->cfg.nent;
+
+   op.cmd = XENPF_firmware_info;
+   op.u.firmware_info.type = XEN_FW_EFI_INFO;
+   

Re: [PATCH] sound/usb: Use meaninful names for goto labels

[Dan Carpenter]

Thanks!

regards,
dan carpenter

[PATCH v5 14/17] XEN: EFI: Move x86 specific codes to architecture directory

[Shannon Zhao]

From: Shannon Zhao 

Move x86 specific codes to architecture directory and export those EFI
runtime service functions. This will be useful for initializing runtime
service on ARM later.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/x86/xen/efi.c| 112 
 drivers/xen/efi.c | 174 ++
 include/xen/xen-ops.h |  30 ++---
 3 files changed, 168 insertions(+), 148 deletions(-)

diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index be14cc3..86527f1 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -20,10 +20,122 @@
 #include 
 #include 
 
+#include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
+
+static efi_char16_t vendor[100] __initdata;
+
+static efi_system_table_t efi_systab_xen __initdata = {
+   .hdr = {
+   .signature  = EFI_SYSTEM_TABLE_SIGNATURE,
+   .revision   = 0, /* Initialized later. */
+   .headersize = 0, /* Ignored by Linux Kernel. */
+   .crc32  = 0, /* Ignored by Linux Kernel. */
+   .reserved   = 0
+   },
+   .fw_vendor  = EFI_INVALID_TABLE_ADDR, /* Initialized later. */
+   .fw_revision= 0,  /* Initialized later. */
+   .con_in_handle  = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_in = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_out_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_out= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .stderr_handle  = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .stderr = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .runtime= (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+   .boottime   = (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+   .nr_tables  = 0,  /* Initialized later. */
+   .tables = EFI_INVALID_TABLE_ADDR  /* Initialized later. */
+};
+
+static const struct efi efi_xen __initconst = {
+   .systab   = NULL, /* Initialized later. */
+   .runtime_version  = 0,/* Initialized later. */
+   .mps  = EFI_INVALID_TABLE_ADDR,
+   .acpi = EFI_INVALID_TABLE_ADDR,
+   .acpi20   = EFI_INVALID_TABLE_ADDR,
+   .smbios   = EFI_INVALID_TABLE_ADDR,
+   .smbios3  = EFI_INVALID_TABLE_ADDR,
+   .sal_systab   = EFI_INVALID_TABLE_ADDR,
+   .boot_info= EFI_INVALID_TABLE_ADDR,
+   .hcdp = EFI_INVALID_TABLE_ADDR,
+   .uga  = EFI_INVALID_TABLE_ADDR,
+   .uv_systab= EFI_INVALID_TABLE_ADDR,
+   .fw_vendor= EFI_INVALID_TABLE_ADDR,
+   .runtime  = EFI_INVALID_TABLE_ADDR,
+   .config_table = EFI_INVALID_TABLE_ADDR,
+   .get_time = xen_efi_get_time,
+   .set_time = xen_efi_set_time,
+   .get_wakeup_time  = xen_efi_get_wakeup_time,
+   .set_wakeup_time  = xen_efi_set_wakeup_time,
+   .get_variable = xen_efi_get_variable,
+   .get_next_variable= xen_efi_get_next_variable,
+   .set_variable = xen_efi_set_variable,
+   .query_variable_info  = xen_efi_query_variable_info,
+   .update_capsule   = xen_efi_update_capsule,
+   .query_capsule_caps   = xen_efi_query_capsule_caps,
+   .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+   .reset_system = NULL, /* Functionality provided by Xen. */
+   .set_virtual_address_map  = NULL, /* Not used under Xen. */
+   .memmap   = NULL, /* Not used under Xen. */
+   .flags= 0 /* Initialized later. */
+};
+
+static efi_system_table_t __init *xen_efi_probe(void)
+{
+   struct xen_platform_op op = {
+   .cmd = XENPF_firmware_info,
+   .u.firmware_info = {
+   .type = XEN_FW_EFI_INFO,
+   .index = XEN_FW_EFI_CONFIG_TABLE
+   }
+   };
+   union xenpf_efi_info *info = _info.u.efi_info;
+
+   if (!xen_initial_domain() || HYPERVISOR_platform_op() < 0)
+   return NULL;
+
+   /* Here we know that Xen runs on EFI platform. */
+
+   efi = efi_xen;
+
+   efi_systab_xen.tables = info->cfg.addr;
+   efi_systab_xen.nr_tables = info->cfg.nent;
+
+   op.cmd = XENPF_firmware_info;
+   op.u.firmware_info.type = XEN_FW_EFI_INFO;
+   op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
+   info->vendor.bufsz = sizeof(vendor);
+   

[PATCH v5 16/17] FDT: Add a helper to get the subnode by given name

[Shannon Zhao]

From: Shannon Zhao 

Sometimes it needs to check if there is a subnode of given node in FDT
by given name. Introduce this helper to get the subnode if it exists.

CC: Rob Herring 
Signed-off-by: Shannon Zhao 
---
 drivers/of/fdt.c   | 13 +
 include/linux/of_fdt.h |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..09001db 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -645,6 +645,19 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
 }
 
 /**
+ * of_get_flat_dt_subnode_by_name - get the subnode by given name
+ *
+ * @node: the parent node
+ * @uname: the name of subnode
+ * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
+ */
+
+int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
+{
+   return fdt_subnode_offset(initial_boot_params, node, uname);
+}
+
+/**
  * of_get_flat_dt_root - find the root node in the flat blob
  */
 unsigned long __init of_get_flat_dt_root(void)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..fc28162 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -52,6 +52,8 @@ extern char __dtb_end[];
 extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
 int depth, void *data),
   void *data);
+extern int of_get_flat_dt_subnode_by_name(unsigned long node,
+ const char *uname);
 extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
   int *size);
 extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
-- 
2.0.4

[PATCH v5 16/17] FDT: Add a helper to get the subnode by given name

[Shannon Zhao]

From: Shannon Zhao 

Sometimes it needs to check if there is a subnode of given node in FDT
by given name. Introduce this helper to get the subnode if it exists.

CC: Rob Herring 
Signed-off-by: Shannon Zhao 
---
 drivers/of/fdt.c   | 13 +
 include/linux/of_fdt.h |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..09001db 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -645,6 +645,19 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
 }
 
 /**
+ * of_get_flat_dt_subnode_by_name - get the subnode by given name
+ *
+ * @node: the parent node
+ * @uname: the name of subnode
+ * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
+ */
+
+int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
+{
+   return fdt_subnode_offset(initial_boot_params, node, uname);
+}
+
+/**
  * of_get_flat_dt_root - find the root node in the flat blob
  */
 unsigned long __init of_get_flat_dt_root(void)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..fc28162 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -52,6 +52,8 @@ extern char __dtb_end[];
 extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
 int depth, void *data),
   void *data);
+extern int of_get_flat_dt_subnode_by_name(unsigned long node,
+ const char *uname);
 extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
   int *size);
 extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
-- 
2.0.4

[PATCH v5 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services

[Shannon Zhao]

From: Shannon Zhao 

When running on Xen hypervisor, runtime services are supported through
hypercall. Add a Xen specific function to initialize runtime services.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/xen-ops.h   |  6 ++
 arch/arm/xen/Makefile|  1 +
 arch/arm/xen/efi.c   | 40 
 arch/arm64/include/asm/xen/xen-ops.h |  6 ++
 arch/arm64/xen/Makefile  |  1 +
 drivers/xen/Kconfig  |  2 +-
 6 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/xen/xen-ops.h
 create mode 100644 arch/arm/xen/efi.c
 create mode 100644 arch/arm64/include/asm/xen/xen-ops.h

diff --git a/arch/arm/include/asm/xen/xen-ops.h 
b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 000..ec154e7
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1296952..2279521 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1,2 @@
 obj-y  := enlighten.o hypercall.o grant-table.o p2m.o mm.o
+obj-$(CONFIG_XEN_EFI) += efi.o
diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
new file mode 100644
index 000..16db419
--- /dev/null
+++ b/arch/arm/xen/efi.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+/* Set XEN EFI runtime services function pointers. Other fields of struct efi,
+ * e.g. efi.systab, will be set like normal EFI.
+ */
+void __init xen_efi_runtime_setup(void)
+{
+   efi.get_time = xen_efi_get_time;
+   efi.set_time = xen_efi_set_time;
+   efi.get_wakeup_time  = xen_efi_get_wakeup_time;
+   efi.set_wakeup_time  = xen_efi_set_wakeup_time;
+   efi.get_variable = xen_efi_get_variable;
+   efi.get_next_variable= xen_efi_get_next_variable;
+   efi.set_variable = xen_efi_set_variable;
+   efi.query_variable_info  = xen_efi_query_variable_info;
+   efi.update_capsule   = xen_efi_update_capsule;
+   efi.query_capsule_caps   = xen_efi_query_capsule_caps;
+   efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+   efi.reset_system = NULL; /* Functionality provided by Xen. 
*/
+}
+EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
diff --git a/arch/arm64/include/asm/xen/xen-ops.h 
b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 000..ec154e7
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index 74a8d87..8ff8aa9 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,3 @@
 xen-arm-y  += $(addprefix ../../arm/xen/, enlighten.o grant-table.o p2m.o 
mm.o)
 obj-y  := xen-arm.o hypercall.o
+obj-$(CONFIG_XEN_EFI) += $(addprefix ../../arm/xen/, efi.o)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 73708ac..d50571c 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -268,7 +268,7 @@ config XEN_HAVE_PVMMU
 
 config XEN_EFI
def_bool y
-   depends on X86_64 && EFI
+   depends on (ARM || ARM64 || X86_64) && EFI
 
 config XEN_AUTO_XLATE
def_bool y
-- 
2.0.4

[PATCH v5 00/17] Add ACPI support for Xen Dom0 on ARM64

[Shannon Zhao]

From: Shannon Zhao 

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen
ACPI on ARM64 design document could be found from [1].

This patch set adds a new FDT node "uefi" under /hypervisor to pass UEFI
information. Introduce a bus notifier of AMBA and Platform bus to map
the new added device's MMIO space. Make Xen domain use
xlated_setup_gnttab_pages to setup grant table and a new hypercall to
get event-channel irq.

Regarding the initialization flow of Linux kernel, it needs to move
xen_early_init() before efi_init(). Then xen_early_init() will check
whether it runs on Xen through the /hypervisor node and efi_init() will
call a new function fdt_find_xen_uefi_params(), to parse those
xen,uefi-* parameters just like the existing efi_get_fdt_params().

And in arm64_enable_runtime_services() it will check whether it runs on
Xen and call another new function xen_efi_runtime_setup() to setup
runtime service instead of efi_native_runtime_setup(). The
xen_efi_runtime_setup() will assign the runtime function pointers with
the functions of driver/xen/efi.c.

And since we pass a /hypervisor node and a /chosen node to Dom0, it
needs to check whether the DTS only contains a /hypervisor node and a
/chosen node in acpi_boot_table_init().

Patches are tested on FVP base model.

Thanks,
Shannon

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html

Changes since v4:
* rebase on linux master
* move the check acpi_device_should_be_hidden into
  acpi_bus_type_and_status (patch 1)
* use existing function fdt_subnode_offset (patch 16)

Changes since v3:
* rebase on linux master
* print a warning when there is no SPCR table
* rephase the commit message of PATCH 3
* rephase the words of PATCH 13
* use strcmp and factor the function in PATCH 16
* Add several ACKs and RBs, thanks a lot


Changes since v2:
* Use 0 to check if it should ignore the UART
* Fix the use of page_to_xen_pfn
* Factor ACPI and DT parts in xen_guest_init
* Check "uefi" node by full path
* Fix the statement of Documentation/devicetree/bindings/arm/xen.txt

Changes since v1:
* Rebase on linux mainline and wallclock patch from Stefano
* Refactor AMBA and platform device MMIO map to one file
* Use EFI_PARAVIRT to check if it supports XEN EFI
* Refactor Xen EFI codes
* Address other comments

Shannon Zhao (17):
  Xen: ACPI: Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
  arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping AMBA device mmio
  Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
  xen/hvm/params: Add a new delivery type for event-channel in
HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with
ACPI
  ARM: XEN: Move xen_early_init() before efi_init()
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  XEN: EFI: Move x86 specific codes to architecture directory
  ARM64: XEN: Add a function to initialize Xen specific UEFI runtime
services
  FDT: Add a helper to get the subnode by given name
  Xen: EFI: Parse DT parameters for Xen specific UEFI

 Documentation/devicetree/bindings/arm/xen.txt |  33 +
 arch/arm/include/asm/xen/xen-ops.h|   6 +
 arch/arm/xen/Makefile |   1 +
 arch/arm/xen/efi.c|  40 ++
 arch/arm/xen/enlighten.c  | 109 +++
 arch/arm64/include/asm/xen/xen-ops.h  |   6 +
 arch/arm64/kernel/acpi.c  |  12 +-
 arch/arm64/kernel/setup.c |   2 +-
 arch/arm64/xen/Makefile   |   1 +
 arch/x86/xen/efi.c| 112 
 arch/x86/xen/grant-table.c|  57 +---
 drivers/acpi/scan.c   |  68 ++
 drivers/firmware/efi/arm-runtime.c|  17 ++-
 drivers/firmware/efi/efi.c|  45 ++-
 drivers/of/fdt.c  |  13 ++
 drivers/xen/Kconfig   |   2 +-
 drivers/xen/Makefile  |   1 +
 drivers/xen/arm-device.c  | 184 ++
 drivers/xen/efi.c | 174 +---
 drivers/xen/xlate_mmu.c   |  67 ++
 include/linux/of_fdt.h|   2 +
 include/xen/interface/hvm/params.h|  37 +-
 include/xen/interface/memory.h|   1 +
 include/xen/xen-ops.h |  32 +++--
 24 files changed, 775 insertions(+), 247 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/xen-ops.h
 create 

[PATCH v5 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services

[Shannon Zhao]

From: Shannon Zhao 

When running on Xen hypervisor, runtime services are supported through
hypercall. Add a Xen specific function to initialize runtime services.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/xen-ops.h   |  6 ++
 arch/arm/xen/Makefile|  1 +
 arch/arm/xen/efi.c   | 40 
 arch/arm64/include/asm/xen/xen-ops.h |  6 ++
 arch/arm64/xen/Makefile  |  1 +
 drivers/xen/Kconfig  |  2 +-
 6 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/xen/xen-ops.h
 create mode 100644 arch/arm/xen/efi.c
 create mode 100644 arch/arm64/include/asm/xen/xen-ops.h

diff --git a/arch/arm/include/asm/xen/xen-ops.h 
b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 000..ec154e7
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1296952..2279521 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1,2 @@
 obj-y  := enlighten.o hypercall.o grant-table.o p2m.o mm.o
+obj-$(CONFIG_XEN_EFI) += efi.o
diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
new file mode 100644
index 000..16db419
--- /dev/null
+++ b/arch/arm/xen/efi.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+/* Set XEN EFI runtime services function pointers. Other fields of struct efi,
+ * e.g. efi.systab, will be set like normal EFI.
+ */
+void __init xen_efi_runtime_setup(void)
+{
+   efi.get_time = xen_efi_get_time;
+   efi.set_time = xen_efi_set_time;
+   efi.get_wakeup_time  = xen_efi_get_wakeup_time;
+   efi.set_wakeup_time  = xen_efi_set_wakeup_time;
+   efi.get_variable = xen_efi_get_variable;
+   efi.get_next_variable= xen_efi_get_next_variable;
+   efi.set_variable = xen_efi_set_variable;
+   efi.query_variable_info  = xen_efi_query_variable_info;
+   efi.update_capsule   = xen_efi_update_capsule;
+   efi.query_capsule_caps   = xen_efi_query_capsule_caps;
+   efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+   efi.reset_system = NULL; /* Functionality provided by Xen. 
*/
+}
+EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
diff --git a/arch/arm64/include/asm/xen/xen-ops.h 
b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 000..ec154e7
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index 74a8d87..8ff8aa9 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,3 @@
 xen-arm-y  += $(addprefix ../../arm/xen/, enlighten.o grant-table.o p2m.o 
mm.o)
 obj-y  := xen-arm.o hypercall.o
+obj-$(CONFIG_XEN_EFI) += $(addprefix ../../arm/xen/, efi.o)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 73708ac..d50571c 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -268,7 +268,7 @@ config XEN_HAVE_PVMMU
 
 config XEN_EFI
def_bool y
-   depends on X86_64 && EFI
+   depends on (ARM || ARM64 || X86_64) && EFI
 
 config XEN_AUTO_XLATE
def_bool y
-- 
2.0.4

[PATCH v5 00/17] Add ACPI support for Xen Dom0 on ARM64

[Shannon Zhao]

From: Shannon Zhao 

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen
ACPI on ARM64 design document could be found from [1].

This patch set adds a new FDT node "uefi" under /hypervisor to pass UEFI
information. Introduce a bus notifier of AMBA and Platform bus to map
the new added device's MMIO space. Make Xen domain use
xlated_setup_gnttab_pages to setup grant table and a new hypercall to
get event-channel irq.

Regarding the initialization flow of Linux kernel, it needs to move
xen_early_init() before efi_init(). Then xen_early_init() will check
whether it runs on Xen through the /hypervisor node and efi_init() will
call a new function fdt_find_xen_uefi_params(), to parse those
xen,uefi-* parameters just like the existing efi_get_fdt_params().

And in arm64_enable_runtime_services() it will check whether it runs on
Xen and call another new function xen_efi_runtime_setup() to setup
runtime service instead of efi_native_runtime_setup(). The
xen_efi_runtime_setup() will assign the runtime function pointers with
the functions of driver/xen/efi.c.

And since we pass a /hypervisor node and a /chosen node to Dom0, it
needs to check whether the DTS only contains a /hypervisor node and a
/chosen node in acpi_boot_table_init().

Patches are tested on FVP base model.

Thanks,
Shannon

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html

Changes since v4:
* rebase on linux master
* move the check acpi_device_should_be_hidden into
  acpi_bus_type_and_status (patch 1)
* use existing function fdt_subnode_offset (patch 16)

Changes since v3:
* rebase on linux master
* print a warning when there is no SPCR table
* rephase the commit message of PATCH 3
* rephase the words of PATCH 13
* use strcmp and factor the function in PATCH 16
* Add several ACKs and RBs, thanks a lot


Changes since v2:
* Use 0 to check if it should ignore the UART
* Fix the use of page_to_xen_pfn
* Factor ACPI and DT parts in xen_guest_init
* Check "uefi" node by full path
* Fix the statement of Documentation/devicetree/bindings/arm/xen.txt

Changes since v1:
* Rebase on linux mainline and wallclock patch from Stefano
* Refactor AMBA and platform device MMIO map to one file
* Use EFI_PARAVIRT to check if it supports XEN EFI
* Refactor Xen EFI codes
* Address other comments

Shannon Zhao (17):
  Xen: ACPI: Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
  arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping AMBA device mmio
  Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
  xen/hvm/params: Add a new delivery type for event-channel in
HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with
ACPI
  ARM: XEN: Move xen_early_init() before efi_init()
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  XEN: EFI: Move x86 specific codes to architecture directory
  ARM64: XEN: Add a function to initialize Xen specific UEFI runtime
services
  FDT: Add a helper to get the subnode by given name
  Xen: EFI: Parse DT parameters for Xen specific UEFI

 Documentation/devicetree/bindings/arm/xen.txt |  33 +
 arch/arm/include/asm/xen/xen-ops.h|   6 +
 arch/arm/xen/Makefile |   1 +
 arch/arm/xen/efi.c|  40 ++
 arch/arm/xen/enlighten.c  | 109 +++
 arch/arm64/include/asm/xen/xen-ops.h  |   6 +
 arch/arm64/kernel/acpi.c  |  12 +-
 arch/arm64/kernel/setup.c |   2 +-
 arch/arm64/xen/Makefile   |   1 +
 arch/x86/xen/efi.c| 112 
 arch/x86/xen/grant-table.c|  57 +---
 drivers/acpi/scan.c   |  68 ++
 drivers/firmware/efi/arm-runtime.c|  17 ++-
 drivers/firmware/efi/efi.c|  45 ++-
 drivers/of/fdt.c  |  13 ++
 drivers/xen/Kconfig   |   2 +-
 drivers/xen/Makefile  |   1 +
 drivers/xen/arm-device.c  | 184 ++
 drivers/xen/efi.c | 174 +---
 drivers/xen/xlate_mmu.c   |  67 ++
 include/linux/of_fdt.h|   2 +
 include/xen/interface/hvm/params.h|  37 +-
 include/xen/interface/memory.h|   1 +
 include/xen/xen-ops.h |  32 +++--
 24 files changed, 775 insertions(+), 247 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/xen-ops.h
 create mode 100644 

[PATCH v5 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

[Shannon Zhao]

From: Shannon Zhao 

Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.

Signed-off-by: Shannon Zhao 
Acked-by: Rob Herring 
Reviewed-by: Stefano Stabellini 
---
CC: Rob Herring 
---
 Documentation/devicetree/bindings/arm/xen.txt | 33 +++
 1 file changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..6f83f76 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,6 +15,26 @@ the following properties:
 - interrupts: the interrupt used by Xen to inject event notifications.
   A GIC node is also required.
 
+To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+
+Name  | Size   | Description
+
+xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
+ || Table.
+
+xen,uefi-mmap-start   | 64-bit | Guest physical address of the UEFI memory
+ || map.
+
+xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
+  || pointed to in previous entry.
+
+xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
+  || memory map.
+
+xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
+
 
 Example (assuming #address-cells = <2> and #size-cells = <2>):
 
@@ -22,4 +42,17 @@ hypervisor {
compatible = "xen,xen-4.3", "xen,xen";
reg = <0 0xb000 0 0x2>;
interrupts = <1 15 0xf08>;
+   uefi {
+   xen,uefi-system-table = <0x>;
+   xen,uefi-mmap-start = <0x>;
+   xen,uefi-mmap-size = <0x>;
+   xen,uefi-mmap-desc-size = <0x>;
+   xen,uefi-mmap-desc-ver = <0x>;
+};
 };
+
+The format and meaning of the "xen,uefi-*" parameters are similar to those in
+Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. 
However
+they differ because they are provided by the Xen hypervisor, together with a 
set
+of UEFI runtime services implemented via hypercalls, see
+http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
-- 
2.0.4

[PATCH v5 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

[Shannon Zhao]

From: Shannon Zhao 

Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.

Signed-off-by: Shannon Zhao 
Acked-by: Rob Herring 
Reviewed-by: Stefano Stabellini 
---
CC: Rob Herring 
---
 Documentation/devicetree/bindings/arm/xen.txt | 33 +++
 1 file changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..6f83f76 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,6 +15,26 @@ the following properties:
 - interrupts: the interrupt used by Xen to inject event notifications.
   A GIC node is also required.
 
+To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+
+Name  | Size   | Description
+
+xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
+ || Table.
+
+xen,uefi-mmap-start   | 64-bit | Guest physical address of the UEFI memory
+ || map.
+
+xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
+  || pointed to in previous entry.
+
+xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
+  || memory map.
+
+xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
+
 
 Example (assuming #address-cells = <2> and #size-cells = <2>):
 
@@ -22,4 +42,17 @@ hypervisor {
compatible = "xen,xen-4.3", "xen,xen";
reg = <0 0xb000 0 0x2>;
interrupts = <1 15 0xf08>;
+   uefi {
+   xen,uefi-system-table = <0x>;
+   xen,uefi-mmap-start = <0x>;
+   xen,uefi-mmap-size = <0x>;
+   xen,uefi-mmap-desc-size = <0x>;
+   xen,uefi-mmap-desc-ver = <0x>;
+};
 };
+
+The format and meaning of the "xen,uefi-*" parameters are similar to those in
+Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. 
However
+they differ because they are provided by the Xen hypervisor, together with a 
set
+of UEFI runtime services implemented via hypercalls, see
+http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
-- 
2.0.4

[PATCH v5 05/17] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a new type of Xen map space for Dom0 to map device's MMIO region.

Signed-off-by: Shannon Zhao 
---
 include/xen/interface/memory.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..9aa8988 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -160,6 +160,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
* XENMEM_add_to_physmap_range only.
*/
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
 
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
-- 
2.0.4

[PATCH v5 05/17] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a new type of Xen map space for Dom0 to map device's MMIO region.

Signed-off-by: Shannon Zhao 
---
 include/xen/interface/memory.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..9aa8988 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -160,6 +160,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
* XENMEM_add_to_physmap_range only.
*/
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
 
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
-- 
2.0.4

[PATCH v5 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place

[Shannon Zhao]

From: Shannon Zhao 

Move xlated_setup_gnttab_pages to common place, so it can be reused by
ARM to setup grant table.

Rename it to xen_xlate_map_ballooned_pages.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/x86/xen/grant-table.c | 57 +--
 drivers/xen/xlate_mmu.c| 61 ++
 include/xen/xen-ops.h  |  2 ++
 3 files changed, 69 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index e079500..de4144c 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -111,63 +111,18 @@ int arch_gnttab_init(unsigned long nr_shared)
 }
 
 #ifdef CONFIG_XEN_PVH
-#include 
 #include 
-#include 
-static int __init xlated_setup_gnttab_pages(void)
-{
-   struct page **pages;
-   xen_pfn_t *pfns;
-   void *vaddr;
-   int rc;
-   unsigned int i;
-   unsigned long nr_grant_frames = gnttab_max_grant_frames();
-
-   BUG_ON(nr_grant_frames == 0);
-   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
-   if (!pages)
-   return -ENOMEM;
-
-   pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
-   if (!pfns) {
-   kfree(pages);
-   return -ENOMEM;
-   }
-   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
-   if (rc) {
-   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   kfree(pages);
-   kfree(pfns);
-   return rc;
-   }
-   for (i = 0; i < nr_grant_frames; i++)
-   pfns[i] = page_to_pfn(pages[i]);
-
-   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
-   if (!vaddr) {
-   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   free_xenballooned_pages(nr_grant_frames, pages);
-   kfree(pages);
-   kfree(pfns);
-   return -ENOMEM;
-   }
-   kfree(pages);
-
-   xen_auto_xlat_grant_frames.pfn = pfns;
-   xen_auto_xlat_grant_frames.count = nr_grant_frames;
-   xen_auto_xlat_grant_frames.vaddr = vaddr;
-
-   return 0;
-}
-
+#include 
 static int __init xen_pvh_gnttab_setup(void)
 {
if (!xen_pvh_domain())
return -ENODEV;
 
-   return xlated_setup_gnttab_pages();
+   xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+
+   return xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
+_auto_xlat_grant_frames.vaddr,
+xen_auto_xlat_grant_frames.count);
 }
 /* Call it _before_ __gnttab_init as we need to initialize the
  * xen_auto_xlat_grant_frames first. */
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 5063c5e..9692656 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -29,6 +29,8 @@
  */
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -37,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 typedef void (*xen_gfn_fn_t)(unsigned long gfn, void *data);
 
@@ -185,3 +188,61 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
return 0;
 }
 EXPORT_SYMBOL_GPL(xen_xlate_unmap_gfn_range);
+
+/**
+ * xen_xlate_map_ballooned_pages - map a new set of ballooned pages
+ * @gfns: returns the array of corresponding GFNs
+ * @virt: returns the virtual address of the mapped region
+ * @nr_grant_frames: number of GFNs
+ * @return 0 on success, error otherwise
+ *
+ * This allocates a set of ballooned pages and maps them into the
+ * kernel's address space.
+ */
+int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
+unsigned long nr_grant_frames)
+{
+   struct page **pages;
+   xen_pfn_t *pfns;
+   void *vaddr;
+   int rc;
+   unsigned int i;
+
+   BUG_ON(nr_grant_frames == 0);
+   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+   if (!pages)
+   return -ENOMEM;
+
+   pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
+   if (!pfns) {
+   kfree(pages);
+   return -ENOMEM;
+   }
+   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+   if (rc) {
+   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
+   nr_grant_frames, rc);
+   kfree(pages);
+   kfree(pfns);
+   return rc;
+   }
+   for (i = 0; i < nr_grant_frames; i++)
+   pfns[i] = page_to_pfn(pages[i]);
+
+   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+   if (!vaddr) {
+   pr_warn("%s Couldn't map %ld pfns rc:%d\n", 

[PATCH v5 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

[Shannon Zhao]

From: Shannon Zhao 

When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
a /hypervisor node in DT. So check if it needs to enable ACPI.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
Acked-by: Hanjun Guo 
---
 arch/arm64/kernel/acpi.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..4e92be0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,10 +67,13 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
 {
/*
 * Return 1 as soon as we encounter a node at depth 1 that is
-* not the /chosen node.
+* not the /chosen node, or /hypervisor node when running on Xen.
 */
-   if (depth == 1 && (strcmp(uname, "chosen") != 0))
-   return 1;
+   if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
+   if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+   return 1;
+   }
+
return 0;
 }
 
@@ -184,7 +187,8 @@ void __init acpi_boot_table_init(void)
/*
 * Enable ACPI instead of device tree unless
 * - ACPI has been disabled explicitly (acpi=off), or
-* - the device tree is not empty (it has more than just a /chosen node)
+* - the device tree is not empty (it has more than just a /chosen node,
+*   and a /hypervisor node when running on Xen)
 *   and ACPI has not been force enabled (acpi=force)
 */
if (param_acpi_off ||
-- 
2.0.4

[PATCH v5 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place

[Shannon Zhao]

From: Shannon Zhao 

Move xlated_setup_gnttab_pages to common place, so it can be reused by
ARM to setup grant table.

Rename it to xen_xlate_map_ballooned_pages.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/x86/xen/grant-table.c | 57 +--
 drivers/xen/xlate_mmu.c| 61 ++
 include/xen/xen-ops.h  |  2 ++
 3 files changed, 69 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index e079500..de4144c 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -111,63 +111,18 @@ int arch_gnttab_init(unsigned long nr_shared)
 }
 
 #ifdef CONFIG_XEN_PVH
-#include 
 #include 
-#include 
-static int __init xlated_setup_gnttab_pages(void)
-{
-   struct page **pages;
-   xen_pfn_t *pfns;
-   void *vaddr;
-   int rc;
-   unsigned int i;
-   unsigned long nr_grant_frames = gnttab_max_grant_frames();
-
-   BUG_ON(nr_grant_frames == 0);
-   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
-   if (!pages)
-   return -ENOMEM;
-
-   pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
-   if (!pfns) {
-   kfree(pages);
-   return -ENOMEM;
-   }
-   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
-   if (rc) {
-   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   kfree(pages);
-   kfree(pfns);
-   return rc;
-   }
-   for (i = 0; i < nr_grant_frames; i++)
-   pfns[i] = page_to_pfn(pages[i]);
-
-   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
-   if (!vaddr) {
-   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   free_xenballooned_pages(nr_grant_frames, pages);
-   kfree(pages);
-   kfree(pfns);
-   return -ENOMEM;
-   }
-   kfree(pages);
-
-   xen_auto_xlat_grant_frames.pfn = pfns;
-   xen_auto_xlat_grant_frames.count = nr_grant_frames;
-   xen_auto_xlat_grant_frames.vaddr = vaddr;
-
-   return 0;
-}
-
+#include 
 static int __init xen_pvh_gnttab_setup(void)
 {
if (!xen_pvh_domain())
return -ENODEV;
 
-   return xlated_setup_gnttab_pages();
+   xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+
+   return xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
+_auto_xlat_grant_frames.vaddr,
+xen_auto_xlat_grant_frames.count);
 }
 /* Call it _before_ __gnttab_init as we need to initialize the
  * xen_auto_xlat_grant_frames first. */
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 5063c5e..9692656 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -29,6 +29,8 @@
  */
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -37,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 typedef void (*xen_gfn_fn_t)(unsigned long gfn, void *data);
 
@@ -185,3 +188,61 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
return 0;
 }
 EXPORT_SYMBOL_GPL(xen_xlate_unmap_gfn_range);
+
+/**
+ * xen_xlate_map_ballooned_pages - map a new set of ballooned pages
+ * @gfns: returns the array of corresponding GFNs
+ * @virt: returns the virtual address of the mapped region
+ * @nr_grant_frames: number of GFNs
+ * @return 0 on success, error otherwise
+ *
+ * This allocates a set of ballooned pages and maps them into the
+ * kernel's address space.
+ */
+int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
+unsigned long nr_grant_frames)
+{
+   struct page **pages;
+   xen_pfn_t *pfns;
+   void *vaddr;
+   int rc;
+   unsigned int i;
+
+   BUG_ON(nr_grant_frames == 0);
+   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+   if (!pages)
+   return -ENOMEM;
+
+   pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
+   if (!pfns) {
+   kfree(pages);
+   return -ENOMEM;
+   }
+   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+   if (rc) {
+   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
+   nr_grant_frames, rc);
+   kfree(pages);
+   kfree(pfns);
+   return rc;
+   }
+   for (i = 0; i < nr_grant_frames; i++)
+   pfns[i] = page_to_pfn(pages[i]);
+
+   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+   if (!vaddr) {
+   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
+   nr_grant_frames, rc);
+   

[PATCH v5 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

[Shannon Zhao]

From: Shannon Zhao 

When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
a /hypervisor node in DT. So check if it needs to enable ACPI.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
Acked-by: Hanjun Guo 
---
 arch/arm64/kernel/acpi.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..4e92be0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,10 +67,13 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
 {
/*
 * Return 1 as soon as we encounter a node at depth 1 that is
-* not the /chosen node.
+* not the /chosen node, or /hypervisor node when running on Xen.
 */
-   if (depth == 1 && (strcmp(uname, "chosen") != 0))
-   return 1;
+   if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
+   if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+   return 1;
+   }
+
return 0;
 }
 
@@ -184,7 +187,8 @@ void __init acpi_boot_table_init(void)
/*
 * Enable ACPI instead of device tree unless
 * - ACPI has been disabled explicitly (acpi=off), or
-* - the device tree is not empty (it has more than just a /chosen node)
+* - the device tree is not empty (it has more than just a /chosen node,
+*   and a /hypervisor node when running on Xen)
 *   and ACPI has not been force enabled (acpi=force)
 */
if (param_acpi_off ||
-- 
2.0.4

[PATCH v5 01/17] Xen: ACPI: Hide UART used by Xen

[Shannon Zhao]

From: Shannon Zhao 

ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.

Signed-off-by: Shannon Zhao 
---
CC: "Rafael J. Wysocki"  (supporter:ACPI)
CC: Len Brown  (supporter:ACPI)
CC: linux-a...@vger.kernel.org (open list:ACPI)
---
 drivers/acpi/scan.c | 68 +
 1 file changed, 68 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 407a376..31d794c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
 DEFINE_MUTEX(acpi_device_lock);
 LIST_HEAD(acpi_wakeup_device_list);
 static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
 
 struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,47 @@ static int acpi_add_single_object(struct acpi_device 
**child,
return 0;
 }
 
+static acpi_status acpi_get_resource_fixed_memory32(struct acpi_resource *res,
+   void *context)
+{
+   struct acpi_resource_fixed_memory32 *fixed_memory32;
+
+   if (res->type != ACPI_RESOURCE_TYPE_FIXED_MEMORY32)
+   return AE_OK;
+
+   fixed_memory32 = >data.fixed_memory32;
+   if (!fixed_memory32)
+   return AE_OK;
+
+   *((u32 *)context) = fixed_memory32->address;
+   return AE_CTRL_TERMINATE;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+   acpi_status status;
+   u32 addr = 0;
+
+   /* Check if it should ignore the UART device */
+   if (spcr_uart_addr != 0) {
+   if (!acpi_has_method(handle, METHOD_NAME__CRS))
+   return false;
+
+   status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+acpi_get_resource_fixed_memory32,
+);
+   if (ACPI_FAILURE(status))
+   return false;
+
+   if (addr == spcr_uart_addr) {
+   printk(KERN_INFO PREFIX "The UART device in SPCR table 
will be hidden\n");
+   return true;
+   }
+   }
+
+   return false;
+}
+
 static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
 {
@@ -1466,6 +1508,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+   if (acpi_device_should_be_hidden(handle))
+   return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1919,6 +1964,8 @@ static int acpi_bus_scan_fixed(void)
 int __init acpi_scan_init(void)
 {
int result;
+   acpi_status status;
+   struct acpi_table_stao *stao_ptr;
 
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1933,6 +1980,27 @@ int __init acpi_scan_init(void)
 
acpi_scan_add_handler(_device_handler);
 
+   /* If there is STAO table, check whether it needs to ignore the UART
+* device in SPCR table.
+*/
+   status = acpi_get_table(ACPI_SIG_STAO, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status)) {
+   if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+   printk(KERN_INFO PREFIX "STAO Name List not yet 
supported.");
+
+   if (stao_ptr->ignore_uart) {
+   struct acpi_table_spcr *spcr_ptr;
+
+   status = acpi_get_table(ACPI_SIG_SPCR, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status))
+   spcr_uart_addr = spcr_ptr->serial_port.address;
+   else
+   printk(KERN_WARNING PREFIX "STAO table present, 
but SPCR is missing\n");
+   }
+   }
+
mutex_lock(_scan_lock);
/*
 * Enumerate devices in the ACPI namespace.
-- 
2.0.4

[PATCH v5 01/17] Xen: ACPI: Hide UART used by Xen

[Shannon Zhao]

From: Shannon Zhao 

ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.

Signed-off-by: Shannon Zhao 
---
CC: "Rafael J. Wysocki"  (supporter:ACPI)
CC: Len Brown  (supporter:ACPI)
CC: linux-a...@vger.kernel.org (open list:ACPI)
---
 drivers/acpi/scan.c | 68 +
 1 file changed, 68 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 407a376..31d794c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
 DEFINE_MUTEX(acpi_device_lock);
 LIST_HEAD(acpi_wakeup_device_list);
 static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
 
 struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,47 @@ static int acpi_add_single_object(struct acpi_device 
**child,
return 0;
 }
 
+static acpi_status acpi_get_resource_fixed_memory32(struct acpi_resource *res,
+   void *context)
+{
+   struct acpi_resource_fixed_memory32 *fixed_memory32;
+
+   if (res->type != ACPI_RESOURCE_TYPE_FIXED_MEMORY32)
+   return AE_OK;
+
+   fixed_memory32 = >data.fixed_memory32;
+   if (!fixed_memory32)
+   return AE_OK;
+
+   *((u32 *)context) = fixed_memory32->address;
+   return AE_CTRL_TERMINATE;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+   acpi_status status;
+   u32 addr = 0;
+
+   /* Check if it should ignore the UART device */
+   if (spcr_uart_addr != 0) {
+   if (!acpi_has_method(handle, METHOD_NAME__CRS))
+   return false;
+
+   status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+acpi_get_resource_fixed_memory32,
+);
+   if (ACPI_FAILURE(status))
+   return false;
+
+   if (addr == spcr_uart_addr) {
+   printk(KERN_INFO PREFIX "The UART device in SPCR table 
will be hidden\n");
+   return true;
+   }
+   }
+
+   return false;
+}
+
 static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
 {
@@ -1466,6 +1508,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+   if (acpi_device_should_be_hidden(handle))
+   return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1919,6 +1964,8 @@ static int acpi_bus_scan_fixed(void)
 int __init acpi_scan_init(void)
 {
int result;
+   acpi_status status;
+   struct acpi_table_stao *stao_ptr;
 
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1933,6 +1980,27 @@ int __init acpi_scan_init(void)
 
acpi_scan_add_handler(_device_handler);
 
+   /* If there is STAO table, check whether it needs to ignore the UART
+* device in SPCR table.
+*/
+   status = acpi_get_table(ACPI_SIG_STAO, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status)) {
+   if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+   printk(KERN_INFO PREFIX "STAO Name List not yet 
supported.");
+
+   if (stao_ptr->ignore_uart) {
+   struct acpi_table_spcr *spcr_ptr;
+
+   status = acpi_get_table(ACPI_SIG_SPCR, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status))
+   spcr_uart_addr = spcr_ptr->serial_port.address;
+   else
+   printk(KERN_WARNING PREFIX "STAO table present, 
but SPCR is missing\n");
+   }
+   }
+
mutex_lock(_scan_lock);
/*
 * Enumerate devices in the ACPI namespace.
-- 
2.0.4

[PATCH v5 09/17] xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ

[Shannon Zhao]

From: Shannon Zhao 

Add a new delivery type:
val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 0 stands the interrupt mode is edge(1) or level(0) and
bit 1 stands the interrupt polarity is active low(1) or high(0).

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 include/xen/interface/hvm/params.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/xen/interface/hvm/params.h 
b/include/xen/interface/hvm/params.h
index 70ad208..d32b02b 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -53,6 +53,16 @@
  * if this delivery method is available.
  */
 
+#define HVM_PARAM_CALLBACK_TYPE_EVENT3
+/*
+ * val[55:16] need to be zero.
+ * val[15:8] is flag of event-channel interrupt:
+ *  bit 8: interrupt is edge(1) or level(0) triggered
+ *  bit 9: interrupt is active low(1) or high(0)
+ * val[7:0] is PPI number used by event-channel.
+ * This is only used by ARM/ARM64.
+ */
+
 #define HVM_PARAM_STORE_PFN1
 #define HVM_PARAM_STORE_EVTCHN 2
 
-- 
2.0.4

[PATCH v5 09/17] xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ

[Shannon Zhao]

From: Shannon Zhao 

Add a new delivery type:
val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 0 stands the interrupt mode is edge(1) or level(0) and
bit 1 stands the interrupt polarity is active low(1) or high(0).

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 include/xen/interface/hvm/params.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/xen/interface/hvm/params.h 
b/include/xen/interface/hvm/params.h
index 70ad208..d32b02b 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -53,6 +53,16 @@
  * if this delivery method is available.
  */
 
+#define HVM_PARAM_CALLBACK_TYPE_EVENT3
+/*
+ * val[55:16] need to be zero.
+ * val[15:8] is flag of event-channel interrupt:
+ *  bit 8: interrupt is edge(1) or level(0) triggered
+ *  bit 9: interrupt is active low(1) or high(0)
+ * val[7:0] is PPI number used by event-channel.
+ * This is only used by ARM/ARM64.
+ */
+
 #define HVM_PARAM_STORE_PFN1
 #define HVM_PARAM_STORE_EVTCHN 2
 
-- 
2.0.4

[PATCH v5 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table

[Shannon Zhao]

From: Shannon Zhao 

Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't
rely on DT or ACPI to pass the start address and size of grant table.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..d94f726 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -282,18 +282,10 @@ static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
struct shared_info *shared_info_page = NULL;
-   struct resource res;
-   phys_addr_t grant_frames;
 
if (!xen_domain())
return 0;
 
-   if (of_address_to_resource(xen_node, GRANT_TABLE_PHYSADDR, )) {
-   pr_err("Xen grant table base address not found\n");
-   return -ENODEV;
-   }
-   grant_frames = res.start;
-
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
@@ -328,7 +320,10 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
 
-   if (gnttab_setup_auto_xlat_frames(grant_frames)) {
+   xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+   if (xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
+ _auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count)) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
}
-- 
2.0.4

[PATCH v5 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table

[Shannon Zhao]

From: Shannon Zhao 

Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't
rely on DT or ACPI to pass the start address and size of grant table.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..d94f726 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -282,18 +282,10 @@ static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
struct shared_info *shared_info_page = NULL;
-   struct resource res;
-   phys_addr_t grant_frames;
 
if (!xen_domain())
return 0;
 
-   if (of_address_to_resource(xen_node, GRANT_TABLE_PHYSADDR, )) {
-   pr_err("Xen grant table base address not found\n");
-   return -ENODEV;
-   }
-   grant_frames = res.start;
-
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
@@ -328,7 +320,10 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
 
-   if (gnttab_setup_auto_xlat_frames(grant_frames)) {
+   xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+   if (xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
+ _auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count)) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
}
-- 
2.0.4

Re: Suspicious error for CMA stress test

[Joonsoo Kim]

On Fri, Mar 04, 2016 at 02:05:09PM +0800, Hanjun Guo wrote:
> On 2016/3/4 12:32, Joonsoo Kim wrote:
> > On Fri, Mar 04, 2016 at 11:02:33AM +0900, Joonsoo Kim wrote:
> >> On Thu, Mar 03, 2016 at 08:49:01PM +0800, Hanjun Guo wrote:
> >>> On 2016/3/3 15:42, Joonsoo Kim wrote:
>  2016-03-03 10:25 GMT+09:00 Laura Abbott :
> > (cc -mm and Joonsoo Kim)
> >
> >
> > On 03/02/2016 05:52 AM, Hanjun Guo wrote:
> >> Hi,
> >>
> >> I came across a suspicious error for CMA stress test:
> >>
> >> Before the test, I got:
> >> -bash-4.3# cat /proc/meminfo | grep Cma
> >> CmaTotal: 204800 kB
> >> CmaFree:  195044 kB
> >>
> >>
> >> After running the test:
> >> -bash-4.3# cat /proc/meminfo | grep Cma
> >> CmaTotal: 204800 kB
> >> CmaFree: 6602584 kB
> >>
> >> So the freed CMA memory is more than total..
> >>
> >> Also the the MemFree is more than mem total:
> >>
> >> -bash-4.3# cat /proc/meminfo
> >> MemTotal:   16342016 kB
> >> MemFree:22367268 kB
> >> MemAvailable:   22370528 kB
> >>> [...]
> > I played with this a bit and can see the same problem. The sanity
> > check of CmaFree < CmaTotal generally triggers in
> > __move_zone_freepage_state in unset_migratetype_isolate.
> > This also seems to be present as far back as v4.0 which was the
> > first version to have the updated accounting from Joonsoo.
> > Were there known limitations with the new freepage accounting,
> > Joonsoo?
>  I don't know. I also played with this and looks like there is
>  accounting problem, however, for my case, number of free page is 
>  slightly less
>  than total. I will take a look.
> 
>  Hanjun, could you tell me your malloc_size? I tested with 1 and it 
>  doesn't
>  look like your case.
> >>> I tested with malloc_size with 2M, and it grows much bigger than 1M, also 
> >>> I
> >>> did some other test:
> >> Thanks! Now, I can re-generate erronous situation you mentioned.
> >>
> >>>  - run with single thread with 10 times, everything is fine.
> >>>
> >>>  - I hack the cam_alloc() and free as below [1] to see if it's lock 
> >>> issue, with
> >>>the same test with 100 multi-thread, then I got:
> >> [1] would not be sufficient to close this race.
> >>
> >> Try following things [A]. And, for more accurate test, I changed code a 
> >> bit more
> >> to prevent kernel page allocation from cma area [B]. This will prevent 
> >> kernel
> >> page allocation from cma area completely so we can focus cma_alloc/release 
> >> race.
> >>
> >> Although, this is not correct fix, it could help that we can guess
> >> where the problem is.
> > More correct fix is something like below.
> > Please test it.
> 
> Hmm, this is not working:

Sad to hear that.

Could you tell me your system's MAX_ORDER and pageblock_order?

Thanks.

Re: Suspicious error for CMA stress test

[Joonsoo Kim]

On Fri, Mar 04, 2016 at 02:05:09PM +0800, Hanjun Guo wrote:
> On 2016/3/4 12:32, Joonsoo Kim wrote:
> > On Fri, Mar 04, 2016 at 11:02:33AM +0900, Joonsoo Kim wrote:
> >> On Thu, Mar 03, 2016 at 08:49:01PM +0800, Hanjun Guo wrote:
> >>> On 2016/3/3 15:42, Joonsoo Kim wrote:
>  2016-03-03 10:25 GMT+09:00 Laura Abbott :
> > (cc -mm and Joonsoo Kim)
> >
> >
> > On 03/02/2016 05:52 AM, Hanjun Guo wrote:
> >> Hi,
> >>
> >> I came across a suspicious error for CMA stress test:
> >>
> >> Before the test, I got:
> >> -bash-4.3# cat /proc/meminfo | grep Cma
> >> CmaTotal: 204800 kB
> >> CmaFree:  195044 kB
> >>
> >>
> >> After running the test:
> >> -bash-4.3# cat /proc/meminfo | grep Cma
> >> CmaTotal: 204800 kB
> >> CmaFree: 6602584 kB
> >>
> >> So the freed CMA memory is more than total..
> >>
> >> Also the the MemFree is more than mem total:
> >>
> >> -bash-4.3# cat /proc/meminfo
> >> MemTotal:   16342016 kB
> >> MemFree:22367268 kB
> >> MemAvailable:   22370528 kB
> >>> [...]
> > I played with this a bit and can see the same problem. The sanity
> > check of CmaFree < CmaTotal generally triggers in
> > __move_zone_freepage_state in unset_migratetype_isolate.
> > This also seems to be present as far back as v4.0 which was the
> > first version to have the updated accounting from Joonsoo.
> > Were there known limitations with the new freepage accounting,
> > Joonsoo?
>  I don't know. I also played with this and looks like there is
>  accounting problem, however, for my case, number of free page is 
>  slightly less
>  than total. I will take a look.
> 
>  Hanjun, could you tell me your malloc_size? I tested with 1 and it 
>  doesn't
>  look like your case.
> >>> I tested with malloc_size with 2M, and it grows much bigger than 1M, also 
> >>> I
> >>> did some other test:
> >> Thanks! Now, I can re-generate erronous situation you mentioned.
> >>
> >>>  - run with single thread with 10 times, everything is fine.
> >>>
> >>>  - I hack the cam_alloc() and free as below [1] to see if it's lock 
> >>> issue, with
> >>>the same test with 100 multi-thread, then I got:
> >> [1] would not be sufficient to close this race.
> >>
> >> Try following things [A]. And, for more accurate test, I changed code a 
> >> bit more
> >> to prevent kernel page allocation from cma area [B]. This will prevent 
> >> kernel
> >> page allocation from cma area completely so we can focus cma_alloc/release 
> >> race.
> >>
> >> Although, this is not correct fix, it could help that we can guess
> >> where the problem is.
> > More correct fix is something like below.
> > Please test it.
> 
> Hmm, this is not working:

Sad to hear that.

Could you tell me your system's MAX_ORDER and pageblock_order?

Thanks.