Re: [PATCH v2 1/1] eventfd: implementation of EFD_MASK flag

[Martin Sustrik]

On 2015-09-16 08:27, Damian Hobson-Garcia wrote:

From: Martin Sustrik 

When implementing network protocols in user space, one has to implement
fake file descriptors to represent the sockets for the protocol.

Polling on such fake file descriptors is a problem (poll/select/epoll
accept only true file descriptors) and forces protocol implementers to 
use
various workarounds resulting in complex, non-standard and convoluted 
APIs.


More generally, ability to create full-blown file descriptors for
userspace-to-userspace signalling is missing. While eventfd(2) goes 
half

the way towards this goal it has follwoing shorcomings:

I.  There's no way to signal POLLPRI, POLLHUP etc.
II. There's no way to signal arbitrary combination of POLL* flags. Most
notably, simultaneous !POLLIN and !POLLOUT, which is a perfectly 
valid
combination for a network protocol (rx buffer is empty and tx 
buffer is

full), cannot be signaled using eventfd.

This patch implements new EFD_MASK flag which solves the above 
problems.


Additionally, to provide a way to associate user-space state with 
eventfd

object, it allows to attach user-space data to the file descriptor.


The above paragraph is a leftover from the past. The functionality no 
longer exist.




The semantics of EFD_MASK are as follows:

eventfd(2):

If eventfd is created with EFD_MASK flag set, it is initialised in such 
a

way as to signal no events on the file descriptor when it is polled on.
The 'initval' argument is ignored.

write(2):

User is allowed to write only buffers containing the following 
structure:


struct efd_mask {
  uint32_t events;
};


Is it worth having a struct here? Why not just uint32_t?

Martin



The value of 'events' should be any combination of event flags as 
defined

by poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified
events will be signaled when polling (select, poll, epoll) on the 
eventfd

is done later on.

read(2):

read is not supported and will fail with EINVAL.

select(2), poll(2) and similar:

When polling on the eventfd marked by EFD_MASK flag, all the events
specified in last written 'events' field shall be signaled.

Signed-off-by: Martin Sustrik 

[dhobs...@igel.co.jp: Rebased, and resubmitted for Linux 4.3]
Signed-off-by: Damian Hobson-Garcia 
---
 fs/eventfd.c | 102 
++-

 include/linux/eventfd.h  |  16 +--
 include/uapi/linux/eventfd.h |  39 +
 3 files changed, 132 insertions(+), 25 deletions(-)
 create mode 100644 include/uapi/linux/eventfd.h

diff --git a/fs/eventfd.c b/fs/eventfd.c
index 8d0c0df..1a6a066 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -2,6 +2,7 @@
  *  fs/eventfd.c
  *
  *  Copyright (C) 2007  Davide Libenzi 
+ *  Copyright (C) 2013  Martin Sustrik 
  *
  */

@@ -22,18 +23,31 @@
 #include 
 #include 

+#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
+#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE | 
EFD_MASK)
+#define EFD_MASK_VALID_EVENTS (POLLIN | POLLPRI | POLLOUT | POLLERR | 
POLLHUP)

+
 struct eventfd_ctx {
struct kref kref;
wait_queue_head_t wqh;
-   /*
-* Every time that a write(2) is performed on an eventfd, the
-* value of the __u64 being written is added to "count" and a
-* wakeup is performed on "wqh". A read(2) will return the "count"
-* value to userspace, and will reset "count" to zero. The kernel
-* side eventfd_signal() also, adds to the "count" counter and
-* issue a wakeup.
-*/
-   __u64 count;
+   union {
+   /*
+* Every time that a write(2) is performed on an eventfd, the
+* value of the __u64 being written is added to "count" and a
+* wakeup is performed on "wqh". A read(2) will return the
+* "count" value to userspace, and will reset "count" to zero.
+* The kernel side eventfd_signal() also, adds to the "count"
+* counter and issue a wakeup.
+*/
+   __u64 count;
+
+   /*
+* When using eventfd in EFD_MASK mode this stracture stores the
+* current events to be signaled on the eventfd (events member)
+* along with opaque user-defined data (data member).
+*/
+   struct efd_mask mask;
+   };
unsigned int flags;
 };

@@ -134,6 +148,14 @@ static unsigned int eventfd_poll(struct file
*file, poll_table *wait)
return events;
 }

+static unsigned int eventfd_mask_poll(struct file *file, poll_table 
*wait)

+{
+   struct eventfd_ctx *ctx = file->private_data;
+
+   poll_wait(file, &ctx->wqh, wait);
+   return ctx->mask.events;
+}
+
 static void eventfd_ctx_do_read(struct eventfd_ctx *ctx, __u64 *cnt)
 {
*cnt = (ctx->flags & EFD_SEMAPHORE) ? 1 : ctx->count;
@@ -239,6 +261,14 @@ static ssize_t eventfd_read(struct fi

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

[Geert Uytterhoeven]

Hi Andrew,

On Wed, Sep 9, 2015 at 1:21 AM, Andrew Morton  wrote:
> New syscalls are rather a pain, both from the patch-monkeying POV and
> also because nobody knows what the syscall numbers will be until
> everything lands in mainline.  Oh well, it doesn't happen often and
> it's easy stuff.

One more reason to let the assignment of syscall numbers be handled
(1) by the architecture maintainer, (2) after -rc1, even for x86.

If x86 is no more the canonical source, scripts/checksyscalls.sh needs an
update, though.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v8 05/10] arc: axs10x_defconfig: remove CONFIG_MMC_DW_IDMAC

[Shawn Lin]

DesignWare MMC Controller's transfer mode should be decided
at runtime instead of compile-time. So we remove this config
option and read dw_mmc's register to select DMA master.

Signed-off-by: Shawn Lin 
Acked-by: Vineet Gupta 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arc/configs/axs101_defconfig | 1 -
 arch/arc/configs/axs103_defconfig | 1 -
 arch/arc/configs/axs103_smp_defconfig | 1 -
 3 files changed, 3 deletions(-)

diff --git a/arch/arc/configs/axs101_defconfig 
b/arch/arc/configs/axs101_defconfig
index 562dac6..c92c0ef 100644
--- a/arch/arc/configs/axs101_defconfig
+++ b/arch/arc/configs/axs101_defconfig
@@ -89,7 +89,6 @@ CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_DW=y
-CONFIG_MMC_DW_IDMAC=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT3_FS=y
 CONFIG_EXT4_FS=y
diff --git a/arch/arc/configs/axs103_defconfig 
b/arch/arc/configs/axs103_defconfig
index 83a6d8d..cfac24e 100644
--- a/arch/arc/configs/axs103_defconfig
+++ b/arch/arc/configs/axs103_defconfig
@@ -95,7 +95,6 @@ CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_DW=y
-CONFIG_MMC_DW_IDMAC=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT3_FS=y
 CONFIG_EXT4_FS=y
diff --git a/arch/arc/configs/axs103_smp_defconfig 
b/arch/arc/configs/axs103_smp_defconfig
index f1e1c84..9922a11 100644
--- a/arch/arc/configs/axs103_smp_defconfig
+++ b/arch/arc/configs/axs103_smp_defconfig
@@ -96,7 +96,6 @@ CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_DW=y
-CONFIG_MMC_DW_IDMAC=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT3_FS=y
 CONFIG_EXT4_FS=y
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/7] [RFC] [media]: v4l2: introduce v4l2_timeval

[Hans Verkuil]

On 09/15/2015 10:26 PM, Arnd Bergmann wrote:
> On Tuesday 15 September 2015 18:27:19 Hans Verkuil wrote:
>> On 09/15/2015 05:49 PM, Arnd Bergmann wrote:
>>> The v4l2 API uses a 'struct timeval' to communicate time stamps to user
>>> space. This is broken on 32-bit architectures as soon as we have a C library
>>> that defines time_t as 64 bit, which then changes the structure layout of
>>> struct v4l2_buffer.
>>>
>>> Fortunately, almost all v4l2 drivers use monotonic timestamps and call
>>> v4l2_get_timestamp(), which means they don't also have a y2038 problem.
>>> This means we can keep using the existing binary layout of the structure
>>> and do not need to worry about defining a new kernel interface for
>>> userland with 64-bit time_t.
>>>
>>> A possible downside of this approach is that it breaks any user space
>>> that tries to assign the timeval structure returned from the kernel
>>> to another timeval, or to pass a pointer to it into a function that
>>> expects a timeval. Those will cause a build-time warning or error
>>> that can be fixed up in a backwards compatible way.
>>>
>>> The alternative to this patch is to leave the structure using
>>> 'struct timeval', but then we have to rework the kernel to let
>>> it handle both 32-bit and 64-bit time_t for 32-bit user space
>>> processes.
>>
>> Cool. Only this morning I was thinking about what would be needed in v4l2
>> to be y2038 safe, and here it is!
> 
> Nice!
> 
> fwiw, I also have a list of drivers at
> https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T_0YiQwis/edit?usp=sharing
> which lists all known files that still need changing, in case you are
> wondering what else needs to be done, though it currently only covers
> things that nobody so far has started working on, and I have a couple
> patches on my disk that need polishing (I pushed out the v4l2 portion
> of that as a start)

I just *thought* about it, I never said I would do it! :-)

> 
>>> @@ -839,7 +845,7 @@ struct v4l2_buffer {
>>> __u32   bytesused;
>>> __u32   flags;
>>> __u32   field;
>>> -   struct timeval  timestamp;
>>> +   struct v4l2_timeval timestamp;
>>> struct v4l2_timecodetimecode;
>>> __u32   sequence;
>>>  
>>>
>>
>> I suspect that quite a few apps use assign the timestamp to another timeval
>> struct. A quick grep in v4l-utils (which we maintain) shows at least two of
>> those assignments. Ditto for xawtv3.
> 
> Ok, that is very helpful information, thanks for finding that!
> 
>> So I don't think v4l2_timeval is an option as it would break userspace too 
>> badly.
> 
> Agreed, we definitely don't want to break building user space with
> existing environments, i.e. 64-bit architectures, or 32-bit architectures
> with 32-bit time_t.
> 
>> An alternative to supporting a 64-bit timeval for 32-bit userspace is to 
>> make a
>> new y2038-aware struct and a new set of ioctls and use this opportunity to 
>> clean
>> up and extend the v4l2_buffer struct.
>>
>> So any 32-bit app that needs to be y2038 compliant would just use the new
>> struct and ioctls.
>>
>> But this is something to discuss among the v4l2 developers.
> 
> Ok. We generally to require as few source level changes to user space
> as possible for the conversion, and we want to make sure that when
> using a 32-bit libc with 64-bit time_t, we don't accidentally get
> broken interfaces (i.e. we should get a compile error whenever we
> can't get it right automatically).
> 
> One aspect that makes v4l2_buffer special is that the binary format
> is already clean for y2038 (once patch 4/7 "exynos4-is: use monotonic
> timestamps as advertized" gets merged), and we only need to worry about
> what happens when user space disagrees about the size of timeval.
> 
> Let me describe the options that I can think of here:
> 
> a) Similar to my first attempt, define a new struct v4l2_timeval, but
>only use it when building with a y2038-aware libc, so we don't break
>existing environments:
> 
>   /* some compile-time conditional that we first need to agree on with 
> libc */
>   #if __BITS_PER_TIME_T > __BITS_PER_LONG
>   struct v4l2_timeval { long tv_sec; long tv_usec; }
>   #else
>   #define v4l2_timeval timeval
>   #endif
> 
>This means that any user space that currently assumes the timestamp
>member to be a 'struct timeval' has to be changed to access the members
>individually, or get a build error.
>The __BITS_PER_TIME_T trick has to be used in a couple of other subsystems
>too, as some of them have no other way to identify an interface

I don't like this as this means some applications will compile on 64 bit or
with a non-y2038-aware libc, but fail on a 32-bit with y2038-aware libc. This
will be confusing and it may take a long time before the application developer
discovers this.

> b) Keep the header file unchanged, but deal with both formats of v4l2_bu

Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Lee Jones]

On Wed, 16 Sep 2015, Viresh Kumar wrote:

> On 10-09-15, 09:31, Lee Jones wrote:
> > I think you answered your own question.
> > 
> > No users == !ABI == Strip it out.
> 
> Okay, as I have delayed things enough for you, didn't wanted to do
> that anymore. And so worked on it despite very tight schedule :)
> 
> Below is the refreshed binding changes (I have split that into 3
> patches, but kept the diff here for simplicity).
> 
> Other than that, all code changes you need to test your driver are
> pushed here:
> 
> https://git.linaro.org/people/viresh.kumar/linux.git 
> opp/supported-hw-prop-name-v1
> 
> I am not gonna post the patches to the lists, until the time existing
> patches get reviewed.

Thanks dude.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/2] KVM: nVMX: enhance allocate/free_vpid to handle shadow vpid

[Wanpeng Li]

On 9/16/15 2:42 PM, Jan Kiszka wrote:

On 2015-09-16 05:51, Wanpeng Li wrote:

Enhance allocate/free_vid to handle shadow vpid.

Signed-off-by: Wanpeng Li 
---
  arch/x86/kvm/vmx.c | 24 +++-
  1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9ff6a3f..4956081 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4155,29 +4155,27 @@ static int alloc_identity_pagetable(struct kvm *kvm)
return r;
  }
  
-static void allocate_vpid(struct vcpu_vmx *vmx)

+static int allocate_vpid(void)
  {
-   int vpid;
+   int vpid = 0;

Initialization is not pointless with the current code.

  
-	vmx->vpid = 0;

if (!enable_vpid)
-   return;
+   return 0;
spin_lock(&vmx_vpid_lock);
vpid = find_first_zero_bit(vmx_vpid_bitmap, VMX_NR_VPIDS);
-   if (vpid < VMX_NR_VPIDS) {
-   vmx->vpid = vpid;
+   if (vpid < VMX_NR_VPIDS)
__set_bit(vpid, vmx_vpid_bitmap);
-   }
spin_unlock(&vmx_vpid_lock);
+   return vpid;

You should return 0 also if vpid == VMX_NR_VPIDS.


Agreed.




  }
  
-static void free_vpid(struct vcpu_vmx *vmx)

+static void free_vpid(int vpid)
  {
if (!enable_vpid)

You could already test for vpid == 0 here...


return;
spin_lock(&vmx_vpid_lock);
-   if (vmx->vpid != 0)
-   __clear_bit(vmx->vpid, vmx_vpid_bitmap);
+   if (vpid != 0)

...then you could skip this.


Agreed.




+   __clear_bit(vpid, vmx_vpid_bitmap);
spin_unlock(&vmx_vpid_lock);
  }
  
@@ -8482,7 +8480,7 @@ static void vmx_free_vcpu(struct kvm_vcpu *vcpu)
  
  	if (enable_pml)

vmx_disable_pml(vmx);
-   free_vpid(vmx);
+   free_vpid(vmx->vpid);
leave_guest_mode(vcpu);
vmx_load_vmcs01(vcpu);
free_nested(vmx);
@@ -8501,7 +8499,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, 
unsigned int id)
if (!vmx)
return ERR_PTR(-ENOMEM);
  
-	allocate_vpid(vmx);

+   vmx->vpid = allocate_vpid();
  
  	err = kvm_vcpu_init(&vmx->vcpu, kvm, id);

if (err)
@@ -8577,7 +8575,7 @@ free_msrs:
  uninit_vcpu:
kvm_vcpu_uninit(&vmx->vcpu);
  free_vcpu:
-   free_vpid(vmx);
+   free_vpid(vmx->vpid);
kmem_cache_free(kvm_vcpu_cache, vmx);
return ERR_PTR(err);
  }


Yes, this is what I had in mind.


Thanks for your review. :-)

Regards,
Wanpeng Li
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Request for submaintainer moderation: PFC pinctrl patches

[Geert Uytterhoeven]

Hi Linus,

On Tue, Sep 15, 2015 at 10:48 PM, Linus Walleij
 wrote:
> On Fri, Sep 11, 2015 at 2:49 PM, Laurent Pinchart
>  wrote:
>
>> The topic is on our agenda for a meeting on Monday, I believe we'll appoint
>> someone to submaintain the PFC patches and send you pull requests.
>
> How did it go?

I will queue up all sh-pfc patches in a branch, and plan to send a pull request
after v4.3-rc3. That will include both support for the new r8a7795 SoC, and
fixes/updates for the existing code (e.g. the pfc patches from "[PATCH v2 0/6]
ARM: shmobile: Move gpio ranges from C code to DT",
http://www.spinics.net/lists/linux-gpio/msg07733.html).

Is that OK for you?

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/17] Update the mmc driver to use idr helper functions.

[Ulf Hansson]

On 15 September 2015 at 18:46, Lee Duncan  wrote:
> Signed-off-by: Lee Duncan 

Please change the prefix of the commit message header to "mmc: core"
and resend to linux-mmc.

Kind regards
Uffe

> ---
>  drivers/mmc/core/host.c | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 99a9c9011c50..5aa2330f074c 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -40,9 +40,8 @@ static DEFINE_SPINLOCK(mmc_host_lock);
>  static void mmc_host_classdev_release(struct device *dev)
>  {
> struct mmc_host *host = cls_dev_to_mmc_host(dev);
> -   spin_lock(&mmc_host_lock);
> -   idr_remove(&mmc_host_idr, host->index);
> -   spin_unlock(&mmc_host_lock);
> +
> +   idr_put_index(&mmc_host_idr, &mmc_host_lock, host->index);
> kfree(host);
>  }
>
> @@ -559,17 +558,12 @@ struct mmc_host *mmc_alloc_host(int extra, struct 
> device *dev)
>
> /* scanning will be enabled when we're ready */
> host->rescan_disable = 1;
> -   idr_preload(GFP_KERNEL);
> -   spin_lock(&mmc_host_lock);
> -   err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
> -   if (err >= 0)
> -   host->index = err;
> -   spin_unlock(&mmc_host_lock);
> -   idr_preload_end();
> +   err = idr_get_index(&mmc_host_idr, &mmc_host_lock, host);
> if (err < 0) {
> kfree(host);
> return NULL;
> }
> +   host->index = err;
>
> dev_set_name(&host->class_dev, "mmc%d", host->index);
>
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v8 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller

[Chunfeng Yun]

add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt| 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
new file mode 100644
index 000..0c96273
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -0,0 +1,52 @@
+MT8173 xHCI
+
+The device node for Mediatek SOC USB3.0 host controller
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers,
+   the first one for MAC, the second for IPPC
+ - interrupts : interrupt used by the controller
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain
+   "sys_ck": for clock of xHCI MAC
+   "wakeup_deb_p0": for USB wakeup debounce clock of port0
+   "wakeup_deb_p0": for USB wakeup debounce clock of port1
+
+ - phys : a list of phandle + phy specifier pairs
+ - usb3-lpm-capable : supports USB3.0 LPM
+
+Optional properties:
+ - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
+   mode;
+ - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
+   control register, it depends on "mediatek,wakeup-src".
+ - vbus-supply : reference to the VBUS regulator;
+
+Example:
+usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>,
+ <0 0x11280700 0 0x0100>;
+   interrupts = ;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+   clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   phys = <&phy_port0 PHY_TYPE_USB3>,
+  <&phy_port1 PHY_TYPE_USB2>;
+   vusb33-supply = <&mt6397_vusb_reg>;
+   vbus-supply = <&usb_p1_vbus>;
+   usb3-lpm-capable;
+   mediatek,syscon-wakeup = <&pericfg>;
+   mediatek,wakeup-src = <1>;
+   status = "okay";
+};
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] csiostor:Fix error handling in the function csio_device_reset

[Hannes Reinecke]

