Re: [PATCH 1/2] tpm, tpm_tis: use acpi_driver instead of pnp_driver

[Jarkko Sakkinen]

On Tue, Sep 29, 2015 at 06:30:25PM +0100, Matthew Garrett wrote:
> On Tue, Sep 29, 2015 at 08:07:10PM +0300, Jarkko Sakkinen wrote:
> > Migrate to struct acpi_driver in order to get out of 7 character
> > limitation for the HID.
> 
> Are we guaranteed that there are no old systems reporting these devices 
> via pnpbios rather than acpi?

Right. I think it would make sense to be conservative and use
acpi_driver only for MSFT0101 because at least I don't know answer
to this question. It would be a risk to take these fixes to the stable
kernels othwerwise.

> -- 
> Matthew Garrett | mj...@srcf.ucam.org

/Jarkko
--
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] tpm, tpm_tis: use acpi_driver instead of pnp_driver

[Jarkko Sakkinen]

On Tue, Sep 29, 2015 at 11:26:53AM -0600, Jason Gunthorpe wrote:
> On Tue, Sep 29, 2015 at 08:07:10PM +0300, Jarkko Sakkinen wrote:
> 
> > -static struct pnp_device_id tpm_pnp_tbl[] = {
> > +static struct acpi_device_id tpm_acpi_tbl[] = {
> > {"PNP0C31", 0}, /* TPM */
> > {"ATM1200", 0}, /* Atmel */
> > {"IFX0102", 0}, /* Infineon */
> > @@ -925,28 +941,34 @@ static struct pnp_device_id tpm_pnp_tbl[] = {
> > {"", 0},/* User Specified */
> > {"", 0} /* Terminator */
> >  };
> 
> Is this OK? I don't know alot about x86 PNP, but I thought the
> pnp_device_id scheme would work with ACPI and legacy PNPBIOS stuff,
> and changing to ACPI means ACPI only?
> 
> If so, should we care? Is there a spec for non-ACPI TPM discovery we
> need to be following here?

I found at least all the IDs listed from drivers/acpi/acpi_pnp.c but you
might be right that they might be (don't know) with pnpbios.

Maybe a better solution would to have two tables and have only MSFT0101
in tpm_acpi_tbl in order to make sure that old functionality is not
broken up because we want this also to the stable kernels.

/Jarkko
--
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 v5 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

[maitysanchayan]

Hello Shawn,

The driver has landed in your tree. Can you queue this DT change for the same?

Thanks.

- Sanchayan.

On 15-09-01 18:06:53, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vf500-colibri-eval-v3.dts |  5 +++
>  arch/arm/boot/dts/vf500-colibri.dtsi| 47 
> +
>  2 files changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> index 7fc782c..c3173fc 100644
> --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> @@ -15,3 +15,8 @@
>   model = "Toradex Colibri VF50 on Colibri Evaluation Board";
>   compatible = "toradex,vf500-colibri_vf50-on-eval", 
> "toradex,vf500-colibri_vf50", "fsl,vf500";
>  };
> +
> + {
> + vf50-ts-min-pressure = <200>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi 
> b/arch/arm/boot/dts/vf500-colibri.dtsi
> index cee34a3..84f091d 100644
> --- a/arch/arm/boot/dts/vf500-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
> @@ -17,4 +17,51 @@
>   memory {
>   reg = <0x8000 0x800>;
>   };
> +
> + touchscreen: vf50-touchscreen {
> + compatible = "toradex,vf50-touchscreen";
> + io-channels = < 0>,< 0>,
> + < 1>,< 2>;
> + xp-gpios = < 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = < 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = < 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = < 4 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <>;
> + interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <_touchctrl_idle>;
> + pinctrl-1 = <_touchctrl_default>;
> + pinctrl-2 = <_touchctrl_gpios>;
> + vf50-ts-min-pressure = <200>;
> + status = "disabled";
> + };
> +};
> +
> + {
> + vf610-colibri {
> + pinctrl_touchctrl_idle: touchctrl_idle {
> + fsl,pins = <
> + VF610_PAD_PTA18__GPIO_8 0x006d
> + VF610_PAD_PTA19__GPIO_9 0x006c
> + >;
> + };
> +
> + pinctrl_touchctrl_default: touchctrl_default {
> + fsl,pins = <
> + VF610_PAD_PTA18__ADC0_SE0   0x0040
> + VF610_PAD_PTA19__ADC0_SE1   0x0040
> + VF610_PAD_PTA16__ADC1_SE0   0x0040
> + VF610_PAD_PTB2__ADC1_SE20x0040
> + >;
> + };
> +
> + pinctrl_touchctrl_gpios: touchctrl_gpios {
> + fsl,pins = <
> + VF610_PAD_PTA23__GPIO_130x22e9
> + VF610_PAD_PTB23__GPIO_930x22e9
> + VF610_PAD_PTA22__GPIO_120x22e9
> + VF610_PAD_PTA11__GPIO_4 0x22e9
> + >;
> + };
> + };
>  };
> -- 
> 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: List corruption on epoll_ctl(EPOLL_CTL_DEL) an AF_UNIX socket

[Mathias Krause]

On 29 September 2015 at 21:09, Jason Baron  wrote:
> However, if we call connect on socket 's', to connect to a new socket 'o2', we
> drop the reference on the original socket 'o'. Thus, we can now close socket
> 'o' without unregistering from epoll. Then, when we either close the ep
> or unregister 'o', we end up with this list corruption. Thus, this is not a
> race per se, but can be triggered sequentially.

Sounds profound, but the reproducers calls connect only once per
socket. So there is no "connect to a new socket", no?
But w/e, see below.

> Linus explains the general case in the context the signalfd stuff here:
> https://lkml.org/lkml/2013/10/14/634

I also found that posting while looking for similar bug reports. Also
found that one: https://lkml.org/lkml/2014/5/15/532

> So this may be the case that we've been chasing here for a while...

That bug triggers since commit 3c73419c09 "af_unix: fix 'poll for
write'/ connected DGRAM sockets". That's v2.6.26-rc7, as noted in the
reproducer.

>
> In any case, we could fix with that same POLLFREE mechansim, the simplest
> would be something like:
>
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 03ee4d3..d499f81 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -392,6 +392,9 @@ static void unix_sock_destructor(struct sock *sk)
> pr_debug("UNIX %p is destroyed, %ld are still alive.\n", sk,
> atomic_long_read(_nr_socks));
>  #endif
> +   /* make sure we remove from epoll */
> +   wake_up_poll(>peer_wait, POLLFREE);
> +   synchronize_sched();
>  }
>
>  static void unix_release_sock(struct sock *sk, int embrion)
>
> I'm not suggesting we apply that, but that fixed the supplied test case.
> We could enhance the above, to avoid the free'ing latency there by doing
> the SLAB_DESTROY_BY_RCU for unix sockets. But I'm not convinced
> that this wouldn't be still broken for select()/poll() as well. I think
> we can be in a select() call for socket 's', and if we remove socket
> 'o' from it in the meantime (by doing a connect() on s to somewhere else
> and a close on 'o'), I think we can still crash there. So POLLFREE would
> have to be extended. I tried to hit this with select() but could not,
> but I think if I tried harder I could.
>
> Instead of going further down that route, perhaps something like below
> might be better. The basic idea would be to do away with the 'other'
> poll call in unix_dgram_poll(), and instead revert back to a registering
> on a single wait queue. We add a new wait queue to unix sockets such
> that we can register it with a remote other on connect(). Then we can
> use the wakeup from the remote to wake up the registered unix socket.
> Probably better explained with the patch below. Note I didn't add to
> the remote for SOCK_STREAM, since the poll() routine there doesn't do
> the double wait queue registering:
>
> diff --git a/include/net/af_unix.h b/include/net/af_unix.h
> index 4a167b3..9698aff 100644
> --- a/include/net/af_unix.h
> +++ b/include/net/af_unix.h
> @@ -62,6 +62,7 @@ struct unix_sock {
>  #define UNIX_GC_CANDIDATE  0
>  #define UNIX_GC_MAYBE_CYCLE1
> struct socket_wqpeer_wq;
> +   wait_queue_twait;
>  };
>  #define unix_sk(__sk) ((struct unix_sock *)__sk)
>
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 03ee4d3..9e0692a 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -420,6 +420,8 @@ static void unix_release_sock(struct sock *sk, int 
> embrion)
> skpair = unix_peer(sk);
>
> if (skpair != NULL) {
> +   if (sk->sk_type != SOCK_STREAM)
> +   remove_wait_queue(_sk(skpair)->peer_wait, 
> >wait);
> if (sk->sk_type == SOCK_STREAM || sk->sk_type == 
> SOCK_SEQPACKET) {
> unix_state_lock(skpair);
> /* No more writes */
> @@ -636,6 +638,16 @@ static struct proto unix_proto = {
>   */
>  static struct lock_class_key af_unix_sk_receive_queue_lock_key;
>
> +static int peer_wake(wait_queue_t *wait, unsigned mode, int sync, void *key)
> +{
> +   struct unix_sock *u;
> +
> +   u = container_of(wait, struct unix_sock, wait);
> +   wake_up_interruptible_sync_poll(sk_sleep(>sk), key);
> +
> +   return 0;
> +}
> +
>  static struct sock *unix_create1(struct net *net, struct socket *sock, int 
> kern)
>  {
> struct sock *sk = NULL;
> @@ -664,6 +676,7 @@ static struct sock *unix_create1(struct net *net, struct 
> socket *sock, int kern)
> INIT_LIST_HEAD(>link);
> mutex_init(>readlock); /* single task reading lock */
> init_waitqueue_head(>peer_wait);
> +   init_waitqueue_func_entry(>wait, peer_wake);
> unix_insert_socket(unix_sockets_unbound(sk), sk);
>  out:
> if (sk == NULL)
> @@ -1030,7 +1043,10 @@ restart:
>  */
> if (unix_peer(sk)) {
> struct sock *old_peer = unix_peer(sk);
> +
> + 

Re: [PATCH 3.14 00/84] 3.14.54-stable review

[Sudip Mukherjee]

On Tue, Sep 29, 2015 at 05:17:52PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.54 release.
> There are 84 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Oct  1 14:52:55 UTC 2015.
> Anything received after that time might be too late.
Compiled and booted on x86_32. No errors in dmesg.

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/

[tip:x86/urgent] x86/hyperv: Fix the build in the !CONFIG_KEXEC_CORE case

[tip-bot for Vitaly Kuznetsov]

Commit-ID:  1e034743e918d195d339af340ae933727c072bce
Gitweb: http://git.kernel.org/tip/1e034743e918d195d339af340ae933727c072bce
Author: Vitaly Kuznetsov 
AuthorDate: Wed, 23 Sep 2015 12:02:57 +0200
Committer:  Ingo Molnar 
CommitDate: Wed, 30 Sep 2015 07:44:15 +0200

x86/hyperv: Fix the build in the !CONFIG_KEXEC_CORE case

Recent changes in the Hyper-V driver:

  b4370df2b1f5 ("Drivers: hv: vmbus: add special crash handler")

broke the build when CONFIG_KEXEC_CORE is not set:

  arch/x86/built-in.o: In function `hv_machine_crash_shutdown':
  arch/x86/kernel/cpu/mshyperv.c:112: undefined reference to 
`native_machine_crash_shutdown'

Decorate all kexec related code with #ifdef CONFIG_KEXEC_CORE.

Reported-by: Jim Davis 
Reported-by: Stephen Hemminger 
Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: Thomas Gleixner 
Cc: de...@linuxdriverproject.org
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Greg Kroah-Hartman 
Cc: Peter Zijlstra 
Cc: Linus Torvalds 
Link: 
http://lkml.kernel.org/r/1443002577-25370-1-git-send-email-vkuzn...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/mshyperv.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 381c8b9..20e242e 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -34,11 +34,10 @@
 struct ms_hyperv_info ms_hyperv;
 EXPORT_SYMBOL_GPL(ms_hyperv);
 
-static void (*hv_kexec_handler)(void);
-static void (*hv_crash_handler)(struct pt_regs *regs);
-
 #if IS_ENABLED(CONFIG_HYPERV)
 static void (*vmbus_handler)(void);
+static void (*hv_kexec_handler)(void);
+static void (*hv_crash_handler)(struct pt_regs *regs);
 
 void hyperv_vector_handler(struct pt_regs *regs)
 {
@@ -96,8 +95,8 @@ void hv_remove_crash_handler(void)
hv_crash_handler = NULL;
 }
 EXPORT_SYMBOL_GPL(hv_remove_crash_handler);
-#endif
 
+#ifdef CONFIG_KEXEC_CORE
 static void hv_machine_shutdown(void)
 {
if (kexec_in_progress && hv_kexec_handler)
@@ -111,7 +110,8 @@ static void hv_machine_crash_shutdown(struct pt_regs *regs)
hv_crash_handler(regs);
native_machine_crash_shutdown(regs);
 }
-
+#endif /* CONFIG_KEXEC_CORE */
+#endif /* CONFIG_HYPERV */
 
 static uint32_t  __init ms_hyperv_platform(void)
 {
@@ -186,8 +186,10 @@ static void __init ms_hyperv_init_platform(void)
no_timer_check = 1;
 #endif
 
+#if IS_ENABLED(CONFIG_HYPERV) && defined(CONFIG_KEXEC_CORE)
machine_ops.shutdown = hv_machine_shutdown;
machine_ops.crash_shutdown = hv_machine_crash_shutdown;
+#endif
mark_tsc_unstable("running on Hyper-V");
 }
 
--
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 3.10 00/56] 3.10.90-stable review

[Sudip Mukherjee]

On Tue, Sep 29, 2015 at 03:46:48PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.90 release.
> There are 56 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Oct  1 13:46:31 UTC 2015.
> Anything received after that time might be too late.
Compiled and booted on x86_32. No errors in dmesg.

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: [tip:x86/urgent] x86/hyperv: Fix the build in the CONFIG_KEXEC_CORE=y case

[Ingo Molnar]

* Vitaly Kuznetsov  wrote:

> tip-bot for Vitaly Kuznetsov  writes:
> 
> > Commit-ID:  7d381b749a010ccd48d5649c843cac0d14d1c229
> > Gitweb: 
> > http://git.kernel.org/tip/7d381b749a010ccd48d5649c843cac0d14d1c229
> > Author: Vitaly Kuznetsov 
> > AuthorDate: Wed, 23 Sep 2015 12:02:57 +0200
> > Committer:  Ingo Molnar 
> > CommitDate: Tue, 29 Sep 2015 09:37:06 +0200
> >
> > x86/hyperv: Fix the build in the CONFIG_KEXEC_CORE=y case
> 
> It was '!CONFIG_KEXEC_CORE' in the original patch so I'd expect to see
> 'CONFIG_KEXEC_CORE=n' here (if the '!' sign causes issues).
> 
> [...]

Ok, fixed it up.

Thanks,

Ingo
--
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 2/2] iio:light:tsl2563: Add DT support

[Peter Meerwald]

Hello Suresh,

> * Add Device Tree support for the Dyna Image AP3223 ambient light sensor and
> * proximity driver,
> * Document the binding and
> * Add a vendor prefix for Dyna Image

the mail's subject line should read something like
iio: light: Add AP3223 DT support

tsl2563 is a different driver

> v2
> * Seperating the device tree changes from code

Separating

> 
> Signed-off-by: Suresh Rajashekara 
> ---
>  Documentation/devicetree/bindings/iio/light/ap3223.txt | 18 
> ++
>  Documentation/devicetree/bindings/vendor-prefixes.txt  |  1 +
>  2 files changed, 19 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/light/ap3223.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/light/ap3223.txt 
> b/Documentation/devicetree/bindings/iio/light/ap3223.txt
> new file mode 100644
> index 000..b255d27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/ap3223.txt
> @@ -0,0 +1,18 @@
> +* Dyna Image AP3223 ambient light sensor and proximity sensor
> +
> +http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2=8
> +
> +Required properties:
> +
> +  - compatible : should be "dynaimage,ap3223"
> +  - reg : the I2C address of the sensor
> +
> +Example:
> +
> +ap3223@1c {
> + compatible = "dynaimage,ap3223";
> + reg = <0x1c>;
> +
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 5f20add..704da45 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -46,6 +46,7 @@ digilentDiglent, Inc.
>  dlg  Dialog Semiconductor
>  dlinkD-Link Corporation
>  dmo  Data Modul AG
> +dynaimageDyna-Image
>  ebv  EBV Elektronik
>  edt  Emerging Display Technologies
>  elan Elan Microelectronic Corp.
> 

-- 

Peter Meerwald
+43-664-218 (mobile)
--
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 v15 1/2] arm:dts:ls1021a: Add DCU dts node

[Shawn Guo]

On Thu, Aug 27, 2015 at 02:13:46PM +0800, Jianwei Wang wrote:
> Add DCU node, DCU is a display controller of Freescale
> named 2D-ACE.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 

When you resend, please use "ARM: dts: ls1021a: ..." as subject prefix.

Shawn
--
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/

Loan Offer

[Loan]

Contact us as we offer our finance service at a low and affordable interest 
rate for long and short cash term. Interested applicant should contact us for 
further acquisition procedures. Thanks as we remain obliged to render service 
to you; worldtrading1...@gmail.com
--
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 v15 1/2] arm:dts:ls1021a: Add DCU dts node

[Shawn Guo]

On Thu, Aug 27, 2015 at 02:13:46PM +0800, Jianwei Wang wrote:
> Add DCU node, DCU is a display controller of Freescale
> named 2D-ACE.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 

MAINTAINERS file has been updated for a couple of release cycles.
Please stop using shawn@linaro.org, and resend to
shawn...@kernel.org instead.

Shawn

> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index c70bb27..6d6e3e2 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -383,6 +383,16 @@
><_clk 1>;
>   };
>  
> + dcu: dcu@2ce {
> + compatible = "fsl,ls1021a-dcu";
> + reg = <0x0 0x2ce 0x0 0x1>;
> + interrupts = ;
> + clocks = <_clk 0>;
> + clock-names = "dcu";
> + big-endian;
> + status = "disabled";
> + };
> +
>   mdio0: mdio@2d24000 {
>   compatible = "gianfar";
>   device_type = "mdio";
> -- 
> 2.1.0.27.g96db324
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
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 v5 07/17] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver

[Krzysztof Kozlowski]

On 22.09.2015 16:43, Yakir Yang wrote:
> After exynos_dp have been split the common IP code into analogix_dp driver,
> the analogix_dp driver have deprecated some Samsung platform properties which
> could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
> for Exynos DTS file for dp-controller.
> 
> Beside the backward compatibility is fully preserved, so there are no
> bisectability break that make this change in a separate patch.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v5:
> - Correct the misspell in commit message. (Krzysztof)
> 
> Changes in v4:
> - Separate all DTS changes to a separate patch. (Krzysztof)
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/boot/dts/exynos5250-arndale.dts   | 2 --
>  arch/arm/boot/dts/exynos5250-smdk5250.dts  | 2 --
>  arch/arm/boot/dts/exynos5250-snow.dts  | 4 +---
>  arch/arm/boot/dts/exynos5250-spring.dts| 4 +---
>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 +---
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  | 2 --
>  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 4 +---
>  7 files changed, 4 insertions(+), 18 deletions(-)
> 

Assuming this will be merged as part of this set (dependency on previous
patches):

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

--
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/2] mm: fix declarations of nr, delta and nr_pagecache_reclaimable

[Alexandru Moise]

On Tue, Sep 29, 2015 at 10:28:57PM -0700, Andrew Morton wrote:
> On Wed, 30 Sep 2015 08:10:04 +0300 Alexandru Moise 
> <00moses.alexande...@gmail.com> wrote:
> 
> > > > --- a/mm/vmscan.c
> > > > +++ b/mm/vmscan.c
> > > > @@ -194,7 +194,7 @@ static bool sane_reclaim(struct scan_control *sc)
> > > >  
> > > >  static unsigned long zone_reclaimable_pages(struct zone *zone)
> > > >  {
> > > > -   int nr;
> > > > +   unsigned long nr;
> > > >  
> > > > nr = zone_page_state(zone, NR_ACTIVE_FILE) +
> > > >  zone_page_state(zone, NR_INACTIVE_FILE);
> > > 
> > > OK.
> > > 
> > 
> > Are you sure? Mel Gorman raised the following issue on patch 1/2:
> > 
> > https://lkml.org/lkml/2015/9/29/253
> 
> __zone_watermark_ok() is very different from zone_reclaimable_pages().

Alright, in time I will gain a better understanding of this.
Thanks again.
--
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/

[GIT PULL] RCU fixes

[Ingo Molnar]

Linus,

Please pull the latest core-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
core-urgent-for-linus

   # HEAD: 7c4f1c694bf84eac538bee3e411aed10ae617d46 Merge branch 'for-mingo' of 
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/urgent

Two RCU fixes:

  - Work around bug with recent GCC versions.
  - Fix false positive lockdep splat.

 Thanks,

Ingo

-->
Oleg Nesterov (1):
  rcu: Change _wait_rcu_gp() to work around GCC bug 67055

Paul E. McKenney (1):
  rcu: Suppress lockdep false positive for rcp->exp_funnel_mutex


 include/linux/rcupdate.h | 11 +--
 kernel/rcu/tree.c|  5 +
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index ff476515f716..581abf848566 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -230,12 +230,11 @@ void __wait_rcu_gp(bool checktiny, int n, call_rcu_func_t 
*crcu_array,
   struct rcu_synchronize *rs_array);
 
 #define _wait_rcu_gp(checktiny, ...) \
-do { \
-   call_rcu_func_t __crcu_array[] = { __VA_ARGS__ }; \
-   const int __n = ARRAY_SIZE(__crcu_array); \
-   struct rcu_synchronize __rs_array[__n]; \
-   \
-   __wait_rcu_gp(checktiny, __n, __crcu_array, __rs_array); \
+do {   \
+   call_rcu_func_t __crcu_array[] = { __VA_ARGS__ };   \
+   struct rcu_synchronize __rs_array[ARRAY_SIZE(__crcu_array)];\
+   __wait_rcu_gp(checktiny, ARRAY_SIZE(__crcu_array),  \
+   __crcu_array, __rs_array);  \
 } while (0)
 
 #define wait_rcu_gp(...) _wait_rcu_gp(false, __VA_ARGS__)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 9f75f25cc5d9..775d36cc0050 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3868,6 +3868,7 @@ static void rcu_init_new_rnp(struct rcu_node *rnp_leaf)
 static void __init
 rcu_boot_init_percpu_data(int cpu, struct rcu_state *rsp)
 {
+   static struct lock_class_key rcu_exp_sched_rdp_class;
unsigned long flags;
struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
struct rcu_node *rnp = rcu_get_root(rsp);
@@ -3883,6 +3884,10 @@ rcu_boot_init_percpu_data(int cpu, struct rcu_state *rsp)
mutex_init(>exp_funnel_mutex);
rcu_boot_init_nocb_percpu_data(rdp);
raw_spin_unlock_irqrestore(>lock, flags);
+   if (rsp == _sched_state)
+   lockdep_set_class_and_name(>exp_funnel_mutex,
+  _exp_sched_rdp_class,
+  "rcu_data_exp_sched");
 }
 
 /*
--
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 v5 04/23] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead

[kbuild test robot]

Hi Andrew,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: arm64-allmodconfig (attached as .config)
reproduce:
  wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
  chmod +x ~/bin/make.cross
  git checkout 4035143523cbf0106ee81f3ea585b363110c1ab6
  # save the attached .config to linux build tree
  make.cross ARCH=arm64 

Note: the linux-review/Yury-Norov/ILP32-for-ARM64 HEAD 
3dd1a64760c74c774056fb5635ff933762dd6453 builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/elf.h:4:0,
from include/linux/module.h:15,
from fs/ocfs2/dlm/dlmdomain.c:27:
>> arch/arm64/include/asm/elf.h:202:0: warning: "compat_elf_check_arch" 
>> redefined
#define compat_elf_check_arch(x) compat_a32_elf_check_arch(x)
^
   arch/arm64/include/asm/elf.h:179:0: note: this is the location of the 
previous definition
#define compat_elf_check_arch(x) (((x)->e_machine == EM_ARM) && \
^
   In file included from include/linux/elf.h:4:0,
from include/linux/module.h:15,
from fs/ocfs2/dlm/dlmdomain.c:27:
>> arch/arm64/include/asm/elf.h:202:0: warning: "compat_elf_check_arch" 
>> redefined
#define compat_elf_check_arch(x) compat_a32_elf_check_arch(x)
^
   arch/arm64/include/asm/elf.h:179:0: note: this is the location of the 
previous definition
#define compat_elf_check_arch(x) (((x)->e_machine == EM_ARM) && \
^
--
   In file included from include/linux/elf.h:4:0,
from include/linux/module.h:15,
from fs/ocfs2/dlm/dlmthread.c:28:
>> arch/arm64/include/asm/elf.h:202:0: warning: "compat_elf_check_arch" 
>> redefined
#define compat_elf_check_arch(x) compat_a32_elf_check_arch(x)
^
   arch/arm64/include/asm/elf.h:179:0: note: this is the location of the 
previous definition
#define compat_elf_check_arch(x) (((x)->e_machine == EM_ARM) && \
^
--
   In file included from include/linux/elf.h:4:0,
from arch/arm64/kernel/ptrace.c:39:
>> arch/arm64/include/asm/elf.h:202:0: warning: "compat_elf_check_arch" 
>> redefined
#define compat_elf_check_arch(x) compat_a32_elf_check_arch(x)
^
   arch/arm64/include/asm/elf.h:179:0: note: this is the location of the 
previous definition
#define compat_elf_check_arch(x) (((x)->e_machine == EM_ARM) && \
^
>> arch/arm64/kernel/ptrace.c:880:8: error: 'COMPAT_ELF_NGREG' undeclared here 
>> (not in a function)
  .n = COMPAT_ELF_NGREG,
   ^
--
   In file included from include/linux/elf.h:4:0,
from include/linux/elfcore-compat.h:4,
from fs/compat_binfmt_elf.c:20:
>> arch/arm64/include/asm/elf.h:202:0: warning: "compat_elf_check_arch" 
>> redefined
#define compat_elf_check_arch(x) compat_a32_elf_check_arch(x)
^
   arch/arm64/include/asm/elf.h:179:0: note: this is the location of the 
previous definition
#define compat_elf_check_arch(x) (((x)->e_machine == EM_ARM) && \
^
   In file included from fs/compat_binfmt_elf.c:145:0:
   fs/binfmt_elf.c: In function 'load_elf_interp':
>> fs/binfmt_elf.c:533:2: error: implicit declaration of function 
>> 'compat_a32_elf_check_arch' [-Werror=implicit-function-declaration]
 if (!elf_check_arch(interp_elf_ex))
 ^
   cc1: some warnings being treated as errors

vim +/COMPAT_ELF_NGREG +880 arch/arm64/kernel/ptrace.c

478fcb2c Will Deacon 2012-03-05  874.regsets = aarch32_regsets, .n 
= ARRAY_SIZE(aarch32_regsets)
478fcb2c Will Deacon 2012-03-05  875  };
478fcb2c Will Deacon 2012-03-05  876  
5d220ff9 Catalin Marinas 2015-07-14  877  static const struct user_regset 
aarch32_ptrace_regsets[] = {
5d220ff9 Catalin Marinas 2015-07-14  878[REGSET_GPR] = {
5d220ff9 Catalin Marinas 2015-07-14  879.core_note_type = 
NT_PRSTATUS,
5d220ff9 Catalin Marinas 2015-07-14 @880.n = COMPAT_ELF_NGREG,
5d220ff9 Catalin Marinas 2015-07-14  881.size = 
sizeof(compat_elf_greg_t),
5d220ff9 Catalin Marinas 2015-07-14  882.align = 
sizeof(compat_elf_greg_t),
5d220ff9 Catalin Marinas 2015-07-14  883.get = compat_gpr_get,

:: The code at line 880 was first introduced by commit
:: 5d220ff9420f8b1689805ba2d938bedf9e0860a4 arm64: Better native ptrace 
support for compat tasks

:: TO: Catalin Marinas 
:: CC: Will Deacon 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] staging: rtl8712: remove dead code

[Joshua Clayton]

On Monday, September 28, 2015 10:52:33 PM Luis de Bethencourt wrote:
> The while() loop will only exit in a return or a goto ask_for_joinbss,
> which means it will never break and execute the return after it.
> Removing return _FAIL since it is dead code.
> 
> Signed-off-by: Luis de Bethencourt 
> ---
>  drivers/staging/rtl8712/rtl871x_mlme.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c 
> b/drivers/staging/rtl8712/rtl871x_mlme.c
> index fc5dbea..fbcb248 100644
> --- a/drivers/staging/rtl8712/rtl871x_mlme.c
> +++ b/drivers/staging/rtl8712/rtl871x_mlme.c
> @@ -1190,7 +1190,7 @@ int r8712_select_and_join_from_scan(struct mlme_priv 
> *pmlmepriv)
>   }
>   }
>   }
> - return _FAIL;
> +
>  ask_for_joinbss:
>   return r8712_joinbss_cmd(adapter, pnetwork);
>  }
> 

Yes, that line is unreachable, (no breaks, only returns and gotos to get out of 
the loop).

but ugh, that function is an abomination.
removing the return _FAIL does little to improve the code flow or
readability. 

perhaps a nicer fix would be to change it to follow the convention
of gotos for the failure path, so instead of 5 levels of nesting, 
it would flow naturally toward r8712_joinbss_cmd();
--
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/1] staging: ion: Fix error handling in ion_buffer_create

[Rohit kumar]

This patch fixes error handling case when buffer->pages allocation
fails. Also, it removes unreachable code of checking ret variable
although it is not updated.

Signed-off-by: Rohit kumar 
---
 drivers/staging/android/ion/ion.c |   14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 217aa53..af59e4a 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -213,10 +213,10 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
"heap->ops->map_dma should return ERR_PTR on error"))
table = ERR_PTR(-EINVAL);
if (IS_ERR(table)) {
-   heap->ops->free(buffer);
-   kfree(buffer);
-   return ERR_CAST(table);
+   ret = -EINVAL;
+   goto err1;
}
+
buffer->sg_table = table;
if (ion_buffer_fault_user_mappings(buffer)) {
int num_pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
@@ -226,7 +226,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
buffer->pages = vmalloc(sizeof(struct page *) * num_pages);
if (!buffer->pages) {
ret = -ENOMEM;
-   goto err1;
+   goto err;
}
 
for_each_sg(table->sgl, sg, table->nents, i) {
@@ -235,9 +235,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
for (j = 0; j < sg->length / PAGE_SIZE; j++)
buffer->pages[k++] = page++;
}
-
-   if (ret)
-   goto err;
}
 
buffer->dev = dev;
@@ -261,9 +258,8 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
 
 err:
heap->ops->unmap_dma(heap, buffer);
-   heap->ops->free(buffer);
 err1:
-   vfree(buffer->pages);
+   heap->ops->free(buffer);
 err2:
kfree(buffer);
return ERR_PTR(ret);
-- 
1.7.9.5

--
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/9] drivers:mtd:UBI: add bakvol module for MLC NAND paired page issue

[beanhuo]

> Am 28.09.2015 um 09:02 schrieb Bean Huo 霍斌斌 (beanhuo):
> > Hello,
> >
> > This series aims at adding a bakvol module for MLC NAND paired page
> > Power loss protection.
> > MLC NAND paired page power loss is a known issue so far, MLC NAND
> > pages are coupled in a sense that if you cut power while writing to a
> > page, you corrupt not only this page, but also one of the previous pages
> which is paired with the current one.
> > Currently, there is no a perfect solution for this.
> > This paired page solution is based on NAND multiple plane program
> > feature. For this Patch, only used dual plane page program, means two
> > different plane pages can Be programmed together at the same time.
> > Dual plane page program only implements in backup operation. Only
> > lower page data Be duplicated and back up into a internal log volume by
> dual plane program method.
> >
> > This patch has been testing on Micron 70s/80s/90s MLC NAND.
> > Of course there are some places needed to be improved and simplified.
> >
> > Any suggestion and comments welcomed.
> 
> As stated before, using OOB in UBI is not going to happen unless proven that
> there is absolutely no other way to solve the paired pages problem.
> 
> Nacked-by: Richard Weinberger 
> 
> Sorry,
> //Richard

Hi, Richard
Thanks for your concern. I am a new patch submitter.
Can you tell me Nacked-by means?

By the way, Do you review my patches series ? I don't backup duplicated data in 
OOB .
Can you specify which sector codes ? so that I can explain it in detail.
Thanks.

Re: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Krzysztof Kozlowski]

On 22.09.2015 16:37, Yakir Yang wrote:
> Both hsync/vsync polarity and interlace mode can be parsed from
> drm display mode, and dynamic_range and ycbcr_coeff can be judge
> by the video code.
> 
> But presumably Exynos still relies on the DT properties, so take
> good use of mode_fixup() in to achieve the compatibility hacks.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v5:
> - Switch video timing type to "u32", so driver could use 
> "of_property_read_u32"
>   to get the backword timing values. 

Okay

> Krzysztof suggest me that driver could use
>   the "of_property_read_bool" to get backword timing values, but that 
> interfacs
>   would modify the original drm_display_mode timing directly (whether those
>   properties exists or not).

Hmm, I don't understand. You have a:
struct video_info {
bool h_sync_polarity;
bool v_sync_polarity;
bool interlaced;
};

so what is wrong with:
dp_video_config->h_sync_polarity =
of_property_read_bool(dp_node, "hsync-active-high");

Is it exactly the same binding as previously?

Best regards,
Krzysztof

> 
> Changes in v4:
> - Provide backword compatibility with samsung. (Krzysztof)
> 
> Changes in v3:
> - Dynamic parse video timing info from struct drm_display_mode and
>   struct drm_display_info. (Thierry)
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 144 
> +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   8 +-
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
>  3 files changed, 104 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 1e3c8d3..6be139b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
>   return;
>   }
>  
> - ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
> -  dp->video_info->link_rate);
> + ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
> +  dp->video_info.link_rate);
>   if (ret) {
>   dev_err(dp->dev, "unable to do link train\n");
>   return;
> @@ -1030,6 +1030,85 @@ static void analogix_dp_bridge_disable(struct 
> drm_bridge *bridge)
>   dp->dpms_mode = DRM_MODE_DPMS_OFF;
>  }
>  
> +static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *orig_mode,
> + struct drm_display_mode *mode)
> +{
> + struct analogix_dp_device *dp = bridge->driver_private;
> + struct drm_display_info *display_info = >connector->display_info;
> + struct video_info *video = >video_info;
> + struct device_node *dp_node = dp->dev->of_node;
> + int vic;
> +
> + /* Input video interlaces & hsync pol & vsync pol */
> + video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> + video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
> + video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
> +
> + /* Input video dynamic_range & colorimetry */
> + vic = drm_match_cea_mode(mode);
> + if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
> + (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
> + video->dynamic_range = CEA;
> + video->ycbcr_coeff = COLOR_YCBCR601;
> + } else if (vic) {
> + video->dynamic_range = CEA;
> + video->ycbcr_coeff = COLOR_YCBCR709;
> + } else {
> + video->dynamic_range = VESA;
> + video->ycbcr_coeff = COLOR_YCBCR709;
> + }
> +
> + /* Input vide bpc and color_formats */
> + switch (display_info->bpc) {
> + case 12:
> + video->color_depth = COLOR_12;
> + break;
> + case 10:
> + video->color_depth = COLOR_10;
> + break;
> + case 8:
> + video->color_depth = COLOR_8;
> + break;
> + case 6:
> + video->color_depth = COLOR_6;
> + break;
> + default:
> + video->color_depth = COLOR_8;
> + break;
> + }
> + if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
> + video->color_space = COLOR_YCBCR444;
> + else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
> + video->color_space = COLOR_YCBCR422;
> + else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
> + video->color_space = COLOR_RGB;
> + else
> + video->color_space = COLOR_RGB;
> +
> + /*
> +  * NOTE: those property parsing code is used for providing backward
> +  * 

Re: [PATCH 2/2] mm: fix declarations of nr, delta and nr_pagecache_reclaimable

[Andrew Morton]

On Wed, 30 Sep 2015 08:10:04 +0300 Alexandru Moise 
<00moses.alexande...@gmail.com> wrote:

> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -194,7 +194,7 @@ static bool sane_reclaim(struct scan_control *sc)
> > >  
> > >  static unsigned long zone_reclaimable_pages(struct zone *zone)
> > >  {
> > > - int nr;
> > > + unsigned long nr;
> > >  
> > >   nr = zone_page_state(zone, NR_ACTIVE_FILE) +
> > >zone_page_state(zone, NR_INACTIVE_FILE);
> > 
> > OK.
> > 
> 
> Are you sure? Mel Gorman raised the following issue on patch 1/2:
> 
> https://lkml.org/lkml/2015/9/29/253

__zone_watermark_ok() is very different from zone_reclaimable_pages().
--
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 v5 03/17] drm: bridge: analogix/dp: fix some obvious code style

[Krzysztof Kozlowski]

On 22.09.2015 16:34, Yakir Yang wrote:
> Fix some obvious alignment problems, like alignment and line
> over 80 characters problems, make this easy to be maintained
> later.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v5:
> - Resequence this patch after analogix_dp driver have been split
>   from exynos_dp code, and rephrase reasonable commit message, and
>   remove some controversial style (Krzysztof)
> - analogix_dp_write_byte_to_dpcd(
> - dp, DP_TEST_RESPONSE,
> + analogix_dp_write_byte_to_dpcd(dp,
> + DP_TEST_RESPONSE,
>   DP_TEST_EDID_CHECKSUM_WRITE);
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Improved commit message more readable, and avoid using some
>   uncommon style like bellow: (Joe Preches)
> -  retval = exynos_dp_read_bytes_from_i2c(...
> ...);
> +  retval =
> +  exynos_dp_read_bytes_from_i2c(..);
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 
> ++---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
>  3 files changed, 163 insertions(+), 162 deletions(-)
> 

IMHO much better than in previous attempt. The code looks good:

Reviewed-by: Krzysztof Kozlowski 

BTW my opinion is not enough, you still need an ack from Exynos DP
maintainer (or DRM guys).


Best regards,
Krzysztof

--
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 v5 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Krzysztof Kozlowski]

On 22.09.2015 16:29, Yakir Yang wrote:
> Split the dp core driver from exynos directory to bridge directory,
> and rename the core driver to analogix_dp_*, rename the platform
> code to exynos_dp.
> 
> Beside the new analogix_dp driver would export four hooks.
> "analogix_dp_bind()" and "analogix_dp_unbind()"
> "analogix_dp_detect()" and "analogix_dp_get_modes()"
> 
> The bind/unbind symbols is used for analogix platform driver to connect
> with analogix_dp core driver. And the detect/get_modes is used for analogix
> platform driver to init the connector.
> 
> They reason why connector need register in helper driver is rockchip drm
> haven't implement the atomic API, but Exynos drm have implement it, so
> there would need two different connector helper functions, that's why we
> leave the connector register in helper driver.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v5:
> - Correct the check condition of gpio_is_valid when driver try to get
>   the "hpd-gpios" DT propery. (Heiko)
> - Move the platform attach callback in the front of core driver bridge
>   attch function. Cause once platform failed at attach, core driver should
>   still failed, so no need to init connector before platform attached 
> (Krzysztof)
> - Keep code style no changes with the previous exynos_dp_code.c in this
>   patch, and update commit message about the new export symbol (Krzysztof)
> - Gather the device type patch (v4 11/16) into this one. (Krzysztof)
> - leave out the connector registration to analogix platform driver. (Thierry)

Thanks for fixing this, looks much better.

I don't feel comfortable enough to provide a review tag but it looks
good to me.

Best regards,
Krzysztof

--
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: build failure after merge of the l2-mtd tree

[Stephen Rothwell]

Hi Brian,

After merging the l2-mtd tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/mtd/nand/vf610_nfc.c: In function 'vf610_nfc_resume':
drivers/mtd/nand/vf610_nfc.c:859:2: error: implicit declaration of function 
'pinctrl_pm_select_default_state' [-Werror=implicit-function-declaration]
  pinctrl_pm_select_default_state(dev);
  ^

Caused by commit

  456930d80a2d ("mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and 
others")

I have reverted that commit (and the following one) for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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/2] mm: fix declarations of nr, delta and nr_pagecache_reclaimable

[Alexandru Moise]

> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -194,7 +194,7 @@ static bool sane_reclaim(struct scan_control *sc)
> >  
> >  static unsigned long zone_reclaimable_pages(struct zone *zone)
> >  {
> > -   int nr;
> > +   unsigned long nr;
> >  
> > nr = zone_page_state(zone, NR_ACTIVE_FILE) +
> >  zone_page_state(zone, NR_INACTIVE_FILE);
> 
> OK.
> 

Are you sure? Mel Gorman raised the following issue on patch 1/2:

https://lkml.org/lkml/2015/9/29/253

Thanks for the review.
--
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: [RFC v2 00/18] kthread: Use kthread worker API more widely

[Paul E. McKenney]

On Mon, Sep 21, 2015 at 03:03:41PM +0200, Petr Mladek wrote:
> My intention is to make it easier to manipulate kthreads. This RFC tries
> to use the kthread worker API. It is based on comments from the
> first attempt. See https://lkml.org/lkml/2015/7/28/648 and
> the list of changes below.
> 
> 1st..8th patches: improve the existing kthread worker API
> 
> 9th, 12th, 17th patches: convert three kthreads into the new API,
>  namely: khugepaged, ring buffer benchmark, RCU gp kthreads[*]
> 
> 10th, 11th patches: fix potential problems in the ring buffer
>   benchmark; also sent separately
> 
> 13th patch: small fix for RCU kthread; also sent separately;
>  being tested by Paul
> 
> 14th..16th patches: preparation steps for the RCU threads
>  conversion; they are needed _only_ if we split GP start
>  and QS handling into separate works[*]
> 
> 18th patch: does a possible improvement of the kthread worker API;
>  it adds an extra parameter to the create*() functions, so I
>  rather put it into this draft
>  
> 
> [*] IMPORTANT: I tried to split RCU GP start and GS state handling
> into separate works this time. But there is a problem with
> a race in rcu_gp_kthread_worker_poke(). It might queue
> the wrong work. It can be detected and fixed by the work
> itself but it is a bit ugly. Alternative solution is to
> do both operations in one work. But then we sleep too much
> in the work which is ugly as well. Any idea is appreciated.

I think that the kernel is trying really hard to tell you that splitting
up the RCU grace-period kthreads in this manner is not such a good idea.

So what are we really trying to accomplish here?  I am guessing something
like the following:

1.  Get each grace-period kthread to a known safe state within a
short time of having requested a safe state.  If I recall
correctly, the point of this is to allow no-downtime kernel
patches to the functions executed by the grace-period kthreads.

2.  At the same time, if someone suddenly needs a grace period
at some point in this process, the grace period kthreads are
going to have to wake back up and handle the grace period.
Or do you have some tricky way to guarantee that no one is
going to need a grace period beyond the time you freeze
the grace-period kthreads?

3.  The boost kthreads should not be a big problem because failing
to boost simply lets the grace period run longer.

4.  The callback-offload kthreads are likely to be a big problem,
because in systems configured with them, they need to be running
to invoke the callbacks, and if the callbacks are not invoked,
the grace period might just as well have failed to end.

5.  The per-CPU kthreads are in the same boat as the callback-offload
kthreads.  One approach is to offline all the CPUs but one, and
that will park all but the last per-CPU kthread.  But handling
that last per-CPU kthread would likely be "good clean fun"...

6.  Other requirements?

One approach would be to simply say that the top-level rcu_gp_kthread()
function cannot be patched, and arrange for the grace-period kthreads
to park at some point within this function.  Or is there some requirement
that I am missing?

Thanx, Paul

> Changes against v1:
> 
> + remove wrappers to manipulate the scheduling policy and priority
> 
> + remove questionable wakeup_and_destroy_kthread_worker() variant
> 
> + do not check for chained work when draining the queue
> 
> + allocate struct kthread worker in create_kthread_work() and
>   use more simple checks for running worker
> 
> + add support for delayed kthread works and use them instead
>   of waiting inside the works
> 
> + rework the "unrelated" fixes for the ring buffer benchmark
>   as discussed in the 1st RFC; also sent separately
> 
> + convert also the consumer in the ring buffer benchmark
> 
> 
> I have tested this patch set against the stable Linus tree
> for 4.3-rc2.
> 
> Petr Mladek (18):
>   kthread: Allow to call __kthread_create_on_node() with va_list args
>   kthread: Add create_kthread_worker*()
>   kthread: Add drain_kthread_worker()
>   kthread: Add destroy_kthread_worker()
>   kthread: Add pending flag to kthread work
>   kthread: Initial support for delayed kthread work
>   kthread: Allow to cancel kthread work
>   kthread: Allow to modify delayed kthread work
>   mm/huge_page: Convert khugepaged() into kthread worker API
>   ring_buffer: Do no not complete benchmark reader too early
>   ring_buffer: Fix more races when terminating the producer in the
> benchmark
>   ring_buffer: Convert benchmark kthreads into kthread worker API
>   rcu: Finish folding ->fqs_state into ->gp_state
>   rcu: Store first_gp_fqs into struct rcu_state
>   rcu: Clean up timeouts for forcing the quiescent state
>   rcu: Check 

[PATCH 2/2] ASoC: sun4i-codec: Remove redundant SND_PCM_RATE_KNOT

[Maxime Ripard]

The SND_PCM_RATE_KNOT covers all the rate settings, even though some that
we don't support, while we also list all the rate we support. Simply remove
it.

Signed-off-by: Maxime Ripard 
---
 sound/soc/sunxi/sun4i-codec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 28834129bea3..e5d195fe491e 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -389,8 +389,7 @@ static struct snd_soc_dai_driver sun4i_codec_dai = {
.rate_max   = 192000,
.rates  = SNDRV_PCM_RATE_8000_48000 |
  SNDRV_PCM_RATE_96000 |
- SNDRV_PCM_RATE_192000 |
- SNDRV_PCM_RATE_KNOT,
+ SNDRV_PCM_RATE_192000,
.formats= SNDRV_PCM_FMTBIT_S16_LE |
  SNDRV_PCM_FMTBIT_S32_LE,
.sig_bits   = 24,
-- 
2.5.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 1/2] ASoC: sun4i-codec: pass through clk_set_rate error

[Maxime Ripard]

The current code, disregarding the clk_set_rate error code, was always
returning -EINVAL. Fix that and return the code in order to have more clue
about what's going on.

Signed-off-by: Maxime Ripard 
---
 sound/soc/sunxi/sun4i-codec.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 6e83e62ef039..28834129bea3 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -283,7 +283,7 @@ static int sun4i_codec_hw_params(struct snd_pcm_substream 
*substream,
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct sun4i_codec *scodec = snd_soc_card_get_drvdata(rtd->card);
unsigned long clk_freq;
-   int hwrate;
+   int ret, hwrate;
u32 val;
 
if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
@@ -293,8 +293,9 @@ static int sun4i_codec_hw_params(struct snd_pcm_substream 
*substream,
if (!clk_freq)
return -EINVAL;
 
-   if (clk_set_rate(scodec->clk_module, clk_freq))
-   return -EINVAL;
+   ret = clk_set_rate(scodec->clk_module, clk_freq);
+   if (ret)
+   return ret;
 
hwrate = sun4i_codec_get_hw_rate(params);
if (hwrate < 0)
-- 
2.5.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: [linux-sunxi] Re: [PATCH 5/5] ARM: sun5i: Add C.H.I.P DTS

[Maxime Ripard]

On Tue, Sep 22, 2015 at 04:30:04PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 22-09-15 16:04, Maxime Ripard wrote:
> >On Tue, Sep 22, 2015 at 03:01:58PM +0200, Hans de Goede wrote:
> >>>In short, this is not about "power supply" but VBUS detection. IIRC,
> >>>if no VBUS detection method is provided, the phy driver just waits a
> >>>period of time after an ID pin change and then considers VBUS invalid.
> >>
> >>Right, but that is a hack for boards with no / broken vbus detection
> >>(or vbus control), we really want to use vbus-det where available,
> >>so I agree that a TODO comment here would be good.
> >
> >What's so special in our SoCs that makes that we can't just rely on
> >the ID pin ? (which seems to be working just fine here)
> 
> There is nothing special, AFAIK all OTG ports (also for other SoCs)
> have some sort of vbus detection mechanism. We need the hack because
> vbus-det is broken on some of our boards.
> 
> And where it is not broken we should be using vbus-det normallu.

Ah, and most controllers embed that directly into the controller
itself and don't rely on a GPIO to do that. Understood.

Thanks!
Maxime

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


signature.asc
Description: Digital signature

[PATCH 2/2] x86, efi: Add "efi_fake_mem" boot option

[Taku Izumi]

This patch introduces new boot option named "efi_fake_mem".
By specifying this parameter, you can add arbitrary attribute
to specific memory range.
This is useful for debugging of Address Range Mirroring feature.

For example, if "efi_fake_mem=2G@4G:0x1,2G@0x10a000:0x1"
is specified, the original (firmware provided) EFI memmap will be
updated so that the specified memory regions have
EFI_MEMORY_MORE_RELIABLE attribute (0x1):

 
   efi: mem36: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] 
range=[0x0001-0x0020a000) (129536MB)

 
   efi: mem36: [Conventional Memory|  |MR|  |  |  |   |WB|WT|WC|UC] 
range=[0x0001-0x00018000) (2048MB)
   efi: mem37: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] 
range=[0x00018000-0x0010a000) (61952MB)
   efi: mem38: [Conventional Memory|  |MR|  |  |  |   |WB|WT|WC|UC] 
range=[0x0010a000-0x00112000) (2048MB)
   efi: mem39: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] 
range=[0x00112000-0x0020a000) (63488MB)

And you will find that the following message is output:

   efi: Memory: 4096M/131455M mirrored memory

Signed-off-by: Taku Izumi 
---
 Documentation/kernel-parameters.txt |  15 +++
 arch/x86/kernel/setup.c |   4 +-
 drivers/firmware/efi/Kconfig|  22 
 drivers/firmware/efi/Makefile   |   1 +
 drivers/firmware/efi/fake_mem.c | 238 
 include/linux/efi.h |   6 +
 6 files changed, 285 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/efi/fake_mem.c

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 22a4b68..50fc09b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1094,6 +1094,21 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
you are really sure that your UEFI does sane gc and
fulfills the spec otherwise your board may brick.
 
+   efi_fake_mem=   nn[KMG]@ss[KMG]:aa[,nn[KMG]@ss[KMG]:aa,..] [EFI; X86]
+   Add arbitrary attribute to specific memory range by
+   updating original EFI memory map.
+   Region of memory which aa attribute is added to is
+   from ss to ss+nn.
+   If efi_fake_mem=2G@4G:0x1,2G@0x10a000:0x1
+   is specified, EFI_MEMORY_MORE_RELIABLE(0x1)
+   attribute is added to range 0x1-0x18000 and
+   0x10a000-0x112000.
+
+   Using this parameter you can do debugging of EFI memmap
+   related feature. For example, you can do debugging of
+   Address Range Mirroring feature even if your box
+   doesn't support it.
+
eisa_irq_edge=  [PARISC,HW]
See header of drivers/parisc/eisa.c.
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index fdb7f2a..30b4c44 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1079,8 +1079,10 @@ void __init setup_arch(char **cmdline_p)
memblock_set_current_limit(ISA_END_ADDRESS);
memblock_x86_fill();
 
-   if (efi_enabled(EFI_BOOT))
+   if (efi_enabled(EFI_BOOT)) {
+   efi_fake_memmap();
efi_find_mirror();
+   }
 
/*
 * The EFI specification says that boot service code won't be called
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 84533e0..ac47cc4d 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -52,6 +52,28 @@ config EFI_RUNTIME_MAP
 
  See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
 
+config EFI_FAKE_MEMMAP
+   bool "Enable EFI fake memory map"
+   depends on EFI && X86
+   default n
+   help
+ Saying Y here will enable "efi_fake_mem" boot option.
+ By specifying this parameter, you can add arbitrary attribute
+ to specific memory range by updating original (firmware provided)
+ EFI memmap.
+ This is useful for debugging of EFI memmap related feature.
+ e.g. Address Range Mirroring feature.
+
+config EFI_MAX_FAKE_MEM
+   int "maximum allowable number of ranges in efi_fake_mem boot option"
+   depends on EFI && X86 && EFI_FAKE_MEMMAP
+   range 1 128
+   default 8
+   help
+ Maximum allowable number of ranges in efi_fake_mem boot option.
+ Ranges can be set up to this value using comma-separated list.
+ The default value is 8.
+
 config EFI_PARAMS_FROM_FDT
bool
help
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 6fd3da9..c24f005 100644
--- a/drivers/firmware/efi/Makefile
+++ 

Re: [PATCH] net: macb: fix two typos

[David Miller]

From: Geliang Tang 
Date: Tue, 29 Sep 2015 19:31:32 -0700

> Just fix two typos in code comments.
> 
> Signed-off-by: Geliang Tang 

Applied, thanks.
--
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] ASoC: Codec: wm8962: balance pm_runtime_enable

[Jiada Wang]

pm_runtime_enable is called in probe to enable runtime PM
for wm8962 codec, but pm_runtime_disable isn't called in remove
callback, nor is called in error path if probe fails after runtime
PM is enabled, this causes unbalanced pm_runtime_enable.

This patch Adds pm_runtime_disable in remove callback and error path,
to balance pm_runtime_enable.

Signed-off-by: Jiada Wang 
---
 sound/soc/codecs/wm8962.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index 293e47a..2fbc6ef 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -3760,7 +3760,7 @@ static int wm8962_i2c_probe(struct i2c_client *i2c,
ret = snd_soc_register_codec(>dev,
 _codec_dev_wm8962, _dai, 1);
if (ret < 0)
-   goto err_enable;
+   goto err_pm_runtime;
 
regcache_cache_only(wm8962->regmap, true);
 
@@ -3769,6 +3769,8 @@ static int wm8962_i2c_probe(struct i2c_client *i2c,
 
return 0;
 
+err_pm_runtime:
+   pm_runtime_disable(>dev);
 err_enable:
regulator_bulk_disable(ARRAY_SIZE(wm8962->supplies), wm8962->supplies);
 err:
@@ -3778,6 +3780,7 @@ err:
 static int wm8962_i2c_remove(struct i2c_client *client)
 {
snd_soc_unregister_codec(>dev);
+   pm_runtime_disable(>dev);
return 0;
 }
 
-- 
2.4.5

--
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/2] x86, efi: Add "efi_fake_mem" boot option

[Izumi, Taku]

 I've missed git-format-patch after rebasing.
 I'll resend right one..

> -Original Message-
> From: kbuild test robot [mailto:l...@intel.com]
> Sent: Wednesday, September 30, 2015 10:37 AM
> To: Izumi, Taku/泉 拓
> Cc: kbuild-...@01.org; linux-kernel@vger.kernel.org; 
> linux-...@vger.kernel.org; x...@kernel.org; matt.flem...@intel.com;
> t...@linutronix.de; mi...@redhat.com; h...@zytor.com; tony.l...@intel.com; 
> qinxi...@huawei.com; Kamezawa, Hiroyuki/亀
> 澤 寛之; ard.biesheu...@linaro.org; Izumi, Taku/泉 拓
> Subject: Re: [PATCH 2/2] x86, efi: Add "efi_fake_mem" boot option
> 
> Hi Taku,
> 
> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
> ignore]
> 
> config: i386-allmodconfig (attached as .config)
> reproduce:
>   git checkout afcc94d3f91a00ce97d735a563a8e5d595f45a03
>   # save the attached .config to linux build tree
>   make ARCH=i386
> 
> All error/warnings (new ones prefixed by >>):
> 
> >> drivers/firmware/efi/fake_mem.c:36:25: error: 'CONFIG_EFI_MAX_FAKEMEM' 
> >> undeclared here (not in a function)
> #define EFI_MAX_FAKEMEM CONFIG_EFI_MAX_FAKEMEM
> ^
> >> drivers/firmware/efi/fake_mem.c:42:34: note: in expansion of macro 
> >> 'EFI_MAX_FAKEMEM'
> static struct fake_mem fake_mems[EFI_MAX_FAKEMEM];
>  ^
>drivers/firmware/efi/fake_mem.c: In function 'efi_fake_memmap':
> >> drivers/firmware/efi/fake_mem.c:186:20: warning: cast to pointer from 
> >> integer of different size [-Wint-to-pointer-cast]
>  memmap.phys_map = (void *)new_memmap_phy;
>^
>drivers/firmware/efi/fake_mem.c: At top level:
> >> drivers/firmware/efi/fake_mem.c:42:24: warning: 'fake_mems' defined but 
> >> not used [-Wunused-variable]
> static struct fake_mem fake_mems[EFI_MAX_FAKEMEM];
>^
> 
> vim +/CONFIG_EFI_MAX_FAKEMEM +36 drivers/firmware/efi/fake_mem.c
> 
> 30#include 
> 31#include 
> 32#include 
> 33#include 
> 34#include 
> 35
>   > 36#define EFI_MAX_FAKEMEM CONFIG_EFI_MAX_FAKEMEM
> 37
> 38struct fake_mem {
> 39struct range range;
> 40u64 attribute;
> 41};
>   > 42static struct fake_mem fake_mems[EFI_MAX_FAKEMEM];
> 43static int nr_fake_mem;
> 44
> 45static int __init cmp_fake_mem(const void *x1, const void *x2)
> 46{
> 47const struct fake_mem *m1 = x1;
> 48const struct fake_mem *m2 = x2;
> 49
> 50if (m1->range.start < m2->range.start)
> 51return -1;
> 52if (m1->range.start > m2->range.start)
> 53return 1;
> 54return 0;
> 55}
> 56
> 57void __init efi_fake_memmap(void)
> 58{
> 59u64 start, end, m_start, m_end, m_attr;
> 60int new_nr_map = memmap.nr_map;
> 61efi_memory_desc_t *md;
> 62u64 new_memmap_phy;
> 63void *new_memmap;
> 64void *old, *new;
> 65int i;
> 66
> 67if (!nr_fake_mem || !efi_enabled(EFI_MEMMAP))
> 68return;
> 69
> 70/* count up the number of EFI memory descriptor */
> 71for (old = memmap.map; old < memmap.map_end; old += 
> memmap.desc_size) {
> 72md = old;
> 73start = md->phys_addr;
> 74end = start + (md->num_pages << EFI_PAGE_SHIFT) 
> - 1;
> 75
> 76for (i = 0; i < nr_fake_mem; i++) {
> 77/* modifying range */
> 78m_start = fake_mems[i].range.start;
> 79m_end = fake_mems[i].range.end;
> 80
> 81if (m_start <= start) {
> 82/* split into 2 parts */
> 83if (start < m_end && m_end < 
> end)
> 84new_nr_map++;
> 85}
> 86if (start < m_start && m_start < end) {
> 87/* split into 3 parts */
> 88if (m_end < end)
> 89new_nr_map += 2;
> 90/* split into 2 parts */
> 91if (end <= m_end)
> 92new_nr_map++;
> 93}
> 94}
> 95 

[PATCH] perf report: Fix a bug on "--call-graph none" option

[Namhyung Kim]

The patch f9db0d0f1b2c ("perf callchain: Allow disabling call graphs
per event") added an ability to enable/disable callchain recording per
event.  But it had a problem when the enablement setting is changed at
'perf report' time using -g/--call-graph option.

For example, the following scenario will get a segfault.

  $ perf record -ag sleep 1
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.500 MB perf.data (2555 samples) ]

  $ perf report -g none
  perf: Segmentation fault
   backtrace 
  perf[0x53a98a]
  /usr/lib/libc.so.6(+0x335af)[0x7f4e91df95af]

This is because callchain_param.sort() callback was not set but it
tried to call the function as it had the PERF_SAMPLE_CALLCHAIN bit.

Cc: Kan Liang 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/hist.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index b3567a25f0c4..99b8e14ce010 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -1149,7 +1149,7 @@ void hists__output_resort(struct hists *hists, struct 
ui_progress *prog)
struct perf_evsel *evsel = hists_to_evsel(hists);
bool use_callchain;
 
-   if (evsel && !symbol_conf.show_ref_callgraph)
+   if (evsel && symbol_conf.use_callchain && 
!symbol_conf.show_ref_callgraph)
use_callchain = evsel->attr.sample_type & PERF_SAMPLE_CALLCHAIN;
else
use_callchain = symbol_conf.use_callchain;
-- 
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 net] net: dsa: fix preparation of a port STP update

[David Miller]

From: Vivien Didelot 
Date: Tue, 29 Sep 2015 14:17:54 -0400

> Because of the default 0 value of ret in dsa_slave_port_attr_set, a
> driver may return -EOPNOTSUPP from the commit phase of a STP state,
> which triggers a WARN() from switchdev.
> 
> This happened on a 6185 switch which does not support hardware bridging.
> 
> Fixes: 3563606258cf ("switchdev: convert STP update to switchdev attr set")
> Reported-by: Andrew Lunn 
> Signed-off-by: Vivien Didelot 

Applied and queued up for -stable, thanks.
--
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 net-next] net: dsa: fix preparation of a port STP update

[David Miller]

From: Vivien Didelot 
Date: Tue, 29 Sep 2015 12:38:36 -0400

> Because of the default 0 value of ret in dsa_slave_port_attr_set, a
> driver may return -EOPNOTSUPP from the commit phase of a STP state,
> which triggers a WARN() from switchdev.
> 
> This happened on a 6185 switch which does not support hardware bridging.
> 
> Reported-by: Andrew Lunn 
> Signed-off-by: Vivien Didelot 

Applied.
--
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 net-next 0/6] net: switchdev: use specific switchdev_obj_*

[David Miller]

From: Vivien Didelot 
Date: Tue, 29 Sep 2015 12:07:12 -0400

> This patchset changes switchdev add, del, dump operations from this:
 ...
> to something similar to the notifier_call callback of a notifier_block:
 ...
> This allows the caller to pass and expect back a specific switchdev_obj_*
> structure (e.g. switchdev_obj_fdb) instead of the generic switchdev_obj one.
> 
> This will simplify pushing the callback function down to the drivers.
> 
> The first 3 patches get rid of the dev parameter of the dump callback, since 
> it
> is not always neeeded (e.g. vlan_dump) and some drivers (such as DSA drivers)
> may not have easy access to it.
> 
> Patches 4 and 5 implement the change in the switchdev operations and its 
> users.
> 
> Patch 6 extracts the inner switchdev_obj_* structures from switchdev_obj and
> removes this last one.
> 
> v2: fix error spotted by kbuild (extra ';' inline switchdev_port_obj_dump).

Series applied, thanks Vivien.
--
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: can't oom-kill zap the victim's memory?

[Tetsuo Handa]

David Rientjes wrote:
> I think both of your illustrations show why it is not helpful to kill 
> additional processes after a time period has elapsed and a victim has 
> failed to exit.  In both of your scenarios, it would require that KT1 be 
> killed to allow forward progress and we know that's not possible.

My illustrations show why it is helpful to kill additional processes after
a time period has elapsed and a victim has failed to exit. We don't need
to kill KT1 if we combine memory unmapping approach and timeout based OOM
killing approach.

Simply choosing more OOM victims (processes which do not share other OOM
victim's mm) based on timeout itself does not guarantee that other OOM
victims can exit. But if timeout based OOM killing is used together with
memory unmapping approach, the possibility that OOM victims can exit
significantly increases because the only case where memory unmapping
approach stucks will be when mm->mmap_sem was held for writing (which
should unlikely occur).

If we choose only 1 OOM victim, the possibility of hitting this memory
unmapping livelock is (say) 1%. But if we choose multiple OOM victims, the
possibility becomes (almost) 0%. And if we still hit this livelock even
after choosing many OOM victims, it is time to call panic().

(Well, do we need to change __alloc_pages_slowpath() that OOM victims do not
enter direct reclaim paths in order to avoid being blocked by unkillable fs
locks?)

> 
> Perhaps this is an argument that we need to provide access to memory 
> reserves for threads even for !__GFP_WAIT and !__GFP_FS in such scenarios, 
> but I would wait to make that extension until we see it in practice.

I think that GFP_ATOMIC allocations already access memory reserves via
ALLOC_HIGH priority.

> 
> Killing all mm->mmap_sem threads certainly isn't meant to solve all oom 
> killer livelocks, as you show.
> 

Good.

I'm not denying memory unmapping approach. I'm just pointing out that
use of memory unmapping approach alone still leaves room for hang up.
--
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/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

[Ard Biesheuvel]

On 30 September 2015 at 03:16, Andy Lutomirski  wrote:
> On Tue, Sep 29, 2015 at 6:03 PM, H. Peter Anvin  wrote:
>> On 09/27/2015 12:06 AM, Ingo Molnar wrote:
>>>
>>> * Ard Biesheuvel  wrote:
>>>
> If we allocate the EFI runtime as a single virtual memory block then 
> issues
> like rounding between sections does not even come up as a problem: we map 
> the
> original offsets and sizes byte by byte.

 Well, by that reasoning, we should not call SetVirtualAddressMap() in the 
 first
 place, and just use the 1:1 mapping UEFI uses natively. This is more than
 feasible on arm64, and I actually fought hard against using
 SetVirtualAddressMap() at all, but I was overruled by others. I think this 
 is
 also trivially possible on X64, since the 1:1 mapping is already active
 alongside the VA mapping.
>>>
>>> Could we please re-list all the arguments pro and contra of 1:1 physical 
>>> mappings,
>>> in a post that also explains the background so that more people can chime 
>>> in, not
>>> just people versed in EFI internals? It's very much possible that a bad 
>>> decision
>>> was made.
>>>
>>
>> Pro: by far the sanest way to map the UEFI tables.
>> Con: doesn't actually work (breaks on several known platforms.)
>
> Can we at least do 1:1 without an offset on arm64?  Given that Linux
> seems to be more of a reference on arm64 than Windows is, maybe that
> would give everyone something vaguely sane to work with.
>

Yes, as I mentioned before in this thread, on arm64 this is very much
feasible, and it was my strong preference all along. However, the
arguments made by others that outweighed my preference were
(a) x86 uses it
(b) if we don't use it now, we will never be able to start using it
later since it will undoubtedly be broken in /some/ implementation in
the field.

As I also mentioned, the only minor complication is that arm64's VA
space may be configured to be smaller than the physical base of DRAM,
but I already had to address that for the boot ID map and KVM as well.

I will cook up a patch later today.

-- 
Ard.
--
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 net-next v2 RESEND] BNX2: fix a Null Pointer for stats_blk

[David Miller]

From: Weidong Wang 
Date: Tue, 29 Sep 2015 11:18:18 +0800

> @@ -839,11 +828,12 @@ bnx2_free_mem(struct bnx2 *bp)
>  }
> 
>  static int
> -bnx2_alloc_mem(struct bnx2 *bp)
> +bnx2_alloc_stats_blk(struct net_device *dev)
>  {
> - int i, status_blk_size, err;
> + int i, status_blk_size;
>   struct bnx2_napi *bnapi;
>   void *status_blk;
> + struct bnx2 *bp = netdev_priv(dev);
> 
>   /* Combine status and statistics blocks into one allocation. */
>   status_blk_size = L1_CACHE_ALIGN(sizeof(struct status_block));

This function is not just allocating the stats block, it's allocating
a whole bunch of other things too.

Only allocate the stats block at probe time, not the NAPI et al. stuff
as well.  That can safely stay in the open/close paths.
--
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 v5 17/23] arm64:ilp32: add vdso-ilp32 and use for signal return