On 09/16/2015 12:14 AM, Nicholas Krause wrote:
> This fixes error handling in the function csio_device_reset to
> check the return value of aftering the function csio_hw_reset
> to check if it returned a error code and if so unlock the irq
> spinlock for the hardware plus return the hardware error code
> immediately.
> 
> Signed-off-by: Nicholas Krause 
> ---
>  drivers/scsi/csiostor/csio_scsi.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/csiostor/csio_scsi.c 
> b/drivers/scsi/csiostor/csio_scsi.c
> index 2c4562d..faea4e7 100644
> --- a/drivers/scsi/csiostor/csio_scsi.c
> +++ b/drivers/scsi/csiostor/csio_scsi.c
> @@ -1378,6 +1378,7 @@ csio_device_reset(struct device *dev,
>  {
>   struct csio_lnode *ln = shost_priv(class_to_shost(dev));
>   struct csio_hw *hw = csio_lnode_to_hw(ln);
> + int ret;
>  
>   if (*buf != '1')
>   return -EINVAL;
> @@ -1389,7 +1390,11 @@ csio_device_reset(struct device *dev,
>   csio_lnodes_block_request(hw);
>  
>   spin_lock_irq(&hw->lock);
> - csio_hw_reset(hw);
> + ret = csio_hw_reset(hw);
> + if (ret) {
> + spin_unlock_irq(&hw->lock);
> + return ret;
> + }
>   spin_unlock_irq(&hw->lock);
>  
>   /* Unblock upper IOs */
> 
No sure if that is correct; wouldn't the device stay blocked
if csio_hw_reset() fails?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v8 02/10] mmc: dw_mmc: use macro for HCON register operations

[Shawn Lin]

This patch add some macros for HCON register operations
to make code more readable.

Signed-off-by: Shawn Lin 
Acked-by: Jaehoon Chung 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/mmc/host/dw_mmc.c | 6 +++---
 drivers/mmc/host/dw_mmc.h | 3 +++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 5d7a8729..100f56e 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2674,7 +2674,7 @@ static void dw_mci_init_dma(struct dw_mci *host)
* Check ADDR_CONFIG bit in HCON to find
* IDMAC address bus width
*/
-   addr_config = (mci_readl(host, HCON) >> 27) & 0x01;
+   addr_config = SDMMC_GET_ADDR_CONFIG(mci_readl(host, HCON));
 
if (addr_config == 1) {
/* host supports IDMAC in 64-bit address mode */
@@ -3051,7 +3051,7 @@ int dw_mci_probe(struct dw_mci *host)
 * Get the host data width - this assumes that HCON has been set with
 * the correct values.
 */
-   i = (mci_readl(host, HCON) >> 7) & 0x7;
+   i = SDMMC_GET_HDATA_WIDTH(mci_readl(host, HCON));
if (!i) {
host->push_data = dw_mci_push_data16;
host->pull_data = dw_mci_pull_data16;
@@ -3133,7 +3133,7 @@ int dw_mci_probe(struct dw_mci *host)
if (host->pdata->num_slots)
host->num_slots = host->pdata->num_slots;
else
-   host->num_slots = ((mci_readl(host, HCON) >> 1) & 0x1F) + 1;
+   host->num_slots = SDMMC_GET_SLOT_NUM(mci_readl(host, HCON));
 
/*
 * Enable interrupts for command done, data over, data empty,
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 811d467..f2a88d4 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -154,6 +154,9 @@
 #define DMA_INTERFACE_GDMA (0x2)
 #define DMA_INTERFACE_NODMA(0x3)
 #define SDMMC_GET_TRANS_MODE(x)(((x)>>16) & 0x3)
+#define SDMMC_GET_SLOT_NUM(x)  x)>>1) & 0x1F) + 1)
+#define SDMMC_GET_HDATA_WIDTH(x)   (((x)>>7) & 0x7)
+#define SDMMC_GET_ADDR_CONFIG(x)   (((x)>>27) & 0x1)
 /* Internal DMAC interrupt defines */
 #define SDMMC_IDMAC_INT_AI BIT(9)
 #define SDMMC_IDMAC_INT_NI BIT(8)
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v8 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs

[Chunfeng Yun]

add a DT binding documentation of usb3.0 phy for MT65xx
SoCs from Mediatek.

Acked-by: Rob Herring 
Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
new file mode 100644
index 000..00100cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -0,0 +1,68 @@
+mt65xx USB3.0 PHY binding
+--
+
+This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
+
+Required properties (controller (parent) node):
+ - compatible  : should be "mediatek,mt8173-u3phy"
+ - reg : offset and length of register for phy, exclude port's
+ register.
+ - clocks  : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain
+ "u3phya_ref": for reference clock of usb3.0 analog phy.
+
+Required nodes : a sub-node is required for each port the controller
+ provides. Address range information including the usual
+ 'reg' property is used inside these nodes to describe
+ the controller's topology.
+
+Required properties (port (child) node):
+- reg  : address and length of the register set for the port.
+- #phy-cells   : should be 1 (See second example)
+ cell after port phandle is phy type from:
+   - PHY_TYPE_USB2
+   - PHY_TYPE_USB3
+
+Example:
+
+u3phy: usb-phy@1129 {
+   compatible = "mediatek,mt8173-u3phy";
+   reg = <0 0x1129 0 0x800>;
+   clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+   clock-names = "u3phya_ref";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "okay";
+
+   phy_port0: port@11290800 {
+   reg = <0 0x11290800 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   phy_port1: port@11291000 {
+   reg = <0 0x11291000 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+};
+
+Specifying phy control of devices
+-
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the phy port node and a device type;
+phy-names for each port are optional.
+
+Example:
+
+#include 
+
+usb30: usb@1127 {
+   ...
+   phys = <&phy_port0 PHY_TYPE_USB3>;
+   phy-names = "usb3-0";
+   ...
+};
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v8 0/5] Mediatek xHCI support

[Chunfeng Yun]

>From e731877598e7564171bea62955b4e50b04d88d34 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun 
Date: Wed, 16 Sep 2015 14:24:11 +0800
Subject: [PATCH v8 0/5] Mediatek xHCI support

The patch supports MediaTek's xHCI controller.

There are some differences from xHCI spec:
1. The interval is specified in 250 * 8ns increments for Interrupt Moderation
Interval(IMODI) of the Interrupter Moderation(IMOD) register, it is 8 times as
much as that defined in xHCI spec.

2. For the value of TD Size in Normal TRB, MTK's xHCI controller defines a
number of packets that remain to be transferred for a TD after processing all
Max packets in all previous TRBs,that means don't include the current TRB's,
but in xHCI spec it includes the current ones.

3. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK
architecture defines some extra SW scheduling parameters for HW. According to
these parameters provided by SW, the xHC can easily decide whether a
synchronous endpoint should be scheduled in a specific uFrame. The extra SW
scheduling parameters are put into reserved DWs in Slot and Endpoint Context.
And a bandwidth scheduler algorithm is added to support such feature.

A usb3.0 phy driver is also added which used by mt65xx SoCs platform, it
supports two usb2.0 ports and one usb3.0 port.

depend on the patch for TDS calculation:
https://patchwork.kernel.org/patch/7140041/

Change in v8:
1. use struct overlay for ippc register
2. change usb wakeup as optional feature
3. add TDS quirk into unified TDS calculation function

Change in v7:
1. remove xHCI timing setting which only for FPGA
2. revise xHCI scheduler algorithms
3. replace "usb" by "USB" in xHCI binding file

Change in v6:
1. get register base address of port in probe instead of of_xlate
2. enable clock in phy_init instead of probe

Change in v5:
1. descripte more exactly for each specifiers in xHCI binding
2. make use of new multi-phy feature for phy driver

Change in v4:
1. descripte more exactly for each specifiers in binding file
2. use BIT() to define a bit mask mcro

Change in v3:
1. implement generic phy
2. move opperations for IPPC and wakeup from phy driver to xHCI driver
3. seperate quirk functions into a single C file to fix up dependence issue

Change in v2:
1. Rebase to 4.2-rc1
2. Remove probe phy before add usb_hcd patch from this series due to 4.2-rc1
   already fix this issue
3. add xhci mac clocks
4. add suspend/resume
5. support remote wakeup


Chunfeng Yun (5):
  dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
  dt-bindings: Add a binding for Mediatek xHCI host controller
  usb: phy: add usb3.0 phy driver for mt65xx SoCs
  xhci: mediatek: support MTK xHCI host controller
  arm64: dts: mediatek: add xHCI & usb phy for mt8173

 .../devicetree/bindings/phy/phy-mt65xx-usb.txt |  68 ++
 .../devicetree/bindings/usb/mt8173-xhci.txt|  52 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|  16 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  43 ++
 drivers/phy/Kconfig|   9 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-mt65xx-usb3.c  | 456 +
 drivers/usb/host/Kconfig   |   9 +
 drivers/usb/host/Makefile  |   4 +
 drivers/usb/host/xhci-mtk-sch.c| 419 
 drivers/usb/host/xhci-mtk.c| 744 +
 drivers/usb/host/xhci-mtk.h| 156 +
 drivers/usb/host/xhci-ring.c   |  22 +-
 drivers/usb/host/xhci.c|  19 +-
 drivers/usb/host/xhci.h|   1 +
 15 files changed, 2012 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
 create mode 100644 drivers/phy/phy-mt65xx-usb3.c
 create mode 100644 drivers/usb/host/xhci-mtk-sch.c
 create mode 100644 drivers/usb/host/xhci-mtk.c
 create mode 100644 drivers/usb/host/xhci-mtk.h

--
1.8.1.1.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/2] KVM: nVMX: nested VPID emulation

[Jan Kiszka]

On 2015-09-16 05:51, Wanpeng Li wrote:
> VPID is used to tag address space and avoid a TLB flush. Currently L0 use 
> the same VPID to run L1 and all its guests. KVM flushes VPID when switching 
> between L1 and L2. 
> 
> This patch advertises VPID to the L1 hypervisor, then address space of L1 and 
> L2 can be separately treated and avoid TLB flush when swithing between L1 and 
> L2. For each nested vmentry, if vpid12 is changed, reuse shadow vpid w/ an 
> invvpid.
> 
> Performance: 
> 
> run lmbench on L2 w/ 3.5 kernel.
> 
> Context switching - times in microseconds - smaller is better
> -
> Host OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
>  ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
> - - -- -- -- -- -- --- ---
> kernelLinux 3.5.0-1 1.2200 1.3700 1.4500 4.7800 2.3300 5.6 2.88000  
> nested VPID 
> kernelLinux 3.5.0-1 1.2600 1.4300 1.5600   12.7   12.9 3.49000 7.46000  
> vanilla
> 
> Suggested-by: Wincy Van 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/vmx.c | 37 +++--
>  1 file changed, 31 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 4956081..2fd5b5e 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -424,6 +424,9 @@ struct nested_vmx {
>   /* to migrate it to L2 if VM_ENTRY_LOAD_DEBUG_CONTROLS is off */
>   u64 vmcs01_debugctl;
>  
> + u16 vpid02;
> + u16 last_vpid;
> +
>   u32 nested_vmx_procbased_ctls_low;
>   u32 nested_vmx_procbased_ctls_high;
>   u32 nested_vmx_true_procbased_ctls_low;
> @@ -1155,6 +1158,11 @@ static inline bool 
> nested_cpu_has_virt_x2apic_mode(struct vmcs12 *vmcs12)
>   return nested_cpu_has2(vmcs12, SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE);
>  }
>  
> +static inline bool nested_cpu_has_vpid(struct vmcs12 *vmcs12)
> +{
> + return nested_cpu_has2(vmcs12, SECONDARY_EXEC_ENABLE_VPID);
> +}
> +
>  static inline bool nested_cpu_has_apic_reg_virt(struct vmcs12 *vmcs12)
>  {
>   return nested_cpu_has2(vmcs12, SECONDARY_EXEC_APIC_REGISTER_VIRT);
> @@ -2469,6 +2477,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx 
> *vmx)
>   SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
>   SECONDARY_EXEC_RDTSCP |
>   SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
> + SECONDARY_EXEC_ENABLE_VPID |
>   SECONDARY_EXEC_APIC_REGISTER_VIRT |
>   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
>   SECONDARY_EXEC_WBINVD_EXITING |
> @@ -6662,6 +6671,7 @@ static void free_nested(struct vcpu_vmx *vmx)
>   return;
>  
>   vmx->nested.vmxon = false;
> + free_vpid(vmx->nested.vpid02);
>   nested_release_vmcs12(vmx);
>   if (enable_shadow_vmcs)
>   free_vmcs(vmx->nested.current_shadow_vmcs);
> @@ -8547,8 +8557,10 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm 
> *kvm, unsigned int id)
>   goto free_vmcs;
>   }
>  
> - if (nested)
> + if (nested) {
>   nested_vmx_setup_ctls_msrs(vmx);
> + vmx->nested.vpid02 = allocate_vpid();
> + }
>  
>   vmx->nested.posted_intr_nv = -1;
>   vmx->nested.current_vmptr = -1ull;
> @@ -8569,6 +8581,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm 
> *kvm, unsigned int id)
>   return &vmx->vcpu;
>  
>  free_vmcs:
> + free_vpid(vmx->nested.vpid02);
>   free_loaded_vmcs(vmx->loaded_vmcs);
>  free_msrs:
>   kfree(vmx->guest_msrs);
> @@ -9444,12 +9457,24 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu, 
> struct vmcs12 *vmcs12)
>  
>   if (enable_vpid) {
>   /*
> -  * Trivially support vpid by letting L2s share their parent
> -  * L1's vpid. TODO: move to a more elaborate solution, giving
> -  * each L2 its own vpid and exposing the vpid feature to L1.
> +  * There is no direct mapping between vpid02 and vpid12, the
> +  * vpid02 is per-vCPU for L0 and reused while the value of
> +  * vpid12 is changed w/ one invvpid during nested vmentry.
> +  * The vpid12 is allocated by L1 for L2, so it will not
> +  * influence global bitmap(for vpid01 and vpid02 allocation)
> +  * even if spawn a lot of nested vCPUs.
>*/
> - vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->vpid);
> - vmx_flush_tlb(vcpu);
> + if (nested_cpu_has_vpid(vmcs12)) {
> + vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->nested.vpid02);
> + if (vmcs12->virtual_processor_id != 
> vmx->nested.last_vpid) {
> + vmx->nested.last_vpid = 
> vmcs12->virtual_processor_id;
> + vmx_flush_tlb(vcpu);
> + }
> + } else {
> +  

[RFC PATCH v8 09/10] arm: multi_v7_defconfig: remove CONFIG_MMC_DW_IDMAC

[Shawn Lin]

DesignWare MMC Controller's transfer mode should be decided
at runtime instead of compile-time. So we remove this config
option and read dw_mmc's register to select DMA master.

Signed-off-by: Shawn Lin 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/configs/multi_v7_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 03deb7f..ad929ea 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -539,7 +539,6 @@ CONFIG_MMC_ATMELMCI=y
 CONFIG_MMC_MVSDIO=y
 CONFIG_MMC_SDHI=y
 CONFIG_MMC_DW=y
-CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_PLTFM=y
 CONFIG_MMC_DW_EXYNOS=y
 CONFIG_MMC_DW_ROCKCHIP=y
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v8 03/10] Documentation: synopsys-dw-mshc: add bindings for idmac and edmac

[Shawn Lin]

synopsys-dw-mshc supports three types of transfer mode. We add
bindings and description for how to use them at runtime.

Signed-off-by: Shawn Lin 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/mmc/synopsys-dw-mshc.txt   | 25 ++
 1 file changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 346c609..8636f5a 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -75,6 +75,12 @@ Optional properties:
 * vmmc-supply: The phandle to the regulator to use for vmmc.  If this is
   specified we'll defer probe until we can find this regulator.
 
+* dmas: List of DMA specifiers with the controller specific format as described
+  in the generic DMA client binding. Refer to dma.txt for details.
+
+* dma-names: request names for generic DMA client binding. Must be "rx-tx".
+  Refer to dma.txt for details.
+
 Aliases:
 
 - All the MSHC controller nodes should be represented in the aliases node using
@@ -95,6 +101,23 @@ board specific portions as listed below.
#size-cells = <0>;
};
 
+[board specific internal DMA resources]
+
+   dwmmc0@1220 {
+   clock-frequency = <4>;
+   clock-freq-min-max = <40 2>;
+   num-slots = <1>;
+   broken-cd;
+   fifo-depth = <0x80>;
+   card-detect-delay = <200>;
+   vmmc-supply = <&buck8>;
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
+   };
+
+[board specific generic DMA request binding]
+
dwmmc0@1220 {
clock-frequency = <4>;
clock-freq-min-max = <40 2>;
@@ -106,4 +129,6 @@ board specific portions as listed below.
bus-width = <8>;
cap-mmc-highspeed;
cap-sd-highspeed;
+   dmas = <&pdma 12>;
+   dma-names = "rx-tx";
};
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v8 10/10] arm: zx_defconfig: remove CONFIG_MMC_DW_IDMAC

[Shawn Lin]

DesignWare MMC Controller's transfer mode should be decided
at runtime instead of compile-time. So we remove this config
option and read dw_mmc's register to select DMA master.

Signed-off-by: Shawn Lin 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/configs/zx_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/zx_defconfig b/arch/arm/configs/zx_defconfig
index b200bb0..ab683fb 100644
--- a/arch/arm/configs/zx_defconfig
+++ b/arch/arm/configs/zx_defconfig
@@ -83,7 +83,6 @@ CONFIG_MMC=y
 CONFIG_MMC_UNSAFE_RESUME=y
 CONFIG_MMC_BLOCK_MINORS=16
 CONFIG_MMC_DW=y
-CONFIG_MMC_DW_IDMAC=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT4_FS=y
 CONFIG_EXT4_FS_POSIX_ACL=y
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v8 07/10] arm: hisi_defconfig: remove CONFIG_MMC_DW_IDMAC

[Shawn Lin]

DesignWare MMC Controller's transfer mode should be decided
at runtime instead of compile-time. So we remove this config
option and read dw_mmc's register to select DMA master.

Signed-off-by: Shawn Lin 
Acked-by: Wei Xu 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/configs/hisi_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
index 5997dbc..b2e340b 100644
--- a/arch/arm/configs/hisi_defconfig
+++ b/arch/arm/configs/hisi_defconfig
@@ -69,7 +69,6 @@ CONFIG_NOP_USB_XCEIV=y
 CONFIG_MMC=y
 CONFIG_RTC_CLASS=y
 CONFIG_MMC_DW=y
-CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_PLTFM=y
 CONFIG_RTC_DRV_PL031=y
 CONFIG_DMADEVICES=y
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v8 06/10] arm: exynos_defconfig: remove CONFIG_MMC_DW_IDMAC

[Shawn Lin]

DesignWare MMC Controller's transfer mode should be decided
at runtime instead of compile-time. So we remove this config
option and read dw_mmc's register to select DMA master.

Signed-off-by: Shawn Lin 
Acked-by: Krzysztof Kozlowski 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/configs/exynos_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 1ff2bfa..13ba48c 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -166,7 +166,6 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_S3C=y
 CONFIG_MMC_SDHCI_S3C_DMA=y
 CONFIG_MMC_DW=y
-CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_EXYNOS=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_MAX77686=y
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v8 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173

[Chunfeng Yun]

add xHCI and phy drivers for MT8173-EVB

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 16 +++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi| 43 +
 2 files changed, 59 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 4be66ca..d039a1c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -13,6 +13,7 @@
  */
 
 /dts-v1/;
+#include 
 #include "mt8173.dtsi"
 
 / {
@@ -32,6 +33,15 @@
};
 
chosen { };
+
+   usb_p1_vbus: regulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
 };
 
 &i2c1 {
@@ -390,3 +400,9 @@
 &uart0 {
status = "okay";
 };
+
+&usb30 {
+   vusb33-supply = <&mt6397_vusb_reg>;
+   vbus-supply = <&usb_p1_vbus>;
+   mediatek,wakeup-src = <1>;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..ceca7a5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "mt8173-pinfunc.h"
@@ -487,6 +488,48 @@
clock-names = "source", "hclk";
status = "disabled";
};
+
+   usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>,
+ <0 0x11280700 0 0x0100>;
+   interrupts = ;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+   clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   phys = <&phy_port0 PHY_TYPE_USB3>,
+  <&phy_port1 PHY_TYPE_USB2>;
+   usb3-lpm-capable;
+   mediatek,syscon-wakeup = <&pericfg>;
+   status = "okay";
+   };
+
+   u3phy: usb-phy@1129 {
+   compatible = "mediatek,mt8173-u3phy";
+   reg = <0 0x1129 0 0x800>;
+   clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+   clock-names = "u3phya_ref";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "okay";
+
+   phy_port0: port@11290800 {
+   reg = <0 0x11290800 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   phy_port1: port@11291000 {
+   reg = <0 0x11291000 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+   };
};
 };
 
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v8 08/10] arm: lpc18xx_defconfig: remove CONFIG_MMC_DW_IDMAC

[Shawn Lin]

DesignWare MMC Controller's transfer mode should be decided
at runtime instead of compile-time. So we remove this config
option and read dw_mmc's register to select DMA master.

Signed-off-by: Shawn Lin 
Acked-by: Joachim Eastwood 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/configs/lpc18xx_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/lpc18xx_defconfig 
b/arch/arm/configs/lpc18xx_defconfig
index 1c47f86..b7e8cda 100644
--- a/arch/arm/configs/lpc18xx_defconfig
+++ b/arch/arm/configs/lpc18xx_defconfig
@@ -119,7 +119,6 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_ROOT_HUB_TT=y
 CONFIG_MMC=y
 CONFIG_MMC_DW=y
-CONFIG_MMC_DW_IDMAC=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_PCA9532=y
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v8 04/10] mips: pistachio_defconfig: remove CONFIG_MMC_DW_IDMAC

[Shawn Lin]

DesignWare MMC Controller's transfer mode should be decided
at runtime instead of compile-time. So we remove this config
option and read dw_mmc's register to select DMA master.

Signed-off-by: Shawn Lin 
Acked-by: Govindraj Raja 
Acked-by: Ralf Baechle 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/mips/configs/pistachio_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/mips/configs/pistachio_defconfig 
b/arch/mips/configs/pistachio_defconfig
index 642b509..8b74291 100644
--- a/arch/mips/configs/pistachio_defconfig
+++ b/arch/mips/configs/pistachio_defconfig
@@ -257,7 +257,6 @@ CONFIG_MMC=y
 CONFIG_MMC_BLOCK_MINORS=16
 CONFIG_MMC_TEST=m
 CONFIG_MMC_DW=y
-CONFIG_MMC_DW_IDMAC=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_RTC_CLASS=y
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v8 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs

[Chunfeng Yun]

support usb3.0 phy of mt65xx SoCs

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/Kconfig   |   9 +
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-mt65xx-usb3.c | 456 ++
 3 files changed, 466 insertions(+)
 create mode 100644 drivers/phy/phy-mt65xx-usb3.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 47da573..ec436c1 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -206,6 +206,15 @@ config PHY_HIX5HD2_SATA
help
  Support for SATA PHY on Hisilicon hix5hd2 Soc.
 
+config PHY_MT65XX_USB3
+   tristate "Mediatek USB3.0 PHY Driver"
+   depends on ARCH_MEDIATEK && OF
+   select GENERIC_PHY
+   help
+ Say 'Y' here to add support for Mediatek USB3.0 PHY driver
+ for mt65xx SoCs. it supports two usb2.0 ports and
+ one usb3.0 port.
+
 config PHY_SUN4I_USB
tristate "Allwinner sunxi SoC USB PHY driver"
depends on ARCH_SUNXI && HAS_IOMEM && OF
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a5b18c1..a7cc629 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_TI_PIPE3)+= 
phy-ti-pipe3.o
 obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
 obj-$(CONFIG_PHY_EXYNOS5250_SATA)  += phy-exynos5250-sata.o
 obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
+obj-$(CONFIG_PHY_MT65XX_USB3)  += phy-mt65xx-usb3.o
 obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
 obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o
 obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
new file mode 100644
index 000..1f00b05
--- /dev/null
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -0,0 +1,456 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Chunfeng Yun 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * for sifslv2 register, but exclude port's;
+ * relative to USB3_SIF2_BASE base address
+ */
+#define SSUSB_SIFSLV_SPLLC 0x
+
+/* offsets of sub-segment in each port registers */
+#define SSUSB_SIFSLV_U2PHY_COM_BASE0x
+#define SSUSB_SIFSLV_U3PHYD_BASE   0x0100
+#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300
+#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400
+
+#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
+#define PA0_RG_U2PLL_FORCE_ON  BIT(15)
+
+#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008)
+#define PA2_RG_SIF_U2PLL_FORCE_EN  BIT(18)
+
+#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014)
+#define PA5_RG_U2_HSTX_SRCTRL  GENMASK(14, 12)
+#define PA5_RG_U2_HSTX_SRCTRL_VAL(x)   ((0x7 & (x)) << 12)
+#define PA5_RG_U2_HS_100U_U3_ENBIT(11)
+
+#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
+#define PA6_RG_U2_ISO_EN   BIT(31)
+#define PA6_RG_U2_BC11_SW_EN   BIT(23)
+#define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
+
+#define U3P_U2PHYACR4  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020)
+#define P2C_RG_USB20_GPIO_CTL  BIT(9)
+#define P2C_USB20_GPIO_MODEBIT(8)
+#define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE)
+
+#define U3D_U2PHYDCR0  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060)
+#define P2C_RG_SIF_U2PLL_FORCE_ON  BIT(24)
+
+#define U3P_U2PHYDTM0  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068)
+#define P2C_FORCE_UART_EN  BIT(26)
+#define P2C_FORCE_DATAIN   BIT(23)
+#define P2C_FORCE_DM_PULLDOWN  BIT(21)
+#define P2C_FORCE_DP_PULLDOWN  BIT(20)
+#define P2C_FORCE_XCVRSEL  BIT(19)
+#define P2C_FORCE_SUSPENDM BIT(18)
+#define P2C_FORCE_TERMSEL  BIT(17)
+#define P2C_RG_DATAIN  GENMASK(13, 10)
+#define P2C_RG_DATAIN_VAL(x)   ((0xf & (x)) << 10)
+#define P2C_RG_DMPULLDOWN  BIT(7)
+#define P2C_RG_DPPULLDOWN  BIT(6)
+#define P2C_RG_XCVRSEL GENMASK(5, 4)
+#define P2C_RG_XCVRSEL_VAL(x)  ((0x3 & (x)) << 4)
+#define P2C_RG_SUSPENDMBIT(3)
+#define P2C_RG_TERMSEL BIT(2)
+#define P2C_DTM0_PART_MASK \
+   (P2C_FORCE_DATAIN | P2C_FORCE_DM_PULLDOWN | \
+   P2C_FORCE_DP_PULLDOWN | P2C_FORCE_XCVRSEL | \
+   P2C_FORCE_TERMSEL | P2C_RG_DMPULLDOWN | \
+   P2C_RG_DPPULL

[PATCH v8 4/5] xhci: mediatek: support MTK xHCI host controller

[Chunfeng Yun]

There some vendor quirks for MTK xhci host controller:
1. It defines some extra SW scheduling parameters for HW
  to minimize the scheduling effort for synchronous and
  interrupt endpoints. The parameters are put into reseved
  DWs of slot context and endpoint context.
2. Its IMODI unit for Interrupter Moderation register is
  8 times as much as that defined in xHCI spec.
3. Its TDS in  Normal TRB defines a number of packets that
  remains to be transferred for a TD after processing all
  Max packets in all previous TRBs.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/Kconfig|   9 +
 drivers/usb/host/Makefile   |   4 +
 drivers/usb/host/xhci-mtk-sch.c | 419 ++
 drivers/usb/host/xhci-mtk.c | 744 
 drivers/usb/host/xhci-mtk.h | 156 +
 drivers/usb/host/xhci-ring.c|  22 +-
 drivers/usb/host/xhci.c |  19 +-
 drivers/usb/host/xhci.h |   1 +
 8 files changed, 1367 insertions(+), 7 deletions(-)
 create mode 100644 drivers/usb/host/xhci-mtk-sch.c
 create mode 100644 drivers/usb/host/xhci-mtk.c
 create mode 100644 drivers/usb/host/xhci-mtk.h

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 079991e..4674118 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -41,6 +41,15 @@ config USB_XHCI_PLATFORM
 
  If unsure, say N.
 
+config USB_XHCI_MTK
+   tristate "xHCI support for Mediatek MT65xx"
+   select MFD_SYSCON
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in Mediatek MT65xx SoCs.
+ If unsure, say N.
+
 config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x"
select USB_XHCI_PLATFORM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 754efaa..00401f9 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -13,6 +13,9 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 xhci-hcd-y := xhci.o xhci-mem.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
 xhci-hcd-y += xhci-trace.o
+ifneq ($(CONFIG_USB_XHCI_MTK), )
+   xhci-hcd-y += xhci-mtk-sch.o
+endif
 
 xhci-plat-hcd-y := xhci-plat.o
 ifneq ($(CONFIG_USB_XHCI_MVEBU), )
@@ -30,6 +33,7 @@ endif
 
 obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
 obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
 
 obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
 obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
new file mode 100644
index 000..534d089
--- /dev/null
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -0,0 +1,419 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author:
+ *  Zhigang.Wei 
+ *  Chunfeng.Yun 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include "xhci.h"
+#include "xhci-mtk.h"
+
+#define SS_BW_BOUNDARY 51000
+/* table 5-5. High-speed Isoc Transaction Limits in usb_20 spec */
+#define HS_BW_BOUNDARY 6144
+/* usb2 spec section11.18.1: at most 188 FS bytes per microframe */
+#define FS_PAYLOAD_MAX 188
+
+/* mtk scheduler bitmasks */
+#define EP_BPKTS(p)((p) & 0x3f)
+#define EP_BCSCOUNT(p) (((p) & 0x7) << 8)
+#define EP_BBM(p)  ((p) << 11)
+#define EP_BOFFSET(p)  ((p) & 0x3fff)
+#define EP_BREPEAT(p)  (((p) & 0x7fff) << 16)
+
+static int is_fs_or_ls(enum usb_device_speed speed)
+{
+   return speed == USB_SPEED_FULL || speed == USB_SPEED_LOW;
+}
+
+/*
+* get the index of bandwidth domains array which @ep belongs to.
+*
+* the bandwidth domain array is saved to @sch_array of struct xhci_hcd_mtk,
+* each HS root port is treated as a single bandwidth domain,
+* but each SS root port is treated as two bandwidth domains, one for IN eps,
+* one for OUT eps.
+* @real_port value is defined as follow according to xHCI spec:
+* 1 for SSport0, ..., N+1 for SSportN, N+2 for HSport0, N+3 for HSport1, etc
+* so the bandwidth domain array is organized as follow for simplification:
+* SSport0-OUT, SSport0-IN, ..., SSportX-OUT, SSportX-IN, HSport0, ..., HSportY
+*/
+static int get_bw_index(struct xhci_hcd *xhci, struct usb_device *udev,
+   struct usb_host_endpoint *ep)
+{
+   struct xhci_virt_device *virt_dev;
+   int bw_index;
+
+   virt_dev = xhci->devs[udev->slot_id];
+
+   if (udev->speed == USB_SPEED_SUPER) {
+   if (usb_endpoint_dir_out(&ep->desc))
+   bw_index = (virt_dev->real_port - 1) * 2;
+ 

[RFC PATCH v8 01/10] mmc: dw_mmc: Add external dma interface support

[Shawn Lin]

DesignWare MMC Controller can supports two types of DMA
mode: external dma and internal dma. We get a RK312x platform
integrated dw_mmc and ARM pl330 dma controller. This patch add
edmac ops to support these platforms. I've tested it on RK31xx
platform with edmac mode and RK3288 platform with idmac mode.

Signed-off-by: Shawn Lin 

---

Changes in v8:
- remove trans_mode variable
- remove unnecessary dma_ops check
- remove unnecessary comment
- fix coding style based on latest ulf's next
- add Acked-by: Jaehoon Chung 
  for HCON's changes

Changes in v7:
- rebased on Ulf's next
- combine condition state
- elaborate more about DMA_INTERFACE
- define some macro for DMA_INERFACE value
- spilt HCON ops' changes into another patch

Changes in v6:
- add trans_mode condition for IDMAC initialization
  suggested by Heiko
- re-test my patch on rk3188 platform and update commit msg
- update performance of pio vs edmac in cover letter

Changes in v5:
- add the title of cover letter
- fix typo of comment
- add macro for reading HCON register
- add "Acked-by: Krzysztof Kozlowski " for 
exynos_defconfig patch
- add "Acked-by: Vineet Gupta " for axs10x_defconfig patch
- add "Acked-by: Govindraj Raja " and
  "Acked-by: Ralf Baechle " for pistachio_defconfig patch
- add "Acked-by: Joachim Eastwood " for lpc18xx_defconfig 
patch
- add "Acked-by: Wei Xu " for hisi_defconfig patch
- rebase on "https://github.com/jh80chung/dw-mmc.git tags/dw-mmc-for-ulf-v4.2" 
for merging easily

Changes in v4:
- remove "host->trans_mode" and use "host->use_dma" to indicate
  transfer mode.
- remove all bt-bindings' changes since we don't need new properities.
- check transfer mode at runtime by reading HCON reg
- spilt defconfig changes for each sub-architecture
- fix the title of cover letter
- reuse some code for reducing code size

Changes in v3:
- choose transfer mode at runtime
- remove all CONFIG_MMC_DW_IDMAC config option
- add supports-idmac property for some platforms

Changes in v2:
- Fix typo of dev_info msg
- remove unused dmach from declaration of dw_mci_dma_slave

 drivers/mmc/host/Kconfig|  11 +-
 drivers/mmc/host/dw_mmc-pltfm.c |   2 +
 drivers/mmc/host/dw_mmc.c   | 268 
 drivers/mmc/host/dw_mmc.h   |   6 +
 include/linux/mmc/dw_mmc.h  |  23 +++-
 5 files changed, 246 insertions(+), 64 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8a1e349..515527e 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -615,15 +615,7 @@ config MMC_DW
help
  This selects support for the Synopsys DesignWare Mobile Storage IP
  block, this provides host support for SD and MMC interfaces, in both
- PIO and external DMA modes.
-
-config MMC_DW_IDMAC
-   bool "Internal DMAC interface"
-   depends on MMC_DW
-   help
- This selects support for the internal DMAC block within the Synopsys
- Designware Mobile Storage IP block. This disables the external DMA
- interface.
+ PIO, internal DMA mode and external DMA mode.
 
 config MMC_DW_PLTFM
tristate "Synopsys Designware MCI Support as platform device"
@@ -652,7 +644,6 @@ config MMC_DW_K3
tristate "K3 specific extensions for Synopsys DW Memory Card Interface"
depends on MMC_DW
select MMC_DW_PLTFM
-   select MMC_DW_IDMAC
help
  This selects support for Hisilicon K3 SoC specific extensions to the
  Synopsys DesignWare Memory Card Interface driver. Select this option
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index ec6dbcd..7e1d13b 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -59,6 +59,8 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
host->pdata = pdev->dev.platform_data;
 
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   /* Get registers' physical base address */
+   host->phy_regs = (void *)(regs->start);
host->regs = devm_ioremap_resource(&pdev->dev, regs);
if (IS_ERR(host->regs))
return PTR_ERR(host->regs);
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index fcbf552..5d7a8729 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -56,7 +56,6 @@
 #define DW_MCI_FREQ_MAX2   /* unit: HZ */
 #define DW_MCI_FREQ_MIN40  /* unit: HZ */
 
-#ifdef CONFIG_MMC_DW_IDMAC
 #define IDMAC_INT_CLR  (SDMMC_IDMAC_INT_AI | SDMMC_IDMAC_INT_NI | \
 SDMMC_IDMAC_INT_CES | SDMMC_IDMAC_INT_DU | \
 SDMMC_IDMAC_INT_FBE | SDMMC_IDMAC_INT_RI | \
@@ -102,7 +101,6 @@ struct idmac_desc {
 
 /* Each descriptor can transfer up to 4KB of data in chained mode */
 #define DW_MCI_DESC_DATA_LENGTH0x1000
-#endif /* CONFIG_MMC_DW_IDMAC */
 
 static bool dw_mci_reset(struct dw_mci *host);
 st

[RFC PATCH v8 0/10] Add external dma support for Synopsys MSHC

[Shawn Lin]

Synopsys DesignWare mobile storage host controller supports three
types of transfer mode: pio, internal dma and external dma. However,
dw_mmc can only supports pio and internal dma now. Thus some platforms
using dw-mshc integrated with generic dma can't work in dma mode. So we
submit this patch to achieve it.

And the config option, CONFIG_MMC_DW_IDMAC, was added by Will Newton
(commit:f95f3850) for the first version of dw_mmc and never be touched since
then. At that time dt-bindings hadn't been introduced into dw_mmc yet means
we should select CONFIG_MMC_DW_IDMAC to enable internal dma mode at compile
time. Nowadays, device-tree helps us to support a variety of boards with one
kernel. That's why we need to remove it and decide the transfer mode by reading
dw_mmc's HCON reg at runtime.

This RFC patch needs lots of ACKs. I know it's hard, but it does need someone
to make the running.

Patch does the following things:
- remove CONFIG_MMC_DW_IDMAC config option
- add bindings for edmac used by synopsys-dw-mshc
  at runtime
- add edmac support for synopsys-dw-mshc

Patch is based on next of git://git.linaro.org/people/ulf.hansson/mmc

Test emmc throughput on my platform with edmac support and without edmac 
support(pio only)
iozone -L64 -S32 -azecwI -+n -r4k -r64k -r128k -s1g -i0 -i1 -i2 -f datafile -Rb 
out.xls > /mnt/result.txt
(light cpu loading, Direct IO, fixed line size, all pattern recycle, 1GB data 
in total)
 ___
|   external dma mode   |
|---|
|blksz | Random Read | Random Write | Seq Read   | Seq Write|
|---|
|4kB   |  13953kB/s  |8602kB/s  | 13672kB/s  |  9785kB/s|
|---|
|64kB  |  46058kB/s  |   24794kB/s  | 48058kB/s  | 25418kB/s|
|---|
|128kB |  57026kB/s  |   35117kB/s  | 57375kB/s  | 35183kB/s|
|---|
   VS
 ___
|  pio mode |
|---|
|blksz | Random Read  | Random Write | Seq Read  | Seq Write|
|---|
|4kB   |  11720kB/s   |8644kB/s  | 11549kB/s |  9624kB/s|
|---|
|64kB  |  21869kB/s   |   24414kB/s  | 22031kB/s | 27986kB/s|
|---|
|128kB |  23718kB/s   |   34495kB/s  | 24698kB/s | 34637kB/s|
|---|


Changes in v8:
- remove trans_mode variable
- remove unnecessary dma_ops check
- remove unnecessary comment
- fix coding style based on latest ulf's next
- add Acked-by: Jaehoon Chung 
  for HCON's changes

Changes in v7:
- rebased on Ulf's next
- combine condition state
- elaborate more about DMA_INTERFACE
- define some macro for DMA_INERFACE value
- spilt HCON ops' changes into another patch

Changes in v6:
- add trans_mode condition for IDMAC initialization
  suggested by Heiko
- re-test my patch on rk3188 platform and update commit msg
- update performance of pio vs edmac in cover letter

Changes in v5:
- add the title of cover letter
- fix typo of comment
- add macro for reading HCON register
- add "Acked-by: Krzysztof Kozlowski " for 
exynos_defconfig patch
- add "Acked-by: Vineet Gupta " for axs10x_defconfig patch
- add "Acked-by: Govindraj Raja " and
  "Acked-by: Ralf Baechle " for pistachio_defconfig patch
- add "Acked-by: Joachim Eastwood " for lpc18xx_defconfig 
patch
- add "Acked-by: Wei Xu " for hisi_defconfig patch
- rebase on "https://github.com/jh80chung/dw-mmc.git tags/dw-mmc-for-ulf-v4.2" 
for merging easily

Changes in v4:
- remove "host->trans_mode" and use "host->use_dma" to indicate
  transfer mode.
- remove all bt-bindings' changes since we don't need new properities.
- check transfer mode at runtime by reading HCON reg
- spilt defconfig changes for each sub-architecture
- fix the title of cover letter
- reuse some code for reducing code size

Changes in v3:
- choose transfer mode at runtime
- remove all CONFIG_MMC_DW_IDMAC config option
- add supports-idmac property for some platforms

Changes in v2:
- Fix typo of dev_info msg
- remove unused dmach from declaration of dw_mci_dma_slave

Shawn Lin (10):
  mmc: dw_mmc: Add external dma interface support
  mmc: dw_mmc: use macro for HCON register operations
  Documentation: synopsys-dw-mshc: add bindings for idmac and edmac
  mips: pistachio_defconfig: remove CONFIG_MMC_DW_IDMAC
  arc: axs10x_defconfig: remove CONFIG_MMC_DW_IDMAC
  arm: exynos_defconfig: remove CONFIG_MMC_DW_IDMAC
  arm: hisi_defconfig: remove CONFIG_MMC_DW_IDMAC
  arm: lpc18xx_defconfig: rem

Re: [PATCH v3 1/2] KVM: nVMX: enhance allocate/free_vpid to handle shadow vpid

[Jan Kiszka]

On 2015-09-16 05:51, Wanpeng Li wrote:
> Enhance allocate/free_vid to handle shadow vpid.
> 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/vmx.c | 24 +++-
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 9ff6a3f..4956081 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -4155,29 +4155,27 @@ static int alloc_identity_pagetable(struct kvm *kvm)
>   return r;
>  }
>  
> -static void allocate_vpid(struct vcpu_vmx *vmx)
> +static int allocate_vpid(void)
>  {
> - int vpid;
> + int vpid = 0;

Initialization is not pointless with the current code.

>  
> - vmx->vpid = 0;
>   if (!enable_vpid)
> - return;
> + return 0;
>   spin_lock(&vmx_vpid_lock);
>   vpid = find_first_zero_bit(vmx_vpid_bitmap, VMX_NR_VPIDS);
> - if (vpid < VMX_NR_VPIDS) {
> - vmx->vpid = vpid;
> + if (vpid < VMX_NR_VPIDS)
>   __set_bit(vpid, vmx_vpid_bitmap);
> - }
>   spin_unlock(&vmx_vpid_lock);
> + return vpid;

You should return 0 also if vpid == VMX_NR_VPIDS.

>  }
>  
> -static void free_vpid(struct vcpu_vmx *vmx)
> +static void free_vpid(int vpid)
>  {
>   if (!enable_vpid)

You could already test for vpid == 0 here...

>   return;
>   spin_lock(&vmx_vpid_lock);
> - if (vmx->vpid != 0)
> - __clear_bit(vmx->vpid, vmx_vpid_bitmap);
> + if (vpid != 0)

...then you could skip this.

> + __clear_bit(vpid, vmx_vpid_bitmap);
>   spin_unlock(&vmx_vpid_lock);
>  }
>  
> @@ -8482,7 +8480,7 @@ static void vmx_free_vcpu(struct kvm_vcpu *vcpu)
>  
>   if (enable_pml)
>   vmx_disable_pml(vmx);
> - free_vpid(vmx);
> + free_vpid(vmx->vpid);
>   leave_guest_mode(vcpu);
>   vmx_load_vmcs01(vcpu);
>   free_nested(vmx);
> @@ -8501,7 +8499,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm 
> *kvm, unsigned int id)
>   if (!vmx)
>   return ERR_PTR(-ENOMEM);
>  
> - allocate_vpid(vmx);
> + vmx->vpid = allocate_vpid();
>  
>   err = kvm_vcpu_init(&vmx->vcpu, kvm, id);
>   if (err)
> @@ -8577,7 +8575,7 @@ free_msrs:
>  uninit_vcpu:
>   kvm_vcpu_uninit(&vmx->vcpu);
>  free_vcpu:
> - free_vpid(vmx);
> + free_vpid(vmx->vpid);
>   kmem_cache_free(kvm_vcpu_cache, vmx);
>   return ERR_PTR(err);
>  }
> 

Yes, this is what I had in mind.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: ti: clk-7xx: Remove hardwired ABE clock configuration

[Tero Kristo]

On 09/14/2015 11:52 AM, Peter Ujfalusi wrote:

Hi Tero,

On 08/24/2015 10:35 AM, Peter Ujfalusi wrote:

The ABE related clocks should be configured via DT and not have it wired
inside of the kernel.


can you take a look at this patch? It will not cause any regression since we
do not have audio support mainline and the pending series does not need this
part anymore.


This patch looks okay to me. So, you are saying this doesn't depend on 
anything? Isn't this causing any boot-time issues with the ABE DPLL left 
dangling with boot setup, potentially blocking PM? I am just wondering 
if we should group this patch with the rest of the audio support patches 
for dra7.


-Tero




Signed-off-by: Peter Ujfalusi 
---
Hi Tero,

the ABE PLL configuration can, and will be done for dra7xx in DT with the
assigned-clocks/rate/parent feature so no need to have this anymore.

Regards,
Peter

  drivers/clk/ti/clk-7xx.c | 18 +-
  1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 9b5b289e6334..a911d7de3377 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -18,7 +18,6 @@

  #include "clock.h"

-#define DRA7_DPLL_ABE_DEFFREQ  180633600
  #define DRA7_DPLL_GMAC_DEFFREQ10
  #define DRA7_DPLL_USB_DEFFREQ 96000

@@ -313,27 +312,12 @@ static struct ti_dt_clk dra7xx_clks[] = {
  int __init dra7xx_dt_clk_init(void)
  {
int rc;
-   struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
+   struct clk *dpll_ck, *hdcp_ck;

ti_dt_clocks_register(dra7xx_clks);

omap2_clk_disable_autoidle_all();

-   abe_dpll_mux = clk_get_sys(NULL, "abe_dpll_sys_clk_mux");
-   sys_clkin2 = clk_get_sys(NULL, "sys_clkin2");
-   dpll_ck = clk_get_sys(NULL, "dpll_abe_ck");
-
-   rc = clk_set_parent(abe_dpll_mux, sys_clkin2);
-   if (!rc)
-   rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ);
-   if (rc)
-   pr_err("%s: failed to configure ABE DPLL!\n", __func__);
-
-   dpll_ck = clk_get_sys(NULL, "dpll_abe_m2x2_ck");
-   rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2);
-   if (rc)
-   pr_err("%s: failed to configure ABE DPLL m2x2!\n", __func__);
-
dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
if (rc)






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jiri Olsa]

On Wed, Sep 16, 2015 at 08:16:52AM +0200, Jiri Olsa wrote:
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> > 
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> > 'tools/perf/arch/common.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> > 'tools/perf/fs/fs.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> > 'tools/perf/util/abspath.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> > 
> > Maybe caused by commit
> > 
> >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> > objects")
> > 
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
> 
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
> 
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap
> 
> > 
> > I have used the tip tree from next-20150915 for today.
> > 
> > Also, building perf seems to ignore O= on the make invocation.
> > Is that expected?
> 
> hum, not sure about this one.. I'm not using it, but we have
> tests for this and I thought we're ok.. I'll check

seems to work on latest Arnaldo's perf/core,
what command line failed for you?

[jolsa@krava perf]$ make O=/tmp/krava/
...
[jolsa@krava perf]$ ll /tmp/krava/perf
-rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf


jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1] mm: hwpoison: ratelimit messages from unpoison_memory()

[Naoya Horiguchi]

Currently kernel prints out results of every single unpoison event, which is
not necessary because unpoison is purely a testing feature and testers can get
little or no information from lots of lines of unpoison log storm. So this
patch ratelimits printk in unpoison_memory().

This patch introduces a file local ratelimit_state, which adds 64 bytes to
memory-failure.o. If we apply pr_info_ratelimited() for 8 callsite below, 256
bytes is added, so it's a win.

Signed-off-by: Naoya Horiguchi 
---
 mm/memory-failure.c | 34 +-
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git v4.3-rc1/mm/memory-failure.c v4.3-rc1_patched/mm/memory-failure.c
index 95882692e747..16a0ec385320 100644
--- v4.3-rc1/mm/memory-failure.c
+++ v4.3-rc1_patched/mm/memory-failure.c
@@ -56,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "internal.h"
 #include "ras/ras_event.h"
 
@@ -1403,6 +1404,12 @@ static int __init memory_failure_init(void)
 }
 core_initcall(memory_failure_init);
 
+#define unpoison_pr_info(fmt, pfn, rs) \
+({ \
+   if (__ratelimit(rs))\
+   pr_info(fmt, pfn);  \
+})
+
 /**
  * unpoison_memory - Unpoison a previously poisoned page
  * @pfn: Page number of the to be unpoisoned page
@@ -1421,6 +1428,8 @@ int unpoison_memory(unsigned long pfn)
struct page *p;
int freeit = 0;
unsigned int nr_pages;
+   static DEFINE_RATELIMIT_STATE(unpoison_rs, DEFAULT_RATELIMIT_INTERVAL,
+   DEFAULT_RATELIMIT_BURST);
 
if (!pfn_valid(pfn))
return -ENXIO;
@@ -1429,23 +1438,26 @@ int unpoison_memory(unsigned long pfn)
page = compound_head(p);
 
if (!PageHWPoison(p)) {
-   pr_info("MCE: Page was already unpoisoned %#lx\n", pfn);
+   unpoison_pr_info("MCE: Page was already unpoisoned %#lx\n",
+pfn, &unpoison_rs);
return 0;
}
 
if (page_count(page) > 1) {
-   pr_info("MCE: Someone grabs the hwpoison page %#lx\n", pfn);
+   unpoison_pr_info("MCE: Someone grabs the hwpoison page %#lx\n",
+pfn, &unpoison_rs);
return 0;
}
 
if (page_mapped(page)) {
-   pr_info("MCE: Someone maps the hwpoison page %#lx\n", pfn);
+   unpoison_pr_info("MCE: Someone maps the hwpoison page %#lx\n",
+pfn, &unpoison_rs);
return 0;
}
 
if (page_mapping(page)) {
-   pr_info("MCE: the hwpoison page has non-NULL mapping %#lx\n",
-   pfn);
+   unpoison_pr_info("MCE: the hwpoison page has non-NULL mapping 
%#lx\n",
+pfn, &unpoison_rs);
return 0;
}
 
@@ -1455,7 +1467,8 @@ int unpoison_memory(unsigned long pfn)
 * In such case, we yield to memory_failure() and make unpoison fail.
 */
if (!PageHuge(page) && PageTransHuge(page)) {
-   pr_info("MCE: Memory failure is now running on %#lx\n", pfn);
+   unpoison_pr_info("MCE: Memory failure is now running on %#lx\n",
+pfn, &unpoison_rs);
return 0;
}
 
@@ -1469,12 +1482,14 @@ int unpoison_memory(unsigned long pfn)
 * to the end.
 */
if (PageHuge(page)) {
-   pr_info("MCE: Memory failure is now running on free 
hugepage %#lx\n", pfn);
+   unpoison_pr_info("MCE: Memory failure is now running on 
free hugepage %#lx\n",
+pfn, &unpoison_rs);
return 0;
}
if (TestClearPageHWPoison(p))
num_poisoned_pages_dec();
-   pr_info("MCE: Software-unpoisoned free page %#lx\n", pfn);
+   unpoison_pr_info("MCE: Software-unpoisoned free page %#lx\n",
+pfn, &unpoison_rs);
return 0;
}
 
@@ -1486,7 +1501,8 @@ int unpoison_memory(unsigned long pfn)
 * the free buddy page pool.
 */
if (TestClearPageHWPoison(page)) {
-   pr_info("MCE: Software-unpoisoned page %#lx\n", pfn);
+   unpoison_pr_info("MCE: Software-unpoisoned page %#lx\n",
+pfn, &unpoison_rs);
num_poisoned_pages_sub(nr_pages);
freeit = 1;
if (PageHuge(page))
-- 
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/1] eventfd: implementation of EFD_MASK flag

[Damian Hobson-Garcia]

From: Martin Sustrik 

When implementing network protocols in user space, one has to implement
fake file descriptors to represent the sockets for the protocol.

Polling on such fake file descriptors is a problem (poll/select/epoll
accept only true file descriptors) and forces protocol implementers to use
various workarounds resulting in complex, non-standard and convoluted APIs.

More generally, ability to create full-blown file descriptors for
userspace-to-userspace signalling is missing. While eventfd(2) goes half
the way towards this goal it has follwoing shorcomings:

I.  There's no way to signal POLLPRI, POLLHUP etc.
II. There's no way to signal arbitrary combination of POLL* flags. Most
notably, simultaneous !POLLIN and !POLLOUT, which is a perfectly valid
combination for a network protocol (rx buffer is empty and tx buffer is
full), cannot be signaled using eventfd.

This patch implements new EFD_MASK flag which solves the above problems.

Additionally, to provide a way to associate user-space state with eventfd
object, it allows to attach user-space data to the file descriptor.

The semantics of EFD_MASK are as follows:

eventfd(2):

If eventfd is created with EFD_MASK flag set, it is initialised in such a
way as to signal no events on the file descriptor when it is polled on.
The 'initval' argument is ignored.

write(2):

User is allowed to write only buffers containing the following structure:

struct efd_mask {
  uint32_t events;
};

The value of 'events' should be any combination of event flags as defined
by poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified
events will be signaled when polling (select, poll, epoll) on the eventfd
is done later on.

read(2):

read is not supported and will fail with EINVAL.

select(2), poll(2) and similar:

When polling on the eventfd marked by EFD_MASK flag, all the events
specified in last written 'events' field shall be signaled.

Signed-off-by: Martin Sustrik 

[dhobs...@igel.co.jp: Rebased, and resubmitted for Linux 4.3]
Signed-off-by: Damian Hobson-Garcia 
---
 fs/eventfd.c | 102 ++-
 include/linux/eventfd.h  |  16 +--
 include/uapi/linux/eventfd.h |  39 +
 3 files changed, 132 insertions(+), 25 deletions(-)
 create mode 100644 include/uapi/linux/eventfd.h

diff --git a/fs/eventfd.c b/fs/eventfd.c
index 8d0c0df..1a6a066 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -2,6 +2,7 @@
  *  fs/eventfd.c
  *
  *  Copyright (C) 2007  Davide Libenzi 
+ *  Copyright (C) 2013  Martin Sustrik 
  *
  */
 
@@ -22,18 +23,31 @@
 #include 
 #include 
 
+#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
+#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE | EFD_MASK)
+#define EFD_MASK_VALID_EVENTS (POLLIN | POLLPRI | POLLOUT | POLLERR | POLLHUP)
+
 struct eventfd_ctx {
struct kref kref;
wait_queue_head_t wqh;
-   /*
-* Every time that a write(2) is performed on an eventfd, the
-* value of the __u64 being written is added to "count" and a
-* wakeup is performed on "wqh". A read(2) will return the "count"
-* value to userspace, and will reset "count" to zero. The kernel
-* side eventfd_signal() also, adds to the "count" counter and
-* issue a wakeup.
-*/
-   __u64 count;
+   union {
+   /*
+* Every time that a write(2) is performed on an eventfd, the
+* value of the __u64 being written is added to "count" and a
+* wakeup is performed on "wqh". A read(2) will return the
+* "count" value to userspace, and will reset "count" to zero.
+* The kernel side eventfd_signal() also, adds to the "count"
+* counter and issue a wakeup.
+*/
+   __u64 count;
+
+   /*
+* When using eventfd in EFD_MASK mode this stracture stores the
+* current events to be signaled on the eventfd (events member)
+* along with opaque user-defined data (data member).
+*/
+   struct efd_mask mask;
+   };
unsigned int flags;
 };
 