[Nathan Lynch]

On 09/29/2015 05:14 PM, Yury Norov wrote:
> From: Philipp Tomsich 
> 
> Adjusted to move the move data page before code pages in sync with
> commit 601255ae3c98fd3a8bb4696425e4f868b4f1

This commit message needs more information about how the ilp32 VDSO uses
the existing arm64 code.  I had to really hunt through the Makefile to
figure out what's going on.

The commit message should also identify the APIs that are supported.
The subject line mentions signal return, but gettimeofday, clock_gettime
and clock_getres are being added here too, and it is not obvious.


> Signed-off-by: Philipp Tomsich 
> Signed-off-by: Christoph Muellner 
> Signed-off-by: Yury Norov 
> 
>  create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
>  create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
>  copy arch/arm64/{include/asm/vdso.h => kernel/vdso-ilp32/vdso-ilp32.S} (56%)
>  create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S

How are you invoking git-format-patch?  The copy detection in this case
is not conducive to review.

It looks like the existing arm64 vdso Makefile has been copied to
vdso-ilp32/ and adjusted for paths and naming.  While the gettimeofday
assembly implementation is reused, the build logic is duplicated.  x86
produces VDSOs for multiple ABIs with a single Makefile; is a similar
approach not appropriate for arm64?


> diff --git a/arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S 
> b/arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
> new file mode 100644
> index 000..ac8029b
> --- /dev/null
> +++ b/arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
> @@ -0,0 +1,98 @@