@@ -134,6 +148,14 @@ static unsigned int eventfd_poll(struct file *file, 
poll_table *wait)
return events;
 }
 
+static unsigned int eventfd_mask_poll(struct file *file, poll_table *wait)
+{
+   struct eventfd_ctx *ctx = file->private_data;
+
+   poll_wait(file, &ctx->wqh, wait);
+   return ctx->mask.events;
+}
+
 static void eventfd_ctx_do_read(struct eventfd_ctx *ctx, __u64 *cnt)
 {
*cnt = (ctx->flags & EFD_SEMAPHORE) ? 1 : ctx->count;
@@ -239,6 +261,14 @@ static ssize_t eventfd_read(struct file *file, char __user 
*buf, size_t count,
return put_user(cnt, (__u64 __user *) buf) ? -EFAULT : sizeof(cnt);
 }
 
+static ssize_t eventfd_mask_read(struct file *file, char __user *buf,
+   size_t co

[PATCH v2 0/1] Generalize poll events from eventfd

[Damian Hobson-Garcia]

Using eventfd user space can generate POLLIN/POLLOUT events but some
applications may want to generate POLLPRI/POLLERR events as well.
This patch submission aims to generalize the events generated by an
eventfd. This is a resubmission of a patch from Feb 2013[1]. The original
discussion trailed off without any conclusion, but the original author
has recently confirmed[2] that this functionality is still useful, so I
volunteered to rebase and resubmit the patch for discussion.

[1] https://lkml.org/lkml/2013/2/18/147
[2] https://lkml.org/lkml/2015/7/9/153

Changes in v2
-

* rebased on Linux v4.3-rc1
* Move file operation implementations for EFD_MASK to a seperate structure
* Remove 'data' element from efd_mask structure
* read() is no longer supported when EFD_MASK is set (fails with EINVAL)
* eventfd_ctx_fileget() now returns EINVAL when EFD_MASK is set, eliminating
  the possibility of triggering the orginal BUG_ON() macros which have now
  been removed.

Thank you,
Damian

Martin Sustrik (1):
  eventfd: implementation of EFD_MASK flag

 fs/eventfd.c | 91 ++--
 include/linux/eventfd.h  | 16 +---
 include/uapi/linux/eventfd.h | 40 +++
 3 files changed, 121 insertions(+), 26 deletions(-)
 create mode 100644 include/uapi/linux/eventfd.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jiri Olsa]

On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (perf) failed
> like this:
> 
> make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> 'tools/perf/arch/common.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'arch' failed
> make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> 'tools/perf/fs/fs.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'fs' failed
> make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> 'tools/perf/util/abspath.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'util' failed
> Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> Makefile:68: recipe for target 'all' failed
> 
> Maybe caused by commit
> 
>   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> objects")
> 
> This is an incremental build i.e. I do not do a "make clean" after doing
> the build for each tree merge (in case that matters).

it does in this case, removed header files stay in
cmd build dependency file (like in .abspath.o.cmd above)
and cause build error

build system is not smart enough yet to find out,
I was postponning fixing this for some time now,
I'll try to get this resolved asap

> 
> I have used the tip tree from next-20150915 for today.
> 
> Also, building perf seems to ignore O= on the make invocation.
> Is that expected?

hum, not sure about this one.. I'm not using it, but we have
tests for this and I thought we're ok.. I'll check

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] clk: tegra: dfll: add missing rcu_read_unlock() for error path

[Vince Hsu]

From: Vince Hsu 

The commit e770940218028c6a5927fda45f2ca9db5d9b35e0 ("clk: tegra: dfll:
Properly protect OPP list") added the rcu_read_{lock,unlock} but missed
one in the error path. So add the missing one.

Signed-off-by: Vince Hsu 
---
Hi,

I noticed the missed unlock because we had a similar fix as the commit
e77094021 in ChromeOS[1]. 

[1] https://chromium-review.googlesource.com/#/c/223661/


 drivers/clk/tegra/clk-dfll.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
index 4adff56dd0ef..c4e3a52e225b 100644
--- a/drivers/clk/tegra/clk-dfll.c
+++ b/drivers/clk/tegra/clk-dfll.c
@@ -685,8 +685,10 @@ static int find_lut_index_for_rate(struct tegra_dfll *td, 
unsigned long rate)
rcu_read_lock();
 
opp = dev_pm_opp_find_freq_ceil(td->soc->dev, &rate);
-   if (IS_ERR(opp))
+   if (IS_ERR(opp)) {
+   rcu_read_unlock();
return PTR_ERR(opp);
+   }
uv = dev_pm_opp_get_voltage(opp);
 
rcu_read_unlock();
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] KVM: nVMX: nested VPID emulation

[Wanpeng Li]

On 9/16/15 1:20 PM, Jan Kiszka wrote:

On 2015-09-16 04:36, Wanpeng Li wrote:

On 9/16/15 1:32 AM, Jan Kiszka wrote:

On 2015-09-15 12:14, Wanpeng Li wrote:

On 9/14/15 10:54 PM, Jan Kiszka wrote:

Last but not least: the guest can now easily exhaust the host's pool of
vpid by simply spawning plenty of VCPUs for L2, no? Is this acceptable
or should there be some limit?

I reuse the value of vpid02 while vpid12 changed w/ one invvpid in v2,
and the scenario which you pointed out can be avoid.

I cannot yet follow why there is no chance for L1 to consume all vpids
that the host manages in that single, global bitmap by simply spawning a
lot of nested VCPUs for some L2. What is enforcing L1 to call nested
vmclear - apparently the only way, besides destructing nested VCPUs, to
release such vpids again?

In v2, there is no direct mapping between vpid02 and vpid12, the vpid02
is per-vCPU for L0 and reused while the value of vpid12 is changed w/
one invvpid during nested vmentry. The vpid12 is allocated by L1 for L2,
so it will not influence global bitmap(for vpid01 and vpid02 allocation)
even if spawn a lot of nested vCPUs.

Ah, I see, you limit allocation to one additional host-side vpid per
VCPU, for nesting. That looks better. That also means all vpids for L2
will be folded on that single vpid in hardware, right? So the major


Exactly.


benefit comes from having separate vpids when switching between L1 and
L2, in fact.


And also when L2's vCPUs not sched in/out on L1. Btw, your review of v3 
is a great appreciated. :-)


Regards,
Wanpeng Li

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] alpha: fix build failure

[Sudip Mukherjee]

On Tue, Sep 15, 2015 at 07:26:34AM -0700, Guenter Roeck wrote:
> On 09/15/2015 06:50 AM, Sudip Mukherjee wrote:
> >On Tue, Sep 15, 2015 at 06:28:40AM -0700, Guenter Roeck wrote:
> >>On 09/15/2015 01:21 AM, Sudip Mukherjee wrote:
> >>>On Mon, Sep 14, 2015 at 02:22:08PM -0700, Guenter Roeck wrote:
> On Mon, Sep 14, 2015 at 05:19:27PM +0530, Sudip Mukherjee wrote:
> >>
> >>I am not building m32r:allmodconfig or openrisc:allmodconfig.
> >>
> >>You can always check http://server.roeck-us.net:8010/builders to see
> >>what is covered by my builds and tests.
> >ok, openrisc:defconfig and allnoconfig.
> >
> >Well, the first error on allmodconfig is:
> >drivers/vhost/vhost.c: In function 'vhost_vring_ioctl':
> >drivers/vhost/vhost.c:818:3: error: call to '__compiletime_assert_818' 
> >declared with attribute error: BUILD_BUG_ON failed: __alignof__
> >*vq->avail > VRING_AVAIL_ALIGN_SIZE
> >
> >Any hint about this one?
> >
> 
> No idea, sorry. Is that a new problem ?
I think no. Not sure though, as I have started testing these just
recently.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] ARM: sun8i: Fix A23 and A33 clock gates indices

[Chen-Yu Tsai]

On Fri, Sep 11, 2015 at 9:26 PM, Maxime Ripard
 wrote:
> Hi everyone,
>
> Here is a patch set that adds the missing clocks for the message box
> in the A33 and A23 SoCs.
>
> In order to support that properly, the addition of a new clock driver
> for the A33 has been needed, and we split the gates definition that
> was previously shared to each DTSI.
>
> Let me know what you think,
> Maxime
>
> Maxime Ripard (4):
>   clk: sunxi: Add A33 gates support
>   ARM: sun8i: Add the A33 AHB1 gates clock driver
>   ARM: sun8i: Move A23 AHB1 gates out of common DTSI
>   ARM: sun8i: A23: Add missing msgbox gate
>
>  arch/arm/boot/dts/sun8i-a23-a33.dtsi | 25 -
>  arch/arm/boot/dts/sun8i-a23.dtsi | 25 +
>  arch/arm/boot/dts/sun8i-a33.dtsi | 27 +++
>  drivers/clk/sunxi/clk-simple-gates.c |  2 ++
>  4 files changed, 54 insertions(+), 25 deletions(-)

Apart from the small issue with the second patch's commit message,
this series looks good.

Reviewed-by: Chen-Yu Tsai 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/19] staging/lustre: Remove IS_SERVER and all users

[Sudip Mukherjee]

On Tue, Sep 15, 2015 at 08:30:41PM -0400, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin 
> 
> Since the client can never be server, this is all dead code.
> 
> Signed-off-by: Oleg Drokin 
> ---
OOPS.. build fails with error:
error: ‘lsi’ undeclared (first use in this function)

reegards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.32 42/62] fixing infinite OPEN loop in 4.0 stateid recovery

[Willy Tarreau]

Hi Olga,

On Tue, Sep 15, 2015 at 02:36:06PM +, Kornievskaia, Olga wrote:
> 
> Hi Willy,
> 
> After checking with the list, I believe the course of action will be to
> correct the patch with the patch below instead of reverting it.

OK but as far as I can tell, mainline is still not fixed regarding this
issue. I can't introduce in a stable branch a fix which is not yet in
mainline. Thus I'll simply remove the patch from this series and will
merge both patches in a future series once your fix reaches mainline.

Note that I picked this fix from 3.2 (commit ef8500b18fc4bb) so my
understanding is that this patch needs to be reverted from 3.2 as well
for the time being ?

Thanks very much for the detailed investigations!

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: slab: convert slab_is_available to boolean

[Pekka Enberg]

On 9/15/15 8:50 PM, Denis Kirjanov wrote:

A good one candidate to return a boolean result

Signed-off-by: Denis Kirjanov 


Reviewed-by: Pekka Enberg 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/5] dt/bindings: bcm2835: add binding documentation for bcm2835-aux

[Martin Sperl]

> On 16.09.2015, at 06:12, Stephen Warren  wrote:
> 
> On 09/04/2015 01:26 AM, Martin Sperl wrote:
>> 
>>> On 26.08.2015, at 03:44, Stephen Warren  wrote:
>>> 
>>> On 08/24/2015 02:40 AM, ker...@martin.sperl.org wrote:
>>> 
 +Example:
 +
 +aux_enable: aux_enable@0x7e215004 {
 +  compatible = "bcrm,bcm2835-aux";
 +  reg = <0x7e215004 0x04>;
>>> 
>>> I'd expect that to be <0x7e215000 0x8>;
>> 
>> The reason is that we just handle enable with this driver,
>> which just requires access to the 0x7e215004 register.
>> 
>> The 0x7e215000 register (interrupt mask) could be used by a
>> cascaded interrupt-controller, but as the spi and uart drivers
>> can run with shared interrupts this is not a necessity.
> 
> The DT is supposed to describe the HW, not any particular SW's use of
> the HW. If the HW block has 2 registers, so must the DT reg property.

Please look at V6 of the patch-series, that uses Erics clock-patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.32 00/62] 2.6.32.68-longterm review

[Willy Tarreau]

On Tue, Sep 15, 2015 at 01:06:31PM +0100, Ben Hutchings wrote:
> On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > This is the start of the longterm review cycle for the 2.6.32.68 release.
> > All patches will be posted as a response to this one. If anyone has any
> > issue with these being applied, please let me know. If anyone is a
> > maintainer of the proper subsystem, and wants to add a Signed-off-by: line
> > to the patch, please respond with it. If anyone thinks some important
> > patches are missing and should be added prior to the release, please
> > report them quickly with their respective mainline commit IDs.
> > 
> > Responses should be made by Sat Sep 19 00:56:05 CEST 2015.
> > Anything received after that time might be too late. If someone
> > wants a bit more time for a deeper review, please let me know.
> > 
> > NOTE: 2.6.32 is approaching end of support. There will probably be one
> > or maybe two other versions issued in the next 3-6 months, and that will
> > be all, at least for me. Adding to this the time it can take to validate
> > and deploy in some environments, it probably makes sense to start to
> > think about switching to another longterm branch. 3.2 and 3.4 are good
> > candidates for those seeking rock-solid versions. Longterm branches and
> > their projected EOLs are listed here :
> > 
> >  https://www.kernel.org/category/releases.html
> > 
> > The whole patch series can be found in one patch at :
> >  
> > https://kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.68-rc1.gz
> > 
> > The shortlog and diffstat are appended below.
> [...]
> 
> Patches 3 "crypto: testmgr - update LZO compression test vectors",
> 58 "dccp: fix auto-loading of dccp(_probe)",
> 60 "dccp: catch failed request_module call in dccp_probe init",
> 61 "dmaengine: fix missing cnt in ?: in dmatest" and
> 62 "ipv6: Fix return of xfrm6_tunnel_rcv()" have a git cherry-pick
> line in the commit mesage rather than the usual "commit xxx upstream."

Yes indeed, I cherry-picked them after the first build attempts when I
discovered build warnings. I'll add the line by hand.

> Patches 10 and 59 didn't reach me at all, though I can guess from its
> neighbours that 59 is cherry-picked from commit
> d984e6197ecd2babc1537f42dc1e676133005cda upstream.

Yep. Sorry for this, I'm attaching both of them to this e-mail, and
will add the upstream commit line to 59 as well.

Thanks,
Willy

>From 3f3fe288bb34818096135a93062ab588acbda269 Mon Sep 17 00:00:00 2001
From: Jan Kara 
Date: Mon, 12 Dec 2011 15:13:50 +0100
Subject: udf: Treat symlink component of type 2 as /
MIME-Version: 1.0
Content-Type: text/plain; charset=latin1
Content-Transfer-Encoding: 8bit

From: Jan Kara 

commit fef2e9f3301934773e4f1b3cc5c7bffb119346b8 upstream.

Currently, we ignore symlink component of type 2. But mkisofs and other OS'
seem to treat it as / so do the same for compatibility.

Reported-by: "Gábor S." 
Signed-off-by: Jan Kara 
[bwh: Needed for the following fix]
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau 
---
 fs/udf/symlink.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index e28a902..2d60484 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -43,10 +43,16 @@ static void udf_pc_to_char(struct super_block *sb, char 
*from, int fromlen,
pc = (struct pathComponent *)(from + elen);
switch (pc->componentType) {
case 1:
-   if (pc->lengthComponentIdent == 0) {
-   p = to;
-   *p++ = '/';
-   }
+   /*
+* Symlink points to some place which should be agreed
+* upon between originator and receiver of the media. 
Ignore.
+*/
+   if (pc->lengthComponentIdent > 0)
+   break;
+   /* Fall through */
+   case 2:
+   p = to;
+   *p++ = '/';
break;
case 3:
memcpy(p, "../", 3);
-- 
1.7.12.2.21.g234cd45.dirty

>From 361fb30bc6abac898b3815bef9e9a56a95f46059 Mon Sep 17 00:00:00 2001
From: "David S. Miller" 
Date: Thu, 1 Dec 2011 14:45:49 -0500
Subject: dccp: Fix compile warning in probe code.
MIME-Version: 1.0
Content-Type: text/plain; charset=latin1
Content-Transfer-Encoding: 8bit

From: "David S. Miller" 

Commit 1386be55e32a3c5d8ef4a2b243c530a7b664c02c ("dccp: fix
auto-loading of dccp(_probe)") fixed a bug but created a new
compiler warning:

net/dccp/probe.c: In function ‘dccpprobe_init’:
net/dccp/probe.c:166:2: warning: the omitted middle operand in ?: will always 
be ‘true’, suggest explicit middle operand [-Wparentheses]

try_then_request_module() is built for situations where the
"existence" test is some lookup fun

Re: [PATCH] KVM: nVMX: nested VPID emulation

[Jan Kiszka]

On 2015-09-16 04:36, Wanpeng Li wrote:
> On 9/16/15 1:32 AM, Jan Kiszka wrote:
>> On 2015-09-15 12:14, Wanpeng Li wrote:
>>> On 9/14/15 10:54 PM, Jan Kiszka wrote:
 Last but not least: the guest can now easily exhaust the host's pool of
 vpid by simply spawning plenty of VCPUs for L2, no? Is this acceptable
 or should there be some limit?
>>> I reuse the value of vpid02 while vpid12 changed w/ one invvpid in v2,
>>> and the scenario which you pointed out can be avoid.
>> I cannot yet follow why there is no chance for L1 to consume all vpids
>> that the host manages in that single, global bitmap by simply spawning a
>> lot of nested VCPUs for some L2. What is enforcing L1 to call nested
>> vmclear - apparently the only way, besides destructing nested VCPUs, to
>> release such vpids again?
> 
> In v2, there is no direct mapping between vpid02 and vpid12, the vpid02
> is per-vCPU for L0 and reused while the value of vpid12 is changed w/
> one invvpid during nested vmentry. The vpid12 is allocated by L1 for L2,
> so it will not influence global bitmap(for vpid01 and vpid02 allocation)
> even if spawn a lot of nested vCPUs.

Ah, I see, you limit allocation to one additional host-side vpid per
VCPU, for nesting. That looks better. That also means all vpids for L2
will be folded on that single vpid in hardware, right? So the major
benefit comes from having separate vpids when switching between L1 and
L2, in fact.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.32 36/62] MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard.

[Willy Tarreau]

On Tue, Sep 15, 2015 at 12:37:21PM +0100, Ben Hutchings wrote:
> > From: Ralf Baechle 
> > 
> > commit f05ff43355e6997c18f82ddcee370a6e5f8643ce upstream.
> > 
> > This is no longer needed with the fixed, new and improved definition
> > of cpu_has_mips_r2_exec_hazard in .
> [...]
> 
> This needs to be dropped along with the previous patch.

Good catch indeed. Done.
Thanks,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] ARM:dts:sun7i: Add keypad clk node

[Maxime Ripard]

On Wed, Sep 16, 2015 at 12:05:54AM +1000, yassinjaf...@gmail.com wrote:
> From: Yassin Jaffer 
> 
> This patch add support to the keypad clock on sun7i
> 
> Signed-off-by: Yassin Jaffer 

Applied, thanks!

Maxime

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


signature.asc
Description: Digital signature

Re: [Bugfix 0/3] Convert eata driver to a normal PCI device driver

[Jiang Liu]

On 2015/9/15 15:19, Arthur Marsh wrote:
> 
> 
> Jiang Liu wrote on 15/09/15 12:01:
> 
>> HI Arthur,
>> Really appreciate your help to test the patches. That's
>> a good sign we have moved forward a bit:)
>> For kexec, it's always challenging to me. So could you
>> please help to provide full dmesg logs with working kernels
>> so I could try to figure out the order among scsi and PCI devices.
>> It may be shutdown order related.
>> Thanks!
>> Gerry
> 
> OK, attached is the dmesg output from the 4.2.0 kernel where kexec worked.
Hi Arthur,
Could you please also help to capture the log messages
of kexec, I need to those log messages to figure out the order
to shutdown PCI devices and scsi devices during kexec.
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: wlan-ng: prism2fw: coding style: Fixed too long lines.

[Sudip Mukherjee]

On Tue, Sep 15, 2015 at 08:09:54PM -0300, Marcos Canán wrote:
> This is a patch to the prism2fw.c file that fixes
> too long lines.
> 
> Signed-off-by: Marcos Canán 
> ---
This will not apply because of cfa6954ced97 ("staging: wlan-ng: fix long line").
Which tree you have used?

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell 
Date: Wed, 16 Sep 2015 11:30:53 +1000

> I have added the following fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Wed, 16 Sep 2015 11:10:16 +1000
> Subject: [PATCH] cdc: add header guards
> 
> Signed-off-by: Stephen Rothwell 

Applied, thanks Stephen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

[Parav Pandit]

Hi Jason, Sean, Tejun,

I am in process of defining new approach, design based on the feedback
given here for new RDMA cgroup from all of you.
I have also collected feedback from Liran yesterday and ORNL folks too.

Soon I will post the new approach, high level APIs and functionality
for review before submitting actual implementation.

Regards,
Parav Pandit

On Tue, Sep 15, 2015 at 9:15 AM, Jason Gunthorpe
 wrote:
> On Tue, Sep 15, 2015 at 08:38:54AM +0530, Parav Pandit wrote:
>
>> As you precisely described, about wild ratio,
>> we are asking vendor driver (bottom most layer) to statically define
>> what the resource pool is, without telling him which application are
>> we going to run to use those pool.
>> Therefore vendor layer cannot ever define "right" resource pool.
>
> No, I'm saying the resource pool is *well defined* and *fixed* by each
> hardware.
>
> The only question is how do we expose the N resource limits, the list
> of which is totally vendor specific.
>


>> rdma cgroup will allow us to run post 512 or 1024 containers without
>> using PCIe SR-IOV, without creating any vendor specific resource
>> pools.
>
> If you ignore any vendor specific resource limits then you've just
> left open a hole, a wayward container can exhaust all others - so what
> was the point of doing all this work?
>
> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: wilc1000: Removed curly braces

[Sudip Mukherjee]

On Tue, Sep 15, 2015 at 07:24:00PM +0530, Aparna Karuthodi wrote:
> Removed the curly braces of a single statement if block to remove a
> coding style warning detected by checkpatch.
> The warning is given below:
> WARNING: braces {} are not necessary for single statement blocks
> 
> Signed-off-by: Aparna Karuthodi 
> ---
This will not apply any more due to recent modification to this file.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [4.2] commit d59cfc09c32 (sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem) causes regression for libvirt/kvm

[Paul E. McKenney]

On Tue, Sep 15, 2015 at 09:24:15PM -0400, Tejun Heo wrote:
> Hello, Paul.
> 
> On Tue, Sep 15, 2015 at 04:38:18PM -0700, Paul E. McKenney wrote:
> > Well, the decision as to what is too big for -stable is owned by the
> > -stable maintainers, not by me.
> 
> Is it tho?  Usually the subsystem maintainer knows the best and has
> most say in it.  I was mostly curious whether you'd think that the
> changes would be too risky.  If not, great.

I do hope that they would listen to what I thought about it, but at
the end of the day, it is the -stable maintainers who pull a given
patch, or don't.

> > I am suggesting trying the options and seeing what works best, then
> > working to convince people as needed.
> 
> Yeah, sure thing.  Let's wait for Christian.

Indeed.  Is there enough benefit to risk jamming this thing into 4.3?
I believe that 4.4 should be a no-brainer.

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Viresh Kumar]

On 10-09-15, 09:31, Lee Jones wrote:
> I think you answered your own question.
> 
> No users == !ABI == Strip it out.

Okay, as I have delayed things enough for you, didn't wanted to do
that anymore. And so worked on it despite very tight schedule :)

Below is the refreshed binding changes (I have split that into 3
patches, but kept the diff here for simplicity).

Other than that, all code changes you need to test your driver are
pushed here:

https://git.linaro.org/people/viresh.kumar/linux.git 
opp/supported-hw-prop-name-v1

I am not gonna post the patches to the lists, until the time existing
patches get reviewed.

-- 
viresh

-8<-
diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
b/Documentation/devicetree/bindings/opp/opp.txt
index 719603b87353..b652d0403e93 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -45,21 +45,10 @@ Devices supporting OPPs must set their 
"operating-points-v2" property with
 phandle to a OPP table in their DT node. The OPP core will use this phandle to
 find the operating points for the device.
 
-Devices may want to choose OPP tables at runtime and so can provide a list of
-phandles here. But only *one* of them should be chosen at runtime. This must be
-accompanied by a corresponding "operating-points-names" property, to uniquely
-identify the OPP tables.
-
 If required, this can be extended for SoC vendor specfic bindings. Such 
bindings
 should be documented as 
Documentation/devicetree/bindings/power/-opp.txt
 and should have a compatible description like: "operating-points-v2-".
 
-Optional properties:
-- operating-points-names: Names of OPP tables (required if multiple OPP
-  tables are present), to uniquely identify them. The same list must be present
-  for all the CPUs which are sharing clock/voltage rails and hence the OPP
-  tables.
-
 * OPP Table Node
 
 This describes the OPPs belonging to a device. This node can have following
@@ -117,6 +106,14 @@ properties.
   Entries for multiple regulators must be present in the same order as their
   names are present in 'supply-names' property of the opp-table.
 
+- opp-microvolt-: Named opp-microvolt property. This is exactly similar 
to
+  the above opp-microvolt property, but allows multiple voltage ranges to be
+  provided for the same OPP. At runtime, the platform can pick a  and
+  matching opp-microvolt- property will be enabled for all OPPs. If the
+  platform doesn't pick a specific  or the  doesn't match with any
+  opp-microvolt- properties, then opp-microvolt property shall be used, 
if
+  present.
+
 - opp-microamp: The maximum current drawn by the device in microamperes
   considering system specific parameters (such as transients, process, aging,
   maximum operating temperature range etc.) as necessary. This may be used to
@@ -131,6 +128,9 @@ properties.
   as zero for them. If it isn't required for any regulator, then this property
   need not be present.
 
+- opp-microamp-: Named opp-microamp property. Similar to
+  opp-microvolt- property, but for microamp instead.
+
 - clock-latency-ns: Specifies the maximum possible transition latency (in
   nanoseconds) for switching to this OPP from any other OPP.
 
@@ -139,9 +139,27 @@ properties.
   frequency for a short duration of time limited by the device's power, current
   and thermal limits.
 
+- turbo-mode-: Named turbo-mode property. Similar to opp-microvolt-
+  property, but for turbo mode instead.
+
 - opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
   the table should have this.
 
+- opp-suspend-: Named opp-suspend property. Similar to
+  opp-microvolt- property, but for suspend opp instead.
+
+- opp-supported-hw: User defined array containing a hierarchy of hardware
+  version numbers, supported by the OPP. For example: a platform with hierarchy
+  of three levels of versions (A, B and C), this field should be like ,
+  where X corresponds to Version hierarchy A, Y corresponds to version 
hierarchy
+  B and Z corresponds to version hierarchy C.
+
+  Each level of hierarchy is represented by a 32 bit value, and so there can be
+  only 32 different supported version per hierarchy. i.e. 1 bit per version. A
+  value of 0x will enable the OPP for all versions for that hierarchy
+  level. And a value of 0x will disable the OPP completely, and so we
+  never want that to happen.
+
 - status: Marks the node enabled/disabled.
 
 Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
@@ -443,7 +461,8 @@ Example 4: Handling multiple regulators
};
 };
 
-Example 5: Multiple OPP tables
+Example 5: opp-supported-hw
+(example: three level hierarchy of versions: cuts, substrate and process)
 
 / {
cpus {
@@ -452,40 +471,84 @@ Example 5: Multiple OPP tables
...
 
cpu-supply = <&cpu_supply>
-   oper

[PATCH] PCI: Relax function 0 VPD test and relocate

[Alex Williamson]

When we quirk a device with PCI_DEV_FLAGS_VPD_REF_F0 we're expecting
to find a device where all the functions are identical.  If we don't
find that, we don't make VPD accessible through pci_vpd_ops.  That
means that if we quirk devices we shouldn't, we filter them out by
hiding VPD entirely rather than allowing default access.  Instead, we
can flip this around to only quirk devices that match a slightly more
rigorous test in the quirk, allowing regular access for anything else.

Tests for the multifunction flag are removed since a) function 0 and
the function under test are clearly a multifunction device if we're
scanning a non-zero function in the same slot and b) at this point the
flag is only set in the device under test if the multifunction bit is
set in the PCI HEADER, which is a point of interpretation for the PCI
spec.

Signed-off-by: Alex Williamson 
---

This is potentially another stable candiate since we're continuing to
iterate on 932c435caba8, but since we don't actually know of a device
where VPD is blocked (we don't think my Skylake example actually
supports VPD), I'm not including it.  I would support it if requested
though.

 drivers/pci/access.c |   22 --
 drivers/pci/quirks.c |   20 ++--
 2 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 5a5f0a7..59ac36f 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -475,23 +475,6 @@ static const struct pci_vpd_ops pci_vpd_f0_ops = {
.release = pci_vpd_pci22_release,
 };
 
-static int pci_vpd_f0_dev_check(struct pci_dev *dev)
-{
-   struct pci_dev *tdev = pci_get_slot(dev->bus,
-   PCI_DEVFN(PCI_SLOT(dev->devfn), 0));
-   int ret = 0;
-
-   if (!tdev)
-   return -ENODEV;
-   if (!tdev->vpd || !tdev->multifunction ||
-   dev->class != tdev->class || dev->vendor != tdev->vendor ||
-   dev->device != tdev->device)
-   ret = -ENODEV;
-
-   pci_dev_put(tdev);
-   return ret;
-}
-
 int pci_vpd_pci22_init(struct pci_dev *dev)
 {
struct pci_vpd_pci22 *vpd;
@@ -500,12 +483,7 @@ int pci_vpd_pci22_init(struct pci_dev *dev)
cap = pci_find_capability(dev, PCI_CAP_ID_VPD);
if (!cap)
return -ENODEV;
-   if (dev->dev_flags & PCI_DEV_FLAGS_VPD_REF_F0) {
-   int ret = pci_vpd_f0_dev_check(dev);
 
-   if (ret)
-   return ret;
-   }
vpd = kzalloc(sizeof(*vpd), GFP_ATOMIC);
if (!vpd)
return -ENOMEM;
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 6a30252..b03373f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1907,11 +1907,27 @@ static void quirk_netmos(struct pci_dev *dev)
 DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_NETMOS, PCI_ANY_ID,
 PCI_CLASS_COMMUNICATION_SERIAL, 8, quirk_netmos);
 
+/*
+ * Quirk non-zero PCI functions to route VPD access through function 0 for
+ * devices that share VPD resources between functions.  The functions are
+ * expected to be identical devices.
+ */
 static void quirk_f0_vpd_link(struct pci_dev *dev)
 {
-   if (!dev->multifunction || !PCI_FUNC(dev->devfn))
+   struct pci_dev *f0;
+
+   if (!PCI_FUNC(dev->devfn))
return;
-   dev->dev_flags |= PCI_DEV_FLAGS_VPD_REF_F0;
+
+   f0 = pci_get_slot(dev->bus, PCI_DEVFN(PCI_SLOT(dev->devfn), 0));
+   if (!f0)
+   return;
+
+   if (f0->vpd && dev->class == f0->class &&
+   dev->vendor == f0->vendor && dev->device == f0->device)
+   dev->dev_flags |= PCI_DEV_FLAGS_VPD_REF_F0;
+
+   pci_dev_put(f0);
 }
 DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
  PCI_CLASS_NETWORK_ETHERNET, 8, quirk_f0_vpd_link);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v3 3/3] arm/arm64: fix a migrating irq bug when hotplug cpu

[Yang Yingliang]

When cpu is disabled, all irqs will be migratged to another cpu.
In some cases, a new affinity is different, it needed to be coppied
to irq's affinity. But if the type of irq is LPI, it's affinity will
not be coppied because of irq_set_affinity's return value. Fix it by
using irq_do_set_affinity.

And migrating interrupts is a core code matter, so move the code to
kernel/irq/migration.c and select CONFIG_GENERIC_IRQ_MIGRATION when
CONFIG_HOTPLUG_CPU and CONFIG_SMP is enabled.

Cc: Jiang Liu 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: Will Deacon 
Cc: Russell King - ARM Linux 
Cc: Hanjun Guo 
Signed-off-by: Yang Yingliang 
---
 arch/arm/Kconfig |  1 +
 arch/arm/include/asm/irq.h   |  1 -
 arch/arm/kernel/irq.c| 62 -
 arch/arm64/Kconfig   |  1 +
 arch/arm64/include/asm/irq.h |  1 -
 arch/arm64/kernel/irq.c  | 62 -
 include/linux/irq.h  |  4 +++
 kernel/irq/migration.c   | 66 
 8 files changed, 72 insertions(+), 126 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 72ad724..d70ddd5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -22,6 +22,7 @@ config ARM
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_PROBE
+   select GENERIC_IRQ_MIGRATION if SMP && HOTPLUG_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
select GENERIC_PCI_IOMAP
diff --git a/arch/arm/include/asm/irq.h b/arch/arm/include/asm/irq.h
index be1d07d..882bf98 100644
--- a/arch/arm/include/asm/irq.h
+++ b/arch/arm/include/asm/irq.h
@@ -24,7 +24,6 @@
 #ifndef __ASSEMBLY__
 struct irqaction;
 struct pt_regs;
-extern void migrate_irqs(void);
 
 extern void asm_do_IRQ(unsigned int, struct pt_regs *);
 void handle_IRQ(unsigned int, struct pt_regs *);
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 5ff4826..78abea8 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -136,64 +135,3 @@ int __init arch_probe_nr_irqs(void)
return nr_irqs;
 }
 #endif
-
-#ifdef CONFIG_HOTPLUG_CPU
-static bool migrate_one_irq(struct irq_desc *desc)
-{
-   struct irq_data *d = irq_desc_get_irq_data(desc);
-   const struct cpumask *affinity = irq_data_get_affinity_mask(d);
-   struct irq_chip *c;
-   bool ret = false;
-
-   /*
-* If this is a per-CPU interrupt, or the affinity does not
-* include this CPU, then we have nothing to do.
-*/
-   if (irqd_is_per_cpu(d) || !cpumask_test_cpu(smp_processor_id(), 
affinity))
-   return false;
-
-   if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
-   affinity = cpu_online_mask;
-   ret = true;
-   }
-
-   c = irq_data_get_irq_chip(d);
-   if (!c->irq_set_affinity)
-   pr_debug("IRQ%u: unable to set affinity\n", d->irq);
-   else if (c->irq_set_affinity(d, affinity, false) == IRQ_SET_MASK_OK && 
ret)
-   cpumask_copy(irq_data_get_affinity_mask(d), affinity);
-
-   return ret;
-}
-
-/*
- * The current CPU has been marked offline.  Migrate IRQs off this CPU.
- * If the affinity settings do not allow other CPUs, force them onto any
- * available CPU.
- *
- * Note: we must iterate over all IRQs, whether they have an attached
- * action structure or not, as we need to get chained interrupts too.
- */
-void migrate_irqs(void)
-{
-   unsigned int i;
-   struct irq_desc *desc;
-   unsigned long flags;
-
-   local_irq_save(flags);
-
-   for_each_irq_desc(i, desc) {
-   bool affinity_broken;
-
-   raw_spin_lock(&desc->lock);
-   affinity_broken = migrate_one_irq(desc);
-   raw_spin_unlock(&desc->lock);
-
-   if (affinity_broken)
-   pr_warn_ratelimited("IRQ%u no longer affine to CPU%u\n",
-   i, smp_processor_id());
-   }
-
-   local_irq_restore(flags);
-}
-#endif /* CONFIG_HOTPLUG_CPU */
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7d95663..70d5b23 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -33,6 +33,7 @@ config ARM64
select GENERIC_CPU_AUTOPROBE
select GENERIC_EARLY_IOREMAP
select GENERIC_IRQ_PROBE
+   select GENERIC_IRQ_MIGRATION if SMP && HOTPLUG_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
select GENERIC_PCI_IOMAP
diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
index bbb251b..0916929 100644
--- a/arch/arm64/include/asm/irq.h
+++ b/arch/arm64/include/asm/irq.h
@@ -7,7 +7,6 @@
 
 struct pt_regs;
 
-extern void migrate_irqs(void);
 extern void set_handle_irq(void (*handle_irq)(struct pt_regs *));
 
 static 

Re: [PATCH v4 3/5] dt/bindings: bcm2835: add binding documentation for bcm2835-aux

[Stephen Warren]

On 09/04/2015 01:26 AM, Martin Sperl wrote:
> 
>> On 26.08.2015, at 03:44, Stephen Warren  wrote:
>>
>> On 08/24/2015 02:40 AM, ker...@martin.sperl.org wrote:
>>
>>> +Example:
>>> +
>>> +aux_enable: aux_enable@0x7e215004 {
>>> +   compatible = "bcrm,bcm2835-aux";
>>> +   reg = <0x7e215004 0x04>;
>>
>> I'd expect that to be <0x7e215000 0x8>;
> 
> The reason is that we just handle enable with this driver,
> which just requires access to the 0x7e215004 register.
> 
> The 0x7e215000 register (interrupt mask) could be used by a
> cascaded interrupt-controller, but as the spi and uart drivers
> can run with shared interrupts this is not a necessity.

The DT is supposed to describe the HW, not any particular SW's use of
the HW. If the HW block has 2 registers, so must the DT reg property.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v3 2/3] ia64: rename migrate_irqs() to avoid compiling error

[Yang Yingliang]

To avoid multi-declaration error after adding migrate_irqs into
kernel/irq/migration.c, rename migrate_irqs() to move_irqs().

Cc: Jiang Liu 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: Will Deacon 
Cc: Russell King - ARM Linux 
Cc: Hanjun Guo 
Signed-off-by: Yang Yingliang 
---
 arch/ia64/kernel/irq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/ia64/kernel/irq.c b/arch/ia64/kernel/irq.c
index de4fc00..005f339 100644
--- a/arch/ia64/kernel/irq.c
+++ b/arch/ia64/kernel/irq.c
@@ -98,7 +98,7 @@ unsigned int vectors_in_migration[NR_IRQS];
  * Since cpu_online_mask is already updated, we just need to check for
  * affinity that has zeros
  */
-static void migrate_irqs(void)
+static void move_irqs(void)
 {
int irq, new_cpu;
 
@@ -167,7 +167,7 @@ void fixup_irqs(void)
 * Phase 1: Locate IRQs bound to this cpu and
 * relocate them for cpu removal.
 */
-   migrate_irqs();
+   move_irqs();
 
/*
 * Phase 2: Perform interrupt processing for all entries reported in
-- 
2.5.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v3 0/3] arm/arm64: fix a migrating irq bug when hotplug cpu

[Yang Yingliang]

Changes in v3:
 - introduce config GENERIC_IRQ_MIGRATION for compiling migration.c
 - rename migrate_irqs in arch/ia64/kernel/irq.c to avoid compiling error

Changes in v2:
 - use the exiting helper to set IRQD_MOVE_PCNTXT flag
 - use for_each_active_irq() instead of for_each_irq_desc()
 - add some warn messages when affinity is null or do set affinity failed


Hi All,

There is a bug:

When cpu is disabled, all irqs will be migratged to another cpu.
In some cases, a new affinity is different, it needed to be coppied
to irq's affinity. But if the type of irq is LPI, it's affinity will
not be coppied because of irq_set_affinity's return value.



As Marc and Will suggested, I refactor the arm/arm64 migrating interrupts
code and fix the migrating irq bug while cpu is offline.

I'm trying let the core code do the migrating interrupts matter. 
kernel/irq/migration.c
depends on CONFIG_GENERIC_PENDING_IRQ, so I introduce config 
GENERIC_IRQ_MIGRATION for
compiling migration.c. On ia64, there is a migrate_irqs() in 
arch/ia64/kernel/irq.c,
rename it to avoid compiling error.

With the above preparation, move the migrating interrupts code into 
kernel/irq/migration.c
and fix the bug by using irq_do_set_affinity().

Cc: Jiang Liu 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: Will Deacon 
Cc: Russell King - ARM Linux 
Cc: Hanjun Guo 

Yang Yingliang (3):
  genirq: introduce CONFIG_GENERIC_IRQ_MIGRATION
  ia64: rename migrate_irqs() to avoid compiling error
  arm/arm64: fix a migrating irq bug when hotplug cpu

 arch/arc/Kconfig |  1 +
 arch/arm/Kconfig |  1 +
 arch/arm/include/asm/irq.h   |  1 -
 arch/arm/kernel/irq.c| 62 
 arch/arm64/Kconfig   |  1 +
 arch/arm64/include/asm/irq.h |  1 -
 arch/arm64/kernel/irq.c  | 62 
 arch/hexagon/Kconfig |  1 +
 arch/ia64/Kconfig|  1 +
 arch/ia64/kernel/irq.c   |  4 +--
 arch/tile/Kconfig|  1 +
 arch/x86/Kconfig |  1 +
 include/linux/irq.h  |  4 +++
 kernel/irq/Kconfig   |  4 +++
 kernel/irq/Makefile  |  2 +-
 kernel/irq/migration.c   | 68 
 16 files changed, 86 insertions(+), 129 deletions(-)

-- 
2.5.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v3 1/3] genirq: introduce CONFIG_GENERIC_IRQ_MIGRATION

[Yang Yingliang]

Introduce a more general config for compile kernel/irq/migration.c.
Move the CONFIG_GENERIC_PENDING_IRQ into migration.c. So we can
move other migration interrupts code into migration.c without
select CONFIG_GENERIC_PENDING_IRQ.

Cc: Jiang Liu 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: Will Deacon 
Cc: Russell King - ARM Linux 
Cc: Hanjun Guo 
Signed-off-by: Yang Yingliang 
---
 arch/arc/Kconfig   | 1 +
 arch/hexagon/Kconfig   | 1 +
 arch/ia64/Kconfig  | 1 +
 arch/tile/Kconfig  | 1 +
 arch/x86/Kconfig   | 1 +
 kernel/irq/Kconfig | 4 
 kernel/irq/Makefile| 2 +-
 kernel/irq/migration.c | 2 ++
 8 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 78c0621..4133070 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -20,6 +20,7 @@ config ARC
# for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
select GENERIC_IRQ_SHOW
select GENERIC_PENDING_IRQ if SMP
+   select GENERIC_IRQ_MIGRATION if SMP
select GENERIC_SMP_IDLE_THREAD
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 4dc89d1..18d3255 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -12,6 +12,7 @@ config HEXAGON
# select ARCH_REQUIRE_GPIOLIB
# select HAVE_CLK
# select GENERIC_PENDING_IRQ if SMP
+   # select GENERIC_IRQ_MIGRATION if SMP
select GENERIC_ATOMIC64
select HAVE_PERF_EVENTS
# GENERIC_ALLOCATOR is used by dma_alloc_coherent()
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index eb0249e..e48c2c8 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -37,6 +37,7 @@ config IA64
select ARCH_DISCARD_MEMBLOCK
select GENERIC_IRQ_PROBE
select GENERIC_PENDING_IRQ if SMP
+   select GENERIC_IRQ_MIGRATION if SMP
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_LEGACY
select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 106c21b..bf8b059 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -14,6 +14,7 @@ config TILE
select HAVE_DEBUG_KMEMLEAK
select GENERIC_IRQ_PROBE
select GENERIC_PENDING_IRQ if SMP
+   select GENERIC_IRQ_MIGRATION if SMP
select GENERIC_IRQ_SHOW
select HAVE_DEBUG_BUGVERBOSE
select VIRT_TO_BUS
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7aef2d5..a217a23 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -68,6 +68,7 @@ config X86
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
select GENERIC_PENDING_IRQ  if SMP
+   select GENERIC_IRQ_MIGRATIONif SMP
select GENERIC_SMP_IDLE_THREAD
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index 9a76e3b..530c54a 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -30,6 +30,10 @@ config GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
 config GENERIC_PENDING_IRQ
bool
 
+# Support for generic irq migration
+config GENERIC_IRQ_MIGRATION
+   bool
+
 # Alpha specific irq affinity mechanism
 config AUTO_IRQ_AFFINITY
bool
diff --git a/kernel/irq/Makefile b/kernel/irq/Makefile
index d121235..bdd31b7 100644
--- a/kernel/irq/Makefile
+++ b/kernel/irq/Makefile
@@ -4,6 +4,6 @@ obj-$(CONFIG_GENERIC_IRQ_CHIP) += generic-chip.o
 obj-$(CONFIG_GENERIC_IRQ_PROBE) += autoprobe.o
 obj-$(CONFIG_IRQ_DOMAIN) += irqdomain.o
 obj-$(CONFIG_PROC_FS) += proc.o
-obj-$(CONFIG_GENERIC_PENDING_IRQ) += migration.o
+obj-$(CONFIG_GENERIC_IRQ_MIGRATION) += migration.o
 obj-$(CONFIG_PM_SLEEP) += pm.o
 obj-$(CONFIG_GENERIC_MSI_IRQ) += msi.o
diff --git a/kernel/irq/migration.c b/kernel/irq/migration.c
index 37ddb7b..1ff2b77 100644
--- a/kernel/irq/migration.c
+++ b/kernel/irq/migration.c
@@ -4,6 +4,7 @@
 
 #include "internals.h"
 
+#ifdef CONFIG_GENERIC_PENDING_IRQ
 void irq_move_masked_irq(struct irq_data *idata)
 {
struct irq_desc *desc = irq_data_to_desc(idata);
@@ -77,3 +78,4 @@ void irq_move_irq(struct irq_data *idata)
if (!masked)
idata->chip->irq_unmask(idata);
 }
+#endif
-- 
2.5.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] KVM: nVMX: enhance allocate/free_vpid to handle shadow vpid

[Wanpeng Li]

On 9/15/15 8:54 PM, Paolo Bonzini wrote:


On 15/09/2015 12:30, Wanpeng Li wrote:

+   if (!nested) {
+   vpid = find_first_zero_bit(vmx_vpid_bitmap, VMX_NR_VPIDS);
+   if (vpid < VMX_NR_VPIDS) {
vmx->vpid = vpid;
__set_bit(vpid, vmx_vpid_bitmap);
+   }
+   } else {
+   vpid = find_first_zero_bit(vmx_vpid_bitmap, VMX_NR_VPIDS);
+   if (vpid < VMX_NR_VPIDS) {
+   vmx->nested.vpid02 = vpid;
+   __set_bit(vpid, vmx_vpid_bitmap);
+   }

Messy indentation, and a lot of duplicate code.  Can you instead have
(which I think was Jan's suggestion too):

static int allocate_vpid(void);
static void free_vpid(int vpid);


I see, done in v3.



That said, I like the simple solution to the "too many VPIDs for each L1
VCPU" processor.


Thanks. :-)

Regards,
Wanpeng Li

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm: rpi: Device tree modifications for U-Boot

[Stephen Warren]

On 08/28/2015 11:27 AM, Simon Glass wrote:
> Hi Rob,
> 
> On 25 August 2015 at 10:22, Rob Herring  wrote:
>> On Sat, Aug 15, 2015 at 8:46 AM, Simon Glass  wrote:
>>> Hi Rob,
>>>
>>> On 14 August 2015 at 14:29, Rob Herring  wrote:
 On Fri, Aug 14, 2015 at 1:34 PM, Simon Glass  wrote:
> -linux-tegra
>
> Hi,
>
> On 12 August 2015 at 07:21, Simon Glass  wrote:
>> Hi Lucas,
>>
>> On 11 August 2015 at 11:05, Lucas Stach  wrote:
>>> Hi Simon,
>>>
>>> why did you send this to the Tegra ML?
>>>
>>> Am Dienstag, den 11.08.2015, 08:25 -0600 schrieb Simon Glass:
 This updates the device tree from the kernel version to something 
 suitable
 for U-Boot:

 - Add stdout-path alias for console
 - Mark the /soc node to be available pre-relocation so that the early
 serial console works (we need the 'ranges' property to be available)

[... discussion of u-boot,dm-pre-reloc property]
 Can't the need for that property change over time? Either as more
 drivers are converted to DM you need to add this or you add some
 feature that depends on a driver (e.g. get a board rev or boot mode
 from GPIO). You would have backwards compatibility issues with this.
 I'm somewhat less worried about that for u-boot as we should be
 bundling the dtb and bootloader rather than kernel and dtb. For the
 UART, you can just get which UART to initialize early from
 stdout-path. But for other cases, couldn't you just have the platform
 provide the list of needed drivers. Then when u-boot needs change, you
 just change u-boot.
>>>
>>> Yes U-Boot and its device tree are normally built from the same tree
>>> at the same time. We don't expect to have to support an older or newer
>>> device tree with the same U-Boot binary. So I don't see a problem
>>> here.
>>
>> My point is that if I had to pick how bootloader+dtb+kernel are
>> bundled or not, I would rather see the dtb in sync with the bootloader
>> rather than the kernel. But I can't decide that for everyone and
>> neither can you. You still have a compatibility problem and that has
>> to be addressed.
> 
> What are you getting at here? If I move to a new kernel and still use
> an old device tree I may be missing features, or fail to boot. Don't
> do that!

One of the central points of DT is that it is an ABI. As such, moving to
a new kernel and continuing to use the same old DTB *MUST NOT* break
anything. Of course, you won't get any features enabled/described in any
new DT if you don't use it.

...
> After reading your email I am none the wiser about what you are suggesting.
> 
> This is not a screwy case. Every board will have a console. In some
> cases it is inside a 'soc {' node and in some cases it is not. The
> pure solution would be to mark every UART node with
> u-boot,dm-pre-reloc and we can do that if you prefer. It isn't
> necessary though for the reasons I previously explained.
> 
> It seems reasonable that U-Boot should be able to add private
> properties to the device tree, intended for U-Boot, just as Linux
> does. What is the problem here?

Why is that reasonable? DT is intended to describe the HW. It is
supposed to be OS-agnostic. Having U-Boot-specific properties completely
goes against that.

What Linux-specific properties are you referring to? The only one I
recall you mentioning (although I'm missing a lot of sleep right now) is
the keycodes in the input binding. While the DT property name for those
is linux,... and the values happen to match internal Linux numbering,
there's absolutely nothing Linux specific about the /concept/ of a
keycode, and some numbering scheme had to be picked. There's nothing
practical or conceptual stopping any other OS/SW-stack from translating
those Linux IDs into something internally meaningful. Conversely, the
concept of e.g. "u-boot,dm-pre-reloc" is not something that translates
at all to any other OS/WW-stack.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 0/2] KVM: nested VPID emulation

[Wanpeng Li]

v2 -> v3:
 * enhance allocate/free_vpid as Jan's suggestion
 * add more comments to 2/2

v1 -> v2:
 * enhance allocate/free_vpid to handle shadow vpid
 * drop empty space
 * allocate shadow vpid during initialization
 * For each nested vmentry, if vpid12 is changed, reuse shadow vpid w/ an 
   invvpid.

VPID is used to tag address space and avoid a TLB flush. Currently L0 use 
the same VPID to run L1 and all its guests. KVM flushes VPID when switching 
between L1 and L2. 

This patch advertises VPID to the L1 hypervisor, then address space of L1 and 
L2 can be separately treated and avoid TLB flush when swithing between L1 and 
L2.

Performance: 

run lmbench on L2 w/ 3.5 kernel.

Context switching - times in microseconds - smaller is better
-
Host OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
 ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
- - -- -- -- -- -- --- ---
kernelLinux 3.5.0-1 1.2200 1.3700 1.4500 4.7800 2.3300 5.6 2.88000  
nested VPID 
kernelLinux 3.5.0-1 1.2600 1.4300 1.5600   12.7   12.9 3.49000 7.46000  
vanilla

Wanpeng Li (2):
  KVM: nVMX: enhance allocate/free_vpid to handle shadow vpid
  KVM: nVMX: nested VPID emulation

 arch/x86/kvm/vmx.c | 61 +-
 1 file changed, 42 insertions(+), 19 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/2] KVM: nVMX: enhance allocate/free_vpid to handle shadow vpid

[Wanpeng Li]

Enhance allocate/free_vid to handle shadow vpid.

Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9ff6a3f..4956081 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4155,29 +4155,27 @@ static int alloc_identity_pagetable(struct kvm *kvm)
return r;
 }
 
-static void allocate_vpid(struct vcpu_vmx *vmx)
+static int allocate_vpid(void)
 {
-   int vpid;
+   int vpid = 0;
 
-   vmx->vpid = 0;
if (!enable_vpid)
-   return;
+   return 0;
spin_lock(&vmx_vpid_lock);
vpid = find_first_zero_bit(vmx_vpid_bitmap, VMX_NR_VPIDS);
-   if (vpid < VMX_NR_VPIDS) {
-   vmx->vpid = vpid;
+   if (vpid < VMX_NR_VPIDS)
__set_bit(vpid, vmx_vpid_bitmap);
-   }
spin_unlock(&vmx_vpid_lock);
+   return vpid;
 }
 
-static void free_vpid(struct vcpu_vmx *vmx)
+static void free_vpid(int vpid)
 {
if (!enable_vpid)
return;
spin_lock(&vmx_vpid_lock);
-   if (vmx->vpid != 0)
-   __clear_bit(vmx->vpid, vmx_vpid_bitmap);
+   if (vpid != 0)
+   __clear_bit(vpid, vmx_vpid_bitmap);
spin_unlock(&vmx_vpid_lock);
 }
 
@@ -8482,7 +8480,7 @@ static void vmx_free_vcpu(struct kvm_vcpu *vcpu)
 
if (enable_pml)
vmx_disable_pml(vmx);
-   free_vpid(vmx);
+   free_vpid(vmx->vpid);
leave_guest_mode(vcpu);
vmx_load_vmcs01(vcpu);
free_nested(vmx);
@@ -8501,7 +8499,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, 
unsigned int id)
if (!vmx)
return ERR_PTR(-ENOMEM);
 
-   allocate_vpid(vmx);
+   vmx->vpid = allocate_vpid();
 
err = kvm_vcpu_init(&vmx->vcpu, kvm, id);
if (err)
@@ -8577,7 +8575,7 @@ free_msrs:
 uninit_vcpu:
kvm_vcpu_uninit(&vmx->vcpu);
 free_vcpu:
-   free_vpid(vmx);
+   free_vpid(vmx->vpid);
kmem_cache_free(kvm_vcpu_cache, vmx);
return ERR_PTR(err);
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/2] KVM: nVMX: nested VPID emulation

[Wanpeng Li]

VPID is used to tag address space and avoid a TLB flush. Currently L0 use 
the same VPID to run L1 and all its guests. KVM flushes VPID when switching 
between L1 and L2. 

This patch advertises VPID to the L1 hypervisor, then address space of L1 and 
L2 can be separately treated and avoid TLB flush when swithing between L1 and 
L2. For each nested vmentry, if vpid12 is changed, reuse shadow vpid w/ an 
invvpid.

Performance: 

run lmbench on L2 w/ 3.5 kernel.

Context switching - times in microseconds - smaller is better
-
Host OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
 ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
- - -- -- -- -- -- --- ---
kernelLinux 3.5.0-1 1.2200 1.3700 1.4500 4.7800 2.3300 5.6 2.88000  
nested VPID 
kernelLinux 3.5.0-1 1.2600 1.4300 1.5600   12.7   12.9 3.49000 7.46000  
vanilla

Suggested-by: Wincy Van 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 37 +++--
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4956081..2fd5b5e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -424,6 +424,9 @@ struct nested_vmx {
/* to migrate it to L2 if VM_ENTRY_LOAD_DEBUG_CONTROLS is off */
u64 vmcs01_debugctl;
 
+   u16 vpid02;
+   u16 last_vpid;
+
u32 nested_vmx_procbased_ctls_low;
u32 nested_vmx_procbased_ctls_high;
u32 nested_vmx_true_procbased_ctls_low;
@@ -1155,6 +1158,11 @@ static inline bool 
nested_cpu_has_virt_x2apic_mode(struct vmcs12 *vmcs12)
return nested_cpu_has2(vmcs12, SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE);
 }
 