[...]

> +#include 
> +#include 
> +#include 
> +
> +/*OUTPUT_FORMAT("elf32-littleaarch64", "elf32-bigaarch64", 
> "elf32-littleaarch64")
> +OUTPUT_ARCH(aarch64)
> +*/

If these lines aren't needed then omit them.

[...]


> +/*
> + * This controls what symbols we export from the DSO.
> + */
> +VERSION
> +{
> + LINUX_2.6.39 {
> + global:
> + __kernel_rt_sigreturn;
> + __kernel_gettimeofday;
> + __kernel_clock_gettime;
> + __kernel_clock_getres;
> + local: *;
> + };
> +}

Something that came up during review of arch/arm's VDSO code: consider
using version and names that match x86, i.e. LINUX_2.6, __vdso_gettimeofday.

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267940.html

Using LINUX_2.6.39 for this code is nonsensical.


> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> index b239b9b..bed6cf1 100644
> --- a/arch/arm64/kernel/vdso.c
> +++ b/arch/arm64/kernel/vdso.c
> @@ -40,6 +40,12 @@ extern char vdso_start, vdso_end;
>  static unsigned long vdso_pages;
>  static struct page **vdso_pagelist;
>  
> +#ifdef CONFIG_ARM64_ILP32
> +extern char vdso_ilp32_start, vdso_ilp32_end;
> +static unsigned long vdso_ilp32_pages;
> +static struct page **vdso_ilp32_pagelist;
> +#endif
> +
>  /*
>   * The vDSO data page.
>   */
> @@ -117,24 +123,29 @@ int aarch32_setup_vectors_page(struct linux_binprm 
> *bprm, int uses_interp)
>  }
>  #endif /* CONFIG_AARCH32_EL0 */
>  
> -static struct vm_special_mapping vdso_spec[2];
> -
> -static int __init vdso_init(void)
> +static inline int __init vdso_init_common(char *vdso_start, char *vdso_end,

No inline please.


> +   unsigned long *vdso_pagesp,
> +   struct page ***vdso_pagelistp,
> +   struct vm_special_mapping* vdso_spec)
>  {

[...]

>  int arch_setup_additional_pages(struct linux_binprm *bprm,
>   int uses_interp)
>  {
>   struct mm_struct *mm = current->mm;
>   unsigned long vdso_base, vdso_text_len, vdso_mapping_len;
> - void *ret;
> + void* ret;

Gratuitous (and incorrect) style change.


> + unsigned long pages = vdso_pages;
> + struct vm_special_mapping* spec = vdso_spec;

Incorrect style:  *spec

--
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/5] y2038 conversion for ntp/pps and sfc driver

[David Miller]

From: Arnd Bergmann 
Date: Mon, 28 Sep 2015 22:21:27 +0200

> When trying to build a kernel with time_t commented out, I found that
> the ntp subsystem still relies on timespec for its pps handling.
> 
> This series addresses this and converts all the code to use timespec64
> instead, step by step. There is one device driver that interacts with
> this code directly (rather than only through the ptp subsystem), so
> I have to convert that driver at the same time.
> 
> The patches should ideally stay together as a series, but they do
> span multiple subsystems, so I'm also looking for the right person
> to merge them.

I'm happy with this going via a tree other than mine, and for the
networking bits:

Acked-by: David S. Miller 
--
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/

[GIT PULL] hwmon fixes for v4.3-rc4

[Guenter Roeck]

Hi Linus,

Please pull hwmon fixes for Linux v4.3-rc4 from signed tag:

git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hwmon-for-linus-v4.3-rc4

Thanks,
Guenter
--

The following changes since commit 1f93e4a96c9109378204c147b3eec0d0e8100fde:

  Linux 4.3-rc2 (2015-09-20 14:32:34 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
tags/hwmon-for-linus-v4.3-rc4

for you to fetch changes up to f491e70ccffa5d19aa51c958909320fa1f3905ed:

  hwmon: (pwm-fan) Fix module autoload for OF platform driver (2015-09-20 
17:50:19 -0700)


Fix module autoload for various drivers


Luis de Bethencourt (3):
  hwmon: (abx500) Fix module autoload for OF platform driver
  hwmon: (gpio-fan) Fix module autoload for OF platform driver
  hwmon: (pwm-fan) Fix module autoload for OF platform driver

 drivers/hwmon/abx500.c   | 1 +
 drivers/hwmon/gpio-fan.c | 1 +
 drivers/hwmon/pwm-fan.c  | 1 +
 3 files changed, 3 insertions(+)
--
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][trivial] u132-hcd: Fix seperate word in printk message

[Masanari Iida]

This patch fix seperated word in printk message.

Signed-off-by: Masanari Iida 
---
 drivers/usb/host/u132-hcd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
index a67bd50..0a94895 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -2245,8 +2245,7 @@ static int u132_urb_enqueue(struct usb_hcd *hcd, struct 
urb *urb,
struct u132 *u132 = hcd_to_u132(hcd);
if (irqs_disabled()) {
if (__GFP_WAIT & mem_flags) {
-   printk(KERN_ERR "invalid context for function that migh"
-   "t sleep\n");
+   printk(KERN_ERR "invalid context for function that 
might sleep\n");
return -EINVAL;
}
}
-- 
2.6.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 v5 10/23] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)

[kbuild test robot]

Hi Andrew,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: arm64-allnoconfig (attached as .config)
reproduce:
  wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
  chmod +x ~/bin/make.cross
  git checkout fe86f28ac31c45961e8b7bedb02c1836ddc91860
  # save the attached .config to linux build tree
  make.cross ARCH=arm64 

All error/warnings (new ones prefixed by >>):

   In file included from arch/arm64/kernel/process.c:48:0:
>> arch/arm64/include/asm/compat.h:336:38: error: macro "is_compat_task" passed 
>> 1 arguments, but takes just 0
static inline int is_compat_task(void)
 ^
>> arch/arm64/include/asm/compat.h:337:1: error: expected '=', ',', ';', 'asm' 
>> or '__attribute__' before '{' token
{
^
>> arch/arm64/include/asm/compat.h:341:19: error: redefinition of 
>> 'is_compat_thread'
static inline int is_compat_thread(struct thread_info *thread)
  ^
   arch/arm64/include/asm/compat.h:324:19: note: previous definition of 
'is_compat_thread' was here
static inline int is_compat_thread(struct thread_info *thread)
  ^
   arch/arm64/include/asm/compat.h: In function 'is_compat_thread':
>> arch/arm64/include/asm/compat.h:343:2: error: implicit declaration of 
>> function 'is_a32_compat_thread' [-Werror=implicit-function-declaration]
 return is_a32_compat_thread(thread);
 ^
   cc1: some warnings being treated as errors
--
   In file included from arch/arm64/kernel/ptrace.c:41:0:
>> arch/arm64/include/asm/compat.h:336:38: error: macro "is_compat_task" passed 
>> 1 arguments, but takes just 0
static inline int is_compat_task(void)
 ^
>> arch/arm64/include/asm/compat.h:337:1: error: expected '=', ',', ';', 'asm' 
>> or '__attribute__' before '{' token
{
^
>> arch/arm64/include/asm/compat.h:341:19: error: redefinition of 
>> 'is_compat_thread'
static inline int is_compat_thread(struct thread_info *thread)
  ^
   arch/arm64/include/asm/compat.h:324:19: note: previous definition of 
'is_compat_thread' was here
static inline int is_compat_thread(struct thread_info *thread)
  ^
   arch/arm64/include/asm/compat.h: In function 'is_compat_thread':
>> arch/arm64/include/asm/compat.h:343:2: error: implicit declaration of 
>> function 'is_a32_compat_thread' [-Werror=implicit-function-declaration]
 return is_a32_compat_thread(thread);
 ^
   arch/arm64/kernel/ptrace.c: At top level:
   arch/arm64/kernel/ptrace.c:1190:56: error: unknown type name 'compat_long_t'
long compat_a32_arch_ptrace(struct task_struct *child, compat_long_t 
request,
   ^
   arch/arm64/kernel/ptrace.c:1191:8: error: unknown type name 'compat_ulong_t'
   compat_ulong_t caddr, compat_ulong_t cdata)
   ^
   arch/arm64/kernel/ptrace.c:1191:30: error: unknown type name 'compat_ulong_t'
   compat_ulong_t caddr, compat_ulong_t cdata)
 ^
   cc1: some warnings being treated as errors
--
   arch/arm64/kernel/signal.c: In function 'setup_restart_syscall':
>> arch/arm64/kernel/signal.c:279:2: error: implicit declaration of function 
>> 'is_a32_compat_task' [-Werror=implicit-function-declaration]
 if (is_a32_compat_task())
 ^
   arch/arm64/kernel/signal.c:280:3: error: implicit declaration of function 
'compat_setup_restart_syscall' [-Werror=implicit-function-declaration]
  compat_setup_restart_syscall(regs);
  ^
   arch/arm64/kernel/signal.c: In function 'handle_signal':
   arch/arm64/kernel/signal.c:300:4: error: implicit declaration of function 
'compat_setup_rt_frame' [-Werror=implicit-function-declaration]
   ret = compat_setup_rt_frame(usig, ksig, oldset, regs);
   ^
   arch/arm64/kernel/signal.c:302:4: error: implicit declaration of function 
'compat_setup_frame' [-Werror=implicit-function-declaration]
   ret = compat_setup_frame(usig, ksig, oldset, regs);
   ^
   cc1: some warnings being treated as errors

vim +/is_compat_task +336 arch/arm64/include/asm/compat.h

   330  {
   331  return 0;
   332  }
   333  
   334  #endif /* CONFIG_COMPAT */
   335  
 > 336  static inline int is_compat_task(void)
 > 337  {
   338  return is_a32_compat_task();
   339  }
   340  
 > 341  static inline int is_compat_thread(struct thread_info *thread)
   342  {
 > 343  return is_a32_compat_thread(thread);
   344  }
   345  #endif /* __KERNEL__ */
   346  #endif /* __ASM_COMPAT_H */

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] ceph: fix a comment typo

[Yan, Zheng]

> On Sep 30, 2015, at 11:36, Geliang Tang  wrote:
> 
> Just fix a typo in the code comment.
> 
> Signed-off-by: Geliang Tang 
> ---
> fs/ceph/cache.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ceph/cache.c b/fs/ceph/cache.c
> index 834f9f3..a4766de 100644
> --- a/fs/ceph/cache.c
> +++ b/fs/ceph/cache.c
> @@ -88,7 +88,7 @@ static uint16_t ceph_fscache_inode_get_key(const void 
> *cookie_netfs_data,
>   const struct ceph_inode_info* ci = cookie_netfs_data;
>   uint16_t klen;
> 
> - /* use ceph virtual inode (id + snaphot) */
> + /* use ceph virtual inode (id + snapshot) */
>   klen = sizeof(ci->i_vino);
>   if (klen > maxbuf)
>   return 0;

Applied, thank you.

Yan, Zheng


> -- 
> 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] PM/hibernate: fix a comment typo

[Geliang Tang]

Just fix a typo in a function name in kerneldoc comments.

Signed-off-by: Geliang Tang 
---
 kernel/power/hibernate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index 690f78f..b7342a2 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -733,7 +733,7 @@ int hibernate(void)
  * contents of memory is restored from the saved image.
  *
  * If this is successful, control reappears in the restored target kernel in
- * hibernation_snaphot() which returns to hibernate().  Otherwise, the routine
+ * hibernation_snapshot() which returns to hibernate().  Otherwise, the routine
  * attempts to recover gracefully and make the kernel return to the normal mode
  * of operation.
  */
-- 
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] ceph: fix a comment typo