+static inline bool nested_cpu_has_vpid(struct vmcs12 *vmcs12)
+{
+   return nested_cpu_has2(vmcs12, SECONDARY_EXEC_ENABLE_VPID);
+}
+
 static inline bool nested_cpu_has_apic_reg_virt(struct vmcs12 *vmcs12)
 {
return nested_cpu_has2(vmcs12, SECONDARY_EXEC_APIC_REGISTER_VIRT);
@@ -2469,6 +2477,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx 
*vmx)
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
SECONDARY_EXEC_RDTSCP |
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
+   SECONDARY_EXEC_ENABLE_VPID |
SECONDARY_EXEC_APIC_REGISTER_VIRT |
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
SECONDARY_EXEC_WBINVD_EXITING |
@@ -6662,6 +6671,7 @@ static void free_nested(struct vcpu_vmx *vmx)
return;
 
vmx->nested.vmxon = false;
+   free_vpid(vmx->nested.vpid02);
nested_release_vmcs12(vmx);
if (enable_shadow_vmcs)
free_vmcs(vmx->nested.current_shadow_vmcs);
@@ -8547,8 +8557,10 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, 
unsigned int id)
goto free_vmcs;
}
 
-   if (nested)
+   if (nested) {
nested_vmx_setup_ctls_msrs(vmx);
+   vmx->nested.vpid02 = allocate_vpid();
+   }
 
vmx->nested.posted_intr_nv = -1;
vmx->nested.current_vmptr = -1ull;
@@ -8569,6 +8581,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, 
unsigned int id)
return &vmx->vcpu;
 
 free_vmcs:
+   free_vpid(vmx->nested.vpid02);
free_loaded_vmcs(vmx->loaded_vmcs);
 free_msrs:
kfree(vmx->guest_msrs);
@@ -9444,12 +9457,24 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu, 
struct vmcs12 *vmcs12)
 
if (enable_vpid) {
/*
-* Trivially support vpid by letting L2s share their parent
-* L1's vpid. TODO: move to a more elaborate solution, giving
-* each L2 its own vpid and exposing the vpid feature to L1.
+* There is no direct mapping between vpid02 and vpid12, the
+* vpid02 is per-vCPU for L0 and reused while the value of
+* vpid12 is changed w/ one invvpid during nested vmentry.
+* The vpid12 is allocated by L1 for L2, so it will not
+* influence global bitmap(for vpid01 and vpid02 allocation)
+* even if spawn a lot of nested vCPUs.
 */
-   vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->vpid);
-   vmx_flush_tlb(vcpu);
+   if (nested_cpu_has_vpid(vmcs12)) {
+   vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->nested.vpid02);
+   if (vmcs12->virtual_processor_id != 
vmx->nested.last_vpid) {
+   vmx->nested.last_vpid = 
vmcs12->virtual_processor_id;
+   vmx_flush_tlb(vcpu);
+   }
+   } else {
+   vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->vpid);
+   vmx_flush_tlb(vcpu);
+   }
+
}
 
if (nested_cpu_h

Re: [PATCH RFC 6/8] drm: hisilicon: Add support for fbdev

[Xinwei Kong]

hi rob

On 2015/9/16 2:25, Rob Herring wrote:
> On 09/15/2015 04:37 AM, Xinwei Kong wrote:
>> If you config DRM_HISI_FBDEV optional, this patch will only support fbdev
>> mode while also supporting double buffer.
> 
> This is a lot of duplicated code from CMA fbdev. Is double buffering the
> only reason why CMA fbdev can't be used or are there some other
> constraints? Double buffering in fbdev has always been a hack, so I'm
> guessing that is not a feature that should be added here.
> 
I will drop it.

xinwei
> Rob
> 
>> Signed-off-by: Xinliang Liu 
>> Signed-off-by: Xinwei Kong 
>> Signed-off-by: Andy Green 
>> Signed-off-by: Jiwen Qi 
>> Signed-off-by: Yu Gong 
>> ---
>>  drivers/gpu/drm/hisilicon/Kconfig  |  13 +
>>  drivers/gpu/drm/hisilicon/Makefile |   3 +-
>>  drivers/gpu/drm/hisilicon/hisi_drm_connector.c |   4 +
>>  drivers/gpu/drm/hisilicon/hisi_drm_drv.c   |   9 +
>>  drivers/gpu/drm/hisilicon/hisi_drm_dsi.c   |  15 +
>>  drivers/gpu/drm/hisilicon/hisi_drm_fb.h|   5 +
>>  drivers/gpu/drm/hisilicon/hisi_drm_fbdev.c | 395 
>> +
>>  drivers/gpu/drm/hisilicon/hisi_drm_fbdev.h |  24 ++
>>  8 files changed, 467 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_fbdev.c
>>  create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_fbdev.h
> 
> 
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Company Payment Agent Needed!!!

[Shougang Group Co., Ltd.]

--
Shougang Group Co., Ltd.
11th Floor, Huaxingge,
Donghua Building, Jiangmen,
GuangDong, China.

Greetings,

This is an official request for Professional/consultants who will  
stand as our regional representative to run logistics on behalf of  
Shougang Group.We are looking for a payment collection agent in USA,  
Canada, Mexico and Europe. Salary is 10% of every payment you receive  
from our customers. Get back to us for more details if interested.


Kindly send us the following information for more details

(1)Your Full names:
(2)Your Complete Address:
a. City:
b. State:
c. Zip code:
d. Country:
(3)Tele/cell numbers:
(4)Occupation:
(5)Gender:
(6)Age:
(7)Email:

Respectfully
Mr Sun Xiao Lan (Human Resources)
Shougang Group

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Sep 16

[Stephen Rothwell]

Hi all,

Changes since 20150915:

Dropped tree: akpm-current (build conflict)

I used the h8300 tree from next-20150828 since the current tree has been
rebased onto something very old :-(

The net-next tree gained a build failure for which I applied a fix patch.

The bluetooth tree still had its build failure.

The tip tree gained a build failure so I used the version from
next-20150915.

The akpm-current tree still had its build failure so I dropped it again
for today.

Non-merge commits (relative to Linus' tree): 1179
 978 files changed, 65094 insertions(+), 13956 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final
link) and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 226 trees (counting Linus' and 33 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (09a77a885233 modsign: Fix GPL/OpenSSL licence 
incompatibility)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (c2172ce23030 Merge branch 'uaccess' into fixes)
Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather 
than duplicating its implementation)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (e297c939b745 powerpc/MSI: Fix race condition in 
tearing down MSI interrupts)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (892aa01df2ad net: stmmac: Use msleep rather then udelay for 
reset delay)
Merging ipsec/master (04a6b8bfee06 xfrm6: Fix ICMPv6 and MH header checks in 
_decode_session6)
Merging sound-current/for-linus (5ee20bc79246 ALSA: usb-audio: Change internal 
PCM order)
Merging pci-current/for-linus (d5da9d99d4d7 PCI: Revert "PCI: Call 
pci_read_bridge_bases() from core instead of arch code")
Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module 
parameter for MSI interrupts)
Merging driver-core.current/driver-core-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging tty.current/tty-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging usb.current/usb-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging usb-gadget-fixes/fixes (762982db33b2 usb: phy: phy-generic: Fix reset 
behaviour on legacy boot)
Merging usb-serial-fixes/usb-linus (19ab6bc5674a USB: option: add ZTE PIDs)
Merging staging.current/staging-linus (8b5081c876bd staging: unisys: visornic: 
handle error return from device registration)
Merging char-misc.current/char-misc-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging input-current/for-linus (53431d0a3534 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (84cba178a3b8 crypto: testmgr - don't copy from 
source IV too much)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (ae7858180510 selftests: exec: revert to default

Gelten Sie für dringende Darlehen bieten1.1%

[BancoPosta Online Loans]

--
BancoPosta Loans
Viale Europa,
175-00144 Roma,
Italy.

Email: bancopost...@gmail.com

Guten Tag meine Damen und Herren,

Brauchen Sie ein Darlehen für einen bestimmten Zweck?

BancoPosta Bank in Italien haben einen günstigen Kredit für Sie. Wir 
bieten gesicherten und ungesicherten persönlichen Darlehen Kunden für 
jeden Zweck, ob ein neues Unternehmen, Privatpersonen und Unternehmen zu 
starten, oder Sie haben ein großes Projekt im Auge. Ein persönliches 
Darlehen, das Sie überall für alles verwenden können, sollten Sie die 
Freiheit, die BancoPosta Bank Darlehen Programm anbieten kann. Mit einer 
vereinfachten Kreditantrag erhalten Sie Ihr BancoPosta Darlehen 
genehmigt und am selben Tag, die Sie anwenden, mit der niedrigen Rate 
von 1.1% der flexiblen Kreditkonditionen aus (1 Jahr auf 20 Jahre), 
Borrow (10,000.00 Euro/Chf bis 100,000,000.00 Euro/Chf) für einen 
bestimmten Zweck ausgestellt. Wenn Sie benötigen ein Darlehen, füllen 
Sie das Antragsformular aus, um loszulegen.


Ihr vollständiger Name: ___
Ihre Adresse: ___
Ihr Darlehensbetrag: ___
Miet-Zweck: ___
Darlehen-Dauer: ___

Bewerben Sie sich jetzt und überlassen Sie uns den Rest!

Vielen Dank für Ihre Schirmherrschaft.

Unser Ziel ist die Erfüllung Ihrer finanziellen Bedürfnisse!

Alles Gute
Massimo Sarmi.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] iov: restore NumVFs register to 0 before return from virtfn_max_buses()

[Ethan Zhao]

After commit 4449f079722c ("PCI: Calculate maximum number of buses
required for VFs"),the initial value of NumVFs register was left to
non-zero after sriov_init() and no VFs was enabled in device driver.
this changed the behaviour of kernel exported by lspci and sysfs etc.
so this patch restore the NumVFs register to zero after the
calculation of max_VF_buses was done and before return from
virtfn_max_buses().

Tested on stable 4.1 and passed building on stable 4.3-rc1

Signed-off-by: Ethan Zhao 
Tested-by: Sriharsha Yadagudde 
---
v1..v2:
 -Suggestions from Bjorn Helgaas (move the restoration of NumVFs register
  to virtfn_max_buses())
---
 drivers/pci/iov.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ee0ebff..92cee06 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -71,6 +71,8 @@ static inline u8 virtfn_max_buses(struct pci_dev *dev)
max = busnr;
}
 
+   /* restore NumVFs register to 0 */
+   pci_iov_set_numvfs(dev, 0);
return max;
 }
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] mfd: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO regulators

[Chen-Yu Tsai]

The DC1SW and DC5LDO regulators in the AXP221 are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property. This causes
some confusion when we actually use it in the dts:

axp221 {
/* self supplying? */
dcdc1-supply = <&dcdc1>;
dcdc5-supply = <&dcdc5>;

dcdc1: dcdc1 {
...
};

dcdc5: dcdc5 {
...
};
};

Change them to the downstream regulator names, or "dc1sw" and "dc5ldo"
respectively.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 41811223e5be..8e79252b1e7c 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -60,8 +60,8 @@ DCDC2 : DC-DC buck: vin2-supply
 DCDC3  : DC-DC buck: vin3-supply
 DCDC4  : DC-DC buck: vin4-supply
 DCDC5  : DC-DC buck: vin5-supply
-DC1SW  : On/Off Switch : dcdc1-supply  : DCDC1 secondary output
-DC5LDO : LDO   : dcdc5-supply  : input from DCDC5
+DC1SW  : On/Off Switch : dc1sw-supply  : DCDC1 secondary output
+DC5LDO : LDO   : dc5ldo-supply : input from DCDC5
 ALDO1  : LDO   : aldoin-supply : shared supply
 ALDO2  : LDO   : aldoin-supply : shared supply
 ALDO3  : LDO   : aldoin-supply : shared supply
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] ARM: dts: sun6i: hummingbird: Rename AXP221 DC1SW and DC5LDO supply names

[Chen-Yu Tsai]

"dcdc1-supply" and "dcdc5-supply" are renamed to "dc1sw-supply" and
"dc5ldo-supply" respectively. Update the dts to reflect the new supply
names for the regulators.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts 
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 06d9391ca30e..144f563a3d6d 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -178,8 +178,8 @@
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <1>;
-   dcdc1-supply = <&vcc_3v0>;
-   dcdc5-supply = <&vcc_dram>;
+   dc1sw-supply = <&vcc_3v0>;
+   dc5ldo-supply = <&vcc_dram>;
 
regulators {
x-powers,dcdc-freq = <3000>;
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] regulators: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO

[Chen-Yu Tsai]

The DC1SW and DC5LDO regulators in the AXP221 are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property. This causes
some confusion when we actually use it in the dts:

axp221 {
/* self supplying? */
dcdc1-supply = <&dcdc1>;
dcdc5-supply = <&dcdc5>;

dcdc1: dcdc1 {
...
};

dcdc5: dcdc5 {
...
};
};

Change them to the downstream regulator names, or "dc1sw" and "dc5ldo"
respectively.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/regulator/axp20x-regulator.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 01bf3476a791..27ebee8e224c 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -196,10 +196,10 @@ static const struct regulator_desc axp22x_regulators[] = {
AXP_DESC(AXP22X, DCDC5, "dcdc5", "vin5", 1000, 2550, 50,
 AXP22X_DCDC5_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(4)),
/* secondary switchable output of DCDC1 */
-   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", "dcdc1", 1600, 3400, 100,
+   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", "dc1sw", 1600, 3400, 100,
AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(7)),
/* LDO regulator internally chained to DCDC5 */
-   AXP_DESC(AXP22X, DC5LDO, "dc5ldo", "dcdc5", 700, 1400, 100,
+   AXP_DESC(AXP22X, DC5LDO, "dc5ldo", "dc5ldo", 700, 1400, 100,
 AXP22X_DC5LDO_V_OUT, 0x7, AXP22X_PWR_OUT_CTRL1, BIT(0)),
AXP_DESC(AXP22X, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
 AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(6)),
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] regulators: axp20x: Rename AXP221 DC1SW and DC5LDO supply names

[Chen-Yu Tsai]

Hi everyone,

This series renames regulator supply names for DC1SW and DC5LDO for
the AXP221. These 2 are secondary outputs for DCDC1 and DCDC5 buck
regulators, respectively, so they are connected to them internally.
There's no external input pin to name the supplies after.

When I originally did the support, I used the parent regulator's name
for the supply name. However this results in a misleading dts:

axp221: pmic@68 {
dcdc1-supply = <&dcdc1>;
dcdc5-supply = <&dcdc5>;

dcdc1: dcdc1 {
...
};

...
};

At first glance, one might interpret it as "DCDC1 supplies itself".
Indeed, Maxime raised this issue.

This series renames the supply names to the regulator names themselves,
or "dc1sw-supply" and "dc5ldo-supply" respectively:

axp221: pmic@68 {
dc1sw-supply = <&dcdc1>;
dc5ldo-supply = <&dcdc5>;
...
};

Renaming these shouldn't result in any problems in the real world.
All the board designs we've seen have DCDC1 supplying a common 3/3.3V
rail, and DCDC5 supplying 1.5V for DDR3 SDRAM. These 2 would have
"always-on" set, so even if the rename results in the secondary
regulator outputs being decoupled from the primary in the software
implementation, it would just be a representation issue. Function-wise,
it would function as before. On the Linux side, no one is actually
using the secondary outputs yet.

Patch 1 renames the supply names in the axp20x DT bindings.

Patch 2 updates the axp20x regulator driver.

Patch 3 updates the only dts, the Hummingbird A31, that uses these
bindings.

If everything's ok, could we merge the first 2 patches through the
regulator tree, and the 3rd through the sunxi tree?

Thanks.


Regards,
ChenYu


Chen-Yu Tsai (3):
  mfd: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO
regulators
  regulators: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO
  ARM: dts: sun6i: hummingbird: Rename AXP221 DC1SW and DC5LDO supply
names

 Documentation/devicetree/bindings/mfd/axp20x.txt | 4 ++--
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts  | 4 ++--
 drivers/regulator/axp20x-regulator.c | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Gelten Sie für dringende Darlehen bieten1.1%

[BancoPosta Online Loans]

--
BancoPosta Loans
Viale Europa,
175-00144 Roma,
Italy.

Email: bancopost...@gmail.com

Guten Tag meine Damen und Herren,

Brauchen Sie ein Darlehen für einen bestimmten Zweck?

BancoPosta Bank in Italien haben einen günstigen Kredit für Sie. Wir 
bieten gesicherten und ungesicherten persönlichen Darlehen Kunden für 
jeden Zweck, ob ein neues Unternehmen, Privatpersonen und Unternehmen zu 
starten, oder Sie haben ein großes Projekt im Auge. Ein persönliches 
Darlehen, das Sie überall für alles verwenden können, sollten Sie die 
Freiheit, die BancoPosta Bank Darlehen Programm anbieten kann. Mit einer 
vereinfachten Kreditantrag erhalten Sie Ihr BancoPosta Darlehen 
genehmigt und am selben Tag, die Sie anwenden, mit der niedrigen Rate 
von 1.1% der flexiblen Kreditkonditionen aus (1 Jahr auf 20 Jahre), 
Borrow (10,000.00 Euro/Chf bis 100,000,000.00 Euro/Chf) für einen 
bestimmten Zweck ausgestellt. Wenn Sie benötigen ein Darlehen, füllen 
Sie das Antragsformular aus, um loszulegen.


Ihr vollständiger Name: ___
Ihre Adresse: ___
Ihr Darlehensbetrag: ___
Miet-Zweck: ___
Darlehen-Dauer: ___

Bewerben Sie sich jetzt und überlassen Sie uns den Rest!

Vielen Dank für Ihre Schirmherrschaft.

Unser Ziel ist die Erfüllung Ihrer finanziellen Bedürfnisse!

Alles Gute
Massimo Sarmi.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] vmcore: replace Elf64_Ehdr/Elf32_Ehdr with elfhdr

[yanjiang.jin]

From: Yanjiang Jin 

Function parse_crash_elf_headers() reads e_ident[EI_CLASS] then decides to
call parse_crash_elf64_headers() or parse_crash_elf32_headers().
But this happens in run time, not compile time. So compiler will report
the below warning:

In file included from include/linux/elf.h:4:0,
 from fs/proc/vmcore.c:13:
fs/proc/vmcore.c: In function 'parse_crash_elf32_headers':
arch/mips/include/asm/elf.h:258:23: warning: initializatio
n from incompatible pointer type
  struct elfhdr *__h = (hdr); \
   ^
fs/proc/vmcore.c:1071:4: note: in expansion of macro 'elf_
check_arch'
   !elf_check_arch(&ehdr) ||
^

Signed-off-by: Yanjiang Jin 
---
 fs/proc/vmcore.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 4e61388..576bb26 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -999,7 +999,7 @@ static void free_elfcorebuf(void)
 static int __init parse_crash_elf64_headers(void)
 {
int rc=0;
-   Elf64_Ehdr ehdr;
+   struct elfhdr ehdr;
u64 addr;
 
addr = elfcorehdr_addr;
@@ -1055,7 +1055,7 @@ fail:
 static int __init parse_crash_elf32_headers(void)
 {
int rc=0;
-   Elf32_Ehdr ehdr;
+   struct elfhdr ehdr;
u64 addr;
 
addr = elfcorehdr_addr;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] vmcore: replace Elf64_Ehdr/Elf32_Ehdr with elfhdr

[yanjiang.jin]

From: Yanjiang Jin 

Already verified this patch on a MIPS64 cavium octeon board: CN78XX.

This patch is to eliminate the compile warning only, has no side effect in 
run-time.

Yanjiang Jin (1):
  vmcore: replace Elf64_Ehdr/Elf32_Ehdr with elfhdr

 fs/proc/vmcore.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1] mm: migrate: hugetlb: putback destination hugepage to active list