[Geliang Tang]

Just fix a typo in the code comment.

Signed-off-by: Geliang Tang 
---
 fs/ceph/cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ceph/cache.c b/fs/ceph/cache.c
index 834f9f3..a4766de 100644
--- a/fs/ceph/cache.c
+++ b/fs/ceph/cache.c
@@ -88,7 +88,7 @@ static uint16_t ceph_fscache_inode_get_key(const void 
*cookie_netfs_data,
const struct ceph_inode_info* ci = cookie_netfs_data;
uint16_t klen;
 
-   /* use ceph virtual inode (id + snaphot) */
+   /* use ceph virtual inode (id + snapshot) */
klen = sizeof(ci->i_vino);
if (klen > maxbuf)
return 0;
-- 
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 v5 04/23] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead

[kbuild test robot]

Hi Andrew,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: arm64-allnoconfig (attached as .config)
reproduce:
  wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
  chmod +x ~/bin/make.cross
  git checkout 4035143523cbf0106ee81f3ea585b363110c1ab6
  # save the attached .config to linux build tree
  make.cross ARCH=arm64 

All error/warnings (new ones prefixed by >>):

>> arch/arm64/kernel/ptrace.c:1190:56: error: unknown type name 'compat_long_t'
long compat_a32_arch_ptrace(struct task_struct *child, compat_long_t 
request,
   ^
>> arch/arm64/kernel/ptrace.c:1191:8: error: unknown type name 'compat_ulong_t'
   compat_ulong_t caddr, compat_ulong_t cdata)
   ^
   arch/arm64/kernel/ptrace.c:1191:30: error: unknown type name 'compat_ulong_t'
   compat_ulong_t caddr, compat_ulong_t cdata)
 ^
--
   arch/arm64/kernel/signal.c: In function 'setup_restart_syscall':
>> arch/arm64/kernel/signal.c:280:3: error: implicit declaration of function 
>> 'compat_setup_restart_syscall' [-Werror=implicit-function-declaration]
  compat_setup_restart_syscall(regs);
  ^
   arch/arm64/kernel/signal.c: In function 'handle_signal':
>> arch/arm64/kernel/signal.c:300:4: error: implicit declaration of function 
>> 'compat_setup_rt_frame' [-Werror=implicit-function-declaration]
   ret = compat_setup_rt_frame(usig, ksig, oldset, regs);
   ^
>> arch/arm64/kernel/signal.c:302:4: error: implicit declaration of function 
>> 'compat_setup_frame' [-Werror=implicit-function-declaration]
   ret = compat_setup_frame(usig, ksig, oldset, regs);
   ^
   cc1: some warnings being treated as errors

vim +/compat_long_t +1190 arch/arm64/kernel/ptrace.c

  1184  break;
  1185  }
  1186  
  1187  return ret;
  1188  }
  1189  #else /* !CONFIG_AARCH32_EL0 */
> 1190  long compat_a32_arch_ptrace(struct task_struct *child, compat_long_t 
> request,
> 1191  compat_ulong_t caddr, compat_ulong_t cdata)
  1192  {
  1193  return -1;
  1194  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[RFC] ECDT support in early stage

[Zheng, Lv]

There are many ECDT quirks in drivers/acpi/ec.c.

I tracked the commit log back to learn what was happening on each ECDT related 
commits.

My observation result is:
For ACPI 2.0+ compliant platforms, where ECDT may be introduced, the BIOSes that
contain the ECDT will make the named object's value that originally is flagged 
in
EC._REG() flagged very early (either default is flagged or flagged in _SB._INI) 
in order
to have all _INI control methods invoked with EC operation region accessibility 
ready.
This is one of the key ACPI 2.0 features.
And this implies that, for ACPI 2.0+, before executing all _INI control 
methods, BIOSes
have already a deal with OSPMs in the spec that there shouldn't be any control 
methods
executed before _SB._INI. In other words, for EC, in order to support ECDT in 
early stage,
when ECDT is probed, it:
1. Shouldn't enable GPE in order not to execute any _Lxx/_Exx;
2. Shouldn't handle SCI_EVT in order not to execute any _Qxx;
3. Shouldn't invoke _REG but should still make the region handler ready;
4. Shouldn't visit any namespace objects (either _GPE/_CRS or the EC device 
itself)
since it shouldn't think the namespace is ready at this point.

Here is the details:

1. Pre-loaded DSDT EC
   Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=9916
   Reporter: Jiri Kosina 
   Machine: Lenovo ThinkPad X61s
   DSDT: \_SB.PCI0.LPC.EC
   ECDT: \_SB.PCI0.LPC.EC
   _REG: Store(Arg1, \H8DR)
   \_H8DR: Default is Zero, set to One very early in \_SB._INI when _REV >= 2.
   Root cause: Shouldn't register EC GPE handler in early stage.
   Old fix: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=208c70a
   New fix: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2044702

It looks to me that:
1. The commit 208c70a is wrong, it shouldn't invoke acpi_get_handle() here.
2. The commit 2044702 is correct, it avoids executing control methods during 
early stage.

2. Pre-loaded DSDT EC is broken/reworked
   Bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=10100
 https://lkml.org/lkml/2008/2/25/282
   Reporter: Michael S. Tsirkin 
   Machine: Lenovo ThinkPad T61p
DSDT: https://lkml.org/lkml/2008/2/25/337
   Root cause: Shouldn't register _Qxx handlers in early stage.
   DSDT: \_SB.PCI0.LPC.EC
   ECDT: \_SB.PCI0.LPC.EC
   _REG: Store(Arg1, \H8DR)
   \_H8DR: Default is Zero, set to One very early in \_SB._INI when _REV >= 2.
   Old Fix: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4af8e10
   New fix: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ce52ddf

It looks to me that:
1. The commit 4af8e10 is correct, it reverts wrong commit 208c70a.
2. The commit ce52ddf is wrong, it splits the _Qxx registration from 
ec_parse_devices() while it really should be there,
 and again invokes acpi_get_handle() in early stage.

Lenovo ThinkPad X61s and T61p are also good ECDT support examples that:
If OSPMs support ACPI 2.0, EC is accessible in AML before executing its _REG.
EC accessibility thus is ready very early in \_SB._INI so that all _INI control 
methods can access EC.

3. Wrong ECDT - reversed
   Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=9399
   Reporter: Milo Casagrande 
   Machine: Asus L4R, Asus M6R
   DSDT: \_SB.PCI0.SBRG.EC0
   ECDT: \_SB.PCI0.SBRG.EC0
   _REG: Store (Arg1, \_SB.PCI0.SBRG.EC0.REGC)
   \_SB.PCI0.SBRG.EC0.REGC: Default is Zero, returned from 
\_SB.PCI0.SBRG.EC0.ECAV.
   \_SB.PCI0.SBRG.EC0.ECAV: Return One  If (_REG(0x03, Ones) && _REV >= 2) || 
_REG(0x03,  One)
Return Zero If (_REG(0x03, Ones) && _REV <  2) || 
_REG(0x03, zero)
When ECAV returns Zero, sometimes port 0x66 (EC 
command/status register) is directly accessed, sometimes no-op.
   Root cause: ECDT is broken. The command/data IO port addresses are reversed.
   Old fix: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2500822
   New fix: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c6cb0e8

It looks to me that:
1. The commit 2500822 is good, it adds quirks for the root cause.
2. The commit c6cb0e8 is wrong, it makes the platform working by use namespace 
EC
 instead of ECDT EC which make the early namespace referencing problem more 
serious.

For this platform, it looks _REG(0x03, Ones) may be invoked by an OEM driver.
So we may not fix this platform using such a kind of quirk.
If we want to add quirk for this platform in Linux,  we may just make sure:
  EC data register address < EC status/command register address

4. Wrong ECDT - dummy
   Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=11880
   Reporter: 
   Machine: Asus X50GL
   DSDT: \_SB.PCI0.SBRG.EC0
   ECDT: \_SB.PCI0.ISA.EC
   _REG: Store (Arg1, \_SB.PCI0.SBRG.EC0.ECFL)
   \_SB.PCI0.SBRG.EC0.ECFL: Default is Ones, returned from 
\_SB.PCI0.SBRG.EC0.ECAV
   \_SB.PCI0.SBRG.EC0.ECAV: Return  

[PATCH] mmc: core: Fix init_card in 52Mhz

[Chaotian Jing]

Suppose that we got a data crc error, and it triggers the mmc_reset.
mmc_reset will call mmc_send_status to see if HW reset was supported.
before issue CMD13, it will do retune, and if EMMC was in HS400 mode,
it will reduce frequency to 52Mhz firstly, that results in card init
was doing at 52Mhz, So need ensure frequency is lower than 400Khz when
re-init card.

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/core/mmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index e726903..f2d0c2a 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1945,6 +1945,7 @@ static int mmc_reset(struct mmc_host *host)
 
/* Set initial state and call mmc_set_ios */
mmc_set_initial_state(host);
+   mmc_set_clock(host, host->f_init);
mmc_host_clk_release(host);
 
return mmc_init_card(host, card->ocr, card);
-- 
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: [RFC 0/6] Non perf based Gen Graphics OA unit driver

[Zhenyu Wang]

On 2015.09.29 15:39:03 +0100, Robert Bragg wrote:
> 
> - Logistically it might be more practical to contain this to the
>   graphics stack.
> 
> It seems fair to consider that if we can't see a very compelling
> benefit to building on perf, then containing this work to
> drivers/gpu/drm/i915 may simplify the review process as well as
> future maintenance and development.
> 

I think even we all initially like to go with perf but it appears later
that we might need to stick this more close with i915 driver. Also think
about to enable global profiling for all graphics clients, extending or
enabling it within i915 specific interface seems more feasible instead of
trying to create another PMU driver like previous implementation attempt
to suit the need for different gfx perf data definition.

Robert, thanks for send and elaborate on this.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature

Re: [PATCH] dax: fix deadlock in __dax_fault

[Dave Chinner]

On Tue, Sep 29, 2015 at 08:04:21PM -0600, Ross Zwisler wrote:
> On Tue, Sep 29, 2015 at 12:44:58PM +1000, Dave Chinner wrote:
> <>
> > Already testing a kernel with those reverted. My current DAX patch
> > stack is (bottom is first commit in stack):
> > 
> > f672ae4 xfs: add ->pfn_mkwrite support for DAX
> > 6855c23 xfs: remove DAX complete_unwritten callback
> > e074bdf Revert "dax: fix race between simultaneous faults"
> > 8ba0157 Revert "mm: take i_mmap_lock in unmap_mapping_range() for DAX"
> > a2ce6a5 xfs: DAX does not use IO completion callbacks
> > 246c52a xfs: update size during allocation for DAX
> > 9d10e7b xfs: Don't use unwritten extents for DAX
> > eaef807 xfs: factor out sector mapping.
> > e7f2d50 xfs: introduce per-inode DAX enablement
> 
> Dave, would you be willing to share these patches with me, even if they are
> just RFC?  I'm working through how to add equivalent support in both ext2 and
> ext4, and a conceptual example in XFS would be really helpful.

When I have code that works properly and isn't fundamentally broken,
I'll post it. Hopefully within the next day.

> Eric and Jan, if you guys have any spare cycles to help with the ext2/ext4
> bits, I certainly wouldn't say no.  :)

ext2 already does the block zeroing in allocation, so it only needs
locking help...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
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/

[BUG] perf cross-compile error dual to fixdep not host-exe

[He Kuang]

Hi,

perf cross-compile error dual to fixdep is not a host executable, first bad 
commit
is 7c422f557266("tools build: Build fixdep helper from perf and basic libs")

Cross-compiling an aarch64 target on x86_64 host, error like this:

  $ make ARCH=aarch64 O=xx/aarch64 CROSS_COMPILE=aarch64-linux-gnu
  ...
  make[3]: *** [xx/aarch64/parse-utils.o] Error 126
  make[3]: *** Waiting for unfinished jobs
  /bin/sh: xx/aarch64//fixdep: cannot execute binary file

  $ uname -a
  x86_64 x86_64 x86_64 GNU/Linux

  $ file xx/aarch64//fixdep
  xx/aarch64//fixdep : ELF 64-bit LSB executable, ARM aarch64, version 1
  (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for
  GNU/Linux 3.7.0, not stripped

Thank you

--
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] kexec: fix out of the ELF headers buffer issue in syscall kexec_file_load()

[Dave Young]