[Naoya Horiguchi]

my bad, this patch is totally unrelated to the thread the previous email
replied to. I just mishandled my script wrapping git-send-email, sorry.

But just resending patch seems to be noisy, so I want this to be reviewed
on this email.
If it's inconvenient or uncommon way of submission, please let me know and
I'll resend in a new thread.

Thanks,
Naoya Horiguchi

On Wed, Sep 16, 2015 at 12:21:04AM +, Naoya Horiguchi wrote:
> Since commit bcc54222309c ("mm: hugetlb: introduce page_huge_active")
> each hugetlb page maintains its active flag to avoid a race condition between
> multiple calls of isolate_huge_page(), but current kernel doesn't set the flag
> on a hugepage allocated by migration because the proper putback routine isn't
> called. This means that users could still encounter the race referred to by
> bcc54222309c in this special case, so this patch fixes it.
> 
> Fixes: bcc54222309c ("mm: hugetlb: introduce page_huge_active")
> Signed-off-by: Naoya Horiguchi 
> Cc:   #4.1
> ---
>  mm/migrate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git v4.3-rc1/mm/migrate.c v4.3-rc1_patched/mm/migrate.c
> index c3cb566af3e2..7452a00bbb50 100644
> --- v4.3-rc1/mm/migrate.c
> +++ v4.3-rc1_patched/mm/migrate.c
> @@ -1075,7 +1075,7 @@ static int unmap_and_move_huge_page(new_page_t 
> get_new_page,
>   if (rc != MIGRATEPAGE_SUCCESS && put_new_page)
>   put_new_page(new_hpage, private);
>   else
> - put_page(new_hpage);
> + putback_active_hugepage(new_hpage);
>  
>   if (result) {
>   if (rc)
> -- 
> 2.4.3
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Add __ioread32_copy() and use it

[Andi Kleen]

> Under what circumstances will the compiler (or linker?) do this? 

Compiler.

> LTO enabled?

Yes it's for LTO.  The optimization allows the compiler to drop unused
functions, which is very popular with users (a lot use it to get smaller
kernel images)

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tty: fix data race in flush_to_ldisc

[Peter Hurley]

On 09/04/2015 03:28 PM, Dmitry Vyukov wrote:
> On Thu, Sep 3, 2015 at 2:50 AM, Peter Hurley  wrote:
>> On 09/02/2015 01:53 PM, Dmitry Vyukov wrote:
>>> The data race is found with KernelThreadSanitizer (on rev 21bdb584af8c):
>>>
>>> ThreadSanitizer: data-race in release_tty
>>> Write of size 8 by thread T325 (K2579):
>>>   release_tty+0xf3/0x1c0 drivers/tty/tty_io.c:1688
>>>   tty_release+0x698/0x7c0 drivers/tty/tty_io.c:1920
>>>   __fput+0x15f/0x310 fs/file_table.c:207
>>>   fput+0x1d/0x30 fs/file_table.c:243
>>>   task_work_run+0x115/0x130 kernel/task_work.c:123
>>>   do_notify_resume+0x73/0x80
>>> tracehook_notify_resume include/linux/tracehook.h:190
>>>   do_notify_resume+0x73/0x80 arch/x86/kernel/signal.c:757
>>>   int_signal+0x12/0x17 arch/x86/entry/entry_64.S:326
>>> Previous read of size 8 by thread T19 (K16):
>>>   flush_to_ldisc+0x29/0x300 drivers/tty/tty_buffer.c:472
>>>   process_one_work+0x47e/0x930 kernel/workqueue.c:2036
>>>   worker_thread+0xb0/0x900 kernel/workqueue.c:2170
>>>   kthread+0x150/0x170 kernel/kthread.c:207
>>
>> The stack traces are not really helpful in describing how the race
>> occurs; I would leave it out of the changelog.
>
> ok

Just to clarify; my comment is only wrt this particular patch.
You may have other patches in the future with unclear execution paths
that may require the call stacks. It's just that this particular
race has invariant call stacks (for the relevant parts).


>>> flush_to_ldisc reads port->itty and checks that it is not NULL,
>>> concurrently release_tty sets port->itty to NULL. It is possible
>>> that flush_to_ldisc loads port->itty once, ensures that it is
>>> not NULL, but then reloads it again and uses. The second load
>>> can already return NULL, which will cause a crash.
>>>
>>> Use READ_ONCE/WRITE_ONCE to read/update port->itty.
>>
>> See below.
>>
>>> Signed-off-by: Dmitry Vyukov 
>>> ---
>>>  drivers/tty/tty_buffer.c | 2 +-
>>>  drivers/tty/tty_io.c | 2 +-
>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>>> index 4cf263d..1f1031d 100644
>>> --- a/drivers/tty/tty_buffer.c
>>> +++ b/drivers/tty/tty_buffer.c
>>> @@ -469,7 +469,7 @@ static void flush_to_ldisc(struct work_struct *work)
>>>   struct tty_struct *tty;
>>>   struct tty_ldisc *disc;
>>>
>>> - tty = port->itty;
>>> + tty = READ_ONCE(port->itty);
>>
>> This is fine.
>>
>>>   if (tty == NULL)
>>>   return;
>>>
>>> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
>>> index 57fc6ee..aad47df 100644
>>> --- a/drivers/tty/tty_io.c
>>> +++ b/drivers/tty/tty_io.c
>>> @@ -1685,7 +1685,7 @@ static void release_tty(struct tty_struct *tty, int 
>>> idx)
>>>   tty_driver_remove_tty(tty->driver, tty);
>>>   tty->port->itty = NULL;
>>>   if (tty->link)
>>> - tty->link->port->itty = NULL;
>>> + WRITE_ONCE(tty->link->port->itty, NULL);
>>
>> This isn't doing anything useful.
>>
>> 1. The compiler can't push the store past the cancel_work_sync() (because the
>>compiler has no visibility into cancel_work_sync()), and,
>> 2. There's no effect if the compiler hoists the store higher in the 
>> release_tty()
>>because the line discipline has already been closed and killed (so the
>>tty_ldisc_ref() in flush_to_ldisc() returns NULL anyway).
>
> OK, let me do one try at convincing you that WRITE_ONCE here is a good
> idea. If you are not convinced then I will remove it.

FWIW, I'm not the gatekeeper wrt tree-wide code/best-practices changes;
iow, convincing me is not a useful goal.  But I think this would be a
good topic/
presentation for either Kernel Summit or Linux Plumbers.

That said, I'll make some observations below that you should expect to read
from other contributors/maintainers regarding your point-of-view.

> WRITE_ONCE/READ_ONCE for all shared memory accesses:
> 1. Make the code more readable but highlighting important aspects.

Most would argue the additional macros detract from readability.

> 2. Required by relevant standards and relieve you, me and everybody
> else reading this code from spending time on proving that it cannot
> break (think of multi-file compilation mode, store tearing which
> compilers indeed known to do in some contexts, and compiler
> transformations that we don't know of).

Multi-file compilation and the compiler memory model are inherently
incompatible with kernel code. Instrumenting code rather than specializing
the tool (compiler) is progress in the wrong direction, imho.

Same with store tearing of primitive types.

Compiler "transforms" are an occasional hazard of kernel development,
as are straight-up compiler bugs; in my limited experience, each occurs
with equal frequency.

> 3. Allow tooling that finds undoubtedly harmful bugs, like this one,

While the READ_ONCE() fix improves robustness, I wouldn't categorize
this as a 'harmful' bug. I seriously doubt any compiler has generated
a reloa

Re: [PATCH 0/3] Add __ioread32_copy() and use it

[Andrew Morton]

On Wed, 16 Sep 2015 04:32:19 +0200 Andi Kleen  wrote:

> > __iowrite32_copy() is marked __visible.  I don't actually know what
> > that does and Andi's d47d5c8194579bc changelog (which sucks the big
> > one) didn't explain it.  Apparently it has something to do with being
> > implemented in assembly, but zillions of functions are implemented in
> > assembly, so why are only two functions marked this way?  Anyway,
> > __ioread32_copy() is implemented in C so I guess __visible isn't needed
> > there.
> 
> __visible is needed for C functions that are called from assembler.
> Otherwise the compiler may optimize them away.

Under what circumstances will the compiler (or linker?) do this? 
LTO enabled?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] arm: Fix backtrace generation when IPI is masked

[Hillf Danton]

> 
> Currently on ARM when  is triggered from an interrupt handler
> (e.g. a SysRq issued using UART or kbd) the main CPU will wedge for ten
> seconds with interrupts masked before issuing a backtrace for every CPU
> except itself.
> 
> The new backtrace code introduced by commit 96f0e00378d4 ("ARM: add
> basic support for on-demand backtrace of other CPUs") does not work
> correctly when run from an interrupt handler because IPI_CPU_BACKTRACE
> is used to generate the backtrace on all CPUs but cannot preempt the
> current calling context.
> 
> This can be fixed by detecting that the calling context cannot be
> preempted and issuing the backtrace directly in this case. Issuing
> directly leaves us without any pt_regs to pass to nmi_cpu_backtrace()
> so we also modify the generic code to call dump_stack() when its
> argument is NULL.
> 
> Signed-off-by: Daniel Thompson 
> ---

Acked-by: Hillf Danton 
> 
> Notes:
> Changes in v3:
> 
> * Added comments to describe how raise_nmi() and nmi_cpu_backtrace()
>   interact with backtrace_mask (Russell King).
> 
> Changes in v2:
> 
> * Improved commit message to better describe the changes to the generic
>   code (Hillf Danton).
> 
>  arch/arm/kernel/smp.c |  9 +
>  lib/nmi_backtrace.c   | 11 ++-
>  2 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 48185a773852..0c4e7fdb9636 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -748,6 +748,15 @@ core_initcall(register_cpufreq_notifier);
> 
>  static void raise_nmi(cpumask_t *mask)
>  {
> + /*
> +  * Generate the backtrace directly if we are running in a calling
> +  * context that is not preemptible by the backtrace IPI. Note
> +  * that nmi_cpu_backtrace() automatically removes the current cpu
> +  * from mask.
> +  */
> + if (cpumask_test_cpu(smp_processor_id(), mask) && irqs_disabled())
> + nmi_cpu_backtrace(NULL);
> +
>   smp_cross_call(mask, IPI_CPU_BACKTRACE);
>  }
> 
> diff --git a/lib/nmi_backtrace.c b/lib/nmi_backtrace.c
> index 88d3d32e5923..6019c53c669e 100644
> --- a/lib/nmi_backtrace.c
> +++ b/lib/nmi_backtrace.c
> @@ -43,6 +43,12 @@ static void print_seq_line(struct nmi_seq_buf *s, int 
> start, int end)
>   printk("%.*s", (end - start) + 1, buf);
>  }
> 
> +/*
> + * When raise() is called it will be is passed a pointer to the
> + * backtrace_mask. Architectures that call nmi_cpu_backtrace()
> + * directly from their raise() functions may rely on the mask
> + * they are passed being updated as a side effect of this call.
> + */
>  void nmi_trigger_all_cpu_backtrace(bool include_self,
>  void (*raise)(cpumask_t *mask))
>  {
> @@ -149,7 +155,10 @@ bool nmi_cpu_backtrace(struct pt_regs *regs)
>   /* Replace printk to write into the NMI seq */
>   this_cpu_write(printk_func, nmi_vprintk);
>   pr_warn("NMI backtrace for cpu %d\n", cpu);
> - show_regs(regs);
> + if (regs)
> + show_regs(regs);
> + else
> + dump_stack();
>   this_cpu_write(printk_func, printk_func_save);
> 
>   cpumask_clear_cpu(cpu, to_cpumask(backtrace_mask));
> --
> 2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] KVM: nVMX: nested VPID emulation

[Wanpeng Li]

On 9/16/15 1:32 AM, Jan Kiszka wrote:

On 2015-09-15 12:14, Wanpeng Li wrote:

On 9/14/15 10:54 PM, Jan Kiszka wrote:

Last but not least: the guest can now easily exhaust the host's pool of
vpid by simply spawning plenty of VCPUs for L2, no? Is this acceptable
or should there be some limit?

I reuse the value of vpid02 while vpid12 changed w/ one invvpid in v2,
and the scenario which you pointed out can be avoid.

I cannot yet follow why there is no chance for L1 to consume all vpids
that the host manages in that single, global bitmap by simply spawning a
lot of nested VCPUs for some L2. What is enforcing L1 to call nested
vmclear - apparently the only way, besides destructing nested VCPUs, to
release such vpids again?


In v2, there is no direct mapping between vpid02 and vpid12, the vpid02 
is per-vCPU for L0 and reused while the value of vpid12 is changed w/ 
one invvpid during nested vmentry. The vpid12 is allocated by L1 for L2, 
so it will not influence global bitmap(for vpid01 and vpid02 allocation) 
even if spawn a lot of nested vCPUs.


Regards,
Wanpeng Li

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Add __ioread32_copy() and use it

[Andi Kleen]

> __iowrite32_copy() is marked __visible.  I don't actually know what
> that does and Andi's d47d5c8194579bc changelog (which sucks the big
> one) didn't explain it.  Apparently it has something to do with being
> implemented in assembly, but zillions of functions are implemented in
> assembly, so why are only two functions marked this way?  Anyway,
> __ioread32_copy() is implemented in C so I guess __visible isn't needed
> there.

__visible is needed for C functions that are called from assembler.
Otherwise the compiler may optimize them away.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/8] mmc: dw_mmc: Generic MMC tuning with the clock phase framework

[Jaehoon Chung]

Hi,

On 09/16/2015 07:09 AM, Heiko Stübner wrote:
> Hi,
> 
> Am Dienstag, 15. September 2015, 17:25:38 schrieb Jaehoon Chung:
>> On 09/01/2015 03:24 AM, Heiko Stuebner wrote:
>>> From: Alexandru M Stan 
>>>
>>> This algorithm will try 1 degree increments, since there's no way to tell
>>> what resolution the underlying phase code uses. As an added bonus, doing
>>> many tunings yields better results since some tests are run more than once
>>> (ex: if the underlying driver uses 45 degree increments, the tuning code
>>> will try the same angle more than once).
>>>
>>> It will then construct a list of good phase ranges (even ranges that cross
>>> 360/0), will pick the biggest range then it will set the sample_clk to the
>>> middle of that range.
>>>
>>> We do not touch ciu_drive (and by extension define default-drive-phase).
>>> Drive phase is mostly used to define minimum hold times, while one could
>>> write some code to determine what phase meets the minimum hold time (ex 10
>>> degrees) this will not work with the current clock phase framework (which
>>> floors angles, so we'll get 0 deg, and there's no way to know what
>>> resolution the floors happen at). We assume that the default drive angles
>>> set by the hardware are good enough.
>>>
>>> If a device has device specific code (like exynos) then that will still
>>> take precedence, otherwise this new code will execute. If the device wants
>>> to tune, but has no sample_clk defined we'll return EIO with an error
>>> message.
>>
>> Which point is "_generic_"? I don't find the code that control the register
>> relevant to CLK_DRV/SMPL PHASE. It seems that posted the similar patches at
>> u-boot mailing list..
> 
> The "generic" part is that it uses the clk phase API for dw_mmc 
> implementations where the clkgen controlling interface is outside the dw_mmc 
> IP itself. So it's open for other implementations as well.

Designware IP also has the CLK phase register(UHS_REG_EXT register)...
if this code is related with it, it should be located into dw-mmc.c.

> 
> But if you are more comfortable with it, I can also move it into the dw_mmc-
> rockchip variant for the time being, until another user comes along.

I think more better that this code is located into dw_mmc-rockchip. how about?

Best Regards,
Jaehoon Chung

> 
> 
> Heiko
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / sleep: Fix broken builds without CONFIG_PM_SLEEP_DEBUG

[Viresh Kumar]

On 16-09-15, 04:54, Rafael J. Wysocki wrote:
> > Yes, it was slightly messed up.  Should be better now, though.

Yeah, its fine now.

> And as a side note, for patches that are in bleeding-edge only and not in
> something like linux-next, you don't need to bother anyone with fixes except
> for me (and maybe the patch author for their education mostly).
> 
> And I either drop patches that cause build problems to happen in bleeding-edge
> or fix them.  That's what bleeding-edge is for.

Okay, will keep that in mind.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig

[Yuyang Du]

On Tue, Sep 15, 2015 at 10:11:41AM -0700, bseg...@google.com wrote:
> >
> > I guess you are saying we are conflating NICE_0 with NICE_0_LOAD. But to me,
> > they are just integer metrics, needing a resolution respectively. That is 
> > it.
> 
> Yes this would change nothing at the moment post-expansion, that's not
> the point. SLR being 10 bits and the nice-0 being 1024 are completely
> and utterly unrelated and the headers should not pretend they need to be
> the same value,

I never said they are related, why should they be related. And they need or
need not to be the same value, fine.

However, the SLR has to be a value. It is because it mighe be 10 or 20 (LOAD),
therefore I make SCHED_RESOLUTION_SHIFT 10 (kind of a denominator). Not the
other way around.

We can define SCHED_RESOLUTION_SHIFT 1, and then define SLR = x * 
SCHED_RESOLUTION_SHIFT
with x being a random number, if you must.

And by the way, with SCHED_RESOLUTION_SHIFT, there will not be SLR anymore, we 
only
need SCHED_LOAD_SHIFT, which has a low resolution 1*SCHED_RESOLUTION_SHIFT or a 
high
one 2*SCHED_RESOLUTION_SHIFT. The scale_load*() is the conversion between the 
resolutions of NICE_0 and NICE_0_LOAD.

> any more than there should be a #define that is shared
> with every other use of 1024 in the kernel.

The point really is, metrics (if not many ) need resolution, not just 
NICE_0_LOAD does. 
You can choose to either hardcode a number, like SCHED_CAPACITY_SHIFT now,
or you can use SCHED_RESOLUTION_SHIFT, which is even as simple as a sign to say 
what
the defined is (the scaled one with a better resolution vs. the original one).
I guess this is to say we now have a (no-big-deal) resolution system.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers: of: check input parameter name for __of_find_property

[Rob Herring]

On 09/15/2015 07:16 PM, Peng Fan wrote:
> Hi Rob,
> 
> On Tue, Sep 15, 2015 at 10:56:28AM -0500, Rob Herring wrote:
>> On 09/11/2015 08:44 AM, Peng Fan wrote:
>>> Check input parameter 'name' for __of_find_property. If name is NULL,
>>> of_prop_cmp->strcasecmp may trigger panic.
>>
>> Arguably that could be a feature. Do you have a usecase where name being
>> NULL is valid and panicking is a problem?
> 
> In drivers/pinctrl/devicetree.c
> 
> 195 propname = kasprintf(GFP_KERNEL, "pinctrl-%d", state);
> 196 prop = of_find_property(np, propname, &size);
> 197 kfree(propname);
> 198 if (!prop)
> 199 break;
> 
> If propname is NULL, of_find_property may trigger panic. Anyway propname 
> should be checked
> before passing to of_find_property.

propname will only be NULL if the memory allocation failed which gives
you a big warning message. I don't think you would want to continue on
in this case.

So I'm inclined to leave this as is with passing NULL to
of_find_property to always be an error and fatal.

Rob

> I did not met panic message. I wrote this patch when I was reading the piece 
> code.
> I think the name parameter should be checked before doing string compare.
> 
> Regards,
> Peng.
> 
>>
>> Rob
>>
>>>
>>> Signed-off-by: Peng Fan 
>>> Cc: Rob Herring 
>>> Cc: Frank Rowand 
>>> Cc: Grant Likely 
>>> ---
>>>  drivers/of/base.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>> index 8b5a187..e41436d 100644
>>> --- a/drivers/of/base.c
>>> +++ b/drivers/of/base.c
>>> @@ -215,7 +215,7 @@ static struct property *__of_find_property(const struct 
>>> device_node *np,
>>>  {
>>> struct property *pp;
>>>  
>>> -   if (!np)
>>> +   if (!np || !name)
>>> return NULL;
>>>  
>>> for (pp = np->properties; pp; pp = pp->next) {
>>>
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / sleep: Fix broken builds without CONFIG_PM_SLEEP_DEBUG

[Rafael J. Wysocki]

On Wednesday, September 16, 2015 04:48:37 AM Rafael J. Wysocki wrote:
> On Wednesday, September 16, 2015 07:30:23 AM Viresh Kumar wrote:
> > On 16-09-15, 03:43, Rafael J. Wysocki wrote:
> > > On Tuesday, September 15, 2015 01:42:21 PM Viresh Kumar wrote:
> > > > The variable 'wakeup_irq' is defined within #ifdef CONFIG_PM_SLEEP_DEBUG
> > > > and used outside of it. And that breaks kernel build:
> > > > 
> > > > /home/viresh/linux/drivers/base/power/wakeup.c:871: undefined reference 
> > > > to `wakeup_irq'
> > > > /home/viresh/drivers/base/power/wakeup.c:871: undefined reference to 
> > > > `wakeup_irq'
> > > > 
> > > > Fix it by defining the variable outside of the ifdef.
> > > > 
> > > > Fixes: d1e59c235322 ("PM / sleep: Report interrupt that caused system 
> > > > wakeup")
> > > > Signed-off-by: Viresh Kumar 
> > > 
> > > I've applied the v11 of the Alexandra's patch that doesn't have this 
> > > problem AFAICS.
> > 
> > For the record, as we have talked on IRC, even the v11 patch suffers
> > from this problem and you will be fixing it.
> 
> Yes, it was slightly messed up.  Should be better now, though.

And as a side note, for patches that are in bleeding-edge only and not in
something like linux-next, you don't need to bother anyone with fixes except
for me (and maybe the patch author for their education mostly).

And I either drop patches that cause build problems to happen in bleeding-edge
or fix them.  That's what bleeding-edge is for.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] arm64: mediatek: enable MTK_TIMER

[Yingjoe Chen]

On Wed, 2015-09-16 at 10:04 +0800, Yingjoe Chen wrote:
> Enable MTK_TIMER for MediaTek plaform, which will be used as
> schedule clock.

Sorry, sending this series too early without cover letter and removing
Change-Id. Here's the cover letter:


This is actually v3 of "add GPT timer support for mt8173" series. This
is based on v4.3-rc1 + clockevents-4.4[1] and James's mediatek-clk
tree[2].

Changes compare to previous version[3]:
- the first two mtk_timer related changes are removed because they are
replaced/accepted in clockevents tree.
- Remove 'add 13mhz clock for MT8173' because it is accepted in
mediatek-clk tree.
- Kconfig.platforms path change.

So we only have 2 patches left here.
Matthias, can you take these and help to remove the Change-Id?


Daniel Kurtz (1):
  arm64: dts: mt8173: add timer node

Yingjoe Chen (1):
  arm64: mediatek: enable MTK_TIMER



[1]
https://git.linaro.org/people/daniel.lezcano/linux.git clockevents/4.4
[2]
http://lists.infradead.org/pipermail/linux-mediatek/2015-August/002069.html
[3]
http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001544.html




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / sleep: Fix broken builds without CONFIG_PM_SLEEP_DEBUG

[Rafael J. Wysocki]

On Wednesday, September 16, 2015 07:30:23 AM Viresh Kumar wrote:
> On 16-09-15, 03:43, Rafael J. Wysocki wrote:
> > On Tuesday, September 15, 2015 01:42:21 PM Viresh Kumar wrote:
> > > The variable 'wakeup_irq' is defined within #ifdef CONFIG_PM_SLEEP_DEBUG
> > > and used outside of it. And that breaks kernel build:
> > > 
> > > /home/viresh/linux/drivers/base/power/wakeup.c:871: undefined reference 
> > > to `wakeup_irq'
> > > /home/viresh/drivers/base/power/wakeup.c:871: undefined reference to 
> > > `wakeup_irq'
> > > 
> > > Fix it by defining the variable outside of the ifdef.
> > > 
> > > Fixes: d1e59c235322 ("PM / sleep: Report interrupt that caused system 
> > > wakeup")
> > > Signed-off-by: Viresh Kumar 
> > 
> > I've applied the v11 of the Alexandra's patch that doesn't have this 
> > problem AFAICS.
> 
> For the record, as we have talked on IRC, even the v11 patch suffers
> from this problem and you will be fixing it.

Yes, it was slightly messed up.  Should be better now, though.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REPOST PATCH] ftrace: Remove the unused variant ftrace_update_time

[Minfei Huang]

On 09/15/15 at 01:01pm, Steven Rostedt wrote:
> On Wed, 16 Sep 2015 00:32:02 +0800
> Minfei Huang  wrote:
>  
> > There is one more confusion. Is it valuable to export such info to
> > userspace? What does user do, if kernel exports this?
> 
> Nothing. The dyn_ftrace_total_info is purely for debugging ftrace. It's
> something I use.
> 

hmmm...

Thanks. I don't insist for this patch, if you want to export this
variant to userspace.

Thanks
Minfei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/5] ACPI: Provide better MADT subtable sanity checks

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 03:13:12 PM Al Stone wrote:
> On 09/09/2015 03:09 PM, Al Stone wrote:
> > Currently, the BAD_MADT_ENTRY macro is used to do a very simple sanity
> > check on the various subtables that are defined for the MADT.  The check
> > compares the size of the subtable data structure as defined by ACPICA to
> > the length entry in the subtable.  If they are not the same, the assumption
> > is that the subtable is incorrect.
> > 
> > Over time, the ACPI spec has allowed for MADT subtables where this can
> > never be true (the local SAPIC subtable, for example).  Or, more recently,
> > the spec has accumulated some minor flaws where there are three possible 
> > sizes for a subtable, all of which are valid, but only for specific versions
> > of the spec (the GICC subtable).  In both cases, BAD_MADT_ENTRY reports 
> > these
> > subtables as bad when they are not.  In order to retain some sanity check
> > on the MADT subtables, we now have to special case these subtables.  Of
> > necessity, these special cases have ended up in arch-dependent code (arm64)
> > or an arch has simply decided to forgo the check (ia64).
> > 
> > This patch set replaces the BAD_MADT_ENTRY macro with a function called
> > bad_madt_entry().  This function uses a data set of details about the
> > subtables to provide more sanity checking than before:
> > 
> > -- is the subtable legal for the version given in the FADT?
> > 
> > -- is the subtable legal for the revision of the MADT in use?
> > 
> > -- is the subtable of the proper length (including checking
> >on the one variable length subtable that is currently ignored),
> >given the FADT version and the MADT revision?
> > 
> > Further, this patch set adds in the call to bad_madt_entry() from the 
> > acpi_table_parse_madt() function, allowing it to be used consistently
> > by all architectures, for all subtables, and removing the need for each
> > of the subtable traversal callback functions to use BAD_MADT_ENTRY.
> > 
> > In theory, as the ACPI specification changes, we would only have to add
> > additional information to the data set describing the MADT subtables in
> > order to continue providing sanity checks, even when new subtables are
> > added.
> > 
> > These patches have been tested on an APM Mustang (arm64) and are known to
> > work there.  They have also been cross-compiled for x86 and ia64 with no
> > known failures.
> > 
> > Changes for v3:
> >-- Reviewed-and-tested-by from Sudeep Holla for arm64 parts
> >-- Clearer language in error messages (Graeme Gregory, Timur Tabi)
> >-- Double checked that inserting call to bad_madt_entry() into the
> >   function acpi_parse_entries() does not impact current behavior
> >   (Sudeep Holla)
> >
> > Changes for v2:
> >-- Acked-by on 2/5 from Marc Zyngier and Catalin Marinas for ARM
> >-- Correct faulty end of loop test found by Timur Tabi
> > 
> > 
> > Al Stone (5):
> >   ACPI: add in a bad_madt_entry() function to eventually replace the
> > macro
> >   ACPI / ARM64: remove usage of BAD_MADT_ENTRY/BAD_MADT_GICC_ENTRY
> >   ACPI / IA64: remove usage of BAD_MADT_ENTRY
> >   ACPI / X86: remove usage of BAD_MADT_ENTRY
> >   ACPI: remove definition of BAD_MADT_ENTRY macro
> > 
> >  arch/arm64/include/asm/acpi.h |   8 --
> >  arch/arm64/kernel/smp.c   |   2 -
> >  arch/ia64/kernel/acpi.c   |  20 
> >  arch/x86/kernel/acpi/boot.c   |  27 -
> >  drivers/acpi/tables.c | 245 
> > +-
> >  drivers/irqchip/irq-gic.c |   6 --
> >  include/linux/acpi.h  |   4 -
> >  7 files changed, 244 insertions(+), 68 deletions(-)
> > 
> 
> Ping?  Any additional comments on this version?  I have only received
> feedback from arm64 reviewers so far, over three revisions, even though
> everyone that needs to be (ACPI, ia64, x86) has also been CCd.
> 
> Anyone else before I fix a couple of things for v4 that the arm64 folks
> found?  ACKs?  NAKs?  Please don't bother me, I'm in the merge window :)?

The merge window is actually over, so why would you expect anything like that?

I'm going to apply this series if people have no problems with it.  I do think
it is slightly overkill, but then as long as it works ...

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] arm64: dts: mt8173: add timer node

[Yingjoe Chen]

From: Daniel Kurtz 

Add device node to enable GPT timer. This timer will be
used as sched clock source.

Change-Id: Idc4e3f0ee80b5c36cae6f0f2328f94aafcca1253
Signed-off-by: Daniel Kurtz 
Signed-off-by: Eddie Huang 
Signed-off-by: Yingjoe Chen 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..d763803 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -238,6 +238,15 @@
reg = <0 0x10007000 0 0x100>;
};
 