On 09/29/15 at 08:58pm, Lee, Chun-Yi wrote:
> This patch modified the code in fill_up_crash_elf_data by using
> walk_system_ram_res instead of walk_system_ram_range to count the max
> number of crash memory ranges. That's because the walk_system_ram_range
> filters out small memory regions that are resided in the same page, but
> walk_system_ram_res does not.
> 
> The oringial issue is page fault error that sometimes happened on big machines
> when preparing ELF headers:
> 
> [  305.291522] BUG: unable to handle kernel paging request at c90613fc9000
> [  305.299621] IP: [] 
> prepare_elf64_ram_headers_callback+0x165/0x260
> [  305.308300] PGD e32067 PUD 6dcbec54067 PMD 9dc9bdeb067 PTE 0
> [  305.315393] Oops: 0002 [#1] SMP
> [...snip]
> [  305.420953] task: 8e1c01ced600 ti: 8e1c03ec2000 task.ti: 
> 8e1c03ec2000
> [  305.429292] RIP: 0010:[]  [] 
> prepare_elf64_ra
> m_headers_callback+0x165/0x260
> [...snip]
> 
> After tracing prepare_elf64_headers and prepare_elf64_ram_headers_callback,
> the code uses walk_system_ram_res to fill-in crash memory regions information
> to program header, so it counts those small memory regions that are resided in
> a page area. But, when kernel was using walk_system_ram_range in
> fill_up_crash_elf_data to count the number of crash memory regions, it filters
> out small regions. I printed those small memory regions, for example:
> 
> kexec: Get nr_ram ranges. vaddr=0x880077592258 paddr=0x77592258, sz=0xdc0
> 
> Base on the code in walk_system_ram_range, this memory region will be filtered
> out:
> 
> pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
> end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
> end_pfn - pfn = 0x77593 - 0x77593 = 0  <=== if (end_pfn > pfn) is FALSE
> 
> So, the max_nr_ranges that's counted by kernel doesn't include small memory
> regions. That causes the page fault issue happened in later code path for
> preparing EFL headers.
> 
> This issus is not easy to reproduce on small machines that don't have too
> many CPUs because the allocated page aligned ELF buffer has more free space
> to cover those small memory regions' PT_LOAD headers.
> 
> v3:
> Changed the declaration of nr_ranges to be unsigned int*
> 
> v2:
> To simplify the patch description, removed some things about CPU number to
> avoid confusing patch reviewer.
> 
> Signed-off-by: Lee, Chun-Yi 
> ---
>  arch/x86/kernel/crash.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index e068d66..74ca2fe 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -185,10 +185,9 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
>  }
>  
>  #ifdef CONFIG_KEXEC_FILE
> -static int get_nr_ram_ranges_callback(unsigned long start_pfn,
> - unsigned long nr_pfn, void *arg)
> +static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
>  {
> - int *nr_ranges = arg;
> + unsigned int *nr_ranges = arg;
>  
>   (*nr_ranges)++;
>   return 0;
> @@ -214,7 +213,7 @@ static void fill_up_crash_elf_data(struct crash_elf_data 
> *ced,
>  
>   ced->image = image;
>  
> - walk_system_ram_range(0, -1, _ranges,
> + walk_system_ram_res(0, -1, _ranges,
>   get_nr_ram_ranges_callback);
>  
>   ced->max_nr_ranges = nr_ranges;

Acked-by: Dave Young 

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/

Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()

[Chen Fan]

On 09/29/2015 12:37 AM, Eric W. Biederman wrote:

Oleg Nesterov  writes:


On 09/25, Konstantin Khlebnikov wrote:

+struct ns_common *proc_ns_fdget(int fd, int nstype, struct fd *fd_ref)
  {
-   struct file *file;
+   struct ns_common *ns;
+   struct fd f;
  
-	file = fget(fd);

-   if (!file)
+   f = fdget(fd);
+   if (!f.file)
return ERR_PTR(-EBADF);
  
-	if (file->f_op != _file_operations)

+   if (f.file->f_op != _file_operations)
+   goto out_invalid;
+
+   ns = get_proc_ns(file_inode(f.file));
+   if (nstype && (ns->ops->type != nstype))
goto out_invalid;
  
-	return file;

+   *fd_ref = f;
+   return ns;
  
  out_invalid:

-   fput(file);
+   fdput(f);
return ERR_PTR(-EINVAL);
  }

Well yes, fdget() makes sense but this is minor.

Honestly, I do not really like the new helper... I understand this
is subjective, so I won't insist. But how about 1/1? We do not need
fd/file at all. With this patch your sys_getvpid() can just use
proc_get_ns_by_fd(fd, CLONE_NEWPID) and put_pid_ns().

Eric, what do you think?

At some level I don't care this is not exposed to userspace.

However since we are going several rounds with this.

Of the existing uses several of them sleep, which unfortunately means we
can not use rcu locking for everything.  The network namespace ones wind
up taking a reference to struct net because the have the legacy pid case
to deal with.  Which makes we can not use fdget for all callers either.

For this translate_pid rcu locking is sufficient, rcu locking is easy
and doing any more than rcu locking just seems silly.  So let me
respectfully suggest.

struct ns_common *ns_by_fd_rcu(int fd, int type)
{
struct files_struct *files = current->files;
struct file *file;
struct ns_common *ns;
void *ret;

pointer files seems no more useful. we can
use fcheck(fd) instead.

Thanks,



file = fcheck_files(files, fd);
 if (!file)
return ERR_PTR(-EBADF);

if (file->f_mode & FMODE_PATH)
return ERR_PTR(-EINVAL);

if (file->f_op != _file_operations)
return ERR_PTR(-EINVAL);

ns = get_proc_ns(file_inode(file));
if (ns->ops->type != type)
return ERR_PTR(-EINVAL);

return ns;
}

struct pid_namespace *pidns_by_fd_rcu(int fd)
{
struct ns_common *ns = ns_by_fd_rcu(fd, CLONE_NEWPID);
 if (IS_ERR(ns))
return ERR_CAST(ns);
return container_of(ns, struct pid_namespace, ns);
}

SYSCALL_DEFINE3(translate_pid, pid_t, pid_nr, int, sourcefd, int, targetfd)
{
struct pid_namespace *source, *target;
struct pid *pid;
pid_t result;

rcu_read_lock();

if (sourcefd >= 0)
source = pidns_by_fd_rcu(sourcefd);
else
source = task_active_pid_ns(current);

if (targetfd >= 0)
target = pidns_by_fd_rcu(targetfd);
else
target = task_active_pid_ns(current);

pid = find_pid_ns(pid_nr, source);
 result = pid_nr_ns(pid, target);
 if (result == 0)
result = -ESRCH;

rcu_read_unlock();

return result;
}

Eric
.



--
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

[Stephen Rothwell]

Hi all,

On Thu, 17 Sep 2015 10:34:23 +1000 Stephen Rothwell  
wrote:
>
> On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa  wrote:
> >
> > On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > > 
> > > 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
> 
> OK, for now I will clean out my objdir before doing the perf build
> after the tip tree merge.  It would be nice to have this fixed, though,
> if possible.

I noticed some commits in the tip tree today that seemed as though they
were addressing this problem.  However, I still get a build failure if
I don't clean out the object directory before building tools/perf:

  BUILD:   Doing 'make -j48' parallel build
  GEN  /home/sfr/next/perf/common-cmds.h
  CC   /home/sfr/next/perf/fixdep.o
  LD   /home/sfr/next/perf/fixdep-in.o
  LINK /home/sfr/next/perf/fixdep
  CC   /home/sfr/next/perf/perf-read-vdso32
  CC   /home/sfr/next/perf/perf-read-vdsox32
make[3]: *** No rule to make target 
'/home/sfr/next/next/tools/lib/api/fs/debugfs.h', needed by 
'/home/sfr/next/perf/ui/gtk/browser.o'.  Stop.
/home/sfr/next/next/tools/build/Makefile.build:116: recipe for target 'ui/gtk' 
failed
make[2]: *** [ui/gtk] Error 2
Makefile.perf:310: recipe for target '/home/sfr/next/perf/gtk-in.o' failed

(/home/sfr/next/perf/ is the object directory)
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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] arm64: ftrace: fix function_graph tracer panic

[Li Bin]

When function graph tracer is enabled, the following operation
will trigger panic:

mount -t debugfs nodev /sys/kernel
echo next_tgid > /sys/kernel/tracing/set_ftrace_filter
echo function_graph > /sys/kernel/tracing/current_tracer
ls /proc/

[ cut here ]
[  198.501417] Unable to handle kernel paging request at virtual address 
cb88537fdc8ba316
[  198.506126] pgd = ffc008f79000
[  198.509363] [cb88537fdc8ba316] *pgd=488c6003, *pud=488c6003, 
*pmd=
[  198.517726] Internal error: Oops: 9405 [#1] SMP
[  198.518798] Modules linked in:
[  198.520582] CPU: 1 PID: 1388 Comm: ls Tainted: G
[  198.521800] Hardware name: linux,dummy-virt (DT)
[  198.522852] task: ffc0fa9e8000 ti: ffc0f9ab task.ti: 
ffc0f9ab
[  198.524306] PC is at next_tgid+0x30/0x100
[  198.525205] LR is at return_to_handler+0x0/0x20
[  198.526090] pc : [] lr : [] pstate: 
6145
[  198.527392] sp : ffc0f9ab3d40
[  198.528084] x29: ffc0f9ab3d40 x28: ffc0f9ab
[  198.529406] x27: ffc000d6a000 x26: ffc000b786e8
[  198.530659] x25: ffc0002a1900 x24: ffc0faf16c00
[  198.531942] x23: ffc0f9ab3ea0 x22: 0002
[  198.533202] x21: ffc000d85050 x20: 0002
[  198.534446] x19: 0002 x18: 
[  198.535719] x17: 0049fa08 x16: ffc000242efc
[  198.537030] x15: 007fa472b54c x14: ff00
[  198.538347] x13: ffc0fada84a0 x12: 0001
[  198.539634] x11: ffc0f9ab3d70 x10: ffc0f9ab3d70
[  198.540915] x9 : ffc907c0 x8 : ffc0f9ab3d40
[  198.542215] x7 : 002e330f08f0 x6 : 0015
[  198.543508] x5 : 0f08 x4 : ffc0f9835ec0
[  198.544792] x3 : cb88537fdc8ba316 x2 : cb88537fdc8ba306
[  198.546108] x1 : 0002 x0 : ffc000d85050
[  198.547432]
[  198.547920] Process ls (pid: 1388, stack limit = 0xffc0f9ab0020)
[  198.549170] Stack: (0xffc0f9ab3d40 to 0xffc0f9ab4000)
[  198.582568] Call trace:
[  198.583313] [] next_tgid+0x30/0x100
[  198.584359] [] ftrace_graph_caller+0x6c/0x70
[  198.585503] [] ftrace_graph_caller+0x6c/0x70
[  198.586574] [] ftrace_graph_caller+0x6c/0x70
[  198.587660] [] ftrace_graph_caller+0x6c/0x70
[  198.588896] Code: aa0003f5 2a0103f4 b4000102 91004043 (885f7c60)
[  198.591092] ---[ end trace 6a346f8f20949ac8 ]---

This is because when using function graph tracer, if the traced
function return value is in multi regs ([0x-07]), return_to_handler
may corrupt them. So in return_to_handler, the parameter regs should
be protected properly.

Cc:  # 3.18+
Signed-off-by: Li Bin 
---
 arch/arm64/kernel/entry-ftrace.S |   22 --
 1 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
index 08cafc5..0f03a8f 100644
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -178,6 +178,24 @@ ENTRY(ftrace_stub)
 ENDPROC(ftrace_stub)
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
+   /* save return value regs*/
+   .macro save_return_regs
+   sub sp, sp, #64
+   stp x0, x1, [sp]
+   stp x2, x3, [sp, #16]
+   stp x4, x5, [sp, #32]
+   stp x6, x7, [sp, #48]
+   .endm
+
+   /* restore return value regs*/
+   .macro restore_return_regs
+   ldp x0, x1, [sp]
+   ldp x2, x3, [sp, #16]
+   ldp x4, x5, [sp, #32]
+   ldp x6, x7, [sp, #48]
+   add sp, sp, #64
+   .endm
+
 /*
  * void ftrace_graph_caller(void)
  *
@@ -204,11 +222,11 @@ ENDPROC(ftrace_graph_caller)
  * only when CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST is enabled.
  */
 ENTRY(return_to_handler)
-   str x0, [sp, #-16]!
+   save_return_regs
mov x0, x29 // parent's fp
bl  ftrace_return_to_handler// addr = ftrace_return_to_hander(fp);
mov x30, x0 // restore the original return address
-   ldr x0, [sp], #16
+   restore_return_regs
ret
 END(return_to_handler)
 #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
-- 
1.7.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] staging: vt6655: Fixed two lines over 80 characters

[Greg KH]

On Tue, Sep 29, 2015 at 10:37:24PM +0530, Arjun Krishna Babu wrote:
> Two lines of code that were over 80 characters long is fixed by
> splitting them into multiple lines.
> 
> This way, the lines of code are now easier to read.
> 
> Issue found by checkpatch.
> 
> Signed-off-by: Arjun Krishna Babu 
> ---
>  drivers/staging/vt6655/baseband.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/vt6655/baseband.c 
> b/drivers/staging/vt6655/baseband.c
> index 9e61f2d..3639f9d 100644
> --- a/drivers/staging/vt6655/baseband.c
> +++ b/drivers/staging/vt6655/baseband.c
> @@ -2089,9 +2089,18 @@ bool BBbVT3253Init(struct vnt_private *priv)
>   byVT3253B0_UW2451[ii][0],
>   byVT3253B0_UW2451[ii][1]);
>  
> - /* Init ANT B select,TX Config CR09 = 0x61->0x45, 
> 0x45->0x41(VC1/VC2 define, make the ANT_A, ANT_B inverted) */
> + /* Init ANT B select,
> +  * TX Config CR09 = 0x61->0x45, 
> +  * 0x45->0x41(VC1/VC2 define, make the ANT_A, ANT_B inverted)
> +  */
> +
>   /*bResult &= BBbWriteEmbedded(dwIoBase,0x09,0x41);*/
> - /* Init ANT B select,RX Config CR10 = 0x28->0x2A, 
> 0x2A->0x28(VC1/VC2 define, make the ANT_A, ANT_B inverted) */
> +
> + /* Init ANT B select,
> +  * RX Config CR10 = 0x28->0x2A, 
> +  * 0x2A->0x28(VC1/VC2 define, make the ANT_A, ANT_B inverted) 
> +  */
> +

Please always run your patches through checkpatch.pl, so that you don't
get an email from the maintainers saying that you need to run your patch
through checkpatch.pl.

thanks,

greg k-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/

Re: [PATCH v3 2/2] iio:light:ap3223: Add DT support

[Rob Herring]

On Tue, Sep 29, 2015 at 8:36 PM, Suresh Rajashekara
 wrote:
> * Add Device Tree support for the Dyna Image AP3223 ambient light sensor and
> * proximity driver,
> * Document the binding and
> * Add a vendor prefix for Dyna Image
>
> v3
> * Fixing typo in comment
> v2
> * Seperating the device tree changes from code
>
> Signed-off-by: Suresh Rajashekara 
> ---
>  Documentation/devicetree/bindings/iio/light/ap3223.txt | 18 
> ++
>  Documentation/devicetree/bindings/vendor-prefixes.txt  |  1 +
>  2 files changed, 19 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/light/ap3223.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/light/ap3223.txt 
> b/Documentation/devicetree/bindings/iio/light/ap3223.txt
> new file mode 100644
> index 000..b255d27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/ap3223.txt
> @@ -0,0 +1,18 @@
> +* Dyna Image AP3223 ambient light sensor and proximity sensor
> +
> +http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2=8
> +
> +Required properties:
> +
> +  - compatible : should be "dynaimage,ap3223"
> +  - reg : the I2C address of the sensor

We have i2c/trivial-devices.txt for simple devices.

> +
> +Example:
> +
> +ap3223@1c {
> +   compatible = "dynaimage,ap3223";
> +   reg = <0x1c>;
> +
> +   pinctrl-0 = <_pins>;
> +   pinctrl-names = "default";

This doesn't belong here.

> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 5f20add..704da45 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -46,6 +46,7 @@ digilent  Diglent, Inc.
>  dlgDialog Semiconductor
>  dlink  D-Link Corporation
>  dmoData Modul AG
> +dynaimage  Dyna-Image
>  ebvEBV Elektronik
>  edtEmerging Display Technologies
>  elan   Elan Microelectronic Corp.
> --
> 2.6.0.rc2.230.g3dd15c0
>
--
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] net: macb: fix two typos

[Geliang Tang]

Just fix two typos in code comments.

Signed-off-by: Geliang Tang 
---
 drivers/net/ethernet/cadence/macb.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index 6e1faea..866b128 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -267,9 +267,9 @@
 #define MACB_BEX_SIZE  1
 #define MACB_RM9200_BNQ_OFFSET 4 /* AT91RM9200 only */
 #define MACB_RM9200_BNQ_SIZE   1 /* AT91RM9200 only */
-#define MACB_COMP_OFFSET   5 /* Trnasmit complete */
+#define MACB_COMP_OFFSET   5 /* Transmit complete */
 #define MACB_COMP_SIZE 1
-#define MACB_UND_OFFSET6 /* Trnasmit under run */
+#define MACB_UND_OFFSET6 /* Transmit under run */
 #define MACB_UND_SIZE  1
 
 /* Bitfields in RSR */
-- 
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] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

[H. Peter Anvin]

No, it is a natural result of an implemention which treats setting the A bit as 
an abnormal flow (e.g. in microcode as opposed to hardware).

On September 29, 2015 7:11:59 PM PDT, ebied...@xmission.com wrote:
>"H. Peter Anvin"  writes:
>
>> On 09/29/2015 06:20 PM, Eric W. Biederman wrote:
>>> Linus Torvalds  writes:
>>> 
 On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski
> wrote:
>
> Does anyone know what happens if you stick a non-accessed segment
>in
> the GDT, map the GDT RO, and access it?

 You should get a #PF, as you guess, but go ahead and test it if you
 want to make sure.
>>> 
>>> I tested this by accident once when workinng on what has become
>known
>>> as coreboot.  Early in boot with your GDT in a EEPROM switching from
>>> real mode to 32bit protected mode causes a write and locks up the
>>> machine when the hardware declines the write to the GDT to set the
>>> accessed bit.  As I recall the write kept being retried and retried
>and
>>> retried...
>>> 
>>> Setting the access bit in the GDT cleared up the problem and I did
>not
>>> look back.
>>> 
>>> Way up in 64bit mode something might be different, but I don't know
>why
>>> cpu designeres would waste the silicon.
>>> 
>>
>> This is totally different from a TLB violation.  In your case, the
>write
>> goes through as far as the CPU is concerned, but when the data is
>> fetched back, it hasn't changed.  A write to a TLB-protected location
>> will #PF.
>
>The key point is that a write is generated when the cpu needs to set
>the
>access bit.  I agree the failure points are different.  A TLB fault vs
>a
>case where the hardware did not accept the write.
>
>The idea of a cpu reading back data (and not trusting it's cache
>coherency controls) to verify the access bit gets set seems mind
>boggling.  That is slow, stupid, racy and incorrect.  Incorrect as the
>cpu should not only set the access bit once per segment register load.
>
>In my case I am pretty certain it was something very weird with the
>hardware not acceppting the write and either not acknowledging the bus
>transaction or cancelling it.  In which case the cpu knew the write had
>not made it to the ``memory'' and was trying to cope.
>
>Eric

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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/

[GIT PULL] ARM: dts: Exynos improvements for 4.4

[Krzysztof Kozlowski]

Dear Kukjin,

DTS related changes for 4.4.

Description along with a tag.
You can find them also on the lists with my reviewed-by.

Best regards,
Krzysztof


The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  https://github.com/krzk/linux.git tags/samsung-dt-4.4

for you to fetch changes up to 01dd011b7a0230a426a79475ae452298421a16e4:

  ARM: dts: exynos4412-trats2: remove regulator-compatible usage (2015-09-30 
09:03:03 +0900)


Device Tree improvements for Exynos based boards:
1. Enable DMA on Exynos4 serial ports. This old patch uncovered
   a number of other issues in dmaengine and samsung serial driver.
   All of known issues are resolved so finally enable the DMA for UART.
2. Fix incorrect location of display-timings node (FIMD->DP node).
3. Minor cleanups.


Javier Martinez Canillas (1):
  ARM: dts: exynos4412-trats2: remove regulator-compatible usage

Robert Baldyga (1):
  ARM: dts: Add DMA support for serial ports in exynos4

Sean Paul (1):
  ARM: dts: Move display-timings node from fimd to dp on Exynos

Tobias Jakobi (2):
  ARM: dts: Remove redundant pinctrl settings in exynos4412-odroid
  ARM: dts: Unify voltage regulator style in exynos4412-odroid

Vladimir Zapolskiy (1):
  ARM: dts: Fix cpu compatible value for s3c2416

 arch/arm/boot/dts/exynos4.dtsi  |   8 ++
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  12 +--
 arch/arm/boot/dts/exynos4412-trats2.dts | 105 
 arch/arm/boot/dts/exynos5250-arndale.dts|   8 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts   |  16 ++--
 arch/arm/boot/dts/exynos5420-smdk5420.dts   |   7 +-
 arch/arm/boot/dts/s3c2416.dtsi  |   2 +-
 7 files changed, 62 insertions(+), 96 deletions(-)
--
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/

[GIT PULL] ARM: defconfig: Exynos improvements for 4.4

[Krzysztof Kozlowski]

Dear Kukjin,

Few defconfig related changes for 4.4.

Description along with a tag.
You can find them also on the lists with my reviewed-by.

Best regards,
Krzysztof


The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  https://github.com/krzk/linux.git tags/samsung-defconfig-4.4

for you to fetch changes up to 7fa5ce4e6fcb4596761c17e124e7d1f8cf64fe96:

  ARM: exynos_defconfig: Disable simplefb support (2015-09-13 19:25:39 +0900)


Defconfig changes around Exynos based boards:
1. Enable DWC2 USB driver for exynos and multi_v7 defconfigs.
   The driver is present on Exynos and Rockhip boards. Enabling also
   ethernet gadget allows betwork communication with the device.
2. Enable LEDS for Odroid XU3/XU4 family boards (provides simple
   monitoring of the board).
3. Disable the simplefb driver because in certain situations (when
   U-boot injects simplefb bindings into DTB) it may break display.


Anand Moon (1):
  ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4

Javier Martinez Canillas (1):
  ARM: exynos_defconfig: Disable simplefb support

Marek Szyprowski (2):
  ARM: exynos_defconfig: Enable DWC2 USB driver and USB ethernet gadget
  ARM: multi_v7_defconfig: Enable DWC2 USB driver and USB ethernet gadget

 arch/arm/configs/exynos_defconfig   | 9 -
 arch/arm/configs/multi_v7_defconfig | 2 ++
 2 files changed, 10 insertions(+), 1 deletion(-)
--
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/

[GIT PULL] arm64: dts: Exynos ARMv8 improvements for 4.4

[Krzysztof Kozlowski]

Dear Kukjin,

One ARMv8 DTS change for 4.4.

Best regards,
Krzysztof

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  https://github.com/krzk/linux.git tags/samsung-dt64-4.4

for you to fetch changes up to 235c8e96f54a76bee201a7c86620c351a30b1ac6:

  arm64: dts: Add BUS1 instance pinctrl support for exynos7 (2015-09-16 
09:03:09 +0900)


Device Tree improvements for Exynos ARMv8 based boards:
1. Add a BUS1 instance pinctrl for Exynos7 SoC.


Alim Akhtar (1):
  arm64: dts: Add BUS1 instance pinctrl support for exynos7

 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 103 
 arch/arm64/boot/dts/exynos/exynos7.dtsi |   7 ++
 2 files changed, 110 insertions(+)
--
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 3/3] mm/oom_kill: fix the wrong task->mm == mm checks in

[Tetsuo Handa]

Oleg Nesterov wrote:
> Both "child->mm == mm" and "p->mm != mm" checks in oom_kill_process()
> are wrong. ->mm can be if task is the exited group leader. This means

can be [missing word here?] if task



> +static bool process_has_mm(struct task_struct *p, struct mm_struct *mm)
> +{
> + struct task_struct *t;
> +
> + for_each_thread(p, t)
> + if (t->mm)

Can t->mm change between pevious line and next line?

> + return t->mm == mm;
> +
> + return false;
> +}
> +
>  #define K(x) ((x) << (PAGE_SHIFT-10))
>  /*
>   * Must be called while holding a reference to p, which will be released upon
> @@ -530,7 +541,7 @@ void oom_kill_process(struct oom_control *oc, struct 
> task_struct *p,
>   list_for_each_entry(child, >children, sibling) {
>   unsigned int child_points;
>  
> - if (child->mm == p->mm)
> + if (process_has_mm(child, p->mm))
>   continue;

We hold read_lock(_lock) but not rcu_read_lock().
Is for_each_thread() safe without rcu_read_lock()?

>   /*
>* oom_badness() returns 0 if the thread is unkillable
--
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] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

[Eric W. Biederman]

"H. Peter Anvin"  writes:

> On 09/29/2015 06:20 PM, Eric W. Biederman wrote:
>> Linus Torvalds  writes:
>> 
>>> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski  
>>> wrote:

 Does anyone know what happens if you stick a non-accessed segment in
 the GDT, map the GDT RO, and access it?
>>>
>>> You should get a #PF, as you guess, but go ahead and test it if you
>>> want to make sure.
>> 
>> I tested this by accident once when workinng on what has become known
>> as coreboot.  Early in boot with your GDT in a EEPROM switching from
>> real mode to 32bit protected mode causes a write and locks up the
>> machine when the hardware declines the write to the GDT to set the
>> accessed bit.  As I recall the write kept being retried and retried and
>> retried...
>> 
>> Setting the access bit in the GDT cleared up the problem and I did not
>> look back.
>> 
>> Way up in 64bit mode something might be different, but I don't know why
>> cpu designeres would waste the silicon.
>> 
>
> This is totally different from a TLB violation.  In your case, the write
> goes through as far as the CPU is concerned, but when the data is
> fetched back, it hasn't changed.  A write to a TLB-protected location
> will #PF.

The key point is that a write is generated when the cpu needs to set the
access bit.  I agree the failure points are different.  A TLB fault vs a
case where the hardware did not accept the write.

The idea of a cpu reading back data (and not trusting it's cache
coherency controls) to verify the access bit gets set seems mind
boggling.  That is slow, stupid, racy and incorrect.  Incorrect as the
cpu should not only set the access bit once per segment register load.

In my case I am pretty certain it was something very weird with the
hardware not acceppting the write and either not acknowledging the bus
transaction or cancelling it.  In which case the cpu knew the write had
not made it to the ``memory'' and was trying to cope.

Eric



--
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 3.14 00/84] 3.14.54-stable review

[Greg Kroah-Hartman]

On Tue, Sep 29, 2015 at 02:15:27PM -0700, Guenter Roeck wrote:
> On 09/29/2015 08:17 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.14.54 release.
> >There are 84 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Thu Oct  1 14:52:55 UTC 2015.
> >Anything received after that time might be too late.
> >
> 
> Build results:
>   total: 127 pass: 127 fail: 0
> Qemu test results:
>   total: 80 pass: 80 fail: 0
> 
> Details are available at http://server.roeck-us.net:8010/builders.

thanks for testing these and letting me know.

greg k-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/

[PATCH 2/2] tile/jump_label: add jump label support for TILE-Gx

[Zhigang Lu]

Add the arch-specific code to support jump label for TILE-Gx. This
code shares NOP instruction with ftrace, so we move it to a common
header file.

Reviewed-by: Chris Metcalf 
Signed-off-by: Zhigang Lu 
---
 arch/tile/Kconfig  |  1 +
 arch/tile/include/asm/insn.h   | 59 +++
 arch/tile/include/asm/jump_label.h | 58 ++
 arch/tile/kernel/Makefile  |  1 +
 arch/tile/kernel/ftrace.c  | 11 +--
 arch/tile/kernel/jump_label.c  | 64 ++
 6 files changed, 184 insertions(+), 10 deletions(-)
 create mode 100644 arch/tile/include/asm/insn.h
 create mode 100644 arch/tile/include/asm/jump_label.h
 create mode 100644 arch/tile/kernel/jump_label.c

diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 106c21b..dff39e2 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -33,6 +33,7 @@ config TILE
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select HAVE_ARCH_SECCOMP_FILTER
+   select HAVE_ARCH_JUMP_LABEL
 
 # FIXME: investigate whether we need/want these options.
 #  select HAVE_IOREMAP_PROT
diff --git a/arch/tile/include/asm/insn.h b/arch/tile/include/asm/insn.h
new file mode 100644
index 000..f78ba5c
--- /dev/null
+++ b/arch/tile/include/asm/insn.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2015 Tilera Corporation. All Rights Reserved.
+ *
+ *   This program is free software; you can redistribute it and/or
+ *   modify it under the terms of the GNU General Public License
+ *   as published by the Free Software Foundation, version 2.
+ *
+ *   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, GOOD TITLE or
+ *   NON INFRINGEMENT.  See the GNU General Public License for
+ *   more details.
+ */
+#ifndef __ASM_TILE_INSN_H
+#define __ASM_TILE_INSN_H
+
+#include 
+
+static inline tilegx_bundle_bits NOP(void)
+{
+   return create_UnaryOpcodeExtension_X0(FNOP_UNARY_OPCODE_X0) |
+   create_RRROpcodeExtension_X0(UNARY_RRR_0_OPCODE_X0) |
+   create_Opcode_X0(RRR_0_OPCODE_X0) |
+   create_UnaryOpcodeExtension_X1(NOP_UNARY_OPCODE_X1) |
+   create_RRROpcodeExtension_X1(UNARY_RRR_0_OPCODE_X1) |
+   create_Opcode_X1(RRR_0_OPCODE_X1);
+}
+
+static inline tilegx_bundle_bits tilegx_gen_branch(unsigned long pc,
+   unsigned long addr,
+   bool link)
+{
+   tilegx_bundle_bits opcode_x0, opcode_x1;
+   long pcrel_by_instr = (addr - pc) >> TILEGX_LOG2_BUNDLE_SIZE_IN_BYTES;
+
+   if (link) {
+   /* opcode: jal addr */
+   opcode_x1 =
+   create_Opcode_X1(JUMP_OPCODE_X1) |
+   create_JumpOpcodeExtension_X1(JAL_JUMP_OPCODE_X1) |
+   create_JumpOff_X1(pcrel_by_instr);
+   } else {
+   /* opcode: j addr */
+   opcode_x1 =
+   create_Opcode_X1(JUMP_OPCODE_X1) |
+   create_JumpOpcodeExtension_X1(J_JUMP_OPCODE_X1) |
+   create_JumpOff_X1(pcrel_by_instr);
+   }
+
+   /* opcode: fnop */
+   opcode_x0 =
+   create_UnaryOpcodeExtension_X0(FNOP_UNARY_OPCODE_X0) |
+   create_RRROpcodeExtension_X0(UNARY_RRR_0_OPCODE_X0) |
+   create_Opcode_X0(RRR_0_OPCODE_X0);
+
+   return opcode_x1 | opcode_x0;
+}
+
+#endif /* __ASM_TILE_INSN_H */
diff --git a/arch/tile/include/asm/jump_label.h 
b/arch/tile/include/asm/jump_label.h
new file mode 100644
index 000..cde7573
--- /dev/null
+++ b/arch/tile/include/asm/jump_label.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright 2015 Tilera Corporation. All Rights Reserved.
+ *
+ *   This program is free software; you can redistribute it and/or
+ *   modify it under the terms of the GNU General Public License
+ *   as published by the Free Software Foundation, version 2.
+ *
+ *   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, GOOD TITLE or
+ *   NON INFRINGEMENT.  See the GNU General Public License for
+ *   more details.
+ */
+
+#ifndef _ASM_TILE_JUMP_LABEL_H
+#define _ASM_TILE_JUMP_LABEL_H
+
+#include 
+
+#define JUMP_LABEL_NOP_SIZETILE_BUNDLE_SIZE_IN_BYTES
+
+static __always_inline bool arch_static_branch(struct static_key *key,
+  bool branch)
+{
+   asm_volatile_goto("1:\n\t"
+   "nop" "\n\t"
+   ".pushsection __jump_table,  \"aw\"\n\t"
+   ".quad 1b, %l[l_yes], %0 + %1 \n\t"
+   ".popsection\n\t"
+   : :  "i" (key), "i" (branch) : : l_yes);
+   return false;
+l_yes:
+  

[PATCH 0/2] add jump label support for TILE-Gx

[Zhigang Lu]

This patch set adds jump_label support for TILE-Gx architecture. As
jump_label shares some code with ftrace, kgdb and kprobes, we factor
this out into a helper routine as a prequel patch.

Zhigang Lu (2):
  tile: define a macro ktext_writable_addr to get writable kernel text
address
  tile/jump_label: add jump label support for TILE-Gx

 arch/tile/Kconfig  |  1 +
 arch/tile/include/asm/insn.h   | 59 +++
 arch/tile/include/asm/jump_label.h | 58 +++
 arch/tile/include/asm/page.h   | 10 ++
 arch/tile/kernel/Makefile  |  1 +
 arch/tile/kernel/ftrace.c  | 13 ++--
 arch/tile/kernel/jump_label.c  | 63 ++
 arch/tile/kernel/kgdb.c|  2 +-
 arch/tile/kernel/kprobes.c |  4 +--
 9 files changed, 197 insertions(+), 14 deletions(-)
 create mode 100644 arch/tile/include/asm/insn.h
 create mode 100644 arch/tile/include/asm/jump_label.h
 create mode 100644 arch/tile/kernel/jump_label.c

-- 
2.1.2

--
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] dax: fix deadlock in __dax_fault

[Ross Zwisler]

On Tue, Sep 29, 2015 at 12:44:58PM +1000, Dave Chinner wrote:
<>
> Already testing a kernel with those reverted. My current DAX patch
> stack is (bottom is first commit in stack):
> 
> f672ae4 xfs: add ->pfn_mkwrite support for DAX
> 6855c23 xfs: remove DAX complete_unwritten callback
> e074bdf Revert "dax: fix race between simultaneous faults"
> 8ba0157 Revert "mm: take i_mmap_lock in unmap_mapping_range() for DAX"
> a2ce6a5 xfs: DAX does not use IO completion callbacks
> 246c52a xfs: update size during allocation for DAX
> 9d10e7b xfs: Don't use unwritten extents for DAX
> eaef807 xfs: factor out sector mapping.
> e7f2d50 xfs: introduce per-inode DAX enablement

Dave, would you be willing to share these patches with me, even if they are
just RFC?  I'm working through how to add equivalent support in both ext2 and
ext4, and a conceptual example in XFS would be really helpful.

Eric and Jan, if you guys have any spare cycles to help with the ext2/ext4
bits, I certainly wouldn't say no.  :)
--
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/1] trace-event-python.c used malloc without checking ptr if NULL

[Heloise NH]

Signed-off-by: Heloise NH 
---
 tools/perf/util/scripting-engines/trace-event-python.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index cff58ae..14d8e73 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -475,7 +475,7 @@ static int python_start_script(const char *script, int 
argc, const char **argv)
FILE *fp;
 
command_line = malloc((argc + 1) * sizeof(const char *));
-   if (command_line == NULL){
+   if (command_line == NULL) {
err = -1;
goto error;
}
-- 
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] tile: define a macro ktext_writable_addr to get writable kernel text address

[Zhigang Lu]

It is used by kgdb, ftrace, kprobe and jump label, so we factor
this out into a helper routine.

Reviewed-by: Chris Metcalf 
Signed-off-by: Zhigang Lu 
---
 arch/tile/include/asm/page.h | 10 ++
 arch/tile/kernel/ftrace.c|  2 +-
 arch/tile/kernel/kgdb.c  |  2 +-
 arch/tile/kernel/kprobes.c   |  4 ++--
 4 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/tile/include/asm/page.h b/arch/tile/include/asm/page.h
index a213a8d..5cee2cb 100644
--- a/arch/tile/include/asm/page.h
+++ b/arch/tile/include/asm/page.h
@@ -319,6 +319,16 @@ static inline int pfn_valid(unsigned long pfn)
 #define virt_to_page(kaddr) pfn_to_page(kaddr_to_pfn((void *)(kaddr)))
 #define page_to_virt(page) pfn_to_kaddr(page_to_pfn(page))
 
+/*
+ * The kernel text is mapped at MEM_SV_START as read-only.  To allow
+ * modifying kernel text, it is also mapped at PAGE_OFFSET as read-write.
+ * This macro converts a kernel address to its writable kernel text mapping,
+ * which is used to modify the text code on a running kernel by kgdb,
+ * ftrace, kprobe, jump label, etc.
+ */
+#define ktext_writable_addr(kaddr) \
+   ((unsigned long)(kaddr) - MEM_SV_START + PAGE_OFFSET)
+
 struct mm_struct;
 extern pte_t *virt_to_pte(struct mm_struct *mm, unsigned long addr);
 extern pte_t *virt_to_kpte(unsigned long kaddr);
diff --git a/arch/tile/kernel/ftrace.c b/arch/tile/kernel/ftrace.c
index 0c09961..4180ccdf 100644
--- a/arch/tile/kernel/ftrace.c
+++ b/arch/tile/kernel/ftrace.c
@@ -117,7 +117,7 @@ static int ftrace_modify_code(unsigned long pc, unsigned 
long old,
return -EINVAL;
 
/* Operate on writable kernel text mapping. */
-   pc_wr = pc - MEM_SV_START + PAGE_OFFSET;
+   pc_wr = ktext_writable_addr(pc);
 
if (probe_kernel_write((void *)pc_wr, , MCOUNT_INSN_SIZE))
return -EPERM;
diff --git a/arch/tile/kernel/kgdb.c b/arch/tile/kernel/kgdb.c
index ff5335a..a506c2c 100644
--- a/arch/tile/kernel/kgdb.c
+++ b/arch/tile/kernel/kgdb.c
@@ -164,7 +164,7 @@ static unsigned long writable_address(unsigned long addr)
unsigned long ret = 0;
 
if (core_kernel_text(addr))
-   ret = addr - MEM_SV_START + PAGE_OFFSET;
+   ret = ktext_writable_addr(addr);
else if (is_module_text_address(addr))
ret = addr;
else
diff --git a/arch/tile/kernel/kprobes.c b/arch/tile/kernel/kprobes.c
index f8a45c5..c68694b 100644
--- a/arch/tile/kernel/kprobes.c
+++ b/arch/tile/kernel/kprobes.c
@@ -116,7 +116,7 @@ void __kprobes arch_arm_kprobe(struct kprobe *p)
unsigned long addr_wr;
 
/* Operate on writable kernel text mapping. */
-   addr_wr = (unsigned long)p->addr - MEM_SV_START + PAGE_OFFSET;
+   addr_wr = ktext_writable_addr(p->addr);
 
if (probe_kernel_write((void *)addr_wr, _insn,
sizeof(breakpoint_insn)))
@@ -131,7 +131,7 @@ void __kprobes arch_disarm_kprobe(struct kprobe *kp)
unsigned long addr_wr;
 
/* Operate on writable kernel text mapping. */
-   addr_wr = (unsigned long)kp->addr - MEM_SV_START + PAGE_OFFSET;
+   addr_wr = ktext_writable_addr(kp->addr);
 
if (probe_kernel_write((void *)addr_wr, >opcode,
sizeof(kp->opcode)))
-- 
2.1.2

--
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] perf record: Allocate area for sample_id_hdr in a synthesized comm event

[Namhyung Kim]

A previous patch added a synthesized comm event for forked child
process but it missed that the event should contain area for
sample_id_hdr at the end.  It worked by accident since the perf_event
union contains bigger event structs like mmap_events.

This patch fixes it by dynamically allocating event struct including
those area like in perf_event__synthesize_thread_map().

Reported-by: Arnaldo Carvalho de Melo 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-record.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index a01c8ae1ee07..5e01c070dbf2 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -637,17 +637,25 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
 * Let the child rip
 */
if (forks) {
-   union perf_event event;
+   union perf_event *event;
+
+   event = malloc(sizeof(event->comm) + machine->id_hdr_size);
+   if (event == NULL) {
+   err = -ENOMEM;
+   goto out_child;
+   }
+
/*
 * Some H/W events are generated before COMM event
 * which is emitted during exec(), so perf script
 * cannot see a correct process name for those events.
 * Synthesize COMM event to prevent it.
 */
-   perf_event__synthesize_comm(tool, ,
+   perf_event__synthesize_comm(tool, event,
rec->evlist->workload.pid,
process_synthesized_event,
machine);
+   free(event);
 
perf_evlist__start_workload(rec->evlist);
}
-- 
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/

[PATCH 3/3] perf top: Register idle thread

[Namhyung Kim]

The perf top didn't add the idle/swapper thread to the machine's
thread list and its comm was displayed as ':0'.  Fix it.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-top.c  | 3 +++
 tools/perf/util/session.c | 2 +-
 tools/perf/util/session.h | 2 ++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index ae4c6420300b..6f641fd68296 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -964,6 +964,9 @@ static int __cmd_top(struct perf_top *top)
if (ret)
goto out_delete;
 
+   if (perf_session__register_idle_thread(top->session) == NULL)
+   goto out_delete;
+
machine__synthesize_threads(>session->machines.host, >target,
top->evlist->threads, false, 
opts->proc_map_timeout);
 
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 84a02eae4394..428149bc64d2 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1311,7 +1311,7 @@ struct thread *perf_session__findnew(struct perf_session 
*session, pid_t pid)
return machine__findnew_thread(>machines.host, -1, pid);
 }
 
-static struct thread *perf_session__register_idle_thread(struct perf_session 
*session)
+struct thread *perf_session__register_idle_thread(struct perf_session *session)
 {
struct thread *thread;
 
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index b44afc75d1cc..3e900c0efc73 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -89,6 +89,8 @@ struct machine *perf_session__findnew_machine(struct 
perf_session *session, pid_
 }
 
 struct thread *perf_session__findnew(struct perf_session *session, pid_t pid);
+struct thread *perf_session__register_idle_thread(struct perf_session 
*session);
+
 size_t perf_session__fprintf(struct perf_session *session, FILE *fp);
 
 size_t perf_session__fprintf_dsos(struct perf_session *session, FILE *fp);
-- 
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] dax: fix deadlock in __dax_fault

[Dave Chinner]

On Tue, Sep 29, 2015 at 12:44:58PM +1000, Dave Chinner wrote:
> On Mon, Sep 28, 2015 at 04:40:01PM -0600, Ross Zwisler wrote:
> > > > 4) Test all changes with xfstests using both xfs & ext4, using lockep.
> > > > 
> > > > Did I miss any issues, or does this path not solve one of them somehow?
> > > > 
> > > > Does this sound like a reasonable path forward for v4.3?  Dave, and 
> > > > Jan, can
> > > > you guys can provide guidance and code reviews for the XFS and ext4 
> > > > bits?
> > > 
> > > IMO, it's way too much to get into 4.3. I'd much prefer we revert
> > > the bad changes in 4.3, and then work towards fixing this for the
> > > 4.4 merge window. If someone needs this for 4.3, then they can
> > > backport the 4.4 code to 4.3-stable.
> > > 
> > > The "fast and loose and fix it later" development model does not
> > > work for persistent storage algorithms; DAX is storage - not memory
> > > management - and so we need to treat it as such.
> > 
> > Okay.  To get our locking back to v4.2 levels here are the two commits I 
> > think
> > we need to look at:
> > 
> > commit 843172978bb9 ("dax: fix race between simultaneous faults")
> > commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for 
> > DAX")
> 
> Already testing a kernel with those reverted. My current DAX patch
> stack is (bottom is first commit in stack):
> 

And just to indicate why 4.3 is completely unrealistic, let me give
you a summary of this patchset so far:

> f672ae4 xfs: add ->pfn_mkwrite support for DAX

I *think* it works.

> 6855c23 xfs: remove DAX complete_unwritten callback

Gone.

> e074bdf Revert "dax: fix race between simultaneous faults"
> 8ba0157 Revert "mm: take i_mmap_lock in unmap_mapping_range() for DAX"
> a2ce6a5 xfs: DAX does not use IO completion callbacks

DAX still needs to use IO completion callbacks for the DIO path, so
needed rewriting. Made 6855c23 redundant.

> 246c52a xfs: update size during allocation for DAX

Fundamentally broken, so removed. DIO passes the actual size from IO
completion, not into block allocation, hence DIO still needs
completion callbacks. DAX page faults can't change
the file size (should segv before we get here), so need to
specifically handle that to avoid leaking ioend structures due to
incorrect detection of EOF updates due to ovreflows...

> 9d10e7b xfs: Don't use unwritten extents for DAX

Exposed a behaviour in DIO and DAX that results in s64 variable
overflow when writing to the block at file offset (2^63 - 1FSB).
Both the DAX and DIO code ask for a mapping at:

xfs_get_blocks_alloc: [...] offset 0x7000 count 4096

which gives a size of 0x8000 (larger than
sb->s_maxbytes!) and results a sign overflow checking if a inode
size update is requireed.  Direct IO avoids this overflow because
the logic checks for unwritten extents first and the IO completion
callback that has the correct size. Removing unwritten extent
allocation from DAX exposed this bug through firing asserts all
through the XFS block mapping and IO completion callbacks

Fixed the overflow, testing got further and then fsx exposed another
problem similar to the size update issue above. Patch is
fundamentally broken: block zeroing needs to be driven all the way
into the low level allocator implementation to fix the problems fsx
exposed.

> eaef807 xfs: factor out sector mapping.

Probably not going to be used now.

So, basically, I've rewritten most of the patch set once, and I'm
about to fundamentally change it again to address problems the first
two versions have exposed.  Hopefully this will show you the
complexity of what we are dealing with here, and why I said this
needs to go through 4.4?

It should also help explain why I suggested that if ext4 developers
aren't interested in fixing DAX problems then we should just drop
ext4 DAX support? Making this stuff work correctly requires more
than just a cursory knowledge of a filesystem, and nobody actively
working on DAX has the qualifications to make these sorts of changes
to ext4...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
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] perf top: Fix unresolved comm when -s comm is used

[Namhyung Kim]

The perf top uses 'dso,symbol' sort keys by default so it overlooked a
problem in task's comm resolving.  When the sort key contains 'comm',
some task's comm is not shown properly.  This is because the
perf_top__mmap_read_idx() checks the cpumode value improperly.

The cpumode value of non-sample events are 0 (PERF_RECORD_MISC_CPUMODE_
UNKNOWN) so the events will be ignored by the switch statement.  This patch
allows it for non-sample events.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-top.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 38d4d6cac823..ae4c6420300b 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -857,9 +857,12 @@ static void perf_top__mmap_read_idx(struct perf_top *top, 
int idx)
 * TODO: we don't process guest user from host side
 * except simple counting.
 */
-   /* Fall thru */
-   default:
goto next_event;
+   default:
+   if (event->header.type == PERF_RECORD_SAMPLE)
+   goto next_event;
+   machine = >machines.host;
+   break;
}
 
 
-- 
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 -mm 1/3] mm/oom_kill: remove the wrong fatal_signal_pending()

[Tetsuo Handa]

David Rientjes wrote:
> On Tue, 29 Sep 2015, Oleg Nesterov wrote:
> 
> > The fatal_signal_pending() was added to suppress unnecessary "sharing
> > same memory" message, but it can't 100% help anyway because it can be
> > false-negative; SIGKILL can be already dequeued.
> > 
> > And worse, it can be false-positive due to exec or coredump. exec is
> > mostly fine, but coredump is not. It is possible that the group leader
> > has the pending SIGKILL because its sub-thread originated the coredump,
> > in this case we must not skip this process.
> > 
> > We could probably add the additional ->group_exit_task check but this
> > pach just removes fatal_signal_pending(), the extra "Kill process" is
> > unlikely and doesn't really hurt.

This fatal_signal_pending() check is about to be added by me because the OOM
killer spams the kernel log when the mm struct which the OOM victim is using
is shared by many threads. ( http://marc.info/?l=linux-mm=143256441501204 )

> > 
> > Signed-off-by: Oleg Nesterov 
> 
> Acked-by: David Rientjes 
> 
> In addition, I'm really debating whether we need the "sharing same memory" 
> line or not.  In the past, it has been helpful because there is no other 
> way to determine what the kernel has killed other than to leave an 
> artifact behind in the kernel log.  I can imagine that this could easily 
> spam the kernel log, though, accompanied by oom killer messages that are 
> already very verbose.  I wouldn't mind if it the printk were removed 
> entirely.
> 

I was waiting for your comment about whether you depend on
the "sharing same memory" message with KERN_ERR level.
( http://marc.info/?l=linux-mm=144120389203133 )

If nobody else objects, I think we can remove the "sharing same memory"
message. ( http://marc.info/?l=linux-mm=144119325831959 )
--
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/2] x86, efi: Add "efi_fake_mem" boot option

[kbuild test robot]

Hi Taku,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: i386-allmodconfig (attached as .config)
reproduce:
  git checkout afcc94d3f91a00ce97d735a563a8e5d595f45a03
  # save the attached .config to linux build tree
  make ARCH=i386 

All error/warnings (new ones prefixed by >>):

>> drivers/firmware/efi/fake_mem.c:36:25: error: 'CONFIG_EFI_MAX_FAKEMEM' 
>> undeclared here (not in a function)
#define EFI_MAX_FAKEMEM CONFIG_EFI_MAX_FAKEMEM
^
>> drivers/firmware/efi/fake_mem.c:42:34: note: in expansion of macro 
>> 'EFI_MAX_FAKEMEM'
static struct fake_mem fake_mems[EFI_MAX_FAKEMEM];
 ^
   drivers/firmware/efi/fake_mem.c: In function 'efi_fake_memmap':
>> drivers/firmware/efi/fake_mem.c:186:20: warning: cast to pointer from 
>> integer of different size [-Wint-to-pointer-cast]
 memmap.phys_map = (void *)new_memmap_phy;
   ^
   drivers/firmware/efi/fake_mem.c: At top level:
>> drivers/firmware/efi/fake_mem.c:42:24: warning: 'fake_mems' defined but not 
>> used [-Wunused-variable]
static struct fake_mem fake_mems[EFI_MAX_FAKEMEM];
   ^

vim +/CONFIG_EFI_MAX_FAKEMEM +36 drivers/firmware/efi/fake_mem.c

30  #include 
31  #include 
32  #include 
33  #include 
34  #include 
35  
  > 36  #define EFI_MAX_FAKEMEM CONFIG_EFI_MAX_FAKEMEM
37  
38  struct fake_mem {
39  struct range range;
40  u64 attribute;
41  };
  > 42  static struct fake_mem fake_mems[EFI_MAX_FAKEMEM];
43  static int nr_fake_mem;
44  
45  static int __init cmp_fake_mem(const void *x1, const void *x2)
46  {
47  const struct fake_mem *m1 = x1;
48  const struct fake_mem *m2 = x2;
49  
50  if (m1->range.start < m2->range.start)
51  return -1;
52  if (m1->range.start > m2->range.start)
53  return 1;
54  return 0;
55  }
56  
57  void __init efi_fake_memmap(void)
58  {
59  u64 start, end, m_start, m_end, m_attr;
60  int new_nr_map = memmap.nr_map;
61  efi_memory_desc_t *md;
62  u64 new_memmap_phy;
63  void *new_memmap;
64  void *old, *new;
65  int i;
66  
67  if (!nr_fake_mem || !efi_enabled(EFI_MEMMAP))
68  return;
69  
70  /* count up the number of EFI memory descriptor */
71  for (old = memmap.map; old < memmap.map_end; old += 
memmap.desc_size) {
72  md = old;
73  start = md->phys_addr;
74  end = start + (md->num_pages << EFI_PAGE_SHIFT) - 1;
75  
76  for (i = 0; i < nr_fake_mem; i++) {
77  /* modifying range */
78  m_start = fake_mems[i].range.start;
79  m_end = fake_mems[i].range.end;
80  
81  if (m_start <= start) {
82  /* split into 2 parts */
83  if (start < m_end && m_end < end)
84  new_nr_map++;
85  }
86  if (start < m_start && m_start < end) {
87  /* split into 3 parts */
88  if (m_end < end)
89  new_nr_map += 2;
90  /* split into 2 parts */
91  if (end <= m_end)
92  new_nr_map++;
93  }
94  }
95  }
96  
97  /* allocate memory for new EFI memmap */
98  new_memmap_phy = memblock_alloc(memmap.desc_size * new_nr_map,
99  PAGE_SIZE);
   100  if (!new_memmap_phy)
   101  return;
   102  
   103  /* create new EFI memmap */
   104  new_memmap = early_memremap(new_memmap_phy,
   105  memmap.desc_size * new_nr_map);
   106  if (!new_memmap) {
   107  memblock_free(new_memmap_phy, memmap.desc_size * 
new_nr_map);
   108  return;
   109  }
   110  
   111  for (old = memmap.map, new = new_memmap;
   112   old < memmap.map_end;
   113   old += memmap.desc_size, new += memmap.desc_size) {
   114  
   115  /* copy original EFI memory descriptor */
   116  memcpy(new, old, memmap.desc_size);
   117  md = new;
   118  start = md->phys_addr;
   119  end = md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) 
- 

linux-next: manual merge of the sound tree with the drm-intel tree

[Stephen Rothwell]

Hi Takashi,

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

  drivers/gpu/drm/i915/intel_audio.c

between commit:

  3c85f5027595 ("drm/i915: s/mode/adjusted_mode/ in functions that really get 
passed the adjusted_mode")

from the drm-intel tree and commit:

  7e8275c2f2bb ("drm/i915: set proper N/CTS in modeset")

from the sound tree.

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

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

diff --cc drivers/gpu/drm/i915/intel_audio.c
index b08b4a7fae49,bf2642eb4ee7..
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@@ -68,8 -68,33 +68,33 @@@ static const struct 
{ 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
  };
  
+ /* HDMI N/CTS table */
+ #define TMDS_297M 297000
+ #define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
+ static const struct {
+   int sample_rate;
+   int clock;
+   int n;
+   int cts;
+ } aud_ncts[] = {
+   { 44100, TMDS_296M, 4459, 234375 },
+   { 44100, TMDS_297M, 4704, 247500 },
+   { 48000, TMDS_296M, 5824, 281250 },
+   { 48000, TMDS_297M, 5120, 247500 },
+   { 32000, TMDS_296M, 5824, 421875 },
+   { 32000, TMDS_297M, 3072, 222750 },
+   { 88200, TMDS_296M, 8918, 234375 },
+   { 88200, TMDS_297M, 9408, 247500 },
+   { 96000, TMDS_296M, 11648, 281250 },
+   { 96000, TMDS_297M, 10240, 247500 },
+   { 176400, TMDS_296M, 17836, 234375 },
+   { 176400, TMDS_297M, 18816, 247500 },
+   { 192000, TMDS_296M, 23296, 281250 },
+   { 192000, TMDS_297M, 20480, 247500 },
+ };
+ 
  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
 -static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
 +static u32 audio_config_hdmi_pixel_clock(const struct drm_display_mode 
*adjusted_mode)
  {
int i;
  
@@@ -252,8 -325,28 +326,28 @@@ static void hsw_audio_codec_enable(stru
if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
else
 -  tmp |= audio_config_hdmi_pixel_clock(mode);
 +  tmp |= audio_config_hdmi_pixel_clock(adjusted_mode);
+ 
+   tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
 -  if (audio_rate_need_prog(intel_crtc, mode)) {
++  if (audio_rate_need_prog(intel_crtc, adjusted_mode)) {
+   if (!acomp)
+   rate = 0;
+   else if (port >= PORT_A && port <= PORT_E)
+   rate = acomp->aud_sample_rate[port];
+   else {
+   DRM_ERROR("invalid port: %d\n", port);
+   rate = 0;
+   }
 -  n = audio_config_get_n(mode, rate);
++  n = audio_config_get_n(adjusted_mode, rate);
+   if (n != 0)
+   tmp = audio_config_setup_n_reg(n, tmp);
+   else
+   DRM_DEBUG_KMS("no suitable N value is found\n");
+   }
+ 
I915_WRITE(HSW_AUD_CFG(pipe), tmp);
+ 
+   mutex_unlock(_priv->av_mutex);
  }
  
  static void ilk_audio_codec_disable(struct intel_encoder *encoder)
--
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] iio:light: Add Dyna-Image AP3223 ambient light and proximity driver

[Suresh Rajashekara]

Minimal implementation with support for raw light and proximity reading.

This is based on the driver provided by the vendor
(which was an input driver). Authors of the
driver from the vendor included
* John Huang 
* Templeton Tsai 
* Vic Lee 

v3
* Resubmitting due to typo in accompanying patch

v2
* Using regmap framework
* Error handling
* Code cleanups following comments

Signed-off-by: Suresh Rajashekara 
---
 drivers/iio/light/Kconfig  |  11 +
 drivers/iio/light/Makefile |   1 +
 drivers/iio/light/ap3223.c | 706 +
 3 files changed, 718 insertions(+)
 create mode 100644 drivers/iio/light/ap3223.c

diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index ae68c64..5c93ef0 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -27,6 +27,17 @@ config AL3320A
 To compile this driver as a module, choose M here: the
 module will be called al3320a.
 
+config AP3223
+   tristate "AP3223 ambient light and proximity sensor"
+   depends on I2C
+   select REGMAP_I2C
+   help
+Say Y here if you want to build a driver for the Dyna Image AP3223
+ambient light and proximity sensor.
+
+To compile this driver as a module, choose M here: the
+module will be called ap3223.
+
 config APDS9300
tristate "APDS9300 ambient light sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index b12a516..13a74f9 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -5,6 +5,7 @@
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_ADJD_S311)+= adjd_s311.o
 obj-$(CONFIG_AL3320A)  += al3320a.o
+obj-$(CONFIG_AP3223)   += ap3223.o
 obj-$(CONFIG_APDS9300) += apds9300.o
 obj-$(CONFIG_CM32181)  += cm32181.o
 obj-$(CONFIG_CM3232)   += cm3232.o
diff --git a/drivers/iio/light/ap3223.c b/drivers/iio/light/ap3223.c
new file mode 100644
index 000..6b457c1
--- /dev/null
+++ b/drivers/iio/light/ap3223.c
@@ -0,0 +1,706 @@
+/*
+ * Copyright (C) 2015 Google, Inc.
+ *
+ * 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.
+ *
+ * Note about the original authors:
+ *
+ * The driver for AP3223 was originally distributed by dyna image in a
+ * different framework (as an input driver). This driver uses code from
+ * that driver and converts it to iio framework. The non-iio driver from
+ * dyna image is not available online anywhere, so there is no reference
+ * for it here. However, that driver is also GPLv2.
+ * The following is part of the header found in that file
+ * (The GPL notice from the original header is removed)
+ *
+ * >> This file is part of the AP3223, AP3212C and AP3216C sensor driver.
+ * >> AP3426 is combined proximity and ambient light sensor.
+ * >> AP3216C is combined proximity, ambient light sensor and IRLED.
+ * >>
+ * >> Contact: John Huang 
+ * >> Templeton Tsai 
+ *
+ * Another author initials mentioned in that file was just YC (and no name).
+ *
+ * Not sure for what kernel version the driver from dyna image was written for.
+ * Vic Lee  made modifications to it to run on 3.14.
+ *
+ * Datasheet:
+ * 
http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2=8#doc
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AP3223_DRV_NAME "ap3223"
+
+/* ap3223 control registers */
+
+#defineAP3223_REG_SYS_CTRL 0x00
+#define AP3223_REG_SYS_CTRL_SHIFT  (0)
+#define AP3223_REG_SYS_CTRL_MASK   0x07
+
+/* System Mode (AP3223_REG_SYS_CTRL) */
+
+#define AP3223_SYS_DEV_DOWN0x00
+#define AP3223_SYS_ALS_ENABLE  0x01
+#define AP3223_SYS_PS_ENABLE   0x02
+#define AP3223_SYS_ALS_PS_ENABLE   0x03
+#define AP3223_SYS_DEV_RESET   0x04
+
+#define AP3223_REG_SYS_INTSTATUS   0x01
+#define AP3223_REG_SYS_INT_SHIFT   (0)
+#define AP3223_REG_SYS_INT_ALS_SHIFT   (0)
+#define AP3223_REG_SYS_INT_PS_SHIFT(1)
+#define AP3223_REG_SYS_INT_OBJ_SHIFT   (4)
+#define AP3223_REG_SYS_INT_IR_OV_SHIFT (5)
+
+/* INT FLAG BIT MASK */
+
+#define AP3223_REG_SYS_INT_MASK0x03
+#define AP3223_REG_SYS_INT_AMASK   0x01
+#define AP3223_REG_SYS_INT_PMASK   0x02
+#define AP3223_REG_SYS_INT_OBJ_MASK0x10
+#define AP3223_REG_SYS_INT_IR_OV_MASK  0x20
+
+#define AP3223_REG_SYS_INTCTRL 0x02
+
+/* INT Clear Manner */
+
+#defineAP3223_SYS_INT_CLEAR_AUTO   

[PATCH v3 2/2] iio:light:ap3223: Add DT support

[Suresh Rajashekara]

* Add Device Tree support for the Dyna Image AP3223 ambient light sensor and
* proximity driver,
* Document the binding and
* Add a vendor prefix for Dyna Image

v3
* Fixing typo in comment
v2
* Seperating the device tree changes from code

Signed-off-by: Suresh Rajashekara 
---
 Documentation/devicetree/bindings/iio/light/ap3223.txt | 18 ++
 Documentation/devicetree/bindings/vendor-prefixes.txt  |  1 +
 2 files changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/ap3223.txt

diff --git a/Documentation/devicetree/bindings/iio/light/ap3223.txt 
b/Documentation/devicetree/bindings/iio/light/ap3223.txt
new file mode 100644
index 000..b255d27
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/ap3223.txt
@@ -0,0 +1,18 @@
+* Dyna Image AP3223 ambient light sensor and proximity sensor
+
+http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2=8
+
+Required properties:
+
+  - compatible : should be "dynaimage,ap3223"
+  - reg : the I2C address of the sensor
+
+Example:
+
+ap3223@1c {
+   compatible = "dynaimage,ap3223";
+   reg = <0x1c>;
+
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 5f20add..704da45 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -46,6 +46,7 @@ digilent  Diglent, Inc.
 dlgDialog Semiconductor
 dlink  D-Link Corporation
 dmoData Modul AG
+dynaimage  Dyna-Image
 ebvEBV Elektronik
 edtEmerging Display Technologies
 elan   Elan Microelectronic Corp.
-- 
2.6.0.rc2.230.g3dd15c0

--
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: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/intel_lrc.c

between commit:

  dfc53c5e73f8 ("drm/i915: Consider HW CSB write pointer before resetting the 
sw read pointer")

from the drm-intel-fixes tree and commit:

  83843d84fcd3 ("drm/i915: Parametrize LRC registers")

from the drm-intel tree.

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

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

diff --cc drivers/gpu/drm/i915/intel_lrc.c
index 7412caedcf7f,256167b2e2ab..
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@@ -492,10 -519,8 +519,8 @@@ void intel_lrc_irq_handler(struct intel
  
while (read_pointer < write_pointer) {
read_pointer++;
-   status = I915_READ(RING_CONTEXT_STATUS_BUF(ring) +
-   (read_pointer % GEN8_CSB_ENTRIES) * 8);
-   status_id = I915_READ(RING_CONTEXT_STATUS_BUF(ring) +
-   (read_pointer % GEN8_CSB_ENTRIES) * 8 + 4);
 -  status = I915_READ(RING_CONTEXT_STATUS_BUF_LO(ring, 
read_pointer % 6));
 -  status_id = I915_READ(RING_CONTEXT_STATUS_BUF_HI(ring, 
read_pointer % 6));
++  status = I915_READ(RING_CONTEXT_STATUS_BUF_LO(ring, 
read_pointer % GEN8_CSB_ENTRIES));
++  status_id = I915_READ(RING_CONTEXT_STATUS_BUF_HI(ring, 
read_pointer % GEN8_CSB_ENTRIES));
  
if (status & GEN8_CTX_STATUS_IDLE_ACTIVE)
continue;
@@@ -1424,8 -1477,10 +1479,11 @@@ static int gen8_init_common_ring(struc
  {
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
 +  u8 next_context_status_buffer_hw;
  
+   lrc_setup_hardware_status_page(ring,
+   ring->default_context->engine[ring->id].state);
+ 
I915_WRITE_IMR(ring, ~(ring->irq_enable_mask | ring->irq_keep_mask));
I915_WRITE(RING_HWSTAM(ring->mmio_base), 0x);
  
--
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] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

[H. Peter Anvin]

On 09/29/2015 06:20 PM, Eric W. Biederman wrote:
> Linus Torvalds  writes:
> 
>> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski  wrote:
>>>
>>> Does anyone know what happens if you stick a non-accessed segment in
>>> the GDT, map the GDT RO, and access it?
>>
>> You should get a #PF, as you guess, but go ahead and test it if you
>> want to make sure.
> 
> I tested this by accident once when workinng on what has become known
> as coreboot.  Early in boot with your GDT in a EEPROM switching from
> real mode to 32bit protected mode causes a write and locks up the
> machine when the hardware declines the write to the GDT to set the
> accessed bit.  As I recall the write kept being retried and retried and
> retried...
> 
> Setting the access bit in the GDT cleared up the problem and I did not
> look back.
> 
> Way up in 64bit mode something might be different, but I don't know why
> cpu designeres would waste the silicon.
> 

This is totally different from a TLB violation.  In your case, the write
goes through as far as the CPU is concerned, but when the data is
fetched back, it hasn't changed.  A write to a TLB-protected location
will #PF.

-hpa


--
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] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

[Eric W. Biederman]

Linus Torvalds  writes:

> On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski  wrote:
>>
>> Does anyone know what happens if you stick a non-accessed segment in
>> the GDT, map the GDT RO, and access it?
>
> You should get a #PF, as you guess, but go ahead and test it if you
> want to make sure.

I tested this by accident once when workinng on what has become known
as coreboot.  Early in boot with your GDT in a EEPROM switching from
real mode to 32bit protected mode causes a write and locks up the
machine when the hardware declines the write to the GDT to set the
accessed bit.  As I recall the write kept being retried and retried and
retried...

Setting the access bit in the GDT cleared up the problem and I did not
look back.

Way up in 64bit mode something might be different, but I don't know why
cpu designeres would waste the silicon.

Eric
--
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 v6 1/2] PM / sleep: Go direct_complete if driver has no callbacks

[Rafael J. Wysocki]

On Tuesday, September 29, 2015 05:32:53 PM Tomeu Vizoso wrote:
> If a suitable prepare callback cannot be found for a given device and
> its driver has no PM callbacks at all, assume that it can go direct to
> complete when the system goes to sleep.
> 
> The reason for this is that there's lots of devices in a system that do
> no PM at all and there's no reason for them to prevent their ancestors
> to do direct_complete if they can support it.
> 
> Signed-off-by: Tomeu Vizoso 
> ---
> 
> Changes in v6:
> - Add stub for !CONFIG_PM.
> - Move implementation of device_check_pm_callbacks to power/main.c as it
>   doesn't belong to CONFIG_PM_SLEEP.
> - Take dev->power.lock before modifying flag.
> 
> Changes in v5:
> - Check for all dev_pm_ops instances associated to a device, updating a
>   no_pm_callbacks flag at the times when that could change.
> 
>  drivers/base/dd.c   |  3 +++
>  drivers/base/power/common.c | 27 +++
>  drivers/base/power/domain.c |  5 +
>  drivers/base/power/main.c   | 44 +---
>  drivers/base/power/power.h  |  6 ++
>  include/linux/pm.h  |  1 +
>  6 files changed, 67 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index be0eb4639128..fe0e9cb684b8 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -205,6 +205,8 @@ static void driver_bound(struct device *dev)
>  
>   klist_add_tail(>p->knode_driver, >driver->p->klist_devices);
>  
> + device_check_pm_callbacks(dev);
> +
>   /*
>* Make sure the device is no longer in one of the deferred lists and
>* kick off retrying all pending devices
> @@ -695,6 +697,7 @@ static void __device_release_driver(struct device *dev)
>   dev->pm_domain->dismiss(dev);
>  
>   klist_remove(>p->knode_driver);
> + device_check_pm_callbacks(dev);
>   if (dev->bus)
>   blocking_notifier_call_chain(>bus->p->bus_notifier,
>BUS_NOTIFY_UNBOUND_DRIVER,
> diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
> index f32b802b98f4..1bba85f8bf8a 100644
> --- a/drivers/base/power/common.c
> +++ b/drivers/base/power/common.c
> @@ -128,3 +128,30 @@ void dev_pm_domain_detach(struct device *dev, bool 
> power_off)
>   dev->pm_domain->detach(dev, power_off);
>  }
>  EXPORT_SYMBOL_GPL(dev_pm_domain_detach);
> +
> +static bool pm_ops_is_empty(const struct dev_pm_ops *ops)
> +{
> + if (!ops)
> + return true;
> +
> + return !ops->prepare &&
> +!ops->suspend &&
> +!ops->suspend_late &&
> +!ops->suspend_noirq &&
> +!ops->resume_noirq &&
> +!ops->resume_early &&
> +!ops->resume &&
> +!ops->complete;
> +}
> +
> +void device_check_pm_callbacks(struct device *dev)
> +{
> + spin_lock_irq(>power.lock);
> + dev->power.no_pm_callbacks =
> + (!dev->bus || pm_ops_is_empty(dev->bus->pm)) &&
> + (!dev->class || pm_ops_is_empty(dev->class->pm)) &&
> + (!dev->type || pm_ops_is_empty(dev->type->pm)) &&
> + (!dev->pm_domain || pm_ops_is_empty(>pm_domain->ops)) &&
> + (!dev->driver || pm_ops_is_empty(dev->driver->pm));
> + spin_unlock_irq(>power.lock);
> +}
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 16550c63d611..3cae1aa1885b 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -20,6 +20,8 @@
>  #include 
>  #include 
>  
> +#include "power.h"
> +
>  #define GENPD_RETRY_MAX_MS   250 /* Approximate */
>  
>  #define GENPD_DEV_CALLBACK(genpd, type, callback, dev)   \
> @@ -1305,6 +1307,7 @@ int __pm_genpd_add_device(struct generic_pm_domain 
> *genpd, struct device *dev,
>  
>   list_add_tail(_data->base.list_node, >dev_list);
>  
> + device_check_pm_callbacks(dev);
>   out:
>   mutex_unlock(>lock);
>  
> @@ -1369,6 +1372,8 @@ int pm_genpd_remove_device(struct generic_pm_domain 
> *genpd,
>  
>   genpd_free_dev_data(dev, gpd_data);
>  
> + device_check_pm_callbacks(dev);
> +
>   return 0;
>  
>   out:
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 1710c26ba097..8f9cdaf21ee4 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -131,6 +131,8 @@ void device_pm_add(struct device *dev)
>   dev_name(dev->parent));
>   list_add_tail(>power.entry, _list);
>   mutex_unlock(_list_mtx);
> +
> + device_check_pm_callbacks(dev);
>  }
>  
>  /**
> @@ -1569,27 +1571,31 @@ static int device_prepare(struct device *dev, 
> pm_message_t state)
>  
>   dev->power.wakeup_path = device_may_wakeup(dev);
>  
> - if (dev->pm_domain) {
> - info = "preparing power domain ";
> - callback = 

Re: [PATCH] zram: keep the exact overcommited value in mem_used_max

[Minchan Kim]

On Thu, Sep 24, 2015 at 06:51:52PM +0900, Sergey Senozhatsky wrote:
> From: Sergey SENOZHATSKY 
> 
> `mem_used_max' is designed to store the max amount of memory zram
> consumed to store the data. However, it does not represent the actual
> 'overcommited' (max) value. The existing code goes to -ENOMEM
> overcommited case before it updates `->stats.max_used_pages', which
> hides the reason we went to -ENOMEM in the first place -- we actually
> used more memory than `->limit_pages':
> 
> alloced_pages = zs_get_total_pages(meta->mem_pool);
> if (zram->limit_pages && alloced_pages > zram->limit_pages) {
> zs_free(meta->mem_pool, handle);
> ret = -ENOMEM;
> goto out;
> }
> 
> update_used_max(zram, alloced_pages);
> 
> Which is misleading. User will see -ENOMEM, check `->limit_pages',
> check `->stats.max_used_pages', which will keep the value BEFORE zram
> passed `->limit_pages', and see:
>   `->stats.max_used_pages' < `->limit_pages'
> 
> Move update_used_max() before we do `->limit_pages' check, so that
> user will see:
>   `->stats.max_used_pages' > `->limit_pages'
> should the overcommit and -ENOMEM happen.
> 
> Signed-off-by: Sergey Senozhatsky 

It was intent.

IOW, I want that max_mem_used is never higher than mem_limit but
I realized you are right because user doesn't have way to detect
where -ENOMEM is coming from.
For example, it could come from mem_limit or real memory alloc fail.

Thanks, Sergey.

Acked-by: Minchan Kim 
--
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 2/2] iio:light:tsl2563: Add DT support

[Suresh Rajashekara]

* Add Device Tree support for the Dyna Image AP3223 ambient light sensor and
* proximity driver,
* Document the binding and
* Add a vendor prefix for Dyna Image

v2
* Seperating the device tree changes from code

Signed-off-by: Suresh Rajashekara 
---
 Documentation/devicetree/bindings/iio/light/ap3223.txt | 18 ++
 Documentation/devicetree/bindings/vendor-prefixes.txt  |  1 +
 2 files changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/ap3223.txt

diff --git a/Documentation/devicetree/bindings/iio/light/ap3223.txt 
b/Documentation/devicetree/bindings/iio/light/ap3223.txt
new file mode 100644
index 000..b255d27
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/ap3223.txt
@@ -0,0 +1,18 @@
+* Dyna Image AP3223 ambient light sensor and proximity sensor
+
+http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2=8
+
+Required properties:
+
+  - compatible : should be "dynaimage,ap3223"
+  - reg : the I2C address of the sensor
+
+Example:
+
+ap3223@1c {
+   compatible = "dynaimage,ap3223";
+   reg = <0x1c>;
+
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 5f20add..704da45 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -46,6 +46,7 @@ digilent  Diglent, Inc.
 dlgDialog Semiconductor
 dlink  D-Link Corporation
 dmoData Modul AG
+dynaimage  Dyna-Image
 ebvEBV Elektronik
 edtEmerging Display Technologies
 elan   Elan Microelectronic Corp.
-- 
2.6.0.rc2.230.g3dd15c0

--
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/2] iio:light: Add Dyna-Image AP3223 ambient light and proximity driver

[Suresh Rajashekara]

Minimal implementation with support for raw light and proximity reading.

This is based on the driver provided by the vendor
(which was an input driver). Authors of the
driver from the vendor included
* John Huang 
* Templeton Tsai 
* Vic Lee 

v2
* Using regmap framework
* Error handling
* Code cleanups following comments

Signed-off-by: Suresh Rajashekara 
---
 drivers/iio/light/Kconfig  |  11 +
 drivers/iio/light/Makefile |   1 +
 drivers/iio/light/ap3223.c | 706 +
 3 files changed, 718 insertions(+)
 create mode 100644 drivers/iio/light/ap3223.c

diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index ae68c64..5c93ef0 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -27,6 +27,17 @@ config AL3320A
 To compile this driver as a module, choose M here: the
 module will be called al3320a.
 
+config AP3223
+   tristate "AP3223 ambient light and proximity sensor"
+   depends on I2C
+   select REGMAP_I2C
+   help
+Say Y here if you want to build a driver for the Dyna Image AP3223
+ambient light and proximity sensor.
+
+To compile this driver as a module, choose M here: the
+module will be called ap3223.
+
 config APDS9300
tristate "APDS9300 ambient light sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index b12a516..13a74f9 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -5,6 +5,7 @@
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_ADJD_S311)+= adjd_s311.o
 obj-$(CONFIG_AL3320A)  += al3320a.o
+obj-$(CONFIG_AP3223)   += ap3223.o
 obj-$(CONFIG_APDS9300) += apds9300.o
 obj-$(CONFIG_CM32181)  += cm32181.o
 obj-$(CONFIG_CM3232)   += cm3232.o
diff --git a/drivers/iio/light/ap3223.c b/drivers/iio/light/ap3223.c
new file mode 100644
index 000..6b457c1
--- /dev/null
+++ b/drivers/iio/light/ap3223.c
@@ -0,0 +1,706 @@
+/*
+ * Copyright (C) 2015 Google, Inc.
+ *
+ * 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.
+ *
+ * Note about the original authors:
+ *
+ * The driver for AP3223 was originally distributed by dyna image in a
+ * different framework (as an input driver). This driver uses code from
+ * that driver and converts it to iio framework. The non-iio driver from
+ * dyna image is not available online anywhere, so there is no reference
+ * for it here. However, that driver is also GPLv2.
+ * The following is part of the header found in that file
+ * (The GPL notice from the original header is removed)
+ *
+ * >> This file is part of the AP3223, AP3212C and AP3216C sensor driver.
+ * >> AP3426 is combined proximity and ambient light sensor.
+ * >> AP3216C is combined proximity, ambient light sensor and IRLED.
+ * >>
+ * >> Contact: John Huang 
+ * >> Templeton Tsai 
+ *
+ * Another author initials mentioned in that file was just YC (and no name).
+ *
+ * Not sure for what kernel version the driver from dyna image was written for.
+ * Vic Lee  made modifications to it to run on 3.14.
+ *
+ * Datasheet:
+ * 
http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2=8#doc
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AP3223_DRV_NAME "ap3223"
+
+/* ap3223 control registers */
+
+#defineAP3223_REG_SYS_CTRL 0x00
+#define AP3223_REG_SYS_CTRL_SHIFT  (0)
+#define AP3223_REG_SYS_CTRL_MASK   0x07
+
+/* System Mode (AP3223_REG_SYS_CTRL) */
+
+#define AP3223_SYS_DEV_DOWN0x00
+#define AP3223_SYS_ALS_ENABLE  0x01
+#define AP3223_SYS_PS_ENABLE   0x02
+#define AP3223_SYS_ALS_PS_ENABLE   0x03
+#define AP3223_SYS_DEV_RESET   0x04
+
+#define AP3223_REG_SYS_INTSTATUS   0x01
+#define AP3223_REG_SYS_INT_SHIFT   (0)
+#define AP3223_REG_SYS_INT_ALS_SHIFT   (0)
+#define AP3223_REG_SYS_INT_PS_SHIFT(1)
+#define AP3223_REG_SYS_INT_OBJ_SHIFT   (4)
+#define AP3223_REG_SYS_INT_IR_OV_SHIFT (5)
+
+/* INT FLAG BIT MASK */
+
+#define AP3223_REG_SYS_INT_MASK0x03
+#define AP3223_REG_SYS_INT_AMASK   0x01
+#define AP3223_REG_SYS_INT_PMASK   0x02
+#define AP3223_REG_SYS_INT_OBJ_MASK0x10
+#define AP3223_REG_SYS_INT_IR_OV_MASK  0x20
+
+#define AP3223_REG_SYS_INTCTRL 0x02
+
+/* INT Clear Manner */
+
+#defineAP3223_SYS_INT_CLEAR_AUTO   0x00
+#defineAP3223_SYS_INT_CLEAR_MANUAL 

Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

[H. Peter Anvin]

On 09/29/2015 06:16 PM, Andy Lutomirski wrote:
> 
> Can we at least do 1:1 without an offset on arm64?  Given that Linux
> seems to be more of a reference on arm64 than Windows is, maybe that
> would give everyone something vaguely sane to work with.
> 

I have no idea.  That's a question for the ARM folks.

-hpa


--
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: [PATCHv2] zram: update documentation

[Minchan Kim]

On Thu, Sep 24, 2015 at 06:56:41PM +0900, Sergey Senozhatsky wrote:
> From: Sergey SENOZHATSKY 
> 
> Several documentation changes.
> 
> First, we never mentioned any errors and never required any
> error checks in documentation.
> 
> Second, mention that there is another way to configure and
> manage zram devices -- zramctl, provided by util-linux.
> 
> Third, add a bit of clarification on why `mem_used_max' attr
> is RW and correct some typos.
> 
> Signed-off-by: Sergey Senozhatsky 

Acked-by: Minchan Kim 

Thanks, Sergey!
--
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/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

[Andy Lutomirski]

On Tue, Sep 29, 2015 at 6:03 PM, H. Peter Anvin  wrote:
> On 09/27/2015 12:06 AM, Ingo Molnar wrote:
>>
>> * Ard Biesheuvel  wrote:
>>
 If we allocate the EFI runtime as a single virtual memory block then issues
 like rounding between sections does not even come up as a problem: we map 
 the
 original offsets and sizes byte by byte.
>>>
>>> Well, by that reasoning, we should not call SetVirtualAddressMap() in the 
>>> first
>>> place, and just use the 1:1 mapping UEFI uses natively. This is more than
>>> feasible on arm64, and I actually fought hard against using
>>> SetVirtualAddressMap() at all, but I was overruled by others. I think this 
>>> is
>>> also trivially possible on X64, since the 1:1 mapping is already active
>>> alongside the VA mapping.
>>
>> Could we please re-list all the arguments pro and contra of 1:1 physical 
>> mappings,
>> in a post that also explains the background so that more people can chime 
>> in, not
>> just people versed in EFI internals? It's very much possible that a bad 
>> decision
>> was made.
>>
>
> Pro: by far the sanest way to map the UEFI tables.
> Con: doesn't actually work (breaks on several known platforms.)

Can we at least do 1:1 without an offset on arm64?  Given that Linux
seems to be more of a reference on arm64 than Windows is, maybe that
would give everyone something vaguely sane to work with.

--Andy
--
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] x86, efi: Add "efi_fake_mem" boot option

[Taku Izumi]

This patch introduces new boot option named "efi_fake_mem".
By specifying this parameter, you can add arbitrary attribute
to specific memory range.
This is useful for debugging of Address Range Mirroring feature.

For example, if "efi_fake_mem=2G@4G:0x1,2G@0x10a000:0x1"
is specified, the original (firmware provided) EFI memmap will be
updated so that the specified memory regions have
EFI_MEMORY_MORE_RELIABLE attribute (0x1):

 
   efi: mem36: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] 
range=[0x0001-0x0020a000) (129536MB)

 
   efi: mem36: [Conventional Memory|  |MR|  |  |  |   |WB|WT|WC|UC] 
range=[0x0001-0x00018000) (2048MB)
   efi: mem37: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] 
range=[0x00018000-0x0010a000) (61952MB)
   efi: mem38: [Conventional Memory|  |MR|  |  |  |   |WB|WT|WC|UC] 
range=[0x0010a000-0x00112000) (2048MB)
   efi: mem39: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] 
range=[0x00112000-0x0020a000) (63488MB)

And you will find that the following message is output:

   efi: Memory: 4096M/131455M mirrored memory

Signed-off-by: Taku Izumi 
---
 Documentation/kernel-parameters.txt |  15 +++
 arch/x86/kernel/setup.c |   4 +-
 drivers/firmware/efi/Kconfig|  22 
 drivers/firmware/efi/Makefile   |   1 +
 drivers/firmware/efi/fake_mem.c | 238 
 include/linux/efi.h |   6 +
 6 files changed, 285 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/efi/fake_mem.c

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 22a4b68..50fc09b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1094,6 +1094,21 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
you are really sure that your UEFI does sane gc and
fulfills the spec otherwise your board may brick.
 
+   efi_fake_mem=   nn[KMG]@ss[KMG]:aa[,nn[KMG]@ss[KMG]:aa,..] [EFI; X86]
+   Add arbitrary attribute to specific memory range by
+   updating original EFI memory map.
+   Region of memory which aa attribute is added to is
+   from ss to ss+nn.
+   If efi_fake_mem=2G@4G:0x1,2G@0x10a000:0x1
+   is specified, EFI_MEMORY_MORE_RELIABLE(0x1)
+   attribute is added to range 0x1-0x18000 and
+   0x10a000-0x112000.
+
+   Using this parameter you can do debugging of EFI memmap
+   related feature. For example, you can do debugging of
+   Address Range Mirroring feature even if your box
+   doesn't support it.
+
eisa_irq_edge=  [PARISC,HW]
See header of drivers/parisc/eisa.c.
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index fdb7f2a..30b4c44 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1079,8 +1079,10 @@ void __init setup_arch(char **cmdline_p)
memblock_set_current_limit(ISA_END_ADDRESS);
memblock_x86_fill();
 
-   if (efi_enabled(EFI_BOOT))
+   if (efi_enabled(EFI_BOOT)) {
+   efi_fake_memmap();
efi_find_mirror();
+   }
 
/*
 * The EFI specification says that boot service code won't be called
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 84533e0..ac47cc4d 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -52,6 +52,28 @@ config EFI_RUNTIME_MAP
 
  See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
 
+config EFI_FAKE_MEMMAP
+   bool "Enable EFI fake memory map"
+   depends on EFI && X86
+   default n
+   help
+ Saying Y here will enable "efi_fake_mem" boot option.
+ By specifying this parameter, you can add arbitrary attribute
+ to specific memory range by updating original (firmware provided)
+ EFI memmap.
+ This is useful for debugging of EFI memmap related feature.
+ e.g. Address Range Mirroring feature.
+
+config EFI_MAX_FAKE_MEM
+   int "maximum allowable number of ranges in efi_fake_mem boot option"
+   depends on EFI && X86 && EFI_FAKE_MEMMAP
+   range 1 128
+   default 8
+   help
+ Maximum allowable number of ranges in efi_fake_mem boot option.
+ Ranges can be set up to this value using comma-separated list.
+ The default value is 8.
+
 config EFI_PARAMS_FROM_FDT
bool
help
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 6fd3da9..c24f005 100644
--- a/drivers/firmware/efi/Makefile
+++ 

[PATCH 0/2] Introduce "efi_fake_mem" boot option

[Taku Izumi]

UEFI spec 2.5 introduces new Memory Attribute Definition named
EFI_MEMORY_MORE_RELIABLE which indicates which memory ranges are
mirrored. Now linux kernel can recognize which memory ranges are mirrored
by handling EFI_MEMORY_MORE_RELIABLE attributes.
However testing this feature necesitates boxes with UEFI spec 2.5 complied
firmware.

This patchset introduces new boot option named "efi_fake_mem".
By specifying this parameter, you can add arbitrary attribute to
specific memory range. This is useful for debugging of Memory 
Address Range Mirroring feature.

This is updated version one of the former patch posted at
 http://www.mail-archive.com/linux-efi@vger.kernel.org/msg05936.html

changelog:
 - change boot option name and spec
   efi_fake_mem_mirror=nn@ss -> efi_fake_mem=nn@ss:aa
 - rename print_efi_memmap() to efi_print_memmap()
 - introduce new config named CONFIG_EFI_MAX_FAKE_MEM
 - and some fix pointed by Matt Flemming

Taku Izumi (2):
  x86, efi: rename print_efi_memmap() to efi_print_memmap()
  x86, efi: Add "efi_fake_mem" boot option

 Documentation/kernel-parameters.txt |  15 +++
 arch/x86/include/asm/efi.h  |   1 +
 arch/x86/kernel/setup.c |   4 +-
 arch/x86/platform/efi/efi.c |   4 +-
 drivers/firmware/efi/Kconfig|  22 
 drivers/firmware/efi/Makefile   |   1 +
 drivers/firmware/efi/fake_mem.c | 238 
 include/linux/efi.h |   6 +
 8 files changed, 288 insertions(+), 3 deletions(-)
 create mode 100644 drivers/firmware/efi/fake_mem.c

-- 
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/2] x86, efi: rename print_efi_memmap() to efi_print_memmap()

[Taku Izumi]

This patch renames print_efi_memmap() to efi_print_memmap() and
make it global function so that we can invoke it outside of
arch/x86/platform/efi/efi.c

Signed-off-by: Taku Izumi 
---
 arch/x86/include/asm/efi.h  | 1 +
 arch/x86/platform/efi/efi.c | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index ab5f1d4..f8b93d6 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -103,6 +103,7 @@ extern void __init efi_set_executable(efi_memory_desc_t 
*md, bool executable);
 extern int __init efi_memblock_x86_reserve_range(void);
 extern pgd_t * __init efi_call_phys_prolog(void);
 extern void __init efi_call_phys_epilog(pgd_t *save_pgd);
+extern void __init efi_print_memmap(void);
 extern void __init efi_unmap_memmap(void);
 extern void __init efi_memory_uc(u64 addr, unsigned long size);
 extern void __init efi_map_region(efi_memory_desc_t *md);
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 1db84c0..1f95caf 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -222,7 +222,7 @@ int __init efi_memblock_x86_reserve_range(void)
return 0;
 }
 
-static void __init print_efi_memmap(void)
+void __init efi_print_memmap(void)
 {
 #ifdef EFI_DEBUG
efi_memory_desc_t *md;
@@ -524,7 +524,7 @@ void __init efi_init(void)
return;
 
if (efi_enabled(EFI_DBG))
-   print_efi_memmap();
+   efi_print_memmap();
 
efi_esrt_init();
 }
-- 
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/

Re: [PATCH RESEND] mach:-s3c64xx:Cause kernel oops with WARN_ON if calls for setting up gpio fail in s3c64xx_i2s_cfg_gpio

[Krzysztof Kozlowski]

On 18.09.2015 09:54, Nicholas Krause wrote:
> This fixes the function s3c64xx_i2c_cfg_gpio

The problem is not described and you did not provide a fix so the
description is highly inaccurate and misleading.

> to cause a kernel oopes

Warn causes oops?

> if the call to either s3c_gpio_cfgpin_range or s3c_gpio_cfgpin fail
> as we cannot continue to run

"cannot continue to run" means BUG_ON?

> on a board using this gpio setup if
> the configuration for the board fails when the gpio configuration
> of the board is being reconfigured in the function in
> s3c64xx_i2s_cfg_gpio.

Please rephrase. You essentially said "Configuration fails when
configuration is being reconfigured". Too many configurations...

Fix the subject as well.

Best regards,
Krzysztof

> 
> Signed-off-by: Nicholas Krause 
> ---
>  arch/arm/mach-s3c64xx/dev-audio.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-s3c64xx/dev-audio.c 
> b/arch/arm/mach-s3c64xx/dev-audio.c
> index ff780a8..5e7538b 100644
> --- a/arch/arm/mach-s3c64xx/dev-audio.c
> +++ b/arch/arm/mach-s3c64xx/dev-audio.c
> @@ -36,10 +36,10 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device 
> *pdev)
>   base = S3C64XX_GPE(0);
>   break;
>   case 2:
> - s3c_gpio_cfgpin(S3C64XX_GPC(4), S3C_GPIO_SFN(5));
> - s3c_gpio_cfgpin(S3C64XX_GPC(5), S3C_GPIO_SFN(5));
> - s3c_gpio_cfgpin(S3C64XX_GPC(7), S3C_GPIO_SFN(5));
> - s3c_gpio_cfgpin_range(S3C64XX_GPH(6), 4, S3C_GPIO_SFN(5));
> + WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(4), S3C_GPIO_SFN(5)));
> + WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(5), S3C_GPIO_SFN(5)));
> + WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(7), S3C_GPIO_SFN(5)));
> + WARN_ON(s3c_gpio_cfgpin_range(S3C64XX_GPH(6), 4, 
> S3C_GPIO_SFN(5));)
>   return 0;
>   default:
>   printk(KERN_DEBUG "Invalid I2S Controller number: %d\n",
> @@ -47,7 +47,7 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device 
> *pdev)
>   return -EINVAL;
>   }
>  
> - s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(3));
> + WARN_ON(s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(3)));
>  
>   return 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: [regression] [git pull] drm for 4.3

[da...@codemonkey.org.uk]

On Thu, Sep 24, 2015 at 04:26:28PM +0300, Jani Nikula wrote:
 > On Thu, 24 Sep 2015, "da...@codemonkey.org.uk"  
 > wrote:
 > > On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
 > >  > Hey,
 > >  > 
 > >  > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
 > >  > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
 > >  > >  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
 > >  > >  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
 > >  > >  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to 
 > > one of
 > >  > >  > > > their recent patches.
 > >  > >  > 
 > >  > >  > Sounds like this showed up before my recent work, but I think I 
 > > might
 > >  > >  > have seen similar problems while working on atomic watermarks; the
 > >  > >  > issues I was seeing were because the initial hardware readout could
 > >  > >  > leave primary->visible set to true even when the CRTC was off.  My
 > >  > >  > series (which is still under development) contains this patch to 
 > > fix
 > >  > >  > that:
 > >  > >  > 
 > >  > >  > http://patchwork.freedesktop.org/patch/59564/
 > >  > >  > 
 > >  > >  > Does applying that help with the problems reported here?
 > >  > > 
 > >  > > No difference at all for me.
 > >  > Looks like a (reopened) dup of 91952?
 > >  > 
 > >  > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
 > >  > visible", and get me the results?
 > >
 > > This doesn't apply on top of Linus' current tree.
 > > If you let me know what it's dependant on, I'll do a build with
 > > those patches tomorrow.
 > 
 > It's now part of the drm-intel-fixes pull request [1], maybe it's
 > easiest to pull that in? Just four commits on top of
 > v4.3-rc2. Alternatively pick it up from our repo [2].

The warning on boot seems to be gone as of rc3, but I can now trigger this 
pretty easily..

WARNING: CPU: 2 PID: 28911 at drivers/gpu/drm/drm_atomic.c:889 
drm_atomic_get_property+0x244/0x2d0()
CPU: 2 PID: 28911 Comm: trinity-c313 Not tainted 4.3.0-rc3-think+ #14
 0379 8801a1377c88 8e35d5ec 
 8801a1377cc0 8e07a862 880500b392b8 880500a13008
 880500b39290 8804fe3806d8 88003fa45668 8801a1377cd0
Call Trace:
 [] dump_stack+0x4e/0x82
 [] warn_slowpath_common+0x82/0xc0
 [] warn_slowpath_null+0x1a/0x20
 [] drm_atomic_get_property+0x244/0x2d0
 [] drm_object_property_get_value+0x6c/0x70
 [] dpms_show+0x2f/0x70
 [] dev_attr_show+0x20/0x50
 [] ? sysfs_file_ops+0x41/0x60
 [] sysfs_kf_seq_show+0xb7/0x110
 [] kernfs_seq_show+0x26/0x30
 [] seq_read+0xe6/0x430
 [] kernfs_fop_read+0x127/0x170
 [] ? mutex_lock_nested+0x26b/0x3f0
 [] __vfs_read+0x28/0xe0
 [] ? mutex_lock_nested+0x287/0x3f0
 [] ? __fdget_pos+0x49/0x50
 [] ? __fdget_pos+0x49/0x50
 [] vfs_read+0x86/0x130
 [] SyS_read+0x49/0xb0
 [] entry_SYSCALL_64_fastpath+0x12/0x6f
---[ end trace e053063c697a1355 ]---

 887 case DRM_MODE_OBJECT_CONNECTOR: {
 888 struct drm_connector *connector = obj_to_connector(obj);
 889 
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 890 ret = drm_atomic_connector_get_property(connector,
 891 connector->state, property, val);
 892 break;
 893 }

--
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/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

[H. Peter Anvin]

On 09/27/2015 12:06 AM, Ingo Molnar wrote:
> 
> * Ard Biesheuvel  wrote:
> 
>>> If we allocate the EFI runtime as a single virtual memory block then issues 
>>> like rounding between sections does not even come up as a problem: we map 
>>> the 
>>> original offsets and sizes byte by byte.
>>
>> Well, by that reasoning, we should not call SetVirtualAddressMap() in the 
>> first 
>> place, and just use the 1:1 mapping UEFI uses natively. This is more than 
>> feasible on arm64, and I actually fought hard against using 
>> SetVirtualAddressMap() at all, but I was overruled by others. I think this 
>> is 
>> also trivially possible on X64, since the 1:1 mapping is already active 
>> alongside the VA mapping.
> 
> Could we please re-list all the arguments pro and contra of 1:1 physical 
> mappings, 
> in a post that also explains the background so that more people can chime in, 
> not 
> just people versed in EFI internals? It's very much possible that a bad 
> decision 
> was made.
> 

Pro: by far the sanest way to map the UEFI tables.
Con: doesn't actually work (breaks on several known platforms.)

-hpa


--
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/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

[H. Peter Anvin]

On 09/29/2015 07:36 AM, Matt Fleming wrote:
>  
> That's a pretty good summary for x86. I think specifically the reason
> we map the EFI memmap entries "backwards" (entry N has higher VA than
> entry N+1) is because the code was easier to write that way, but
> you'll know better than me ;-)
> 

There were two reasons:

1. The code was easier to write.
2. Windows did it that way.

Windows apparently broke and was changed due to this feature, too.

-hpa


--
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] x86/efi: Map EFI memmap entries in-order at runtime

[H. Peter Anvin]

On 09/27/2015 11:16 PM, Ingo Molnar wrote:
> 
> So the question is, what does Windows do?
> 
> PC firmware is a hostile environment for Linux, to be compatible the best we 
> can 
> do is to mimic the environment that the firmware is tested under - i.e. try 
> to use 
> the firmware in the way Windows uses it.
> 

Windows apparently went through the same exercise of breakage followed
by a fix.  It is unknown if Windows will preserve gaps since those are
not manifest on existing firmware.

-hpa


--
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/