+   timer: timer@10008000 {
+   compatible = "mediatek,mt8173-timer",
+"mediatek,mt6577-timer";
+   reg = <0 0x10008000 0 0x1000>;
+   interrupts = ;
+   clocks = <&infracfg CLK_INFRA_CLK_13M>,
+<&topckgen CLK_TOP_RTC_SEL>;
+   };
+
pwrap: pwrap@1000d000 {
compatible = "mediatek,mt8173-pwrap";
reg = <0 0x1000d000 0 0x1000>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] arm64: mediatek: enable MTK_TIMER

[Yingjoe Chen]

Enable MTK_TIMER for MediaTek plaform, which will be used as
schedule clock.

Change-Id: Ib77a0bf01193102c755077b6e72e73e477b18e5f
Signed-off-by: Yingjoe Chen 
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 23800a1..8176455 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -42,6 +42,7 @@ config ARCH_MEDIATEK
bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
select ARM_GIC
select PINCTRL
+   select MTK_TIMER
help
  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / sleep: Fix broken builds without CONFIG_PM_SLEEP_DEBUG

[Viresh Kumar]

On 16-09-15, 03:43, Rafael J. Wysocki wrote:
> On Tuesday, September 15, 2015 01:42:21 PM Viresh Kumar wrote:
> > The variable 'wakeup_irq' is defined within #ifdef CONFIG_PM_SLEEP_DEBUG
> > and used outside of it. And that breaks kernel build:
> > 
> > /home/viresh/linux/drivers/base/power/wakeup.c:871: undefined reference to 
> > `wakeup_irq'
> > /home/viresh/drivers/base/power/wakeup.c:871: undefined reference to 
> > `wakeup_irq'
> > 
> > Fix it by defining the variable outside of the ifdef.
> > 
> > Fixes: d1e59c235322 ("PM / sleep: Report interrupt that caused system 
> > wakeup")
> > Signed-off-by: Viresh Kumar 
> 
> I've applied the v11 of the Alexandra's patch that doesn't have this problem 
> AFAICS.

For the record, as we have talked on IRC, even the v11 patch suffers
from this problem and you will be fixing it.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Viresh Kumar]

On 16-09-15, 04:06, Rafael J. Wysocki wrote:
> In any case, please just split the EC-related changes off from your second
> patch and send them separately.

That !! change isn't required anymore, will be dropping it completely.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver

[Dave Young]

> >> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
> >> new file mode 100644
> >> index 000..7ae45cc
> >> --- /dev/null
> >> +++ b/drivers/watchdog/sbsa_gwdt.c
> >> @@ -0,0 +1,459 @@
> >> +/*
> >> + * SBSA(Server Base System Architecture) Generic Watchdog driver
> >> + *
> >> + * Copyright (c) 2015, Linaro Ltd.
> >> + * Author: Fu Wei 
> >> + * Suravee Suthikulpanit 
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License 2 as published
> >> + * by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * The SBSA Generic watchdog driver is compatible with the pretimeout
> >> + * concept of Linux kernel.
> >> + * The timeout and pretimeout are determined by WCV or WOR.
> >> + * The first watch period is set by writing WCV directly, that can
> >> + * support more than 10s timeout at the maximum system counter
> >> + * frequency (400MHz).
> >> + * When WS0 is triggered, the second watch period (pretimeout) is
> >> + * determined by one of these registers:
> >> + * (1)WOR: 32bit register, this gives a maximum watch period of
> >> + * around 10s at the maximum system counter frequency. It's loaded
> >> + * automatically by hardware.
> >> + * (2)WCV: If the pretimeout value is greater then "max_wor_timeout",
> >> + * it will be loaded in WS0 interrupt routine. If system is in
> >> + * ws0_mode (reboot by kexec/kdump in panic with watchdog enabled
> >> + * and WS0 == true), the ping operation will only reload WCV.
> >
> > Below is the field comment about ws0_mode, it says ws0_mode is only
> > for rebooting in second stage timeout, but kexec/kdump can reboot in
> > either first or second stage
> 
> Great thanks for your feedback.
> 
> yes, if kexec/kdump reboot the system before the WS0, ws0_mode may not be set.
> in this case, if WS0 is triggered during the reboot(AFAIK, panic will
> disable irq, and in the early boot stage of system, irq is disabled,
> too.), ws0_mode will be set at the next "open" in kdump kernel
> if WS0 haven't triggered until the watchdog is opened again in kdump
> kernel , ws0_mode won't  be set.
> 
> ws0_mode doesn't indicate if the system is in the kdump kernel, it
> indicates that if WS0 is triggered, when the watchdog is initialized.
> 
> Do I answer your question?

Yes, thanks for explanation. So it sounds better to change the comment like 
below?
from
(reboot by kexec/kdump in panic with watchdog enabled and WS0 == true)
to
(reboot in the pre-timeout stage and WS0 == true)

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] jump_label: make static_key_enabled() work on static_key_true/false types too

[Tejun Heo]

static_key_enabled() can be used on struct static_key but not on its
wrapper types static_key_true and static_key_false.  The function is
useful for debugging and management of static keys.  Update it so that
it can be used for the wrapper types too.

Signed-off-by: Tejun Heo 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
---
Hello,

If this patch is acceptable, please let me know how it should be
routed.

Thanks.

 include/linux/jump_label.h | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 7f653e8..c9ca050 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -216,11 +216,6 @@ static inline int jump_label_apply_nops(struct module *mod)
 #define STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
 #define jump_label_enabled static_key_enabled
 
-static inline bool static_key_enabled(struct static_key *key)
-{
-   return static_key_count(key) > 0;
-}
-
 static inline void static_key_enable(struct static_key *key)
 {
int count = static_key_count(key);
@@ -267,6 +262,17 @@ struct static_key_false {
 #define DEFINE_STATIC_KEY_FALSE(name)  \
struct static_key_false name = STATIC_KEY_FALSE_INIT
 
+extern bool wrong_branch_error(void);
+
+#define static_key_enabled(x)  
\
+({ 
\
+   if (!__builtin_types_compatible_p(typeof(*x), struct static_key) && 
\
+   !__builtin_types_compatible_p(typeof(*x), struct static_key_true) 
&&\
+   !__builtin_types_compatible_p(typeof(*x), struct static_key_false)) 
\
+   wrong_branch_error();   
\
+   static_key_count((struct static_key *)x) > 0;   
\
+})
+
 #ifdef HAVE_JUMP_LABEL
 
 /*
@@ -325,8 +331,6 @@ struct static_key_false {
  * See jump_label_type() / jump_label_init_type().
  */
 
-extern bool wrong_branch_error(void);
-
 #define static_branch_likely(x)
\
 ({ 
\
bool branch;
\
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] cgroup: replace cgroup_subsys->disabled tests with cgroup_subsys_enabled()

[Tejun Heo]

Replace cgroup_subsys->disabled tests in controllers with
cgroup_subsys_enabled().  cgroup_subsys_enabled() requires literal
subsys name as its parameter and thus can't be used for cgroup core
which iterates through controllers.  For cgroup core, introduce and
use cgroup_ssid_enabled() which uses slower static_key_enabled() test
and can be indexed by subsys ID.

This leaves cgroup_subsys->disabled unused.  Removed.

Signed-off-by: Tejun Heo 
Cc: Li Zefan 
Cc: Johannes Weiner 
Cc: Michal Hocko 
---
 include/linux/cgroup-defs.h|  1 -
 include/linux/hugetlb_cgroup.h |  4 +---
 include/linux/memcontrol.h |  4 +---
 kernel/cgroup.c| 28 +---
 4 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 4d8fcf2..c5d41c3 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -419,7 +419,6 @@ struct cgroup_subsys {
 struct task_struct *task);
void (*bind)(struct cgroup_subsys_state *root_css);
 
-   int disabled;
int early_init;
 
/*
diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
index bcc853e..7edd305 100644
--- a/include/linux/hugetlb_cgroup.h
+++ b/include/linux/hugetlb_cgroup.h
@@ -48,9 +48,7 @@ int set_hugetlb_cgroup(struct page *page, struct 
hugetlb_cgroup *h_cg)
 
 static inline bool hugetlb_cgroup_disabled(void)
 {
-   if (hugetlb_cgrp_subsys.disabled)
-   return true;
-   return false;
+   return !cgroup_subsys_enabled(hugetlb_cgrp_subsys);
 }
 
 extern int hugetlb_cgroup_charge_cgroup(int idx, unsigned long nr_pages,
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index ad800e6..9aa7820 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -347,9 +347,7 @@ ino_t page_cgroup_ino(struct page *page);
 
 static inline bool mem_cgroup_disabled(void)
 {
-   if (memory_cgrp_subsys.disabled)
-   return true;
-   return false;
+   return !cgroup_subsys_enabled(memory_cgrp_subsys);
 }
 
 /*
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 3619389..5703ba7 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -224,6 +224,19 @@ static void kill_css(struct cgroup_subsys_state *css);
 static int cgroup_addrm_files(struct cgroup *cgrp, struct cftype cfts[],
  bool is_add);
 
+/**
+ * cgroup_ssid_enabled - cgroup subsys enabled test by subsys ID
+ * @ssid: subsys ID of interest
+ *
+ * cgroup_subsys_enabled() can only be used with literal subsys names which
+ * is fine for individual subsystems but unsuitable for cgroup core.  This
+ * is slower static_key_enabled() based test indexed by @ssid.
+ */
+static bool cgroup_ssid_enabled(int ssid)
+{
+   return static_key_enabled(cgroup_subsys_enabled_key[ssid]);
+}
+
 /* IDR wrappers which synchronize using cgroup_idr_lock */
 static int cgroup_idr_alloc(struct idr *idr, void *ptr, int start, int end,
gfp_t gfp_mask)
@@ -1482,7 +1495,7 @@ static int parse_cgroupfs_options(char *data, struct 
cgroup_sb_opts *opts)
for_each_subsys(ss, i) {
if (strcmp(token, ss->legacy_name))
continue;
-   if (ss->disabled)
+   if (!cgroup_ssid_enabled(i))
continue;
 
/* Mutually exclusive option 'all' + subsystem name */
@@ -1513,7 +1526,7 @@ static int parse_cgroupfs_options(char *data, struct 
cgroup_sb_opts *opts)
 */
if (all_ss || (!one_ss && !opts->none && !opts->name))
for_each_subsys(ss, i)
-   if (!ss->disabled)
+   if (cgroup_ssid_enabled(i))
opts->subsys_mask |= (1 << i);
 
/*
@@ -2762,7 +2775,8 @@ static ssize_t cgroup_subtree_control_write(struct 
kernfs_open_file *of,
if (tok[0] == '\0')
continue;
for_each_subsys_which(ss, ssid, &tmp_ss_mask) {
-   if (ss->disabled || strcmp(tok + 1, ss->name))
+   if (!cgroup_ssid_enabled(ssid) ||
+   strcmp(tok + 1, ss->name))
continue;
 
if (*tok == '+') {
@@ -3320,7 +3334,7 @@ static int cgroup_add_cftypes(struct cgroup_subsys *ss, 
struct cftype *cfts)
 {
int ret;
 
-   if (ss->disabled)
+   if (!cgroup_ssid_enabled(ss->id))
return 0;
 
if (!cfts || cfts[0].name[0] == '\0')
@@ -5082,7 +5096,7 @@ int __init cgroup_init(void)
 * disabled flag and cftype registration needs kmalloc,
 * both of which aren't available during early_init.
 */
-   if (ss->disabled)
+   if (!cgroup_ssid_enabled(ssid))
conti

[PATCH 4/4] cgroup: replace cgroup_on_dfl() tests in controllers with cgroup_subsys_on_dfl()

[Tejun Heo]

cgroup_on_dfl() tests whether the cgroup's root is the default
hierarchy; however, an individual controller is only interested in
whether the controller is attached to the default hierarchy and never
tests a cgroup which doesn't belong to the hierarchy that the
controller is attached to.

This patch replaces cgroup_on_dfl() tests in controllers with faster
static_key based cgroup_subsys_on_dfl().  This leaves cgroup core as
the only user of cgroup_on_dfl() and the function is moved from the
header file to cgroup.c.

Signed-off-by: Tejun Heo 
Cc: Vivek Goyal 
Cc: Jens Axboe 
Cc: Li Zefan 
Cc: Johannes Weiner 
Cc: Michal Hocko 
---
 block/blk-throttle.c   |  2 +-
 block/cfq-iosched.c|  4 ++--
 include/linux/cgroup.h | 58 --
 kernel/cgroup.c| 58 ++
 kernel/cpuset.c| 23 +++-
 mm/memcontrol.c|  4 ++--
 6 files changed, 76 insertions(+), 73 deletions(-)

diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index c75a263..2149a1d 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -369,7 +369,7 @@ static void throtl_pd_init(struct blkg_policy_data *pd)
 * regardless of the position of the group in the hierarchy.
 */
sq->parent_sq = &td->service_queue;
-   if (cgroup_on_dfl(blkg->blkcg->css.cgroup) && blkg->parent)
+   if (cgroup_subsys_on_dfl(io_cgrp_subsys) && blkg->parent)
sq->parent_sq = &blkg_to_tg(blkg->parent)->service_queue;
tg->td = td;
 }
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 04de884..1f9093e 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -1581,7 +1581,7 @@ static struct blkcg_policy_data *cfq_cpd_alloc(gfp_t gfp)
 static void cfq_cpd_init(struct blkcg_policy_data *cpd)
 {
struct cfq_group_data *cgd = cpd_to_cfqgd(cpd);
-   unsigned int weight = cgroup_on_dfl(blkcg_root.css.cgroup) ?
+   unsigned int weight = cgroup_subsys_on_dfl(io_cgrp_subsys) ?
  CGROUP_WEIGHT_DFL : CFQ_WEIGHT_LEGACY_DFL;
 
if (cpd_to_blkcg(cpd) == &blkcg_root)
@@ -1599,7 +1599,7 @@ static void cfq_cpd_free(struct blkcg_policy_data *cpd)
 static void cfq_cpd_bind(struct blkcg_policy_data *cpd)
 {
struct blkcg *blkcg = cpd_to_blkcg(cpd);
-   bool on_dfl = cgroup_on_dfl(blkcg_root.css.cgroup);
+   bool on_dfl = cgroup_subsys_on_dfl(io_cgrp_subsys);
unsigned int weight = on_dfl ? CGROUP_WEIGHT_DFL : 
CFQ_WEIGHT_LEGACY_DFL;
 
if (blkcg == &blkcg_root)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index c3a9f1e..355bf2e 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -433,64 +433,6 @@ static inline struct cgroup *task_cgroup(struct 
task_struct *task,
return task_css(task, subsys_id)->cgroup;
 }
 
-/**
- * cgroup_on_dfl - test whether a cgroup is on the default hierarchy
- * @cgrp: the cgroup of interest
- *
- * The default hierarchy is the v2 interface of cgroup and this function
- * can be used to test whether a cgroup is on the default hierarchy for
- * cases where a subsystem should behave differnetly depending on the
- * interface version.
- *
- * The set of behaviors which change on the default hierarchy are still
- * being determined and the mount option is prefixed with __DEVEL__.
- *
- * List of changed behaviors:
- *
- * - Mount options "noprefix", "xattr", "clone_children", "release_agent"
- *   and "name" are disallowed.
- *
- * - When mounting an existing superblock, mount options should match.
- *
- * - Remount is disallowed.
- *
- * - rename(2) is disallowed.
- *
- * - "tasks" is removed.  Everything should be at process granularity.  Use
- *   "cgroup.procs" instead.
- *
- * - "cgroup.procs" is not sorted.  pids will be unique unless they got
- *   recycled inbetween reads.
- *
- * - "release_agent" and "notify_on_release" are removed.  Replacement
- *   notification mechanism will be implemented.
- *
- * - "cgroup.clone_children" is removed.
- *
- * - "cgroup.subtree_populated" is available.  Its value is 0 if the cgroup
- *   and its descendants contain no task; otherwise, 1.  The file also
- *   generates kernfs notification which can be monitored through poll and
- *   [di]notify when the value of the file changes.
- *
- * - cpuset: tasks will be kept in empty cpusets when hotplug happens and
- *   take masks of ancestors with non-empty cpus/mems, instead of being
- *   moved to an ancestor.
- *
- * - cpuset: a task can be moved into an empty cpuset, and again it takes
- *   masks of ancestors.
- *
- * - memcg: use_hierarchy is on by default and the cgroup file for the flag
- *   is not created.
- *
- * - blkcg: blk-throttle becomes properly hierarchical.
- *
- * - debug: disallowed on the default hierarchy.
- */
-static inline bool cgroup_on_dfl(const struct cgroup *cgrp)
-{
-   return cgrp->root == &cgrp_dfl_root;
-}
-
 /* no synchronization, t

[PATCH 2/4] cgroup: implement static_key based cgroup_subsys_enabled() and cgroup_subsys_on_dfl()

[Tejun Heo]

Whether a subsys is enabled and attached to the default hierarchy
seldom changes and may be tested in the hot paths.  This patch
implements static_key based cgroup_subsys_enabled() and
cgroup_subsys_on_dfl() tests.

The following patches will update the users and remove duplicate
mechanisms.

Signed-off-by: Tejun Heo 
---
 include/linux/cgroup.h | 21 +
 kernel/cgroup.c| 27 ++-
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index eb7ca55..c3a9f1e 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -50,6 +51,26 @@ extern struct css_set init_css_set;
 #include 
 #undef SUBSYS
 
+#define SUBSYS(_x) 
\
+   extern struct static_key_true _x ## _cgrp_subsys_enabled_key;   
\
+   extern struct static_key_true _x ## _cgrp_subsys_on_dfl_key;
+#include 
+#undef SUBSYS
+
+/**
+ * cgroup_subsys_enabled - fast test on whether a subsys is enabled
+ * @ss: subsystem in question
+ */
+#define cgroup_subsys_enabled(ss)  
\
+   static_branch_likely(&ss ## _enabled_key)
+
+/**
+ * cgroup_subsys_on_dfl - fast test on whether a subsys is on default hierarchy
+ * @ss: subsystem in question
+ */
+#define cgroup_subsys_on_dfl(ss)   
\
+   static_branch_likely(&ss ## _on_dfl_key)
+
 bool css_has_online_children(struct cgroup_subsys_state *css);
 struct cgroup_subsys_state *css_from_id(int id, struct cgroup_subsys *ss);
 struct cgroup_subsys_state *cgroup_get_e_css(struct cgroup *cgroup,
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 2cf0f79..3619389 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -139,6 +139,27 @@ static const char *cgroup_subsys_name[] = {
 };
 #undef SUBSYS
 
+/* array of static_keys for cgroup_subsys_enabled() and cgroup_subsys_on_dfl() 
*/
+#define SUBSYS(_x) 
\
+   DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_enabled_key); 
\
+   DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_on_dfl_key);  
\
+   EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_enabled_key);  
\
+   EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_on_dfl_key);
+#include 
+#undef SUBSYS
+
+#define SUBSYS(_x) [_x ## _cgrp_id] = &_x ## _cgrp_subsys_enabled_key,
+static struct static_key_true *cgroup_subsys_enabled_key[] = {
+#include 
+};
+#undef SUBSYS
+
+#define SUBSYS(_x) [_x ## _cgrp_id] = &_x ## _cgrp_subsys_on_dfl_key,
+static struct static_key_true *cgroup_subsys_on_dfl_key[] = {
+#include 
+};
+#undef SUBSYS
+
 /*
  * The default hierarchy, reserved for the subsystems that are otherwise
  * unattached - it never has more than a single cgroup, and all tasks are
@@ -1319,9 +1340,12 @@ static int rebind_subsystems(struct cgroup_root 
*dst_root,
 
/* default hierarchy doesn't enable controllers by default */
dst_root->subsys_mask |= 1 << ssid;
-   if (dst_root != &cgrp_dfl_root) {
+   if (dst_root == &cgrp_dfl_root) {
+   static_branch_enable(cgroup_subsys_on_dfl_key[ssid]);
+   } else {
dst_root->cgrp.subtree_control |= 1 << ssid;
cgroup_refresh_child_subsys_mask(&dst_root->cgrp);
+   static_branch_disable(cgroup_subsys_on_dfl_key[ssid]);
}
 
if (ss->bind)
@@ -5483,6 +5507,7 @@ static int __init cgroup_disable(char *str)
strcmp(token, ss->legacy_name))
continue;
 
+   static_branch_disable(cgroup_subsys_enabled_key[i]);
ss->disabled = 1;
printk(KERN_INFO "Disabling %s control group 
subsystem\n",
   ss->name);
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/