[PATCH v2 01/17] crypto: talitos - base address for Execution Units and macro for ISR masks

[Christophe Leroy]

SEC1 and SEC2 have different EU base addresses, so define base addresses
as #define
SEC1 and SEC2 have different bit masks for ISR registers, so create a
macro to define them

Signed-off-by: Christophe Leroy 

---
 drivers/crypto/talitos.h | 85 ++--
 1 file changed, 53 insertions(+), 32 deletions(-)

diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index 61a1405..102dc99 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -149,6 +149,8 @@ extern int talitos_submit(struct device *dev, int ch, 
struct talitos_desc *desc,
  * TALITOS_xxx_LO addresses point to the low data bits (32-63) of the register
  */
 
+#define ISR_FORMAT(x)  (((x) << 4) | (x))
+
 /* global register offset addresses */
 #define TALITOS_MCR0x1030  /* master control register */
 #define   TALITOS_MCR_RCA0 (1 << 15) /* remap channel 0 */
@@ -163,12 +165,12 @@ extern int talitos_submit(struct device *dev, int ch, 
struct talitos_desc *desc,
 #define TALITOS_IMR_LO 0x100C
 #define   TALITOS_IMR_LO_INIT  0x2 /* allow RNGU error IRQs */
 #define TALITOS_ISR0x1010  /* interrupt status register */
-#define   TALITOS_ISR_4CHERR   0xaa/* 4 channel errors mask */
-#define   TALITOS_ISR_4CHDONE  0x55/* 4 channel done mask */
-#define   TALITOS_ISR_CH_0_2_ERR   0x22/* channels 0, 2 errors mask */
-#define   TALITOS_ISR_CH_0_2_DONE  0x11/* channels 0, 2 done mask */
-#define   TALITOS_ISR_CH_1_3_ERR   0x88/* channels 1, 3 errors mask */
-#define   TALITOS_ISR_CH_1_3_DONE  0x44/* channels 1, 3 done mask */
+#define   TALITOS_ISR_4CHERR   ISR_FORMAT(0xa) /* 4 ch errors mask */
+#define   TALITOS_ISR_4CHDONE  ISR_FORMAT(0x5) /* 4 ch done mask */
+#define   TALITOS_ISR_CH_0_2_ERR   ISR_FORMAT(0x2) /* ch 0, 2 err mask */
+#define   TALITOS_ISR_CH_0_2_DONE  ISR_FORMAT(0x1) /* ch 0, 2 done mask */
+#define   TALITOS_ISR_CH_1_3_ERR   ISR_FORMAT(0x8) /* ch 1, 3 err mask */
+#define   TALITOS_ISR_CH_1_3_DONE  ISR_FORMAT(0x4) /* ch 1, 3 done mask */
 #define TALITOS_ISR_LO 0x1014
 #define TALITOS_ICR0x1018  /* interrupt clear register */
 #define TALITOS_ICR_LO 0x101C
@@ -224,37 +226,56 @@ extern int talitos_submit(struct device *dev, int ch, 
struct talitos_desc *desc,
 #define TALITOS_SCATTER0xe0
 #define TALITOS_SCATTER_LO 0xe4
 
+/* execution unit registers base */
+#define TALITOS_DEU0x2000
+#define TALITOS_AESU   0x4000
+#define TALITOS_MDEU   0x6000
+#define TALITOS_AFEU   0x8000
+#define TALITOS_RNGU   0xa000
+#define TALITOS_PKEU   0xc000
+#define TALITOS_KEU0xe000
+#define TALITOS_CRCU   0xf000
+
 /* execution unit interrupt status registers */
-#define TALITOS_DEUISR 0x2030 /* DES unit */
-#define TALITOS_DEUISR_LO  0x2034
-#define TALITOS_AESUISR0x4030 /* AES unit */
-#define TALITOS_AESUISR_LO 0x4034
-#define TALITOS_MDEUISR0x6030 /* message digest unit */
-#define TALITOS_MDEUISR_LO 0x6034
-#define TALITOS_MDEUICR0x6038 /* interrupt control */
-#define TALITOS_MDEUICR_LO 0x603c
+/* DES unit */
+#define TALITOS_DEUISR (TALITOS_DEU + 0x30)
+#define TALITOS_DEUISR_LO  (TALITOS_DEU + 0x34)
+#define TALITOS_DEUICR (TALITOS_DEU + 0x38) /* int. control */
+/* AES unit */
+#define TALITOS_AESUISR(TALITOS_AESU + 0x30)
+#define TALITOS_AESUISR_LO (TALITOS_AESU + 0x34)
+/* message digest unit */
+#define TALITOS_MDEUISR(TALITOS_MDEU + 0x30)
+#define TALITOS_MDEUISR_LO (TALITOS_MDEU + 0x34)
+#define TALITOS_MDEUICR(TALITOS_MDEU + 0x38) /* int. 
control */
+#define TALITOS_MDEUICR_LO (TALITOS_MDEU + 0x3c)
 #define   TALITOS_MDEUICR_LO_ICE   0x4000 /* integrity check IRQ enable */
-#define TALITOS_AFEUISR0x8030 /* arc4 unit */
-#define TALITOS_AFEUISR_LO 0x8034
-#define TALITOS_RNGUISR0xa030 /* random number unit */
-#define TALITOS_RNGUISR_LO 0xa034
-#define TALITOS_RNGUSR 0xa028 /* rng status */
-#define TALITOS_RNGUSR_LO  0xa02c
+/* arc4 unit */
+#define TALITOS_AFEUISR(TALITOS_AFEU + 0x30)
+#define TALITOS_AFEUISR_LO (TALITOS_AFEU + 0x34)
+/* random number unit */
+#define TALITOS_RNGUISR(TALITOS_RNGU + 0x30)
+#define TALITOS_RNGUISR_LO (TALITOS_RNGU + 0x34)
+#define TALITOS_RNGUSR (TALITOS_RNGU + 0x28) /* 

Re: [PATCH v3] pci: spear: Drop __initdata from spear13xx_pcie_driver

[Matwey V. Kornilov]

2015-03-06 17:42 GMT+03:00 Stanimir Varbanov :
> On 02/19/2015 07:41 PM, Matwey V. Kornilov wrote:
>> spear13xx_pcie_driver.driver is allocated in text.init section
>> and then the pointer to it is passed futher. This patch is to avoid
>> crashes like the following, when freed memory is used.
>>
>
> What happened with this patch, could it go as a fix?
>

With this patch the kernel works as expected (without crashes), I
think it could be considered as a fix.



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
--
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] pwm: imx-pwm: add explicit compatible strings and required clock properties

[Matt Porter]

On Fri, Mar 06, 2015 at 09:16:44AM -0600, Rob Herring wrote:
> On Fri, Mar 6, 2015 at 9:09 AM, Matt Porter  wrote:
> > The imx-pwm binding contains language indicating compatible
> > strings to be used that is not valid for all supported parts
> > e.g. Should be "fsl,-pwm". Fix this by enumerating the
> > valid compatible strings that represent the two versions of
> > this peripheral in use.
> >
> > The binding is also missing the clocks/clock-names properties
> > so document these,the two required ipg and per clocks, and add
> > add these properties to the example.
> >
> > Signed-off-by: Matt Porter 
> > ---
> >  Documentation/devicetree/bindings/pwm/imx-pwm.txt | 11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt 
> > b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > index b50d7a6d..30d2b82 100644
> > --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > @@ -1,10 +1,16 @@
> >  Freescale i.MX PWM controller
> >
> >  Required properties:
> > -- compatible: should be "fsl,-pwm"
> > +- compatible :
> > +  - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
> > +  - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
> 
> This should be one of these and a more specific value as the example
> below shows.

Ok, yes, I wasn't sure if that was expected to be explicit in the bindings
or not as others don't seem to represent that properly. What about this?

- compatible: should be "fsl,-pwm" and one of the following
  compatible strings:
"fsl,imx1-pwm" for an iMX1 compatible PWM
"fsl,imx27-pwm" for an iMX27 compatible PWM

> >  - reg: physical base address and length of the controller's registers
> >  - #pwm-cells: should be 2. See pwm.txt in this directory for a description 
> > of
> >the cells format.
> > +- clocks : Clock specifiers for both ipg and per clocks.
> > +- clock-names : Clock names should include both "ipg" and "per"
> > +See the clock consumer binding,
> > +   Documentation/devicetree/bindings/clock/clock-bindings.txt
> >  - interrupts: The interrupt for the pwm controller
> >
> >  Example:
> > @@ -13,5 +19,8 @@ pwm1: pwm@53fb4000 {
> > #pwm-cells = <2>;
> > compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
> > reg = <0x53fb4000 0x4000>;
> > +   clocks = < IMX5_CLK_PWM1_IPG_GATE>,
> > +< IMX5_CLK_PWM1_HF_GATE>;
> > +   clock-names = "ipg", "per";
> > interrupts = <61>;
> >  };
> > --
> > 1.8.4
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] capabilities: Ambient capability set V2

[Serge E. Hallyn]

On Fri, Mar 06, 2015 at 09:50:02AM -0600, Christoph Lameter wrote:
> On Thu, 5 Mar 2015, Serge E. Hallyn wrote:
> 
> > > > So I'd say drop this change ^
> > >
> > > Then the ambient caps get ignored for a executables that have capabilities
> > > seton the file?
> >
> > Yes.  Those are assumed to already know what they're doing.
> 
> Ok can we get this patch merged now if I do this change
> (effectively ambient caps for binaries that have no caps set) and deal with 
> the
> other issues later? This would cover most of the use cases here at least.

Sorry, something about that patch-patch didn't make sense to me, but I
need to look more closely.  My objection was that you were able to get the
pA capabilities into pP without them being in your pI.  Your proposed
change didn't seem like it would fix that.

It also seems worth waiting until you talk to Andy in person next week.

-serge
--
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/1] x86/fpu: math_state_restore() should not blindly disable irqs

[Oleg Nesterov]

On 03/06, David Vrabel wrote:
>
> On 06/03/15 15:36, Oleg Nesterov wrote:
> >
> > This needs more discussion, but in short so far I think that fpu_alloc()
> > from #NM exception is fine if user_mode(regs) == T.
>
> I think a memory allocation here, where the only behaviour on a failure
> is to kill the task, is (and has always been) a crazy idea.

Well, I do not agree. But lets discuss this later. This code should be
rewritten in any case. It has more problems.

> Additionally, in a Xen PV guest the #NM handler is called with TS
> already cleared by the hypervisor so the handler must not enable
> interrupts (and thus potentially schedule another task) until after the
> current task's fpu state has been restored.  If a task was scheduled
> before restoring the FPU state, TS would be clear and that task will use
> fpu state from a previous task.

I can be easily wrong (especially because I know nothing about Xen ;), but
I do not think this is true.

Yes sure, we need to avoid preemption, but we need this in any case, even
without Xen.

Again, lets discuss this a bit later?

Oleg.

--
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/7] soc/fman: Add the FMan FLIB headers

[Kumar Gala]

On Mar 4, 2015, at 11:45 PM, Emil Medve  wrote:

> From: Igal Liberman 
> 
> The Freescale Data Path Acceleration Architecture (DPAA) is a set of
> hardware components on specific QorIQ P and T series multicore processors.
> This architecture provides the infrastructure to support simplified
> sharing of networking interfaces and accelerators by multiple CPU cores,
> and the accelerators themselves.
> 
> One of the DPAA accelerators is the Frame Manager (FMan), which
> combines the Ethernet network interfaces with packet distribution
> logic to provide intelligent distribution and queuing decisions for
> incoming traffic at line rate.
> 
> This patch presents the FMan Foundation Libraries (FLIB) headers.
> The FMan FLIB suite adds basic support for the DPAA FMan hardware register 
> access.
> The FMan FLIB suite is used in Freescale's SDK Releases.
> 
> Signed-off-by: Igal Liberman 
> ---
> drivers/soc/fsl/fman/flib/common/general.h |   45 +
> drivers/soc/fsl/fman/flib/fman_common.h|   74 ++
> drivers/soc/fsl/fman/flib/fsl_enet.h   |  276 ++
> drivers/soc/fsl/fman/flib/fsl_fman.h   |  801 +++
> drivers/soc/fsl/fman/flib/fsl_fman_dtsec.h | 1017 
> drivers/soc/fsl/fman/flib/fsl_fman_dtsec_mii_acc.h |  104 ++
> drivers/soc/fsl/fman/flib/fsl_fman_kg.h|  506 ++
> drivers/soc/fsl/fman/flib/fsl_fman_memac.h |  492 ++
> drivers/soc/fsl/fman/flib/fsl_fman_memac_mii_acc.h |   77 ++
> drivers/soc/fsl/fman/flib/fsl_fman_port.h  |  602 
> drivers/soc/fsl/fman/flib/fsl_fman_prs.h   |  106 ++
> drivers/soc/fsl/fman/flib/fsl_fman_rtc.h   |  415 
> drivers/soc/fsl/fman/flib/fsl_fman_sp.h|  133 +++
> drivers/soc/fsl/fman/flib/fsl_fman_tgec.h  |  484 ++
> 14 files changed, 5132 insertions(+)
> create mode 100644 drivers/soc/fsl/fman/flib/common/general.h
> create mode 100644 drivers/soc/fsl/fman/flib/fman_common.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_enet.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_dtsec.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_dtsec_mii_acc.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_kg.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_memac.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_memac_mii_acc.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_port.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_prs.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_rtc.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_sp.h
> create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_tgec.h

1. this is way to big of patch to reasonable review
2. can some of these headers be associated with the code patches that use them 
instead

> 
> diff --git a/drivers/soc/fsl/fman/flib/common/general.h 
> b/drivers/soc/fsl/fman/flib/common/general.h
> new file mode 100644
> index 000..e5f56af
> --- /dev/null
> +++ b/drivers/soc/fsl/fman/flib/common/general.h
> @@ -0,0 +1,45 @@
> +/*
> + * Copyright 2008-2015 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are 
> met:
> + * * Redistributions of source code must retain the above copyright
> + *   notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + *   notice, this list of conditions and the following disclaimer in the
> + *   documentation and/or other materials provided with the distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + *   names of its contributors may be used to endorse or promote products
> + *   derived from this software without specific prior written 
> permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of the
> + * GNU General Public License ("GPL") as published by the Free Software
> + * Foundation, either version 2 of that License or (at your option) any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
> SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 
> AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 

Re: [V4 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching

[Suravee Suthikulanit]

On 3/2/2015 2:27 AM, Suravee Suthikulpanit wrote:

Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.

To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires 
modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.

 acpi..:::
E.g:
 # cat /sys/devices/platform/AMDI0600:00/modalias
 acpi:AMDI0600:010601:

where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code

Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.

 static const struct acpi_device_id ahci_acpi_match[] = {
 { "", 0, PCI_CLASS_STORAGE_SATA_AHCI },
 {},
 };

In this case, the corresponded entry in modules.alias file would be:

 alias acpi*:010601:* ahci_platform

Signed-off-by: Suravee Suthikulpanit
---
  drivers/acpi/acpica/acutils.h |  3 ++
  drivers/acpi/acpica/nsxfname.c| 20 +--
  drivers/acpi/acpica/utids.c   | 71 +++
  drivers/acpi/scan.c   | 17 --
  include/acpi/acnames.h|  1 +
  include/acpi/actypes.h|  4 ++-
  include/linux/mod_devicetable.h   |  1 +
  scripts/mod/devicetable-offsets.c |  1 +
  scripts/mod/file2alias.c  | 13 +--
  9 files changed, 123 insertions(+), 8 deletions(-)

[]

>

diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index b034f10..50d8019 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -1148,7 +1148,7 @@ struct acpi_device_info {
u32 name;   /* ACPI object Name */
acpi_object_type type;  /* ACPI object Type */
u8 param_count; /* If a method, required parameter count */
-   u8 valid;   /* Indicates which optional fields are valid */
+   u16 valid;  /* Indicates which optional fields are valid */
u8 flags;   /* Miscellaneous info */
u8 highest_dstates[4];  /* _sx_d values: 0xFF indicates not valid */
u8 lowest_dstates[5];   /* _sx_w values: 0xFF indicates not valid */
@@ -1158,6 +1158,7 @@ struct acpi_device_info {
struct acpi_pnp_device_id unique_id;/* _UID value */
struct acpi_pnp_device_id subsystem_id; /* _SUB value */
struct acpi_pnp_device_id_list compatible_id_list;  /* _CID list  */
+   struct acpi_pnp_device_id cls;  /* _CLS value */
  };


Please disregard this patch. I found out a mistake on my part here.  I 
have sent out V5 here (https://lkml.org/lkml/2015/3/6/24)


Thank you,

Suravee

--
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] kernel/panic/kexec: fix "crash_kexec_post_notifiers" option issue in oops path

[Hatayama, Daisuke/畑山 大輔]

The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced
"crash_kexec_post_notifiers" kernel boot option, which toggles
wheather panic() calls crash_kexec() before panic_notifiers and dump
kmsg or after.

The problem is that the commit overlooks panic_on_oops kernel boot
option. If it is enabled, crash_kexec() is called directly without
going through panic() in oops path.

To fix this issue, this patch adds a check to
"crash_kexec_post_notifiers" in the condition of kexec_should_crash().

Also, put a comment in kexec_should_crash() to explain not obvious
things on this patch.

Signed-off-by: HATAYAMA Daisuke 
Acked-by: Baoquan He 
Tested-by: Hidehiro Kawai 
Reviewed-by: Masami Hiramatsu 
---
 include/linux/kernel.h |  3 +++
 kernel/kexec.c | 11 +++
 kernel/panic.c |  2 +-
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d6d630d..07483c7 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -426,6 +426,9 @@ extern int panic_on_unrecovered_nmi;
 extern int panic_on_io_nmi;
 extern int panic_on_warn;
 extern int sysctl_panic_on_stackoverflow;
+
+extern bool crash_kexec_post_notifiers;
+
 /*
  * Only to be used by arch init code. If the user over-wrote the default
  * CONFIG_PANIC_TIMEOUT, honor it.
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 38c25b1..5bf6077 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -84,6 +84,17 @@ struct resource crashk_low_res = {

 int kexec_should_crash(struct task_struct *p)
 {
+   /*
+* If crash_kexec_post_notifiers is enabled, don't run
+* crash_kexec() here yet, which must be run after panic
+* notifiers in panic().
+*/
+   if (crash_kexec_post_notifiers)
+   return 0;
+   /*
+* There are 4 panic() calls in do_exit() path, each of which
+* calls corresponds to each of these 4 conditions.
+*/
if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
return 1;
return 0;
diff --git a/kernel/panic.c b/kernel/panic.c
index 8136ad7..79ca912 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -32,7 +32,7 @@ static unsigned long tainted_mask;
 static int pause_on_oops;
 static int pause_on_oops_flag;
 static DEFINE_SPINLOCK(pause_on_oops_lock);
-static bool crash_kexec_post_notifiers;
+bool crash_kexec_post_notifiers;
 int panic_on_warn __read_mostly;

 int panic_timeout = CONFIG_PANIC_TIMEOUT;
-- 
1.9.3


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

Re: [PATCH v3] SATA: OCTEON: support SATA on OCTEON platform

[David Daney]

On 03/06/2015 02:06 AM, Hans de Goede wrote:

Hi,

On 05-03-15 15:58, Aleksey Makarov wrote:

The OCTEON SATA controller is currently found on cn71XX devices.

Signed-off-by: David Daney 
Signed-off-by: Vinita Gupta 
Signed-off-by: Aleksey Makarov 
---

[...]

diff --git
a/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
b/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
new file mode 100644
index 000..59e86a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
@@ -0,0 +1,28 @@
+* UCTL SATA controller glue
+
+Properties:
+- compatible: "cavium,octeon-7130-sata-uctl"
+
+  Compatibility with the cn7130 SOC.
+
+- reg: The base address of the UCTL register bank.
+
+- #address-cells, #size-cells, and ranges must be present and hold
+suitable values to map all child nodes.
+
+Example:
+
+uctl@118006c00 {
+compatible = "cavium,octeon-7130-sata-uctl";
+reg = <0x11800 0x6c00 0x0 0x100>;
+ranges; /* Direct mapping */
+#address-cells = <2>;
+#size-cells = <2>;
+
+sata: sata@16c00 {
+compatible = "cavium,octeon-7130-ahci";
+reg = <0x16c00 0x 0x0 0x200>;
+interrupt-parent = <>;
+interrupts = <2 4>; /* Bit: 2, level */
+};
+};


Sorry for jumping into this discussion a bit late, but this nonsense
nesting of what clearly are 2 related but different hw blocks,
both living at completely different register addresses is unacceptable,
this is not a proper operating system dependent hw description as
devicetree is supposed to be. This is an ugly hack to ensure a
certain init ordering, and requiring manual instantiation of
the platform device for the nested dt-node.

NACK.


Can you point to the portion of the device tree specification that 
states that if a node has both "reg" *and* "ranges" properties, the 
parent-bus-address ranges must be a proper subset of the "reg" property 
ranges of the parent?   Because that seems like what you are saying 
here.  I would really like to read the documentation myself so that we 
can get a better understanding of the requirements.


For what it's worth, there are existing bindings that take the same 
form, and they don't seem to break anything.  See for example 
Documentation/devicetree/bindings/mips/cavium/uctl.txt


In any event, it is somewhat moot at this point.  The device tree being 
effectively being a frozen ABI, cannot really be changed.  We are merely 
documenting what is supplied by the preexisting system boot ROMs, not 
starting from scratch and discussing what the proper device tree binding 
for the device should be.


Thanks,
David Daney


[...]
--
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: randconfig build error with next-20150303, in drivers/bcma/driver_pcie2.c

[Kalle Valo]

Jim Davis  writes:

>>> However, that commit is in next-20150304 and we still get the error
>>> (see, for example,
>>> http://kisskb.ellerman.id.au/kisskb/buildresult/12376688/).
>>
>> I applied few fixes from Rafal and Chen:
>>
>> 1ca2760fb2c1 bcma: prepare Kconfig symbol for PCI driver
>> 0a4e699a41f7 bcma: move internal function declarations to private header
>> c32ec2a11321 bcma: make bcma_host_pci_(up|down) calls safe for every config
>> b09f5ec18b16 bcma: Kconfig: Let it depend on PCI
>>
>> It would be great if someone could report if the build errors are gone
>> now.
>
> I reran that configuration file on
> wireless-drivers-next-for-davem-2015-02-07-9274-g1ca2760fb2c13, with
> no build errors.

Good, thanks for checking.

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

Re: [PATCH v1] mv643xx_eth: only account for work done in rxq_process in poll callback.

[Nicolas Schichan]

On 03/04/2015 10:32 PM, Francois Romieu wrote:
> Nicolas Schichan  :
>> @@ -1050,7 +1049,7 @@ static int txq_reclaim(struct tx_queue *txq, int 
>> budget, int force)
>>  __netif_tx_lock_bh(nq);
>>  
>>  reclaimed = 0;
>> -while (reclaimed < budget && txq->tx_desc_count > 0) {
>> +while (txq->tx_desc_count > 0) {
>>  int tx_index;
>>  struct tx_desc *desc;
>>  u32 cmd_sts;
> 
> You may use a local 'int count = txq->tx_desc_count' variable then
> perform a single update at the end of the locked section. 
> txq->tx_used_desc could be reworked in a similar way.

Hello Francois,

I was trying to minimize the code changes wrt the current source, but if you
want that change to be in the same patch, I can certainly respin a V2 with it.

>> @@ -1105,8 +1104,7 @@ static int txq_reclaim(struct tx_queue *txq, int 
>> budget, int force)
>>  
>>  __netif_tx_unlock_bh(nq);
>>  
>> -if (reclaimed < budget)
>> -mp->work_tx &= ~(1 << txq->index);
>> +mp->work_tx &= ~(1 << txq->index);
>>  
>>  return reclaimed;
>>  }
> 
> work_tx is also updated in irq context. I'd rather see "clear_flag() then
> reclaim()" than "reclaim() then clear_flag()" in a subsequent patch.

Just to be sure that I understand the issue here, under normal conditions,
work_tx is updated in irq context via mv643xx_eth_collect_events() and then
the mv643xx interrupts are masked and napi_schedule() is called. Only once all
the work has been completed in the poll callback and the work flags have been
cleared, are the interrupt unmasked and napi_complete() is called. As far as I
can see there should be no issue here.

The only problem I can see is in OOM condition when napi_schedule is called
from a timer callback (oom_timer_wrapper()) which will result in the poll
callback being called with the interrupts unmasked and if an interrupt fires
(possibly in an other CPU) at the wrong time, mv643xx_eth_collect_events()
will race with the various flags clear in txq_reclaim, rxq_process and
rxq_refill ?

In that case wouldn't be something like clear_bit/set_bit preferred compared
to the direct bitwise operations ?

Regards,


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

Re: [PATCH 1/4] PM / Wakeirq: Add minimal device wakeirq helper functions

[Tony Lindgren]

Hi,

* Rafael J. Wysocki  [150305 17:38]:
> Please always CC linux-pm on CC patches.

Sure will do for the next rev, sorry forgot to add that.
 
> On Thursday, March 05, 2015 04:34:06 PM Tony Lindgren wrote:
> > +/**
> > + * handle_dedicated_wakeirq - Handler for device wake-up interrupts
> > + * @wakeirq: Separate wake-up interrupt for a device different
> > + * @_wirq: Wake-up interrupt data
> > + *
> > + * Some devices have a separate wake-up interrupt in addition to the
> > + * regular device interrupt. The wake-up interrupts signal that the
> > + * device should be woken up from a deeper idle state. This handler
> > + * uses device specific pm_runtime functions to wake-up the device
> > + * and then it's up to the device to do whatever it needs to. Note
> > + * as the device may need to restore context and start up regulators,
> > + * this is not a fast path.
> > + *
> > + * Note that we are not resending the lost device interrupts. We assume
> > + * that the wake-up interrupt just needs to wake-up the device, and
> > + * the device pm_runtime_resume() can deal with the situation.
> > + */
> > +static irqreturn_t handle_dedicated_wakeirq(int wakeirq, void *_wirq)
> > +{
> > +   struct wakeirq_source *wirq = _wirq;
> > +   irqreturn_t ret = IRQ_NONE;
> > +
> > +   /* We don't want RPM_ASYNC or RPM_NOWAIT here */
> > +   if (pm_runtime_suspended(wirq->dev)) {
> 
> What if the device is resumed on a different CPU right here?

Good point, sounds like we need to do this in some pm_runtime
function directly for the locking.
 
> > +   pm_runtime_mark_last_busy(wirq->dev);
> > +   pm_runtime_resume(wirq->dev);
> 
> Calling this with disabled interrupts is a bad idea in general.
> Is the device guaranteed to have power.irq_safe set?

Well right now it's using threaded irq, and I'd like to get rid of
the pm_runtime calls in the regular driver interrupts completely.
We need to ensure the device runtime_resume is completed before
returning IRQ_HANDLED here.
 
> I guess what you want to call here is pm_request_resume() and
> I wouldn't say that calling pm_runtime_mark_last_busy() on a
> suspended device was valid.

I'll verify again, but I believe the issue was that without doing
mark_last_busy here the device falls back asleep right away.
That probably should be fixed in pm_runtime in general if that's
the case.

Considering the above, should we add a new function something like
pm_resume_complete() that does not need irq_safe set but does
not return until the device has completed resume?

I think that would be pretty much probably just pm_request_resume
+ pm_runtime_barrier.

> > +/**
> > + * dev_pm_wakeirq_arm_for_suspend - Configure device wake-up
> > + * @wirq: Device wake-up interrupt
> > + *
> > + * Called from the bus code or the device driver for
> > + * device suspend(). Just sets up the wake-up event
> > + * conditionally based on the device_may_wake(). The
> > + * rest is handled automatically by the generic suspend()
> > + * code and runtime_suspend().
> > + */
> > +void dev_pm_wakeirq_arm_for_suspend(struct wakeirq_source *wirq)
> > +{
> > +   if (is_invalid_wakeirq(wirq))
> > +   return;
> > +
> > +   irq_set_irq_wake(wirq->wakeirq,
> > +device_may_wakeup(wirq->dev));
> 
> You want to do
> 
>   if (device_may_wakeup(wirq->dev))
>   enable_irq_wake(wirq->wakeirq);
> 
> here or strange things may happen if two devices share a wakeup IRQ.

OK sure.
 
> Also instead of doing it this way, I'd prefer to hook system wakeup
> interrupts into the wakeup source objects pointed to by the power.wakeup
> fields in struct device.
> 
> Then we could just walk the list of wakeup sources and do enable_irq_wake()
> automatically for the wakeup interrupts hooked up to them at the
> suspend_device_irqs() time without the need to do anything from drivers
> at suspend time.

OK that's a good idea. Then we can drop dev_pm_wakeirq_arm_for_suspend()
and make that part automatic.

Then for runtime_pm, we could make the toggling of the wakeirq handling
automatic too. Or do you see a problem with that?

> > +struct wakeirq_source {
> > +   struct device *dev;
> > +   int wakeirq;
> > +   bool initialized;
> > +   bool enabled;
> > +   irq_handler_t handler;
> > +   void *data;
> > +};
> 
> Well, so now we have struct wakeup_source already and here we get struct 
> wakeirq_source
> and they mean different things ...

Well I was trying to keep it out of the way for most drivers not needing
to use wakeirqs. I'll take a look at making it a pointer in the struct
wakeup_source.

Regards,

Tony
--
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 stable 3.10, 3.12, 3.14] MIPS: Export FP functions used by lose_fpu(1) for KVM

[Guenter Roeck]

On Thu, Mar 05, 2015 at 10:30:34PM -0800, Greg Kroah-Hartman wrote:
> On Thu, Mar 05, 2015 at 04:08:44PM +, James Hogan wrote:
> > [ Upstream commit 3ce465e04bfd8de9956d515d6e9587faac3375dc ]
> > 
> > Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
> > modules so that KVM can make use of it when it is built as a module.
> > 
> > This fixes the following build error when CONFIG_KVM=m due to commit
> > f798217dfd03 ("KVM: MIPS: Don't leak FPU/DSP to guest"):
> > 
> > ERROR: "_save_fp" [arch/mips/kvm/kvm.ko] undefined!
> > 
> > Signed-off-by: James Hogan 
> > Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest)
> > Cc: Paolo Bonzini 
> > Cc: Ralf Baechle 
> > Cc: Paul Burton 
> > Cc: Gleb Natapov 
> > Cc: k...@vger.kernel.org
> > Cc: linux-m...@linux-mips.org
> > Cc:  # 3.10...3.15
> > Patchwork: https://patchwork.linux-mips.org/patch/9260/
> > Signed-off-by: Ralf Baechle 
> > [james.ho...@imgtec.com: Only export when CPU_R4K_FPU=y prior to v3.16,
> >  so as not to break the Octeon build which excludes FPU support. KVM
> >  depends on MIPS32r2 anyway.]
> > Signed-off-by: James Hogan 
> > ---
> > Appologies for the previous cavium_octeon_defconfig link breakage.
> > Octeon has the symbol since 3.16, but not before. This backport should
> > do the trick for stable 3.10, 3.12, and 3.14. Build tested with
> > cavium_octeon_defconfig and malta_kvm_defconfig on those stable
> > branches.
> > ---
> >  arch/mips/kernel/mips_ksyms.c | 8 
> >  1 file changed, 8 insertions(+)
> 
> Now fixed up, thanks.
> 
My auto-builders still fail to build cavium_octeon_defconfig for 3.10 and 3.14,
and as far as I can see they picked up no changes. Did you push the changes into
the stable queue repository ?

Thanks,
Guenter
--
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/1] x86/fpu: math_state_restore() should not blindly disable irqs

[David Vrabel]

On 06/03/15 15:36, Oleg Nesterov wrote:
> On 03/06, David Vrabel wrote:
>>
>> On 06/03/15 14:01, Oleg Nesterov wrote:
>>
>>> Not sure I understand it correctly after the first quick look, but
>>>
>>> 1. It conflicts with the recent changes in tip/x86/fpu
>>>
>>> 2. fpu_ini() initializes current->thread.fpu.state. This looks unneeded,
>>>the kernel threads no longer have FPU context and do not abuse CPU.
>>>
>>> 3. I can be easily wrong, but it looks buggy... Note that
>>>arch_dup_task_struct() doesn't allocate child->fpu.state if
>>>!tsk_used_math(parent).
>>
>> ...yes. It's bit-rotted a bit.
>>
>>> No, I do not think this patch is a good idea. Perhaps I am wrong, but I
>>> think we need other changes. And they should start from init_fpu().
>>
>> But the general principle of avoiding the allocation in the #NM handler
>> and hence avoiding the need to re-enable IRQs is still a good idea, yes?
> 
> This needs more discussion, but in short so far I think that fpu_alloc()
> from #NM exception is fine if user_mode(regs) == T.

I think a memory allocation here, where the only behaviour on a failure
is to kill the task, is (and has always been) a crazy idea.

Additionally, in a Xen PV guest the #NM handler is called with TS
already cleared by the hypervisor so the handler must not enable
interrupts (and thus potentially schedule another task) until after the
current task's fpu state has been restored.  If a task was scheduled
before restoring the FPU state, TS would be clear and that task will use
fpu state from a previous task.

> Just do_device_not_available() should simply do conditional_sti(), I think.
> Perhaps it can even enable irqs unconditionally, but we need to verify that
> this is 100% correct.
> 
> And I agree that "if (!tsk_used_math(tsk))" code in math_state_restore()
> should be removed. But not to avoid the allocation, and this needs other
> changes.
> 
> Oleg.
> 

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

Re: [Patch V7 02/10] ASoC: qcom: Document LPASS CPU bindings

[Kumar Gala]

On Mar 5, 2015, at 7:51 PM, Kenneth Westfield  wrote:

> On Thu, Mar 05, 2015 at 12:52:30PM -0600, Kumar Gala wrote:
>> 
>> On Mar 3, 2015, at 6:21 PM, Kenneth Westfield  
>> wrote:
>> 
>>> +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt
>>> @@ -0,0 +1,49 @@
>>> +* Qualcomm Technologies LPASS CPU DAI
>>> +
>>> +Required subnodes:
>>> +
>>> +- qcom,adsp: Audio DSP sub-node
>>> +
>>> +Optional Audio DSP subnode properties:
>>> +
>>> +- status   : "disabled" indicates the adsp is not available.
>>> +
>> 
>> What is the intent of this subnode?
>> 
> 
> From the cover letter:
> Even though the ipq806x LPASS does not contain an audio DSP, other SOCs
> do have one.  For those SOCs, the audio DSP typically controls the
> hardware blocks in the LPASS.  Hence, different CPU DAI driver(s) would
> need to be used in order to facilitate audio with the DSP.  As such, the
> LPASS DT contains an adsp subnode, which is disabled for this SOC.  The
> same subnode should be enabled and populated for other SOCs that do
> contain an audio DSP.  Not using the audio DSP would require different
> CPU DAI driver(s), in addition to possible bootloader and/or firmware
> changes.
> 
> This was the result of a request from Mark.  See here:
> http://thread.gmane.org/gmane.linux.drivers.devicetree/109331/focus=11633

Two quick comments before I read Mark’s comments.

1. Its not normal practice to put something into a DT that does not exist.  
Having a node, but marking it disabled implies existence.
2. How would one normally address the audio DSP if it did exist.  I’m just 
wondering if having a subnode is the proper solution vs maybe a phandle

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

--
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] HID: multitouch: add support of clickpads

[Benjamin Tissoires]

Touchpads that have only one button are called clickpads and should
be advertised as such by the kernel.

Signed-off-by: Benjamin Tissoires 
---

Hi,

this has been on my local tree for nearly a year now, but I never really
managed to take the time to make it working properly.
Jason raised the subject yesterday, so I finally had a look and fixed the
last bugs.

All the current touchscreens I have the logs are not showing 
INPUT_PROP_BUTTONPAD
as expected, so I think this should be fine to go upstream.

Cheers,
Benjamin

 drivers/hid/hid-multitouch.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index b61715f..a8bec33 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -115,6 +115,7 @@ struct mt_device {
__u8 touches_by_report; /* how many touches are present in one report:
* 1 means we should use a serial protocol
* > 1 means hybrid (multitouch) protocol */
+   __u8 buttons_count; /* number of physical buttons per touchpad */
bool serial_maybe;  /* need to check for serial protocol */
bool curvalid;  /* is the current contact valid? */
unsigned mt_flags;  /* flags to pass to input-mt */
@@ -378,6 +379,10 @@ static int mt_touch_input_mapping(struct hid_device *hdev, 
struct hid_input *hi,
td->inputmode_value = MT_INPUTMODE_TOUCHPAD;
}
 
+   /* count the buttons on touchpads */
+   if ((usage->hid & HID_USAGE_PAGE) == HID_UP_BUTTON)
+   td->buttons_count++;
+
if (usage->usage_index)
prev_usage = >usage[usage->usage_index - 1];
 
@@ -727,6 +732,10 @@ static void mt_touch_input_configured(struct hid_device 
*hdev,
if (cls->quirks & MT_QUIRK_NOT_SEEN_MEANS_UP)
td->mt_flags |= INPUT_MT_DROP_UNUSED;
 
+   /* check for clickpads */
+   if ((td->mt_flags & INPUT_MT_POINTER) && (td->buttons_count == 1))
+   __set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
+
input_mt_init_slots(input, td->maxcontacts, td->mt_flags);
 
td->mt_flags = 0;
-- 
2.1.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 v4 2/5] irqchip: gicv3-its: use 64KB page as default granule

[Marc Zyngier]

On 06/03/15 04:13, Yun Wu wrote:
> The field of page size in register GITS_BASERn might be read-only
> if an implementation only supports a single, fixed page size. But
> currently the ITS driver will throw out an error when PAGE_SIZE
> is less than the minimum size supported by an ITS. So addressing
> this problem by using 64KB pages as default granule for all the
> ITS base tables.
> 
> Acked-by: Marc Zyngier 
> Signed-off-by: Yun Wu 
> ---
>  drivers/irqchip/irq-gic-v3-its.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
> b/drivers/irqchip/irq-gic-v3-its.c
> index 69eeea3..f5bfa42 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -800,7 +800,7 @@ static int its_alloc_tables(struct its_node *its)
>  {
>   int err;
>   int i;
> - int psz = PAGE_SIZE;
> + int psz = SZ_64K;
>   u64 shr = GITS_BASER_InnerShareable;
> 
>   for (i = 0; i < GITS_BASER_NR_REGS; i++) {

Just went through a test run with this, and this breaks any non Device
Table allocation when PAGE_SIZE != 64K.

The following hunk fixes it:

@@ -806,7 +806,7 @@ static int its_alloc_tables(struct its_node *its)
u64 val = readq_relaxed(its->base + GITS_BASER + i * 8);
u64 type = GITS_BASER_TYPE(val);
u64 entry_size = GITS_BASER_ENTRY_SIZE(val);
-   int order = 0;
+   int order = get_order(psz);
int alloc_size;
u64 tmp;
void *base;

I'll fold it in to the original patch, but I'd be grateful if you could
do a slightly more thorough testing before sending patches.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
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/1] staging: rtl8723au: Remove unnecessary OOM message

[Jes Sorensen]

Julia Lawall  writes:
> On Fri, 6 Mar 2015, Jes Sorensen wrote:
>
>> Quentin Lambert  writes:
>> > This patch reduces the kernel size by removing error messages that 
>> > duplicate
>> > the normal OOM message.
>> >
>> > A simplified version of the semantic patch that finds this problem is as
>> > follows: (http://coccinelle.lip6.fr)
>>
>> This patch removes useful warnings about what allocation failed. The
>> messages removed are NOT duplicate!
>
> Is it really the case that the information can't be reconstructed from the
> information generated by kmalloc on failure?  To my understanding there is
> a stack trace, and from scanning through the changes I see only one change
> per function, so perhaps the stack trace already makes it clear where the
> problem occurred?

It may be possible to backtrack, but this change just makes it harder.

There are tons of real issues to fix in this driver, this patch just
increases the risk of patch conflicts for no real gain.

Jes
--
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 -next 02/12] serial: earlycon: Emit earlycon name in the OF table

[Peter Hurley]

On 03/05/2015 10:13 AM, Rob Herring wrote:
> On Wed, Mar 4, 2015 at 11:24 AM, Peter Hurley  
> wrote:
>> The OF device name of the earlycon is never used because there is no
>> device; re-purpose the name field to store the earlycon name in
>> the OF earlycon table. Earlycon will use the table entry to
>> fixup the console name and index.
>>
>> Signed-off-by: Peter Hurley 
>> ---
>>  include/linux/serial_core.h | 15 +--
>>  1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
>> index 8aeec49..c523785 100644
>> --- a/include/linux/serial_core.h
>> +++ b/include/linux/serial_core.h
>> @@ -29,6 +29,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #ifdef CONFIG_SERIAL_CORE_CONSOLE
>> @@ -353,8 +354,18 @@ extern int of_setup_earlycon(unsigned long addr,
>>  = { .name  = __stringify(_name),   \
>>  .setup = func  }
>>
>> -#define OF_EARLYCON_DECLARE(name, compat, fn)  \
>> -   _OF_DECLARE(earlycon, name, compat, fn, void *)
> 
> The purpose of this was to follow the same structure for all users of
> this. We're not there yet, but this moves in the wrong direction.

Ok.

There's no special dependence on the earlycons needing to be of_device_ids;
afaict that's simply for convenience' sake also.

Maybe this is a good time to ditch separate OF_EARLYCON_DECLARE/EARLYCON_DECLARE
macros and simply use a single table to find and start the correct earlycon?


>> +#ifdef CONFIG_OF
>> +#define EARLYCON_OF_TABLE_ATTR __used __section(__earlycon_of_table)
>> +#else
>> +#define EARLYCON_OF_TABLE_ATTR __attribute__((unused))
>> +#endif
>> +
>> +#define OF_EARLYCON_DECLARE(_name, compat, fn) \
>> +   static const struct of_device_id __of_table_##_name \
>> +   EARLYCON_OF_TABLE_ATTR  \
>> += { .name = __stringify(_name),\
> 
> While convenient, this is an abuse of name which is supposed to be the
> DT node name.
> 
> Perhaps instead of trying to make the earlycon have the right name,
> the real console can know the matching earlycon's name?

Just to be clear here: as of the other patch series, "Extensible console
matching & direct earlycon", the name and index values stored in the earlycon
struct console have no effect on earlycon->console handoff (which at the moment,
is supported by command line matching).

However, console names are really the basis for the whole console subsystem;
I'd really like to see devicetree working within that framework rather than
parallel to it.

Regards,
Peter Hurley

>> +.compatible = compat,  \
>> +.data = (fn == (void *)NULL) ? fn : fn  }
>>
>>  struct uart_port *uart_get_console(struct uart_port *ports, int nr,
>>struct console *c);
>> --
>> 2.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 v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id

[Kumar Gala]

On Mar 5, 2015, at 7:59 PM, Olof Johansson  wrote:

> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala  wrote:
>> 
>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman  wrote:
>> 
>>> Kumar Gala  writes:
>>> 
 The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
 on Qualcomm MSM platforms to determine which device tree should be
 utilized and passed to the kernel.
 
 Cc: 
 Signed-off-by: Kumar Gala 
>>> 
>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>> plus multiple DTBs and figure out which DTB to pass?
>>> 
>>> Kevin
>> 
>> yes
> 
> That's a bummer.
> 
> Luckily, the solution for upstream is still quite simple: Provide only
> one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

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

--
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]Add VT1613 AC97 codec support

[Takashi Iwai]

At Fri, 06 Mar 2015 16:59:00 +0100,
Maciej S. Szmigiero wrote:
> 
> Patch to add an VT1613 AC97 codec support.
> 
> This codec has additional DC offset removal control,
> headphone output and no video input.
> 
> Signed-off-by: Maciej Szmigiero 

Applied, thanks.


Takashi

> 
> diff --git a/sound/pci/ac97/ac97_codec.c b/sound/pci/ac97/ac97_codec.c
> index 5ee2f17..5bca1a3 100644
> --- a/sound/pci/ac97/ac97_codec.c
> +++ b/sound/pci/ac97/ac97_codec.c
> @@ -177,6 +177,7 @@ static const struct ac97_codec_id snd_ac97_codec_ids[] = {
>  { 0x54524123, 0x, "TR28602", NULL,   NULL }, // only 
> guess --jk [TR28023 = eMicro EM28023 (new CT1297)]
>  { 0x54584e03, 0x, "TLV320AIC27", NULL,   NULL },
>  { 0x54584e20, 0x, "TLC320AD9xC", NULL,   NULL },
> +{ 0x56494120, 0xfff0, "VIA1613", patch_vt1613,   NULL },
>  { 0x56494161, 0x, "VIA1612A",NULL,   NULL }, 
> // modified ICE1232 with S/PDIF
>  { 0x56494170, 0x, "VIA1617A",patch_vt1617a,  NULL }, 
> // modified VT1616 with S/PDIF
>  { 0x56494182, 0x, "VIA1618", patch_vt1618,   NULL },
> diff --git a/sound/pci/ac97/ac97_patch.c b/sound/pci/ac97/ac97_patch.c
> index ceaac1c..eca2210 100644
> --- a/sound/pci/ac97/ac97_patch.c
> +++ b/sound/pci/ac97/ac97_patch.c
> @@ -3352,6 +3352,39 @@ static int patch_cm9780(struct snd_ac97 *ac97)
>  }
>  
>  /*
> + * VIA VT1613 codec
> + */
> +static const struct snd_kcontrol_new snd_ac97_controls_vt1613[] = {
> +AC97_SINGLE("DC Offset removal", 0x5a, 10, 1, 0),
> +};
> +
> +static int patch_vt1613_specific(struct snd_ac97 *ac97)
> +{
> + int err;
> +
> + err = patch_build_controls(ac97, _ac97_controls_vt1613[0],
> + ARRAY_SIZE(snd_ac97_controls_vt1613));
> + if (err)
> + return err;
> +
> + return 0;
> +};
> +
> +static const struct snd_ac97_build_ops patch_vt1613_ops = {
> + .build_specific = patch_vt1613_specific
> +};
> +
> +static int patch_vt1613(struct snd_ac97 *ac97)
> +{
> + ac97->build_ops = _vt1613_ops;
> +
> + ac97->flags |= AC97_HAS_NO_VIDEO;
> + ac97->caps |= AC97_BC_HEADPHONE;
> +
> + return 0;
> +}
> +
> +/*
>   * VIA VT1616 codec
>   */
>  static const struct snd_kcontrol_new snd_ac97_controls_vt1616[] = {
> 
--
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: [Xen-devel] kasan_map_early_shadow() on Xen

[Konrad Rzeszutek Wilk]

On Wed, Mar 04, 2015 at 05:47:03PM -0800, Luis R. Rodriguez wrote:
> On Wed, Mar 4, 2015 at 6:36 AM, Andrey Ryabinin  
> wrote:
> > On 03/03/2015 07:02 PM, Konrad Rzeszutek Wilk wrote:
> >> If it is like that - then just using what had to be implemented
> >> for the stack protection as a template ought to pave most of the
> >> work?
> >
> > Probably. I think I could make this work.
> > However, I won't be able to work on this until the end of the next week.
> 
> While a solution is likely possible here I'd like for us to notice how
> two features have gone now under our nose for Xen on v4.0 which have
> issues. Proactive maintainer reviews would detect these issues but we
> can't bet on these, and testing is just as reactive and slow. I'm

Hmm, I see you saying 'Proactive maintainer review would detect' these
but that assumes that the maintainer would even be copied on these patches?

None of the Xen maintainers were copied on this.

And while we all strive to be pro-active I have to remind you maintainers
are usually swamped.

> hinting we keep our eyes out for an architectural solution that would
> avoid these issues. Don't ask me what that is just yet...

Keep in mind that a lot of these issues get resolved during merge window
thanks to the resiliancy of Boris monitoring these tests with an sharp eye!

After all that is what merge windows are - things break during them.

> 
>  Luis
--
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]Add VT1613 AC97 codec support

[Maciej S. Szmigiero]

Patch to add an VT1613 AC97 codec support.

This codec has additional DC offset removal control,
headphone output and no video input.

Signed-off-by: Maciej Szmigiero 

diff --git a/sound/pci/ac97/ac97_codec.c b/sound/pci/ac97/ac97_codec.c
index 5ee2f17..5bca1a3 100644
--- a/sound/pci/ac97/ac97_codec.c
+++ b/sound/pci/ac97/ac97_codec.c
@@ -177,6 +177,7 @@ static const struct ac97_codec_id snd_ac97_codec_ids[] = {
 { 0x54524123, 0x, "TR28602",   NULL,   NULL }, // only 
guess --jk [TR28023 = eMicro EM28023 (new CT1297)]
 { 0x54584e03, 0x, "TLV320AIC27",   NULL,   NULL },
 { 0x54584e20, 0x, "TLC320AD9xC",   NULL,   NULL },
+{ 0x56494120, 0xfff0, "VIA1613",   patch_vt1613,   NULL },
 { 0x56494161, 0x, "VIA1612A",  NULL,   NULL }, // 
modified ICE1232 with S/PDIF
 { 0x56494170, 0x, "VIA1617A",  patch_vt1617a,  NULL }, // 
modified VT1616 with S/PDIF
 { 0x56494182, 0x, "VIA1618",   patch_vt1618,   NULL },
diff --git a/sound/pci/ac97/ac97_patch.c b/sound/pci/ac97/ac97_patch.c
index ceaac1c..eca2210 100644
--- a/sound/pci/ac97/ac97_patch.c
+++ b/sound/pci/ac97/ac97_patch.c
@@ -3352,6 +3352,39 @@ static int patch_cm9780(struct snd_ac97 *ac97)
 }
 
 /*
+ * VIA VT1613 codec
+ */
+static const struct snd_kcontrol_new snd_ac97_controls_vt1613[] = {
+AC97_SINGLE("DC Offset removal", 0x5a, 10, 1, 0),
+};
+
+static int patch_vt1613_specific(struct snd_ac97 *ac97)
+{
+   int err;
+
+   err = patch_build_controls(ac97, _ac97_controls_vt1613[0],
+   ARRAY_SIZE(snd_ac97_controls_vt1613));
+   if (err)
+   return err;
+
+   return 0;
+};
+
+static const struct snd_ac97_build_ops patch_vt1613_ops = {
+   .build_specific = patch_vt1613_specific
+};
+
+static int patch_vt1613(struct snd_ac97 *ac97)
+{
+   ac97->build_ops = _vt1613_ops;
+
+   ac97->flags |= AC97_HAS_NO_VIDEO;
+   ac97->caps |= AC97_BC_HEADPHONE;
+
+   return 0;
+}
+
+/*
  * VIA VT1616 codec
  */
 static const struct snd_kcontrol_new snd_ac97_controls_vt1616[] = {

--
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/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

[Bill Pringlemeir]

On  6 Mar 2015, ste...@agner.ch wrote:

> On 2015-03-06 07:15, Sascha Hauer wrote:
>> Hi Stefan,

>> On Thu, Mar 05, 2015 at 12:10:20AM +0100, Stefan Agner wrote:
>>> +
>>> +static int vf610_nfc_probe_dt(struct device *dev, struct
>>> vf610_nfc_config *cfg)
>>> +{
>>> +   struct device_node *np = dev->of_node;
>>> +   int buswidth;
>>> +   u32 clkrate;
>>> +
>>> +   if (!np)
>>> +   return 1;
>>> +
>>> +   cfg->flash_bbt = of_get_nand_on_flash_bbt(np);
>>> +
>>> +   if (!of_property_read_u32(np, "clock-frequency", ))
>>> +   cfg->clkrate = clkrate;

>> Normally the clock-frequency property tells the driver at which
>> frequency the device actually is running, not to tell the driver at
>> which frequency the device *should* run. It's strange to use the
>> value of the clock-frequency property as input to
>> clk_set_rate(). Maybe the assigned clock binding is more appropriate
>> here, see Documentation/devicetree/bindings/clock/clock-bindings.txt.

> What we try to do here is to specify the hardware limitations. There
> seem to be some hardware restrictions when it comes to clock
> frequencies. There has been a rather long discussion over at
> Freescales community about it:
> https://community.freescale.com/thread/317074

> Not sure if this is the right way to specify the supported
> frequencies, or should we create a custom property for this, something
> like fsl,max-nfc-frequency = <3300>?

On most SOC's with this controller, the input clock to the controller
affects the NAND flash timing and other factors; so you will want to set
it based on the board/NAND stuffed.  The clock is for synchronous logic
in the controller and affects many properties.  

I guess Sascha's point is, the board's DT should just have some
'_clk' node and not have this part of the driver?  Either way works.
However, this clock is very important to get the driver to function.  It
seem better for a user/porter to have this info in the node.  I guess
you need to be trained to look at every node in the sub-tree for a
device.  I think the other way might be better or a sub-system
maintainer.  I looked at 'i2c' and other node which have a
'clock-frequency' parameter. 

In the Documentation/devicetree/bindings/clock/clock-bindings.txt,

uart@a000 {
compatible = "fsl,imx-uart";
reg = <0xa000 0x1000>;
interrupts = <33>;
clocks = < 0>, < 1>;
clock-names = "baud", "register";
};

Here, this uart clock may affect the maximum baud rate supported by the
device.  For this controller (vf610_nfc), the clock is like setting the
'baud rate'; it affect the NAND memory cycles.  There is not really any
'wait state' type logic in the controller register set that would allow
the driver to work with a 'given clock' rate.  For certain a board
should set this clock for the NAND chips they wish to support.

What would the board file look like to use clock node?

[generic]
nfc: nand@400e {
compatible = "fsl,vf610-nfc";
reg = <0x400e 0x4000>;
clocks = < VF610_CLK_NFC>;
clock-names = "nfc_clk";
status = "disabled";
};

[board]

 {
nand-bus-width = <16>;
nand-ecc-mode = "hw";
nand-on-flash-bbt;
nand-ecc-strength = <24>;
nand-ecc-step-size = <2048>;
pinctrl-names = "default";
pinctrl-0 = <_nfc_1>;
status = "okay";
_clk { frequency = <3300>}  /* Like this? */
};

I don't know how to do the 'Like this?' part.  I don't think the
'clock-bindings.txt' explains it.  I see this is better as the the
driver needs no 'clock handling' code.  It is definitely a little more
obtuse for the users.

[snip]

>> Does this driver work without device tree or not? Currently the
>> driver bails out when device tree support is enabled but no device
>> node is given. When device tree support is disabled in the kernel
>> though the driver happily continues here.

> Hm, I never tried using this Driver without DT. 

[snip]

I also didn't test this.  The driver was ported from Linux versions
where DT did not exist.  It is used in some OpenWRT/68k/coldfire
(patched) kernels and I wanted it to be useful for them.  However, we
could probably remove the 'platform support'.  Other people are using
this on PPC platforms and they will also have dt/of.

Currently the platform control has no way to 'pass data', so the driver
only works with whatever defaults it has (or that is my belief).  For
instance, those OpenWRT kernels have a 'machine file' which will set the
'clock-frequency' and other parameters.  We could remove the platform
support completely if it is misleading.  I guess the KConfig would need
a 'depends on CONFIG_OF'.

Thanks for the review,
Bill Pringlemeir.
--
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  

Re: [PATCHv4 00/24] THP refcounting redesign

[Jerome Marchand]

On 03/06/2015 01:18 PM, Kirill A. Shutemov wrote:
> On Thu, Mar 05, 2015 at 01:55:15PM +0100, Jerome Marchand wrote:
>> On 03/04/2015 05:32 PM, Kirill A. Shutemov wrote:
>>> Hello everybody,
>>>
>>> It's bug-fix update of my thp refcounting work.
>>>
>>> The goal of patchset is to make refcounting on THP pages cheaper with
>>> simpler semantics and allow the same THP compound page to be mapped with
>>> PMD and PTEs. This is required to get reasonable THP-pagecache
>>> implementation.
>>>
>>> With the new refcounting design it's much easier to protect against
>>> split_huge_page(): simple reference on a page will make you the deal.
>>> It makes gup_fast() implementation simpler and doesn't require
>>> special-case in futex code to handle tail THP pages.
>>>
>>> It should improve THP utilization over the system since splitting THP in
>>> one process doesn't necessary lead to splitting the page in all other
>>> processes have the page mapped.
>>>
>> [...]
>>> I believe all known bugs have been fixed, but I'm sure Sasha will bring more
>>> reports.
>>>
>>> The patchset also available on git:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git 
>>> thp/refcounting/v4
>>>
>>
>> Hi Kirill,
>>
>> I ran some ltp tests and it triggered two bugs:
>>
> 
> Could you test with the patch below?

It seems to fix the issue. I can't reproduce the bugs anymore.

Thanks,
Jerome

> 
> diff --git a/arch/arc/mm/cache_arc700.c b/arch/arc/mm/cache_arc700.c
> index 8c3a3e02ba92..1baa4d23314b 100644
> --- a/arch/arc/mm/cache_arc700.c
> +++ b/arch/arc/mm/cache_arc700.c
> @@ -490,7 +490,7 @@ void flush_dcache_page(struct page *page)
>*/
>   if (!mapping_mapped(mapping)) {
>   clear_bit(PG_dc_clean, >flags);
> - } else if (page_mapped(page)) {
> + } else if (page_mapcount(page)) {
>  
>   /* kernel reading from page with U-mapping */
>   void *paddr = page_address(page);
> @@ -675,7 +675,7 @@ void copy_user_highpage(struct page *to, struct page 
> *from,
>* Note that while @u_vaddr refers to DST page's userspace vaddr, it is
>* equally valid for SRC page as well
>*/
> - if (page_mapped(from) && addr_not_cache_congruent(kfrom, u_vaddr)) {
> + if (page_mapcount(from) && addr_not_cache_congruent(kfrom, u_vaddr)) {
>   __flush_dcache_page(kfrom, u_vaddr);
>   clean_src_k_mappings = 1;
>   }
> diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
> index 34b66af516ea..8f972fc8933d 100644
> --- a/arch/arm/mm/flush.c
> +++ b/arch/arm/mm/flush.c
> @@ -315,7 +315,7 @@ void flush_dcache_page(struct page *page)
>   mapping = page_mapping(page);
>  
>   if (!cache_ops_need_broadcast() &&
> - mapping && !page_mapped(page))
> + mapping && !page_mapcount(page))
>   clear_bit(PG_dcache_clean, >flags);
>   else {
>   __flush_dcache_page(mapping, page);
> diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
> index 3f8059602765..b28bf185ef77 100644
> --- a/arch/mips/mm/c-r4k.c
> +++ b/arch/mips/mm/c-r4k.c
> @@ -578,7 +578,8 @@ static inline void local_r4k_flush_cache_page(void *args)
>* another ASID than the current one.
>*/
>   map_coherent = (cpu_has_dc_aliases &&
> - page_mapped(page) && !Page_dcache_dirty(page));
> + page_mapcount(page) &&
> + !Page_dcache_dirty(page));
>   if (map_coherent)
>   vaddr = kmap_coherent(page, addr);
>   else
> diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
> index 7e3ea7766822..e695b28dc32c 100644
> --- a/arch/mips/mm/cache.c
> +++ b/arch/mips/mm/cache.c
> @@ -106,7 +106,7 @@ void __flush_anon_page(struct page *page, unsigned long 
> vmaddr)
>   unsigned long addr = (unsigned long) page_address(page);
>  
>   if (pages_do_alias(addr, vmaddr)) {
> - if (page_mapped(page) && !Page_dcache_dirty(page)) {
> + if (page_mapcount(page) && !Page_dcache_dirty(page)) {
>   void *kaddr;
>  
>   kaddr = kmap_coherent(page, vmaddr);
> diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
> index 448cde372af0..2c8e44aa536e 100644
> --- a/arch/mips/mm/init.c
> +++ b/arch/mips/mm/init.c
> @@ -156,7 +156,7 @@ void copy_user_highpage(struct page *to, struct page 
> *from,
>  
>   vto = kmap_atomic(to);
>   if (cpu_has_dc_aliases &&
> - page_mapped(from) && !Page_dcache_dirty(from)) {
> + page_mapcount(from) && !Page_dcache_dirty(from)) {
>   vfrom = kmap_coherent(from, vaddr);
>   copy_page(vto, vfrom);
>   kunmap_coherent();
> @@ -178,7 +178,7 @@ void copy_to_user_page(struct vm_area_struct *vma,
>   unsigned long len)
>  {
>   if (cpu_has_dc_aliases &&
> - page_mapped(page) && !Page_dcache_dirty(page)) {
> + 

[PATCH] phy: ti/omap: Fix modalias

[Axel Lin]

Remove extra space in MODULE_ALIAS.

Signed-off-by: Axel Lin 
---
 drivers/phy/phy-omap-control.c | 2 +-
 drivers/phy/phy-omap-usb2.c| 2 +-
 drivers/phy/phy-ti-pipe3.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c
index efe724f..93252e0 100644
--- a/drivers/phy/phy-omap-control.c
+++ b/drivers/phy/phy-omap-control.c
@@ -360,7 +360,7 @@ static void __exit omap_control_phy_exit(void)
 }
 module_exit(omap_control_phy_exit);
 
-MODULE_ALIAS("platform: omap_control_phy");
+MODULE_ALIAS("platform:omap_control_phy");
 MODULE_AUTHOR("Texas Instruments Inc.");
 MODULE_DESCRIPTION("OMAP Control Module PHY Driver");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 6f4aef3..c4917b2 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -383,7 +383,7 @@ static struct platform_driver omap_usb2_driver = {
 
 module_platform_driver(omap_usb2_driver);
 
-MODULE_ALIAS("platform: omap_usb2");
+MODULE_ALIAS("platform:omap_usb2");
 MODULE_AUTHOR("Texas Instruments Inc.");
 MODULE_DESCRIPTION("OMAP USB2 phy driver");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 95c88f9..242e06b 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -608,7 +608,7 @@ static struct platform_driver ti_pipe3_driver = {
 
 module_platform_driver(ti_pipe3_driver);
 
-MODULE_ALIAS("platform: ti_pipe3");
+MODULE_ALIAS("platform:ti_pipe3");
 MODULE_AUTHOR("Texas Instruments Inc.");
 MODULE_DESCRIPTION("TI PIPE3 phy driver");
 MODULE_LICENSE("GPL v2");
-- 
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 0/4] cleancache: remove limit on the number of cleancache enabled filesystems

[Vladimir Davydov]

On Fri, Mar 06, 2015 at 10:14:26AM -0500, Konrad Rzeszutek Wilk wrote:
> Would you be willing to fold in the description in the patch #4 and repost it?
> 
> Andrew - are you OK picking it up or would you prefer me as the maintainer
> to feed it to Linus? [either option is fine with me]

AFAICS Andrew has already picked it up with the description folded in
patch #4.

Thanks,
Vladimir
--
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] README: make the README agnostic to version numbers

[Josh Poimboeuf]

On Tue, Mar 03, 2015 at 10:08:02PM +0800, Yaowei Bai wrote:
> As we have moved to 4.x, it should be reflected in README.
> 
> Signed-off-by: Yaowei Bai 
> ---
>  README | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)

How about this more version-agnostic version?

--->8---

Subject: [PATCH] README: make the README version number agnostic

Remove all references to Linux version numbers (except for the examples)
in the README so we won't have to update it again for Linux 5.0.

Signed-off-by: Josh Poimboeuf 
---
 README | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/README b/README
index a24ec89..5690938 100644
--- a/README
+++ b/README
@@ -1,6 +1,6 @@
-Linux kernel release 3.x 
+Linux kernel release 
 
-These are the release notes for Linux version 3.  Read them carefully,
+These are the release notes for Linux.  Read them carefully,
 as they tell you what this is all about, explain how to install the
 kernel, and what to do if something goes wrong. 
 
@@ -62,43 +62,43 @@ INSTALLING the kernel source:
directory where you have permissions (eg. your home directory) and
unpack it:
 
- gzip -cd linux-3.X.tar.gz | tar xvf -
+ gzip -cd linux-X.Y.tar.gz | tar xvf -
 
or
 
- bzip2 -dc linux-3.X.tar.bz2 | tar xvf -
+ bzip2 -dc linux-X.Y.tar.bz2 | tar xvf -
 
-   Replace "X" with the version number of the latest kernel.
+   Replace "X.Y" with the version number of the latest kernel.
 
Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files.  They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
 
- - You can also upgrade between 3.x releases by patching.  Patches are
+ - You can also upgrade between kernel releases by patching.  Patches are
distributed in the traditional gzip and the newer bzip2 format.  To
install by patching, get all the newer patch files, enter the
-   top level directory of the kernel source (linux-3.X) and execute:
+   top level directory of the kernel source and execute:
 
- gzip -cd ../patch-3.x.gz | patch -p1
+ gzip -cd ../patch-x.y.gz | patch -p1
 
or
 
- bzip2 -dc ../patch-3.x.bz2 | patch -p1
+ bzip2 -dc ../patch-x.y.bz2 | patch -p1
 
-   Replace "x" for all versions bigger than the version "X" of your current
+   Replace "x.y" for all versions bigger than the version "X.Y" of your current
source tree, _in_order_, and you should be ok.  You may want to remove
the backup files (some-file-name~ or some-file-name.orig), and make sure
that there are no failed patches (some-file-name# or some-file-name.rej).
If there are, either you or I have made a mistake.
 
-   Unlike patches for the 3.x kernels, patches for the 3.x.y kernels
+   Unlike patches for the x.y kernels, patches for the x.y.z kernels
(also known as the -stable kernels) are not incremental but instead apply
-   directly to the base 3.x kernel.  For example, if your base kernel is 3.0
-   and you want to apply the 3.0.3 patch, you must not first apply the 3.0.1
-   and 3.0.2 patches. Similarly, if you are running kernel version 3.0.2 and
-   want to jump to 3.0.3, you must first reverse the 3.0.2 patch (that is,
-   patch -R) _before_ applying the 3.0.3 patch. You can read more on this in
+   directly to the base x.y kernel.  For example, if your base kernel is 4.0
+   and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1
+   and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and
+   want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is,
+   patch -R) _before_ applying the 4.0.3 patch. You can read more on this in
Documentation/applying-patches.txt
 
Alternatively, the script patch-kernel can be used to automate this
@@ -120,7 +120,7 @@ INSTALLING the kernel source:
 
 SOFTWARE REQUIREMENTS
 
-   Compiling and running the 3.x kernels requires up-to-date
+   Compiling and running Linux kernels requires up-to-date
versions of various software packages.  Consult
Documentation/Changes for the minimum version numbers required
and how to get updates for these packages.  Beware that using
@@ -137,12 +137,12 @@ BUILD directory for the kernel:
place for the output files (including .config).
Example:
 
- kernel source code: /usr/src/linux-3.X
+ kernel source code: /usr/src/linux
  build directory:/home/name/build/kernel
 
To configure and build the kernel, use:
 
- cd /usr/src/linux-3.X
+ cd /usr/src/linux
  make O=/home/name/build/kernel menuconfig
  make O=/home/name/build/kernel
  sudo make O=/home/name/build/kernel modules_install install
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a 

Re: [PATCH] capabilities: Ambient capability set V2

[Christoph Lameter]

On Thu, 5 Mar 2015, Serge E. Hallyn wrote:

> > > So I'd say drop this change ^
> >
> > Then the ambient caps get ignored for a executables that have capabilities
> > seton the file?
>
> Yes.  Those are assumed to already know what they're doing.

Ok can we get this patch merged now if I do this change
(effectively ambient caps for binaries that have no caps set) and deal with the
other issues later? This would cover most of the use cases here at least.

--
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: sched: softlockups in multi_cpu_stop

[Sasha Levin]

On 03/06/2015 09:45 AM, Sasha Levin wrote:
> On 03/06/2015 09:34 AM, Rafael David Tinoco wrote:
>> Are you sure about this ? I have a core dump locked on the same place
>> (state machine for powering cpu down for the task swap) from a 3.13 (+
>> upstream patches) and this commit wasn't backported yet.
> 
> bisect took me to that same commit twice, and I'm running a -next with that
> commit reverted and not seeing those hangs anymore.
> 
> I also didn't see the hang up until a month or so ago (which matches with that
> commit date), and definitely not back in 3.13.

I just remembered that I was seeing something similar back then, which was 
fixed:

http://lists.openwall.net/linux-kernel/2014/05/12/725


Thanks,
Sasha

--
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: [PCI] BUG: unable to handle kernel

[Murali Karicheri]

On 03/06/2015 10:13 AM, Murali Karicheri wrote:

On 03/06/2015 01:06 AM, Fengguang Wu wrote:

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git

commit 0b2af171520e5d5e7d5b5f479b90a6a5014d9df6
Author: Murali Karicheri
AuthorDate: Tue Mar 3 12:52:13 2015 -0500
Commit: Bjorn Helgaas
CommitDate: Tue Mar 3 14:42:58 2015 -0600

PCI: Update DMA configuration from DT


cut-

[ 0.57] Modules linked in:
[ 0.57] Modules linked in:

[ 0.57] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.0.0-rc1-6-g0b2af17 #6
[ 0.57] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.0.0-rc1-6-g0b2af17 #6
[ 0.57] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 0.57] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 0.57] task: 7806 ti: 78068000 task.ti: 78068000
[ 0.57] task: 7806 ti: 78068000 task.ti: 78068000
[ 0.57] EIP: 0060:[<79a20c33>] EFLAGS: 00010246 CPU: 0
[ 0.57] EIP: 0060:[<79a20c33>] EFLAGS: 00010246 CPU: 0
[ 0.57] EIP is at of_pci_dma_configure+0x33/0x70
[ 0.57] EIP is at of_pci_dma_configure+0x33/0x70
[ 0.57] EAX:  EBX: 78011800 ECX:  EDX: 0005
[ 0.57] EAX:  EBX: 78011800 ECX:  EDX: 0005
[ 0.57] ESI: 781d8400 EDI: 781d8000 EBP: 78069cd0 ESP: 78069cc8
[ 0.57] ESI: 781d8400 EDI: 781d8000 EBP: 78069cd0 ESP: 78069cc8
[ 0.57] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 0.57] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 0.57] CR0: 8005003b CR2: 01c4 CR3: 0229f000 CR4: 06d0
[ 0.57] CR0: 8005003b CR2: 01c4 CR3: 0229f000 CR4: 06d0
[ 0.57] Stack:
[ 0.57] Stack:
[ 0.57] 78011800
[ 0.57] 78011800 78011860 78011860 78069d5c 78069d5c 7976c1ac
7976c1ac 0002 0002 78069ce8 78069ce8 002e 002e
 

[ 0.57] 1100
[ 0.57] 1100 78011800 78011800 78011860 78011860 781d8000
781d8000      
 

[ 0.57] 
[ 0.57]      
      
 

[ 0.57] Call Trace:
[ 0.57] Call Trace:
[ 0.57] [<7976c1ac>] pci_device_add+0xbc/0x820
[ 0.57] [<7976c1ac>] pci_device_add+0xbc/0x820
[ 0.57] [<7976ca54>] pci_scan_single_device+0x144/0x1c0
[ 0.57] [<7976ca54>] pci_scan_single_device+0x144/0x1c0
[ 0.57] [<7976cb70>] pci_scan_slot+0xa0/0x230
[ 0.57] [<7976cb70>] pci_scan_slot+0xa0/0x230
[ 0.57] [<7976ea6a>] pci_scan_child_bus+0x5a/0x230
[ 0.57] [<7976ea6a>] pci_scan_child_bus+0x5a/0x230
[ 0.57] [<79894626>] ? dev_warn+0x36/0x50
[ 0.57] [<79894626>] ? dev_warn+0x36/0x50
[ 0.57] [<79a48cf5>] pci_acpi_scan_root+0x4c5/0x990
[ 0.57] [<79a48cf5>] pci_acpi_scan_root+0x4c5/0x990
[ 0.57] [<797c9be8>] acpi_pci_root_add+0x4fb/0x64d
[ 0.57] [<797c9be8>] acpi_pci_root_add+0x4fb/0x64d
[ 0.57] [<797be464>] ? acpi_scan_match_handler+0x9d/0x10e
[ 0.57] [<797be464>] ? acpi_scan_match_handler+0x9d/0x10e
[ 0.57] [<797c2a3d>] acpi_bus_attach+0x149/0x381
[ 0.57] [<797c2a3d>] acpi_bus_attach+0x149/0x381
[ 0.57] [<79bd0946>] ? mutex_unlock+0x16/0x30
[ 0.57] [<79bd0946>] ? mutex_unlock+0x16/0x30
[ 0.57] [<7989c2a0>] ? __driver_attach+0x140/0x140
[ 0.57] [<7989c2a0>] ? __driver_attach+0x140/0x140
[ 0.57] [<797c2be5>] acpi_bus_attach+0x2f1/0x381
[ 0.57] [<797c2be5>] acpi_bus_attach+0x2f1/0x381
[ 0.57] [<7989b94d>] ? device_attach+0x6d/0x120
[ 0.57] [<7989b94d>] ? device_attach+0x6d/0x120
[ 0.57] [<7989c2a0>] ? __driver_attach+0x140/0x140
[ 0.57] [<7989c2a0>] ? __driver_attach+0x140/0x140
[ 0.57] [<797c2be5>] acpi_bus_attach+0x2f1/0x381
[ 0.57] [<797c2be5>] acpi_bus_attach+0x2f1/0x381
[ 0.57] [<797c2d06>] acpi_bus_scan+0x91/0xa8
[ 0.57] [<797c2d06>] acpi_bus_scan+0x91/0xa8
[ 0.57] [<7a217b07>] acpi_scan_init+0x137/0x39d
[ 0.57] [<7a217b07>] acpi_scan_init+0x137/0x39d
[ 0.57] [<7a217695>] acpi_init+0x496/0x534
[ 0.57] [<7a217695>] acpi_init+0x496/0x534
[ 0.57] [<7a2171ff>] ? acpi_sleep_proc_init+0x5b/0x5b
[ 0.57] [<7a2171ff>] ? acpi_sleep_proc_init+0x5b/0x5b
[ 0.57] [<790005ae>] do_one_initcall+0x16e/0x3c0
[ 0.57] [<790005ae>] do_one_initcall+0x16e/0x3c0
[ 0.57] [<7a2171ff>] ? acpi_sleep_proc_init+0x5b/0x5b
[ 0.57] [<7a2171ff>] ? acpi_sleep_proc_init+0x5b/0x5b
[ 0.57] [<7a1b8afe>] kernel_init_freeable+0x263/0x3e4
[ 0.57] [<7a1b8afe>] kernel_init_freeable+0x263/0x3e4
[ 0.57] [<79bb7c49>] kernel_init+0x19/0x200
[ 0.57] [<79bb7c49>] kernel_init+0x19/0x200
[ 0.57] [<79bd5d01>] ret_from_kernel_thread+0x21/0x30
[ 0.57] [<79bd5d01>] ret_from_kernel_thread+0x21/0x30
[ 0.57] [<79bb7c30>] 

Re: [PATCH] capabilities: Ambient capability set V2

[Christoph Lameter]

On Thu, 5 Mar 2015, Andy Lutomirski wrote:

> > Yes due to the library issues.
>
> You can't LD_PRELOAD and fP together.  And I'm still unconvinced that
> ambient caps can ever be safe in conjunction with fP.  I'll grill you
> next week on what you're trying to do that makes you want this :)

>From the ld.so manpage:

LD_PRELOAD
  A whitespace-separated list of additional, user-specified, ELF 
shared
  libraries to be loaded before all others.  This can be used to 
selec‐
  tively override functions in other shared libraries.  For 
setuid/set‐
  gid ELF binaries, only libraries in the standard  search  
directories
  that are also setgid will be loaded.

So this mechanism has not been made to work for binaries with caps? We
have to keep using setuid?

Re: [PATCH RESEND 0/3] memory_hotplug: hyperv: fix deadlock between memory adding and onlining

[Michal Hocko]

[Sorry for the late response]

This is basically the same code posted by KY Srinivasan posted late last
year (http://marc.info/?l=linux-mm=141782228129426=2). I had
objections to the implementation
http://marc.info/?l=linux-mm=141805109216700=2

On Thu 12-02-15 11:23:51, Vitaly Kuznetsov wrote:
> RESEND (with no changes) because Rafael J. Wysocki was missing in recepients.
> 
> If newly added memory is brought online with e.g. udev rule:
> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}="online"
> the following deadlock is observed (and easily reproducable):
> 
> First participant, worker thread doing add_memory():
> 
> [  724.948846] kworker/0:1 D 88000412f9c8 1324827  2 
> 0x
> [  724.973543] Workqueue: events hot_add_req [hv_balloon]
> [  724.991736]  88000412f9c8  88003fa1dc30 
> 000151c0
> [  725.019725]  0246 88000412ffd8 000151c0 
> 88003a77a4e0
> [  725.046486]  88003fa1dc30 0001032a6000 88003a7ca838 
> 88003a7ca898
> [  725.072969] Call Trace:
> [  725.082690]  [] schedule_preempt_disabled+0x29/0x70
> [  725.103799]  [] mutex_lock_nested+0x14b/0x470
> [  725.122367]  [] ? device_attach+0x23/0xb0
> [  725.140992]  [] device_attach+0x23/0xb0
> [  725.159131]  [] bus_probe_device+0xb0/0xe0
> [  725.177055]  [] device_add+0x443/0x650
> [  725.195558]  [] device_register+0x1e/0x30
> [  725.213133]  [] init_memory_block+0xd0/0xf0
> [  725.231533]  [] register_new_memory+0xb1/0xd0
> [  725.250769]  [] __add_pages+0x13f/0x250
> [  725.269642]  [] ? arch_add_memory+0x70/0xf0
> [  725.288764]  [] arch_add_memory+0x70/0xf0
> [  725.306117]  [] add_memory+0xef/0x1f0
> [  725.322466]  [] hot_add_req+0x33f/0xf90 [hv_balloon]
> [  725.342777]  [] process_one_work+0x1df/0x4e0
> [  725.361459]  [] ? process_one_work+0x16d/0x4e0
> [  725.380390]  [] worker_thread+0x11b/0x450
> [  725.397684]  [] ? process_one_work+0x4e0/0x4e0
> [  725.416533]  [] kthread+0xf3/0x110
> [  725.433372]  [] ? kthread_create_on_node+0x240/0x240
> [  725.453749]  [] ret_from_fork+0x7c/0xb0
> [  725.470994]  [] ? kthread_create_on_node+0x240/0x240
> [  725.491469] 6 locks held by kworker/0:1/27:
> [  725.505037]  #0:  ("events"){..}, at: [] 
> process_one_work+0x16d/0x4e0
> [  725.533370]  #1:  ((_device.ha_wrk.wrk)){..}, at: 
> [] process_one_work+0x16d/0x4e0
> [  725.565580]  #2:  (mem_hotplug.lock){..}, at: [] 
> mem_hotplug_begin+0x5/0x80
> [  725.594369]  #3:  (mem_hotplug.lock#2){..}, at: [] 
> mem_hotplug_begin+0x4f/0x80
> [  725.628554]  #4:  (mem_sysfs_mutex){..}, at: [] 
> register_new_memory+0x33/0xd0
> [  725.658519]  #5:  (>mutex){..}, at: [] 
> device_attach+0x23/0xb0
> 
> Second participant, udev:
> 
> [  725.750889] systemd-udevd   D 88003b94fc68 14016   888530 
> 0x0004
> [  725.773767]  88003b94fc68  8800034949c0 
> 000151c0
> [  725.798332]  8210d980 88003b94ffd8 000151c0 
> 880037a69270
> [  725.822841]  8800034949c0 00010001 8800034949c0 
> 81ff2b48
> [  725.849184] Call Trace:
> [  725.858987]  [] schedule_preempt_disabled+0x29/0x70
> [  725.879231]  [] mutex_lock_nested+0x14b/0x470
> [  725.897860]  [] ? mem_hotplug_begin+0x4f/0x80
> [  725.916698]  [] mem_hotplug_begin+0x4f/0x80
> [  725.935064]  [] ? mem_hotplug_begin+0x5/0x80
> [  725.953464]  [] online_pages+0x3b/0x520
> [  725.971542]  [] ? device_online+0x23/0xa0
> [  725.989207]  [] memory_subsys_online+0x64/0xc0
> [  726.008513]  [] device_online+0x6d/0xa0
> [  726.025579]  [] store_mem_state+0x5b/0xe0
> [  726.043400]  [] dev_attr_store+0x18/0x30
> [  726.060506]  [] sysfs_kf_write+0x48/0x60
> [  726.077940]  [] kernfs_fop_write+0x13b/0x1a0
> [  726.099416]  [] vfs_write+0xb7/0x1f0
> [  726.115748]  [] SyS_write+0x58/0xd0
> [  726.131933]  [] system_call_fastpath+0x12/0x17
> [  726.150691] 7 locks held by systemd-udevd/888:
> [  726.165044]  #0:  (sb_writers#3){..}, at: [] 
> vfs_write+0x1b3/0x1f0
> [  726.192422]  #1:  (>mutex){..}, at: [] 
> kernfs_fop_write+0x66/0x1a0
> [  726.220289]  #2:  (s_active#60){..}, at: [] 
> kernfs_fop_write+0x6e/0x1a0
> [  726.249382]  #3:  (device_hotplug_lock){..}, at: [] 
> lock_device_hotplug_sysfs+0x15/0x50
> [  726.281901]  #4:  (>mutex){..}, at: [] 
> device_online+0x23/0xa0
> [  726.308619]  #5:  (mem_hotplug.lock){..}, at: [] 
> mem_hotplug_begin+0x5/0x80
> [  726.337994]  #6:  (mem_hotplug.lock#2){..}, at: [] 
> mem_hotplug_begin+0x4f/0x80
> 
> In short: onlining grabs device lock and then tries to do mem_hotplug_begin()
> while add_memory() is between mem_hotplug_begin() and mem_hotplug_done() and 
> it
> tries grabbing device lock.
> 
> To my understanding ACPI memory hotplug doesn't have the same issue as
> device_hotplug_lock is being grabbed when the ACPI device is added.
> 
> Solve the issue by grabbing device_hotplug_lock before doing add_memory(). If
> we do that, 

[RFC PATCH] spi: Ensure that CS line is in non-active state after setup

[Ivan T. Ivanov]

When drivers didn't provide setup() method, SPI core should ensure
that CS line is driven in non-active state after spi_setup().

Signed-off-by: Ivan T. Ivanov 
---
 drivers/spi/spi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index c64a3e5..bfba2d9 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1895,6 +1895,8 @@ int spi_setup(struct spi_device *spi)

if (spi->master->setup)
status = spi->master->setup(spi);
+   else
+   spi_set_cs(spi, false);

dev_dbg(>dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max --> 
%d\n",
(int) (spi->mode & (SPI_CPOL | SPI_CPHA)),
--
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 2/2] audit,x86: add x32_execve[at] to syscall classification

[David Drysdale]

Treat x32 ABI variants of execve[at] the same as x86_64
variants.

Slightly speculative as the audit subsystem doesn't currently
work with x32 ABI syscalls.  If and when audit+x32 does work,
this should correctly classify exec calls.

Signed-off-by: David Drysdale 
---
 arch/x86/kernel/audit_64.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/kernel/audit_64.c b/arch/x86/kernel/audit_64.c
index f3672508b249..0aec72d8d3c7 100644
--- a/arch/x86/kernel/audit_64.c
+++ b/arch/x86/kernel/audit_64.c
@@ -49,6 +49,12 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 2;
case __NR_openat:
return 3;
+#ifdef __NR_x32_execve
+   case __NR_x32_execve:
+#endif
+#ifdef __NR_x32_execveat
+   case __NR_x32_execveat:
+#endif
case __NR_execve:
case __NR_execveat:
return 5;
-- 
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] Input: elan_i2c - Compare signature metadata before update fw

[Duson Lin]

To match different firmware file format, we replace original firmware file size
checking with the signature metadata comparison when update firmware, If failed,
the update will be aborted.

Signed-off-by: Duson Lin 
---
 drivers/input/mouse/elan_i2c.h   |6 +++---
 drivers/input/mouse/elan_i2c_core.c  |   23 +--
 drivers/input/mouse/elan_i2c_i2c.c   |1 -
 drivers/input/mouse/elan_i2c_smbus.c |1 -
 4 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/input/mouse/elan_i2c.h b/drivers/input/mouse/elan_i2c.h
index 2e83862..e100c1b 100644
--- a/drivers/input/mouse/elan_i2c.h
+++ b/drivers/input/mouse/elan_i2c.h
@@ -4,7 +4,6 @@
  * Copyright (c) 2013 ELAN Microelectronics Corp.
  *
  * Author: 林政維 (Duson Lin) 
- * Version: 1.5.5
  *
  * Based on cyapa driver:
  * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
@@ -33,8 +32,9 @@
 #define ETP_FW_IAP_PAGE_ERR(1 << 5)
 #define ETP_FW_IAP_INTF_ERR(1 << 4)
 #define ETP_FW_PAGE_SIZE   64
-#define ETP_FW_PAGE_COUNT  768
-#define ETP_FW_SIZE(ETP_FW_PAGE_SIZE * ETP_FW_PAGE_COUNT)
+#define ETP_FW_VAILDPAGE_COUNT 768
+#define ETP_FW_SIGNATURE_SIZE  6
+#define ETP_FW_SIGNATURE_ADDRESS   0xBFFA
 
 struct i2c_client;
 struct completion;
diff --git a/drivers/input/mouse/elan_i2c_core.c 
b/drivers/input/mouse/elan_i2c_core.c
index 0cb2be4..16f9584 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -4,7 +4,7 @@
  * Copyright (c) 2013 ELAN Microelectronics Corp.
  *
  * Author: 林政維 (Duson Lin) 
- * Version: 1.5.5
+ * Version: 1.5.6
  *
  * Based on cyapa driver:
  * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
@@ -40,7 +40,7 @@
 #include "elan_i2c.h"
 
 #define DRIVER_NAME"elan_i2c"
-#define ELAN_DRIVER_VERSION"1.5.5"
+#define ELAN_DRIVER_VERSION"1.5.6"
 #define ETP_PRESSURE_OFFSET25
 #define ETP_MAX_PRESSURE   255
 #define ETP_FWIDTH_REDUCE  90
@@ -312,7 +312,7 @@ static int __elan_update_firmware(struct elan_tp_data *data,
iap_start_addr = get_unaligned_le16(>data[ETP_IAP_START_ADDR * 2]);
 
boot_page_count = (iap_start_addr * 2) / ETP_FW_PAGE_SIZE;
-   for (i = boot_page_count; i < ETP_FW_PAGE_COUNT; i++) {
+   for (i = boot_page_count; i < ETP_FW_VAILDPAGE_COUNT; i++) {
u16 checksum = 0;
const u8 *page = >data[i * ETP_FW_PAGE_SIZE];
 
@@ -434,10 +434,11 @@ static ssize_t elan_sysfs_update_fw(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
 {
-   struct i2c_client *client = to_i2c_client(dev);
-   struct elan_tp_data *data = i2c_get_clientdata(client);
+   struct elan_tp_data *data = dev_get_drvdata(dev);
const struct firmware *fw;
int error;
+   const u8 *fw_signature;
+   static const u8 signature[] = {0xAA, 0x55, 0xCC, 0x33, 0xFF, 0xFF};
 
error = request_firmware(, ETP_FW_NAME, dev);
if (error) {
@@ -446,10 +447,12 @@ static ssize_t elan_sysfs_update_fw(struct device *dev,
return error;
}
 
-   /* Firmware must be exactly PAGE_NUM * PAGE_SIZE bytes */
-   if (fw->size != ETP_FW_SIZE) {
-   dev_err(dev, "invalid firmware size = %zu, expected %d.\n",
-   fw->size, ETP_FW_SIZE);
+   /* Firmware file must match signature data */
+   fw_signature = >data[ETP_FW_SIGNATURE_ADDRESS];
+   if (memcmp(fw_signature, signature, sizeof(signature)) != 0) {
+   dev_err(dev, "signature mismatch (expected %*ph, got %*ph)\n",
+(int)sizeof(signature), signature,
+(int)sizeof(signature), fw_signature);
error = -EBADF;
goto out_release_fw;
}
@@ -464,7 +467,7 @@ static ssize_t elan_sysfs_update_fw(struct device *dev,
 
 out_release_fw:
release_firmware(fw);
-   return error ?: count;
+   return error?: count;
 }
 
 static ssize_t calibrate_store(struct device *dev,
diff --git a/drivers/input/mouse/elan_i2c_i2c.c 
b/drivers/input/mouse/elan_i2c_i2c.c
index 97d4937..029941f 100644
--- a/drivers/input/mouse/elan_i2c_i2c.c
+++ b/drivers/input/mouse/elan_i2c_i2c.c
@@ -4,7 +4,6 @@
  * Copyright (c) 2013 ELAN Microelectronics Corp.
  *
  * Author: 林政維 (Duson Lin) 
- * Version: 1.5.5
  *
  * Based on cyapa driver:
  * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
diff --git a/drivers/input/mouse/elan_i2c_smbus.c 
b/drivers/input/mouse/elan_i2c_smbus.c
index 359bf85..5cd4a05 100644
--- a/drivers/input/mouse/elan_i2c_smbus.c
+++ b/drivers/input/mouse/elan_i2c_smbus.c
@@ -4,7 +4,6 @@
  * Copyright (c) 2013 ELAN Microelectronics Corp.
  *
  * Author: 林政維 (Duson Lin) 
- * Version: 1.5.5
  *
  * Based on cyapa driver:
  * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
-- 
1.7.10.4

--
To unsubscribe from this list: send 

[PATCH 1/2] audit: add execveat to syscall classification

[David Drysdale]

New execveat syscall from v3.19 is missing from
audit_classify_compat_syscall().

Reported-by: Brian Gerst 
Signed-off-by: David Drysdale 
---
 lib/compat_audit.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/compat_audit.c b/lib/compat_audit.c
index 873f75b640ab..a49469f0511d 100644
--- a/lib/compat_audit.c
+++ b/lib/compat_audit.c
@@ -42,6 +42,9 @@ int audit_classify_compat_syscall(int abi, unsigned syscall)
case __NR_socketcall:
return 4;
 #endif
+#ifdef __NR_execveat
+   case __NR_execveat:
+#endif
case __NR_execve:
return 5;
default:
-- 
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 0/2] Update audit syscall classification for execve variants

[David Drysdale]

Add a couple of missing execve variants to the syscall
classification code in the audit system.

 - Patch 1 is potentially suitable for 3.19 stable.
 - Patch 2 need not be back-applied, as audit doesn't yet work
   with x32 syscalls in general.

David Drysdale (2):
  audit: add execveat to syscall classification
  audit,x86: add x32_execve[at] to syscall classification

 arch/x86/kernel/audit_64.c | 6 ++
 lib/compat_audit.c | 3 +++
 2 files changed, 9 insertions(+)

--
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: [Qemu-devel] [PATCH 02/21] userfaultfd: linux/Documentation/vm/userfaultfd.txt

[Eric Blake]

On 03/05/2015 10:17 AM, Andrea Arcangeli wrote:
> Add documentation.
> 
> Signed-off-by: Andrea Arcangeli 
> ---
>  Documentation/vm/userfaultfd.txt | 97 
> 
>  1 file changed, 97 insertions(+)
>  create mode 100644 Documentation/vm/userfaultfd.txt

Just a grammar review (no analysis of technical correctness)

> 
> diff --git a/Documentation/vm/userfaultfd.txt 
> b/Documentation/vm/userfaultfd.txt
> new file mode 100644
> index 000..2ec296c
> --- /dev/null
> +++ b/Documentation/vm/userfaultfd.txt
> @@ -0,0 +1,97 @@
> += Userfaultfd =
> +
> +== Objective ==
> +
> +Userfaults allow to implement on demand paging from userland and more

s/to implement/the implementation of/
and maybe: s/on demand/on-demand/

> +generally they allow userland to take control various memory page
> +faults, something otherwise only the kernel code could do.
> +
> +For example userfaults allows a proper and more optimal implementation
> +of the PROT_NONE+SIGSEGV trick.
> +
> +== Design ==
> +
> +Userfaults are delivered and resolved through the userfaultfd syscall.
> +
> +The userfaultfd (aside from registering and unregistering virtual
> +memory ranges) provides for two primary functionalities:

s/provides for/provides/

> +
> +1) read/POLLIN protocol to notify an userland thread of the faults

s/an userland/a userland/ (remember, 'a unicorn gets an umbrella' - if
the 'u' is pronounced 'you' the correct article is 'a')

> +   happening
> +
> +2) various UFFDIO_* ioctls that can mangle over the virtual memory
> +   regions registered in the userfaultfd that allows userland to
> +   efficiently resolve the userfaults it receives via 1) or to mangle
> +   the virtual memory in the background

maybe: s/mangle/manage/2

> +
> +The real advantage of userfaults if compared to regular virtual memory
> +management of mremap/mprotect is that the userfaults in all their
> +operations never involve heavyweight structures like vmas (in fact the
> +userfaultfd runtime load never takes the mmap_sem for writing).
> +
> +Vmas are not suitable for page(or hugepage)-granular fault tracking

s/page(or hugepage)-granular/page- (or hugepage-) granular/

> +when dealing with virtual address spaces that could span
> +Terabytes. Too many vmas would be needed for that.
> +
> +The userfaultfd once opened by invoking the syscall, can also be
> +passed using unix domain sockets to a manager process, so the same
> +manager process could handle the userfaults of a multitude of
> +different process without them being aware about what is going on

s/process/processes/

> +(well of course unless they later try to use the userfaultfd themself

s/themself/themselves/

> +on the same region the manager is already tracking, which is a corner
> +case that would currently return -EBUSY).
> +
> +== API ==
> +
> +When first opened the userfaultfd must be enabled invoking the
> +UFFDIO_API ioctl specifying an uffdio_api.api value set to UFFD_API

s/an uffdio/a uffdio/

> +which will specify the read/POLLIN protocol userland intends to speak
> +on the UFFD. The UFFDIO_API ioctl if successful (i.e. if the requested
> +uffdio_api.api is spoken also by the running kernel), will return into
> +uffdio_api.bits and uffdio_api.ioctls two 64bit bitmasks of
> +respectively the activated feature bits below PAGE_SHIFT in the
> +userfault addresses returned by read(2) and the generic ioctl
> +available.
> +
> +Once the userfaultfd has been enabled the UFFDIO_REGISTER ioctl should
> +be invoked (if present in the returned uffdio_api.ioctls bitmask) to
> +register a memory range in the userfaultfd by setting the
> +uffdio_register structure accordingly. The uffdio_register.mode
> +bitmask will specify to the kernel which kind of faults to track for
> +the range (UFFDIO_REGISTER_MODE_MISSING would track missing
> +pages). The UFFDIO_REGISTER ioctl will return the
> +uffdio_register.ioctls bitmask of ioctls that are suitable to resolve
> +userfaults on the range reigstered. Not all ioctls will necessarily be

s/reigstered/registered/

> +supported for all memory types depending on the underlying virtual
> +memory backend (anonymous memory vs tmpfs vs real filebacked
> +mappings).
> +
> +Userland can use the uffdio_register.ioctls to mangle the virtual

maybe s/mangle/manage/

> +address space in the background (to add or potentially also remove
> +memory from the userfaultfd registered range). This means an userfault

s/an/a/

> +could be triggering just before userland maps in the background the
> +user-faulted page. To avoid POLLIN resulting in an unexpected blocking
> +read (if the UFFD is not opened in nonblocking mode in the first
> +place), we don't allow the background thread to wake userfaults that
> +haven't been read by userland yet. If we would do that likely the
> +UFFDIO_WAKE ioctl could be dropped. This may change in the future
> +(with a UFFD_API protocol bumb combined with the removal of the

s/bumb/bump/

> +UFFDIO_WAKE ioctl) 

[GIT PULL] livepatching fix for 4.0-rc

[Jiri Kosina]

Linus,

please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching.git for-linus

to receive


- patch fixing a RCU unlock misplacement in live patching infrastructure,
  from Peter Zijlstra

Thanks.


Peter Zijlstra (1):
  livepatch: fix RCU usage in klp_find_external_symbol()

 kernel/livepatch/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
Jiri Kosina
SUSE Labs
--
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/1] x86/fpu: math_state_restore() should not blindly disable irqs

[Oleg Nesterov]

On 03/06, David Vrabel wrote:
>
> On 06/03/15 14:01, Oleg Nesterov wrote:
>
> > Not sure I understand it correctly after the first quick look, but
> >
> > 1. It conflicts with the recent changes in tip/x86/fpu
> >
> > 2. fpu_ini() initializes current->thread.fpu.state. This looks unneeded,
> >the kernel threads no longer have FPU context and do not abuse CPU.
> >
> > 3. I can be easily wrong, but it looks buggy... Note that
> >arch_dup_task_struct() doesn't allocate child->fpu.state if
> >!tsk_used_math(parent).
>
> ...yes. It's bit-rotted a bit.
>
> > No, I do not think this patch is a good idea. Perhaps I am wrong, but I
> > think we need other changes. And they should start from init_fpu().
>
> But the general principle of avoiding the allocation in the #NM handler
> and hence avoiding the need to re-enable IRQs is still a good idea, yes?

This needs more discussion, but in short so far I think that fpu_alloc()
from #NM exception is fine if user_mode(regs) == T.

Just do_device_not_available() should simply do conditional_sti(), I think.
Perhaps it can even enable irqs unconditionally, but we need to verify that
this is 100% correct.

And I agree that "if (!tsk_used_math(tsk))" code in math_state_restore()
should be removed. But not to avoid the allocation, and this needs other
changes.

Oleg.

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

Reply back to me

[Catherine Peng]

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

Re: [PATCH v2 1/2] livepatch/module: Apply patch when loaded module is unformed

[Petr Mladek]

On Fri 2015-03-06 08:54:23, Josh Poimboeuf wrote:
> On Fri, Mar 06, 2015 at 03:00:13PM +0100, Petr Mladek wrote:
> > This brings me back to the original idea with that boolean that
> > marks the state before and after the coming notifier (module_init).
> > We could use a bitfield instead of the two booleans when requested.
> 
> Yeah, that would work.  Though I think one boolean is enough?
> 
> For example, just have a mod->klp_live which is initialized to false,
> with its value set in the COMING notifier, and cleared in the GOING
> notifier.

Great optimization. I will use it.

> > Alternative solutions:
> > 
> > + reject new patches when a module is coming; this is ugly
> > 
> > + wait with adding new patch until the module leaves the COMING state;
> > this might be dangerous or complicated; we would need to leave
> > kgr_lock in the middle of the patch registration to avoid a deadlock
> > with klp_module_init(); also we might need a waitqueue for each module
> > which seems to be even bigger overhead than the two booleans
> > 
> > + always register/enable new patches and fix up the potential mess
> > (registered patches order) in klp_module_init(); This is nasty and
> > prone to regressions in the future development;
> > 
> > + add another MODULE_STATE where the kallsyms are visible but the
> > module is not used yet; this looks to complex; the module states are
> > checked on "many" locations
> > 
> > 
> > I will wait with v3 over the weekend. I hope that it will bring fresh
> > mind. Sigh, if I could have slept more with the baby twins.
> 
> Good luck!  In my experience, an entire weekend with babies is far from
> restful ;-)

Yeah, you are right :-)

Thanks for review and hint.

Best Regards,
Petr
--
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/1] staging: rtl8723au: Remove unnecessary OOM message

[Julia Lawall]

On Fri, 6 Mar 2015, Jes Sorensen wrote:

> Quentin Lambert  writes:
> > This patch reduces the kernel size by removing error messages that duplicate
> > the normal OOM message.
> >
> > A simplified version of the semantic patch that finds this problem is as
> > follows: (http://coccinelle.lip6.fr)
>
> This patch removes useful warnings about what allocation failed. The
> messages removed are NOT duplicate!

Is it really the case that the information can't be reconstructed from the
information generated by kmalloc on failure?  To my understanding there is
a stack trace, and from scanning through the changes I see only one change
per function, so perhaps the stack trace already makes it clear where the
problem occurred?

julia

>
> NACK
>
> Jes
>
> >
> > @@
> > identifier f,print,l;
> > expression e;
> > constant char[] c;
> > @@
> >
> > e = \(kzalloc\|kmalloc\|devm_kzalloc\|devm_kmalloc\)(...);
> > if (e == NULL) {
> >   <+...
> > -  print(...,c,...);
> >   ... when any
> > (
> >   goto l;
> > |
> >   return ...;
> > )
> >   ...+> }
> >
> > Signed-off-by: Quentin Lambert 
> > ---
> >  drivers/staging/rtl8723au/hal/rtl8723a_cmd.c  | 8 ++--
> >  drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 8 ++--
> >  drivers/staging/rtl8723au/hal/usb_ops_linux.c | 6 +-
> >  drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c | 5 -
> >  4 files changed, 5 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c 
> > b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> > index 7b56411..38f5b7f 100644
> > --- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> > +++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> > @@ -462,10 +462,8 @@ static void SetFwRsvdPagePkt(struct rtw_adapter 
> > *padapter, bool bDLFinished)
> > DBG_8723A("%s\n", __func__);
> >
> > ReservedPagePacket = kzalloc(1000, GFP_KERNEL);
> > -   if (ReservedPagePacket == NULL) {
> > -   DBG_8723A("%s: alloc ReservedPagePacket fail!\n", __func__);
> > +   if (ReservedPagePacket == NULL)
> > return;
> > -   }
> >
> > pHalData = GET_HAL_DATA(padapter);
> > pxmitpriv = >xmitpriv;
> > @@ -669,10 +667,8 @@ static void SetFwRsvdPagePkt_BTCoex(struct rtw_adapter 
> > *padapter)
> > DBG_8723A("+%s\n", __func__);
> >
> > ReservedPagePacket = kzalloc(1024, GFP_KERNEL);
> > -   if (ReservedPagePacket == NULL) {
> > -   DBG_8723A("%s: alloc ReservedPagePacket fail!\n", __func__);
> > +   if (ReservedPagePacket == NULL)
> > return;
> > -   }
> >
> > pHalData = GET_HAL_DATA(padapter);
> > pxmitpriv = >xmitpriv;
> > diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c 
> > b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> > index a5eadd4..6d50b09 100644
> > --- a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> > +++ b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> > @@ -401,10 +401,8 @@ hal_ReadEFuse_WiFi(struct rtw_adapter *padapter,
> > }
> >
> > efuseTbl = kmalloc(EFUSE_MAP_LEN_8723A, GFP_KERNEL);
> > -   if (efuseTbl == NULL) {
> > -   DBG_8723A("%s: alloc efuseTbl fail!\n", __func__);
> > +   if (efuseTbl == NULL)
> > return;
> > -   }
> > /*  0xff will be efuse default value instead of 0x00. */
> > memset(efuseTbl, 0xFF, EFUSE_MAP_LEN_8723A);
> >
> > @@ -494,10 +492,8 @@ hal_ReadEFuse_BT(struct rtw_adapter *padapter,
> > }
> >
> > efuseTbl = kmalloc(EFUSE_BT_MAP_LEN, GFP_KERNEL);
> > -   if (efuseTbl == NULL) {
> > -   DBG_8723A("%s: efuseTbl malloc fail!\n", __func__);
> > +   if (efuseTbl == NULL)
> > return;
> > -   }
> > /*  0xff will be efuse default value instead of 0x00. */
> > memset(efuseTbl, 0xFF, EFUSE_BT_MAP_LEN);
> >
> > diff --git a/drivers/staging/rtl8723au/hal/usb_ops_linux.c 
> > b/drivers/staging/rtl8723au/hal/usb_ops_linux.c
> > index a6d16ad..f1e9202 100644
> > --- a/drivers/staging/rtl8723au/hal/usb_ops_linux.c
> > +++ b/drivers/staging/rtl8723au/hal/usb_ops_linux.c
> > @@ -256,12 +256,8 @@ static void usb_read_interrupt_complete(struct urb 
> > *purb)
> > c2w = kmalloc(sizeof(struct evt_work),
> > GFP_ATOMIC);
> >
> > -   if (!c2w) {
> > -   printk(KERN_WARNING "%s: unable to "
> > -  "allocate work buffer\n",
> > -  __func__);
> > +   if (!c2w)
> > goto urb_submit;
> > -   }
> >
> > c2w->adapter = padapter;
> > INIT_WORK(>work, rtw_evt_work);
> > diff --git a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c 
> > b/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
> > index 537bd82..40bdf4b 100644
> > --- a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
> > +++ 

[PATCH] ASoC: jz4740: Add jz4780 support

[Zubair Lutfullah Kakakhel]

The jz4780 and jz4740 have very similar i2s blocks.

The slight difference is in Rx/Tx fifos.
And the bitclocks for input/output are different.

This patch adds jz4780 support to the driver

Signed-off-by: Zubair Lutfullah Kakakhel 

---
Patch based on 4.0-rc2
Tested on the MIPS Creator CI20.
---
 .../bindings/sound/ingenic,jz4740-i2s.txt  |  2 +-
 sound/soc/jz4740/jz4740-i2s.c  | 63 ++
 2 files changed, 54 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/ingenic,jz4740-i2s.txt 
b/Documentation/devicetree/bindings/sound/ingenic,jz4740-i2s.txt
index b414333..b623d50 100644
--- a/Documentation/devicetree/bindings/sound/ingenic,jz4740-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/ingenic,jz4740-i2s.txt
@@ -1,7 +1,7 @@
 Ingenic JZ4740 I2S controller
 
 Required properties:
-- compatible : "ingenic,jz4740-i2s"
+- compatible : "ingenic,jz4740-i2s" or "ingenic,jz4780-i2s"
 - reg : I2S registers location and length
 - clocks : AIC and I2S PLL clock specifiers.
 - clock-names: "aic" and "i2s"
diff --git a/sound/soc/jz4740/jz4740-i2s.c b/sound/soc/jz4740/jz4740-i2s.c
index 07f7781..630ea96 100644
--- a/sound/soc/jz4740/jz4740-i2s.c
+++ b/sound/soc/jz4740/jz4740-i2s.c
@@ -58,6 +58,12 @@
 
 #define JZ_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET 12
 #define JZ_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET 8
+#define JZ4780_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET 24
+#define JZ4780_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET 16
+#define JZ4780_AIC_CONF_FIFO_RX_THRESHOLD_MASK \
+   (0xf << JZ4780_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET)
+#define JZ4780_AIC_CONF_FIFO_TX_THRESHOLD_MASK \
+   (0x1f <<  JZ4780_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET)
 
 #define JZ_AIC_CTRL_OUTPUT_SAMPLE_SIZE_MASK (0x7 << 19)
 #define JZ_AIC_CTRL_INPUT_SAMPLE_SIZE_MASK (0x7 << 16)
@@ -79,6 +85,7 @@
 #define JZ_AIC_CTRL_INPUT_SAMPLE_SIZE_OFFSET  16
 
 #define JZ_AIC_I2S_FMT_DISABLE_BIT_CLK BIT(12)
+#define JZ_AIC_I2S_FMT_DISABLE_BIT_ICLK BIT(13)
 #define JZ_AIC_I2S_FMT_ENABLE_SYS_CLK BIT(4)
 #define JZ_AIC_I2S_FMT_MSB BIT(0)
 
@@ -87,6 +94,13 @@
 #define JZ_AIC_CLK_DIV_MASK 0xf
 #define I2SDIV_DV_SHIFT 8
 #define I2SDIV_DV_MASK (0xf << I2SDIV_DV_SHIFT)
+#define I2SDIV_IDV_SHIFT 8
+#define I2SDIV_IDV_MASK (0xf << I2SDIV_IDV_SHIFT)
+
+enum jz47xx_i2s_version {
+   JZ_I2S_JZ4740,
+   JZ_I2S_JZ4780,
+};
 
 struct jz4740_i2s {
struct resource *mem;
@@ -98,6 +112,8 @@ struct jz4740_i2s {
 
struct snd_dmaengine_dai_dma_data playback_dma_data;
struct snd_dmaengine_dai_dma_data capture_dma_data;
+
+   enum jz47xx_i2s_version version;
 };
 
 static inline uint32_t jz4740_i2s_read(const struct jz4740_i2s *i2s,
@@ -267,13 +283,22 @@ static int jz4740_i2s_hw_params(struct snd_pcm_substream 
*substream,
ctrl |= JZ_AIC_CTRL_MONO_TO_STEREO;
else
ctrl &= ~JZ_AIC_CTRL_MONO_TO_STEREO;
+
+   div_reg &= ~I2SDIV_DV_MASK;
+   div_reg |= (div - 1) << I2SDIV_DV_SHIFT;
} else {
ctrl &= ~JZ_AIC_CTRL_INPUT_SAMPLE_SIZE_MASK;
ctrl |= sample_size << JZ_AIC_CTRL_INPUT_SAMPLE_SIZE_OFFSET;
+
+   if (i2s->version >= JZ_I2S_JZ4780) {
+   div_reg &= ~I2SDIV_IDV_MASK;
+   div_reg |= (div - 1) << I2SDIV_IDV_SHIFT;
+   } else {
+   div_reg &= ~I2SDIV_DV_MASK;
+   div_reg |= (div - 1) << I2SDIV_DV_SHIFT;
+   }
}
 
-   div_reg &= ~I2SDIV_DV_MASK;
-   div_reg |= (div - 1) << I2SDIV_DV_SHIFT;
jz4740_i2s_write(i2s, JZ_REG_AIC_CTRL, ctrl);
jz4740_i2s_write(i2s, JZ_REG_AIC_CLK_DIV, div_reg);
 
@@ -369,11 +394,19 @@ static int jz4740_i2s_dai_probe(struct snd_soc_dai *dai)
snd_soc_dai_init_dma_data(dai, >playback_dma_data,
>capture_dma_data);
 
-   conf = (7 << JZ_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET) |
-   (8 << JZ_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET) |
-   JZ_AIC_CONF_OVERFLOW_PLAY_LAST |
-   JZ_AIC_CONF_I2S |
-   JZ_AIC_CONF_INTERNAL_CODEC;
+   if (i2s->version >= JZ_I2S_JZ4780) {
+   conf = (7 << JZ4780_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET) |
+   (8 << JZ4780_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET) |
+   JZ_AIC_CONF_OVERFLOW_PLAY_LAST |
+   JZ_AIC_CONF_I2S |
+   JZ_AIC_CONF_INTERNAL_CODEC;
+   } else {
+   conf = (7 << JZ_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET) |
+   (8 << JZ_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET) |
+   JZ_AIC_CONF_OVERFLOW_PLAY_LAST |
+   JZ_AIC_CONF_I2S |
+   JZ_AIC_CONF_INTERNAL_CODEC;
+   }
 
jz4740_i2s_write(i2s, JZ_REG_AIC_CONF, JZ_AIC_CONF_RESET);
jz4740_i2s_write(i2s, JZ_REG_AIC_CONF, conf);
@@ -428,7 +461,8 @@ 

[GIT PULL] sound fixes for 4.0-rc3

[Takashi Iwai]

Linus,

please pull sound fixes for v4.0-rc3 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
tags/sound-4.0-rc3

The topmost commit is 4fda87df09bee2b1bf236aba408c3236d4f1fbca



sound fixes for 4.0-rc3

In this pull request, there are a few more ASoC changes that have been
gathered since rc1, but it's still fairly calm over all.  The only
largish LOC is found in atmel driver, and it's just a removal of
broken non-DT stuff.  The rest are all small driver-specific fixes,
nothing to worry much.



Alexandre Belloni (1):
  ASoC: sam9g20_wm8731: drop machine_is_xxx

Arnd Bergmann (2):
  ASoC: Samsung: add missing I2C/SPI dependencies
  ASoC: cirrus: tlv320aic23 needs I2C

Bard Liao (2):
  ASoC: rt5670: Fix the speaker mono output issue
  ASoC: rt5670: Set RT5670_IRQ_CTRL1 non volatile

Dan Carpenter (2):
  ALSA: msnd: add some missing curly braces
  ALSA: opl3: small array underflow

Guenter Roeck (1):
  ASoC: Fix MAX98357A codec driver dependencies

Hui Wang (1):
  ALSA: hda - One more Dell macine needs DELL1_MIC_NO_PRESENCE quirk

Kenneth Westfield (1):
  ASoC: max98357a: Add missing header files

Kiran Padwal (1):
  ASoC: omap-hdmi-audio: Add missing error check for devm_kzalloc

Kuninori Morimoto (1):
  ASoC: rsnd: set device data before snd_soc_register_platform/component

Mengdong Lin (1):
  ASoC: Intel: set initial runtime PM status to active for ACPI-enumerated 
ADSP

Nicolin Chen (1):
  ASoC: fsl_ssi: Fix the incorrect limitation of the bit clock rate

Oder Chiou (1):
  ASoC: rt5677: Correct the routing paths of that after IF1/2 DACx Mux

Peter Ujfalusi (1):
  ASoC: omap-pcm: Correct dma mask

Takashi Iwai (1):
  ALSA: line6: Clamp values correctly

Takashi Sakamoto (2):
  ALSA: oxfw: fix a condition and return code in start_stream()
  ALSA: dice: fix wrong offsets for Dice interface

Thomas Niederprüm (2):
  ASoC: sta32x: fix register range in regmap.
  ASoC: OMAP: mcbsp: Fix CLKX and CLKR pinmux when used as inputs

Vincent Stehlé (1):
  ASoC: max98357a: Fix missing include

Vinod Koul (3):
  ASoC: Intel: update MMX ID to 3
  ASoC: Intel: save and restore the CSR register
  ASoC: Intel: reset the DSP while suspending

Vishal Thanki (1):
  ASoC: simple-card: Add a NULL pointer check in 
asoc_simple_card_dai_link_of

---
 sound/drivers/opl3/opl3_midi.c   |  2 ++
 sound/firewire/dice/dice-interface.h | 18 +-
 sound/firewire/dice/dice-proc.c  |  4 +--
 sound/firewire/oxfw/oxfw-stream.c|  5 +--
 sound/isa/msnd/msnd_pinnacle_mixer.c |  3 +-
 sound/pci/hda/patch_realtek.c|  7 
 sound/soc/atmel/sam9g20_wm8731.c | 68 
 sound/soc/cirrus/Kconfig |  2 +-
 sound/soc/codecs/Kconfig |  2 +-
 sound/soc/codecs/max98357a.c | 12 ++-
 sound/soc/codecs/rt5670.c|  7 +++-
 sound/soc/codecs/rt5677.c| 32 -
 sound/soc/codecs/sta32x.c|  6 ++--
 sound/soc/fsl/fsl_ssi.c  | 11 +++---
 sound/soc/generic/simple-card.c  |  5 +++
 sound/soc/intel/sst-atom-controls.h  |  2 +-
 sound/soc/intel/sst/sst.c| 10 +-
 sound/soc/omap/omap-hdmi-audio.c |  3 ++
 sound/soc/omap/omap-mcbsp.c  | 11 ++
 sound/soc/omap/omap-pcm.c|  2 +-
 sound/soc/samsung/Kconfig| 10 +++---
 sound/soc/sh/rcar/core.c |  4 +--
 sound/usb/line6/playback.c   |  6 ++--
 23 files changed, 140 insertions(+), 92 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/

Re: [PATCH 1/1] staging: rtl8723au: Remove unnecessary OOM message

[Jes Sorensen]

Quentin Lambert  writes:
> This patch reduces the kernel size by removing error messages that duplicate
> the normal OOM message.
>
> A simplified version of the semantic patch that finds this problem is as
> follows: (http://coccinelle.lip6.fr)

This patch removes useful warnings about what allocation failed. The
messages removed are NOT duplicate!

NACK

Jes

>
> @@
> identifier f,print,l;
> expression e;
> constant char[] c;
> @@
>
> e = \(kzalloc\|kmalloc\|devm_kzalloc\|devm_kmalloc\)(...);
> if (e == NULL) {
>   <+...
> -  print(...,c,...);
>   ... when any
> (
>   goto l;
> |
>   return ...;
> )
>   ...+> }
>
> Signed-off-by: Quentin Lambert 
> ---
>  drivers/staging/rtl8723au/hal/rtl8723a_cmd.c  | 8 ++--
>  drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 8 ++--
>  drivers/staging/rtl8723au/hal/usb_ops_linux.c | 6 +-
>  drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c | 5 -
>  4 files changed, 5 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c 
> b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> index 7b56411..38f5b7f 100644
> --- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> +++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> @@ -462,10 +462,8 @@ static void SetFwRsvdPagePkt(struct rtw_adapter 
> *padapter, bool bDLFinished)
>   DBG_8723A("%s\n", __func__);
>  
>   ReservedPagePacket = kzalloc(1000, GFP_KERNEL);
> - if (ReservedPagePacket == NULL) {
> - DBG_8723A("%s: alloc ReservedPagePacket fail!\n", __func__);
> + if (ReservedPagePacket == NULL)
>   return;
> - }
>  
>   pHalData = GET_HAL_DATA(padapter);
>   pxmitpriv = >xmitpriv;
> @@ -669,10 +667,8 @@ static void SetFwRsvdPagePkt_BTCoex(struct rtw_adapter 
> *padapter)
>   DBG_8723A("+%s\n", __func__);
>  
>   ReservedPagePacket = kzalloc(1024, GFP_KERNEL);
> - if (ReservedPagePacket == NULL) {
> - DBG_8723A("%s: alloc ReservedPagePacket fail!\n", __func__);
> + if (ReservedPagePacket == NULL)
>   return;
> - }
>  
>   pHalData = GET_HAL_DATA(padapter);
>   pxmitpriv = >xmitpriv;
> diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c 
> b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> index a5eadd4..6d50b09 100644
> --- a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> +++ b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> @@ -401,10 +401,8 @@ hal_ReadEFuse_WiFi(struct rtw_adapter *padapter,
>   }
>  
>   efuseTbl = kmalloc(EFUSE_MAP_LEN_8723A, GFP_KERNEL);
> - if (efuseTbl == NULL) {
> - DBG_8723A("%s: alloc efuseTbl fail!\n", __func__);
> + if (efuseTbl == NULL)
>   return;
> - }
>   /*  0xff will be efuse default value instead of 0x00. */
>   memset(efuseTbl, 0xFF, EFUSE_MAP_LEN_8723A);
>  
> @@ -494,10 +492,8 @@ hal_ReadEFuse_BT(struct rtw_adapter *padapter,
>   }
>  
>   efuseTbl = kmalloc(EFUSE_BT_MAP_LEN, GFP_KERNEL);
> - if (efuseTbl == NULL) {
> - DBG_8723A("%s: efuseTbl malloc fail!\n", __func__);
> + if (efuseTbl == NULL)
>   return;
> - }
>   /*  0xff will be efuse default value instead of 0x00. */
>   memset(efuseTbl, 0xFF, EFUSE_BT_MAP_LEN);
>  
> diff --git a/drivers/staging/rtl8723au/hal/usb_ops_linux.c 
> b/drivers/staging/rtl8723au/hal/usb_ops_linux.c
> index a6d16ad..f1e9202 100644
> --- a/drivers/staging/rtl8723au/hal/usb_ops_linux.c
> +++ b/drivers/staging/rtl8723au/hal/usb_ops_linux.c
> @@ -256,12 +256,8 @@ static void usb_read_interrupt_complete(struct urb *purb)
>   c2w = kmalloc(sizeof(struct evt_work),
>   GFP_ATOMIC);
>  
> - if (!c2w) {
> - printk(KERN_WARNING "%s: unable to "
> -"allocate work buffer\n",
> -__func__);
> + if (!c2w)
>   goto urb_submit;
> - }
>  
>   c2w->adapter = padapter;
>   INIT_WORK(>work, rtw_evt_work);
> diff --git a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c 
> b/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
> index 537bd82..40bdf4b 100644
> --- a/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
> +++ b/drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c
> @@ -1327,8 +1327,6 @@ static int rtw_cfg80211_set_probe_req_wpsp2pie(struct 
> rtw_adapter *padapter,
>   pmlmepriv->wps_probe_req_ie = kmemdup(wps_ie, wps_ie[1],
> GFP_KERNEL);
>   if (pmlmepriv->wps_probe_req_ie == NULL) {
> - DBG_8723A("%s()-%d: kmalloc() ERROR!\n",
> -   __func__, __LINE__);
>  

[PATCH 2/2] spi: qup: Request CS GPIO's during probe

[Ivan T. Ivanov]

Ensure that driver is owner of the GPIO's used for CS signals.

Signed-off-by: Ivan T. Ivanov 
---
 drivers/spi/spi-qup.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 2b2c359..a07ba46 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -14,11 +14,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -499,7 +501,7 @@ static int spi_qup_probe(struct platform_device *pdev)
struct device *dev;
void __iomem *base;
u32 max_freq, iomode, num_cs;
-   int ret, irq, size;
+   int ret, irq, size, cs, cs_gpio;

dev = >dev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -556,6 +558,19 @@ static int spi_qup_probe(struct platform_device *pdev)
else
master->num_chipselect = num_cs;

+   for (cs = 0; cs < master->num_chipselect; cs++) {
+   cs_gpio = of_get_named_gpio(dev->of_node, "cs-gpios", cs);
+
+   if (!gpio_is_valid(cs_gpio))
+   continue;
+
+   ret = devm_gpio_request(>dev, cs_gpio, "spi-qup-cs");
+   if (ret) {
+   dev_err(>dev, "can't get cs gpios\n");
+   goto error;
+   }
+   }
+
master->bus_num = pdev->id;
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LOOP;
master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
--
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] spi: qup: Fix cs-num DT property parsing

[Ivan T. Ivanov]

num-cs is 32 bit property, don't read just upper 16 bits.

Fixes: 4a8573abe965 "spi: qup: Remove chip select function"
Signed-off-by: Ivan T. Ivanov 
---
 drivers/spi/spi-qup.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index ff9cdbd..2b2c359 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -498,7 +498,7 @@ static int spi_qup_probe(struct platform_device *pdev)
struct resource *res;
struct device *dev;
void __iomem *base;
-   u32 max_freq, iomode;
+   u32 max_freq, iomode, num_cs;
int ret, irq, size;

dev = >dev;
@@ -550,10 +550,11 @@ static int spi_qup_probe(struct platform_device *pdev)
}

/* use num-cs unless not present or out of range */
-   if (of_property_read_u16(dev->of_node, "num-cs",
-   >num_chipselect) ||
-   (master->num_chipselect > SPI_NUM_CHIPSELECTS))
+   if (of_property_read_u32(dev->of_node, "num-cs", _cs) ||
+   num_cs > SPI_NUM_CHIPSELECTS)
master->num_chipselect = SPI_NUM_CHIPSELECTS;
+   else
+   master->num_chipselect = num_cs;

master->bus_num = pdev->id;
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LOOP;
--
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 net-next v4 0/3] Linn Ethernet Packet Sniffer driver

[Richard Cochran]

BTW I am getting doubles of your messages, both addressed to the
mailings lists, but only one also addressed to me.  You should just
send one copy, with everyone on CC.

Thanks,
Richard
--
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 v4 0/3] Linn Ethernet Packet Sniffer driver

[Richard Cochran]

On Fri, Mar 06, 2015 at 10:50:08AM +, Stathis Voukelatos wrote:
> Although the PTP way appears to be the best from an architectural point
> of view, we have some questions as whether it is suitable for the audio
> use cases that this module is mainly intended for.
> To use the PTP terminology in a large installation we would have a
> potentially large number of clock domains.
> It is not clear how to easily manage the creation and allocation of
> domains. In addition the clock will be pulled according to the audio
> stream and it would be undesirable for other unrelated PTPv2 devices
> on the network to join the clock domain and have their clocks
> synchronized to it.

I don't really know what the problem here is.  Yes, there is some
networking configuration that you need to do when administering a
network using PTP protocols.  But these protocols (1588 aka PTP, and
802.1AS aka gPTP) do offer means for dealing with this.  In
particular, there is no danger mixing 1588 devices with audio devices,
because the gPTP protocol uses a different transport flag.

In any case, this has nothing at all to do with the kernel interface.
 
> The patch in its current form would allow a move to Linux using our
> existing synchronization protocols (which are open-source). A move
> to PTP is something to consider but will involve a fair amount of
> redesign including upgrade of legacy products.

If you want to try and integrate your custom protocols into the
networking stack, by all means please post them.  I would certainly
support expanding the time stamping interface to include your
protocol's packet types (like adding them to hwtstamp_rx_filters).
Maybe that would be enough for you?

Thanks,
Richard
--
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] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.

[Konrad Rzeszutek Wilk]

. snip..

> Format: { ,force,,} is suitable I think.
> And fixing  "force" is follow the code design previously in 
> setup_io_tlb_npages.

It is a bug. It should have been smart enough to deal with the 'force' being
in any order.

If you are willing to make a patch to fix this - either folded into this
patch I am responding to or as a seperate one - that would be most excellent!

However, I can also do it - but my plate is full so it will take me some time
to get to it.
--
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 RESEND] serial: omap_serial: document missing properties and add an example

[Matt Porter]

The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.

Signed-off-by: Matt Porter 
---
 .../devicetree/bindings/serial/omap_serial.txt   | 20 
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
 - compatible : should be "ti,omap2-uart" for OMAP2 controllers
 - compatible : should be "ti,omap3-uart" for OMAP3 controllers
 - compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+  specifier or both the interrupt
+  controller phandle and interrupt
+  specifier.
 - ti,hwmods : Must be "uart", n being the instance number (1-based)
 
 Optional properties:
 - clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : "rx" for receive channel, "tx" for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = "ti,omap3-uart";
+reg = <0x49042000 0x400>;
+interrupts = <80>;
+dmas = < 81  82>;
+dma-names = "tx", "rx";
+ti,hwmods = "uart4";
+clock-frequency = <4800>;
+};
-- 
1.8.4

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

[PATCH v2 02/11] clk: convert clock gate to accept regmap

[Antoine Tenart]

Rework the clk_gate helpers to either use an iomem base address or a
regmap.

Signed-off-by: Antoine Tenart 
---
 drivers/clk/clk-gate.c   | 94 +---
 include/linux/clk-provider.h | 12 --
 2 files changed, 80 insertions(+), 26 deletions(-)

diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 3f0e4200cb5d..d62732f5b417 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -50,15 +51,18 @@ static void clk_gate_endisable(struct clk_hw *hw, int 
enable)
 
set ^= enable;
 
-   if (gate->lock)
-   spin_lock_irqsave(gate->lock, flags);
+   if (gate->reg_type == CLK_REG_TYPE_IOMEM && gate->reg.lock)
+   spin_lock_irqsave(gate->reg.lock, flags);
 
if (gate->flags & CLK_GATE_HIWORD_MASK) {
reg = BIT(gate->bit_idx + 16);
if (set)
reg |= BIT(gate->bit_idx);
} else {
-   reg = clk_readl(gate->reg);
+   if (gate->reg_type == CLK_REG_TYPE_IOMEM)
+   reg = clk_readl(gate->reg.iomem);
+   else
+   regmap_read(gate->reg.regmap, gate->reg.offset, );
 
if (set)
reg |= BIT(gate->bit_idx);
@@ -66,10 +70,13 @@ static void clk_gate_endisable(struct clk_hw *hw, int 
enable)
reg &= ~BIT(gate->bit_idx);
}
 
-   clk_writel(reg, gate->reg);
+   if (gate->reg_type == CLK_REG_TYPE_IOMEM)
+   clk_writel(reg, gate->reg.iomem);
+   else
+   regmap_write(gate->reg.regmap, gate->reg.offset, reg);
 
-   if (gate->lock)
-   spin_unlock_irqrestore(gate->lock, flags);
+   if (gate->reg_type == CLK_REG_TYPE_IOMEM && gate->reg.lock)
+   spin_unlock_irqrestore(gate->reg.lock, flags);
 }
 
 static int clk_gate_enable(struct clk_hw *hw)
@@ -89,7 +96,10 @@ static int clk_gate_is_enabled(struct clk_hw *hw)
u32 reg;
struct clk_gate *gate = to_clk_gate(hw);
 
-   reg = clk_readl(gate->reg);
+   if (gate->reg_type == CLK_REG_TYPE_IOMEM)
+   reg = clk_readl(gate->reg.iomem);
+   else
+   regmap_read(gate->reg.regmap, gate->reg.offset, );
 
/* if a set bit disables this clk, flip it before masking */
if (gate->flags & CLK_GATE_SET_TO_DISABLE)
@@ -107,21 +117,10 @@ const struct clk_ops clk_gate_ops = {
 };
 EXPORT_SYMBOL_GPL(clk_gate_ops);
 
-/**
- * clk_register_gate - register a gate clock with the clock framework
- * @dev: device that is registering this clock
- * @name: name of this clock
- * @parent_name: name of this clock's parent
- * @flags: framework-specific flags for this clock
- * @reg: register address to control gating of this clock
- * @bit_idx: which bit in the register controls gating of this clock
- * @clk_gate_flags: gate-specific flags for this clock
- * @lock: shared register lock for this clock
- */
-struct clk *clk_register_gate(struct device *dev, const char *name,
+struct clk *__clk_register_gate(struct device *dev, const char *name,
const char *parent_name, unsigned long flags,
-   void __iomem *reg, u8 bit_idx,
-   u8 clk_gate_flags, spinlock_t *lock)
+   union clk_reg reg, enum clk_reg_type type, u8 bit_idx,
+   u8 clk_gate_flags)
 {
struct clk_gate *gate;
struct clk *clk;
@@ -149,9 +148,9 @@ struct clk *clk_register_gate(struct device *dev, const 
char *name,
 
/* struct clk_gate assignments */
gate->reg = reg;
+   gate->reg_type = type;
gate->bit_idx = bit_idx;
gate->flags = clk_gate_flags;
-   gate->lock = lock;
gate->hw.init = 
 
clk = clk_register(dev, >hw);
@@ -161,8 +160,59 @@ struct clk *clk_register_gate(struct device *dev, const 
char *name,
 
return clk;
 }
+
+/**
+ * clk_register_gate - register a gate clock with the clock framework
+ * @dev: device that is registering this clock
+ * @name: name of this clock
+ * @parent_name: name of this clock's parent
+ * @flags: framework-specific flags for this clock
+ * @reg: register address to control gating of this clock
+ * @bit_idx: which bit in the register controls gating of this clock
+ * @clk_gate_flags: gate-specific flags for this clock
+ * @lock: shared register lock for this clock
+ */
+struct clk *clk_register_gate(struct device *dev, const char *name,
+   const char *parent_name, unsigned long flags,
+   void __iomem *reg, u8 bit_idx,
+   u8 clk_gate_flags, spinlock_t *lock)
+{
+   union clk_reg clk_reg;
+
+   clk_reg.iomem = reg;
+   clk_reg.lock = lock;
+
+   return __clk_register_gate(dev, name, parent_name, flags, clk_reg,
+  CLK_REG_TYPE_IOMEM, bit_idx, clk_gate_flags);
+}
 

[PATCH v2 04/11] Documentation: bindings: move the Berlin clock documentation

[Antoine Tenart]

The Berlin clock documentation was part of the Marvell Berlin SoC
documentation because the Berlin clock configuration was inside the
chip controller. With the recent rework of the chip and system
controller handling (now all sub-devices of the soc and system
controller nodes are registred with simple-mfd, and each device has its
own sub-node), the documentation of the Berlin clock driver can be moved
to the generic clock documentation directory.

Signed-off-by: Antoine Tenart 
---
 .../devicetree/bindings/arm/marvell,berlin.txt | 27 +++
 .../devicetree/bindings/clock/marvell,berlin.txt   | 31 ++
 2 files changed, 35 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/marvell,berlin.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt 
b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
index ece73c6ad973..4a8ff8e14cb7 100644
--- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -75,37 +75,18 @@ Required properties:
"simple-mfd", "syscon"
 - reg: address and length of the system control register set
 
-* Clock provider binding
-
-As clock related registers are spread among the chip control registers, the
-chip control node also provides the clocks. Marvell Berlin2 (BG2, BG2CD, BG2Q)
-SoCs share the same IP for PLLs and clocks, with some minor differences in
-features and register layout.
-
-Required properties:
-- #clock-cells: shall be set to 1
-- clocks: clock specifiers referencing the core clock input clocks
-- clock-names: array of strings describing the input clock specifiers above.
-Allowed clock-names for the reference clocks are
-  "refclk" for the SoCs osciallator input on all SoCs,
-and SoC-specific input clocks for
-  BG2/BG2CD: "video_ext0" for the external video clock input
-
-Clocks provided by core clocks shall be referenced by a clock specifier
-indexing one of the provided clocks. Refer to dt-bindings/clock/berlin.h
-for the corresponding index mapping.
-
 Example:
 
 chip: chip-control@ea {
compatible = "marvell,berlin2-chip-ctrl", "simple-mfd", "syscon";
-   #clock-cells = <1>;
reg = <0xea 0x400>;
-   clocks = <>, < 0>;
-   clock-names = "refclk", "video_ext0";
+
+   /* sub-device nodes */
 };
 
 sysctrl: system-controller@d000 {
compatible = "marvell,berlin2-system-ctrl", "simple-mfd", "syscon";
reg = <0xd000 0x100>;
+
+   /* sub-device nodes */
 };
diff --git a/Documentation/devicetree/bindings/clock/marvell,berlin.txt 
b/Documentation/devicetree/bindings/clock/marvell,berlin.txt
new file mode 100644
index ..c611c495f3ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,berlin.txt
@@ -0,0 +1,31 @@
+Device Tree Clock bindings for Marvell Berlin
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Clock related registers are spread among the chip control registers. Berlin
+clock node should be a sub-node of the chip controller node. Marvell Berlin2
+(BG2, BG2CD, BG2Q) SoCs share the same IP for PLLs and clocks, with some
+minor differences in features and register layout.
+
+Required properties:
+- compatible: must be "marvell,berlin2-clk" or "marvell,berlin2q-clk"
+- #clock-cells: must be 1
+- clocks: must be the input parent clock phandle
+- clock-names: name of the input parent clock
+   Allowed clock-names for the reference clocks are
+   "refclk" for the SoCs oscillator input on all SoCs,
+   and SoC-specific input clocks for
+   BG2/BG2CD: "video_ext0" for the external video clock input
+
+
+Example:
+
+chip_clk: clock {
+   compatible = "marvell,berlin2q-clk";
+
+   #clock-cells = <1>;
+   clocks = <>;
+   clock-names = "refclk";
+};
-- 
2.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 v2 07/11] ARM: berlin: rework the clock node for BG2Q

[Antoine Tenart]

With the introduction of the Berlin mfd controller driver, all drivers
previously sharing the chip and system controller nodes now have their
own sub-node.

Signed-off-by: Antoine Tenart 
---
 arch/arm/boot/dts/berlin2q.dtsi | 53 ++---
 1 file changed, 29 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 006d382d44ff..9000eb2ebc45 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -74,7 +74,7 @@
sdhci0: sdhci@ab {
compatible = "mrvl,pxav3-mmc";
reg = <0xab 0x200>;
-   clocks = < CLKID_SDIO1XIN>;
+   clocks = <_clk CLKID_SDIO1XIN>;
interrupts = ;
status = "disabled";
};
@@ -82,7 +82,7 @@
sdhci1: sdhci@ab0800 {
compatible = "mrvl,pxav3-mmc";
reg = <0xab0800 0x200>;
-   clocks = < CLKID_SDIO1XIN>;
+   clocks = <_clk CLKID_SDIO1XIN>;
interrupts = ;
status = "disabled";
};
@@ -91,7 +91,7 @@
compatible = "mrvl,pxav3-mmc";
reg = <0xab1000 0x200>;
interrupts = ;
-   clocks = < CLKID_NFC_ECC>, < CLKID_NFC>;
+   clocks = <_clk CLKID_NFC_ECC>, <_clk 
CLKID_NFC>;
clock-names = "io", "core";
status = "disabled";
};
@@ -112,7 +112,7 @@
local-timer@ad0600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0xad0600 0x20>;
-   clocks = < CLKID_TWD>;
+   clocks = <_clk CLKID_TWD>;
interrupts = ;
};
 
@@ -135,7 +135,7 @@
compatible = "chipidea,usb2";
reg = <0xa3 0x1>;
interrupts = ;
-   clocks = < CLKID_USB2>;
+   clocks = <_clk CLKID_USB2>;
phys = <_phy2>;
phy-names = "usb-phy";
status = "disabled";
@@ -153,14 +153,14 @@
compatible = "marvell,berlin2-usb-phy";
reg = <0xb78000 0x128>;
#phy-cells = <0>;
-   resets = < 0x104 13>;
+   resets = <_rst 0x104 13>;
status = "disabled";
};
 
eth0: ethernet@b9 {
compatible = "marvell,pxa168-eth";
reg = <0xb9 0x1>;
-   clocks = < CLKID_GETH0>;
+   clocks = <_clk CLKID_GETH0>;
interrupts = ;
/* set by bootloader */
local-mac-address = [00 00 00 00 00 00];
@@ -267,7 +267,7 @@
reg = <0x1400 0x100>;
interrupt-parent = <>;
interrupts = <4>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
pinctrl-0 = <_pmux>;
pinctrl-names = "default";
status = "disabled";
@@ -280,7 +280,7 @@
reg = <0x1800 0x100>;
interrupt-parent = <>;
interrupts = <5>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
pinctrl-0 = <_pmux>;
pinctrl-names = "default";
status = "disabled";
@@ -289,7 +289,7 @@
timer0: timer@2c00 {
compatible = "snps,dw-apb-timer";
reg = <0x2c00 0x14>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
interrupts = <8>;
};
@@ -297,14 +297,14 @@
timer1: timer@2c14 {
compatible = "snps,dw-apb-timer";
reg = <0x2c14 0x14>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
};
 
timer2: timer@2c28 {
compatible = "snps,dw-apb-timer";

[GIT PULL] Power management and ACPI fixes for 4.0-rc3

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm+acpi-4.0-rc3

to receive power management and ACPI fixes for v4.0-rc1 with top-most
commit e178e7d6df38dab67f51df4282927c4c7392879f

 Merge branches 'pm-domains' and 'pm-cpufreq'

on top of commit 13a7a6ac0a11197edcd0f756a035f472b42cdf8b

 Linux 4.0-rc2

These are fixes for recent regressions (ACPI resources management,
suspend-to-idle), stable-candidate fixes (ACPI backlight), fixes
related to the wakeup IRQ management changes made in v3.18, other
fixes (suspend-to-idle, cpufreq ppc driver) and a couple of cleanups
(suspend-to-idle, generic power domains, ACPI backlight).

Specifics:

 - Fix ACPI resources management problems introduced by the recent
   rework of the code in question (Jiang Liu) and a build issue
   introduced by those changes (Joachim Nilsson).

 - Fix a recent suspend-to-idle regression on systems where entering
   idle states causes local timers to stop, prevent suspend-to-idle
   from crashing in restricted configurations (no cpuidle driver,
   cpuidle disabled etc.) and clean up the idle loop somewhat while
   at it (Rafael J Wysocki).

 - Fix build problem in the cpufreq ppc driver (Geert Uytterhoeven).

 - Allow the ACPI backlight driver module to be loaded if ACPI is
   disabled which helps the i915 driver in those configurations
   (stable-candidate) and change the code to help debug unusual use
   cases (Chris Wilson).

 - Wakeup IRQ management changes in v3.18 caused some drivers on the
   at91 platform to trigger a warning from the IRQ core related to
   an unexpected combination of interrupt action handler flags.
   However, on at91 a timer IRQ is shared with some other devices
   (including system wakeup ones) and that leads to the unusual
   combination of flags in question.  To make it possible to avoid
   the warning introduce a new interrupt action handler flag (which
   can be used by drivers to indicate the special case to the core)
   and rework the problematic at91 drivers to use it and work as
   expected during system suspend/resume.  From Boris Brezillon,
   Rafael J Wysocki and Mark Rutland.

 - Clean up the generic power domains subsystem's debugfs interface
   (Kevin Hilman).

Thanks!


---

Boris BREZILLON (6):
  PM / wakeup: export pm_system_wakeup symbol
  rtc: at91sam9: rework wakeup and interrupt handling
  rtc: at91rm9200: rework wakeup and interrupt handling
  clk: at91: implement suspend/resume for the PMC irqchip
  watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND
  tty: serial: atmel: rework interrupt and wakeup handling

Chris Wilson (2):
  ACPI / video: Load the module even if ACPI is disabled
  ACPI / video: Propagate the error code for acpi_video_register

Geert Uytterhoeven (1):
  cpufreq: ppc: Add missing #include 

Jiang Liu (2):
  x86/PCI/ACPI: Ignore resources consumed by host bridge itself
  x86/PCI/ACPI: Relax ACPI resource descriptor checks to work
around BIOS bugs

Joachim Nilsson (1):
  PCI: versatile: Update for list_for_each_entry() API change

Kevin Hilman (1):
  PM / Domains: cleanup: rename gpd -> genpd in debugfs interface

Mark Rutland (2):
  genirq / PM: better describe IRQF_NO_SUSPEND semantics
  genirq / PM: describe IRQF_COND_SUSPEND

Rafael J. Wysocki (5):
  idle / sleep: Avoid excessive disabling and enabling interrupts
  cpuidle / sleep: Do sanity checks in cpuidle_enter_freeze() too
  cpuidle: Clean up fallback handling in cpuidle_idle_call()
  genirq / PM: Add flag for shared NO_SUSPEND interrupt lines
  cpuidle / sleep: Use broadcast timer for states that stop local timer

---

 Documentation/power/suspend-and-interrupts.txt | 22 ++--
 arch/x86/pci/acpi.c| 11 ++--
 drivers/acpi/resource.c|  4 +-
 drivers/acpi/video.c   | 20 +--
 drivers/base/power/domain.c| 24 -
 drivers/base/power/wakeup.c|  1 +
 drivers/clk/at91/pmc.c | 20 ++-
 drivers/clk/at91/pmc.h |  1 +
 drivers/cpufreq/ppc-corenet-cpufreq.c  |  2 +
 drivers/cpuidle/cpuidle.c  | 61 +
 drivers/pci/host/pci-versatile.c   |  2 +-
 drivers/rtc/rtc-at91rm9200.c   | 62 +-
 drivers/rtc/rtc-at91sam9.c | 73 +-
 drivers/tty/serial/atmel_serial.c  | 49 +++--
 drivers/watchdog/at91sam9_wdt.c|  3 +-
 include/linux/cpuidle.h| 17 +-
 include/linux/interrupt.h  |  9 +++-
 include/linux/irqdesc.h|  1 +
 kernel/irq/manage.c|  7 ++-
 kernel/irq/pm.c|  7 ++-
 kernel/sched/idle.c   

Re: [PATCH 0/4] cleancache: remove limit on the number of cleancache enabled filesystems

[Konrad Rzeszutek Wilk]

On Thu, Mar 05, 2015 at 07:46:36PM +0300, Vladimir Davydov wrote:
> On Wed, Mar 04, 2015 at 04:22:30PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 24, 2015 at 01:34:06PM +0300, Vladimir Davydov wrote:
> > > On Mon, Feb 23, 2015 at 11:12:22AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > Thank you for posting these patches. I was wondering if you had
> > > > run through some of the different combinations that you can
> > > > load the filesystems/tmem drivers in random order? The #4 patch
> > > > deleted a nice chunk of documentation that outlines the different
> > > > combinations.
> > > 
> > > Yeah, I admit the synchronization between cleancache_register_ops and
> > > cleancache_init_fs is far not obvious. I should have updated the comment
> > > instead of merely dropping it, sorry. What about the following patch
> > > proving correctness of register_ops-vs-init_fs synchronization? It is
> > > meant to be applied incrementally on top of patch #4.
> > 
> > Just fold it in please. But more importantly - I was wondering if you
> > had run throught the different combinations it outlines?
> 
> Ah, you mean testing - I misunderstood you at first, sorry.
> 
> Of course, I checked that a cleancache backend module works fine no
> matter if it is loaded before or after a filesystem is mounted. However,
> I used our own cleancache driver for testing (we are trying to use
> cleancache for containers).
> 
> To be 100% sure that I did not occasionally break anything, today I
> installed XenServer on my test machine, enabled tmem both in dom0 and
> domU, and ran through all possible sequences of tmem load vs fs
> mount/use/unmount described in the old comment.

Wow!

Well then, I think this patchset is ready to go then!

Would you be willing to fold in the description in the patch #4 and repost it?

Andrew - are you OK picking it up or would you prefer me as the maintainer
to feed it to Linus? [either option is fine with me]

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

[PATCH v2 1/1] sunrpc/cache: simplify qword_add

[Andy Shevchenko]

The commit 7572d3b29896 (lib/string_helpers.c: change semantics of
string_escape_mem) updates qword_add() to follow the changes in
lib/string_helpers.c. This patch simplifies the approach.

Signed-off-by: Andy Shevchenko 
---
Andrew, I think this one can be folded in the mentioned commit by Rasmus.
Changelog v2:
- add missed curly braces (grr... I have them in initial comment)

 net/sunrpc/cache.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
index 22c4418..ba815df 100644
--- a/net/sunrpc/cache.c
+++ b/net/sunrpc/cache.c
@@ -1068,16 +1068,16 @@ void qword_add(char **bpp, int *lp, char *str)
 {
char *bp = *bpp;
int len = *lp;
-   int ret, written;
+   int ret;
 
if (len < 0) return;
 
ret = string_escape_str(str, bp, len, ESCAPE_OCTAL, "\\ \n\t");
-   written = min(ret, len);
-   bp += written;
-   if (ret >= len)
+   if (ret >= len) {
+   bp += len;
len = -1;
-   else {
+   } else {
+   bp += ret;
len -= ret;
*bp++ = ' ';
len--;
-- 
2.1.4

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

[PATCH v2 00/11] ARM: berlin: refactor the clock

[Antoine Tenart]

Marvell Berlin SoCs have a chip control register set providing several
individual registers dealing with various controllers (pinctrl, reset,
clk). This chip controller is described by a single DT node since the
individual registers are spread among the chip control register bank.

Marvell Berlin also have a system control register set providing several
individual registers for pinctrl or adc.

A series was sent[1] to correctly handle these two nodes, by using
simple-mfd. The series converted the existing pin-controller and reset
drivers to take the changes into account.

Because the Berlin clock driver was still working with the above
modification, Berlin clock reworks were not included into the previous
series. Also the clock reworks change some of the clock framework
functions, so having a dedicated series helps.

This series aims to convert the Berlin clock driver to use the proper
way of dealing with the chip and system controller on Berlin SoCs. To do
this changes were done in the clk-mux and clk-gate helpers so they can
handle regmaps alongside iomem addresses.

This series has been tested on the Marvell Berlin BG2Q DMP.

This series is based on v4.0-rc1 and [1].

Thanks!

Antoine

[1] https://lkml.org/lkml/2015/3/6/511

Changes since v1:
- Rebased of top of the new version of [1].
- Removed now useless chip and system ctrl compatibles.

Antoine Tenart (11):
  clk: convert clock mux to accept regmap
  clk: convert clock gate to accept regmap
  clk: berlin: use regmap
  Documentation: bindings: move the Berlin clock documentation
  ARM: berlin: rework the clock node for BG2
  ARM: berlin: rework the clock node for BG2CD
  ARM: berlin: rework the clock node for BG2Q
  Documentation: bindings: update the berlin chip and system ctrl doc
  ARM: berlin: remove useless chip and system ctrl compatibles in BG2
  ARM: berlin: remove useless chip and system ctrl compatibles in BG2CD
  ARM: berlin: remove useless chip and system ctrl compatibles in BG2Q

 .../devicetree/bindings/arm/marvell,berlin.txt |  43 ++--
 .../devicetree/bindings/clock/marvell,berlin.txt   |  31 ++
 arch/arm/boot/dts/berlin2.dtsi |  47 +
 arch/arm/boot/dts/berlin2cd.dtsi   |  43 
 arch/arm/boot/dts/berlin2q.dtsi|  57 ++-
 drivers/clk/berlin/berlin2-avpll.c |  72 +++--
 drivers/clk/berlin/berlin2-avpll.h |  13 ++-
 drivers/clk/berlin/berlin2-div.c   |  82 +--
 drivers/clk/berlin/berlin2-div.h   |   4 +-
 drivers/clk/berlin/berlin2-pll.c   |  16 +--
 drivers/clk/berlin/berlin2-pll.h   |   7 +-
 drivers/clk/berlin/bg2.c   | 112 +++--
 drivers/clk/berlin/bg2q.c  |  64 +++-
 drivers/clk/clk-gate.c |  94 +
 drivers/clk/clk-mux.c  |  72 +++--
 include/linux/clk-provider.h   |  51 --
 16 files changed, 481 insertions(+), 327 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/marvell,berlin.txt

-- 
2.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 v2 11/11] ARM: berlin: remove useless chip and system ctrl compatibles in BG2Q

[Antoine Tenart]

Now that the rework to have one sub-node per device in the chip and
system controllers is done, their dedicated compatible can be removed.

Signed-off-by: Antoine Tenart 
---
 arch/arm/boot/dts/berlin2q.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 9000eb2ebc45..187d056f7ad2 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -360,7 +360,7 @@
};
 
chip: chip-controller@ea {
-   compatible = "marvell,berlin2q-chip-ctrl", 
"simple-mfd", "syscon";
+   compatible = "simple-mfd", "syscon";
reg = <0xea 0x400>, <0xdd0170 0x10>;
 
chip_clk: clock {
@@ -539,7 +539,7 @@
};
 
sysctrl: system-controller@d000 {
-   compatible = "marvell,berlin2q-system-ctrl", 
"simple-mfd", "syscon";
+   compatible = "simple-mfd", "syscon";
reg = <0xd000 0x100>;
 
sys_pinctrl: pin-controller {
-- 
2.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 v2 06/11] ARM: berlin: rework the clock node for BG2CD

[Antoine Tenart]

With the introduction of the Berlin mfd controller driver, all drivers
previously sharing the chip and system controller nodes now have their
own sub-node.

Signed-off-by: Antoine Tenart 
---
 arch/arm/boot/dts/berlin2cd.dtsi | 39 ++-
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 4bca01ee94d6..240bfe24ae83 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -53,7 +53,7 @@
sdhci0: sdhci@ab {
compatible = "mrvl,pxav3-mmc";
reg = <0xab 0x200>;
-   clocks = < CLKID_SDIO0XIN>, < CLKID_SDIO0>;
+   clocks = <_clk CLKID_SDIO0XIN>, <_clk 
CLKID_SDIO0>;
clock-names = "io", "core";
interrupts = ;
status = "disabled";
@@ -77,7 +77,7 @@
compatible = "arm,cortex-a9-twd-timer";
reg = <0xad0600 0x20>;
interrupts = ;
-   clocks = < CLKID_TWD>;
+   clocks = <_clk CLKID_TWD>;
};
 
usb_phy0: usb-phy@b74000 {
@@ -99,7 +99,7 @@
eth1: ethernet@b9 {
compatible = "marvell,pxa168-eth";
reg = <0xb9 0x1>;
-   clocks = < CLKID_GETH1>;
+   clocks = <_clk CLKID_GETH1>;
interrupts = ;
/* set by bootloader */
local-mac-address = [00 00 00 00 00 00];
@@ -117,7 +117,7 @@
eth0: ethernet@e5 {
compatible = "marvell,pxa168-eth";
reg = <0xe5 0x1>;
-   clocks = < CLKID_GETH0>;
+   clocks = <_clk CLKID_GETH0>;
interrupts = ;
/* set by bootloader */
local-mac-address = [00 00 00 00 00 00];
@@ -216,7 +216,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c00 0x14>;
interrupts = <8>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
status = "okay";
};
@@ -225,7 +225,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c14 0x14>;
interrupts = <9>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
status = "okay";
};
@@ -234,7 +234,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c28 0x14>;
interrupts = <10>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
status = "disabled";
};
@@ -243,7 +243,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c3c 0x14>;
interrupts = <11>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
status = "disabled";
};
@@ -252,7 +252,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c50 0x14>;
interrupts = <12>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
status = "disabled";
};
@@ -261,7 +261,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c64 0x14>;
interrupts = <13>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
status = "disabled";
};
@@ -270,7 +270,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c78 0x14>;
interrupts = <14>;
-   clocks = < 

[PATCH v2 03/11] clk: berlin: use regmap

[Antoine Tenart]

The Berlin clock driver was sharing a DT node with the pin controller
and the reset driver. All these device are now a sub-node of the chip
and system controllers and a regmap is available thanks to syscon to
access the registers safely.

Rework the Berlin clock driver to use the regmap provided by syscon.

Signed-off-by: Antoine Tenart 
---
 drivers/clk/berlin/berlin2-avpll.c |  72 +---
 drivers/clk/berlin/berlin2-avpll.h |  13 +++--
 drivers/clk/berlin/berlin2-div.c   |  82 +--
 drivers/clk/berlin/berlin2-div.h   |   4 +-
 drivers/clk/berlin/berlin2-pll.c   |  16 --
 drivers/clk/berlin/berlin2-pll.h   |   7 ++-
 drivers/clk/berlin/bg2.c   | 112 +++--
 drivers/clk/berlin/bg2q.c  |  64 +
 8 files changed, 188 insertions(+), 182 deletions(-)

diff --git a/drivers/clk/berlin/berlin2-avpll.c 
b/drivers/clk/berlin/berlin2-avpll.c
index fd0f26c38465..7244afb2251f 100644
--- a/drivers/clk/berlin/berlin2-avpll.c
+++ b/drivers/clk/berlin/berlin2-avpll.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "berlin2-avpll.h"
@@ -115,7 +116,8 @@
 
 struct berlin2_avpll_vco {
struct clk_hw hw;
-   void __iomem *base;
+   struct regmap *regmap;
+   unsigned int offset;
u8 flags;
 };
 
@@ -126,7 +128,7 @@ static int berlin2_avpll_vco_is_enabled(struct clk_hw *hw)
struct berlin2_avpll_vco *vco = to_avpll_vco(hw);
u32 reg;
 
-   reg = readl_relaxed(vco->base + VCO_CTRL0);
+   regmap_read(vco->regmap, vco->offset + VCO_CTRL0, );
if (vco->flags & BERLIN2_AVPLL_BIT_QUIRK)
reg >>= 4;
 
@@ -138,12 +140,12 @@ static int berlin2_avpll_vco_enable(struct clk_hw *hw)
struct berlin2_avpll_vco *vco = to_avpll_vco(hw);
u32 reg;
 
-   reg = readl_relaxed(vco->base + VCO_CTRL0);
+   regmap_read(vco->regmap, vco->offset + VCO_CTRL0, );
if (vco->flags & BERLIN2_AVPLL_BIT_QUIRK)
reg |= VCO_POWERUP << 4;
else
reg |= VCO_POWERUP;
-   writel_relaxed(reg, vco->base + VCO_CTRL0);
+   regmap_write(vco->regmap, vco->offset + VCO_CTRL0, reg);
 
return 0;
 }
@@ -153,12 +155,12 @@ static void berlin2_avpll_vco_disable(struct clk_hw *hw)
struct berlin2_avpll_vco *vco = to_avpll_vco(hw);
u32 reg;
 
-   reg = readl_relaxed(vco->base + VCO_CTRL0);
+   regmap_read(vco->regmap, vco->offset + VCO_CTRL0, );
if (vco->flags & BERLIN2_AVPLL_BIT_QUIRK)
reg &= ~(VCO_POWERUP << 4);
else
reg &= ~VCO_POWERUP;
-   writel_relaxed(reg, vco->base + VCO_CTRL0);
+   regmap_write(vco->regmap, vco->offset + VCO_CTRL0, reg);
 }
 
 static u8 vco_refdiv[] = { 1, 2, 4, 3 };
@@ -171,7 +173,7 @@ berlin2_avpll_vco_recalc_rate(struct clk_hw *hw, unsigned 
long parent_rate)
u64 freq = parent_rate;
 
/* AVPLL VCO frequency: Fvco = (Fref / refdiv) * fbdiv */
-   reg = readl_relaxed(vco->base + VCO_CTRL1);
+   regmap_read(vco->regmap, vco->offset + VCO_CTRL1, );
refdiv = (reg & VCO_REFDIV_MASK) >> VCO_REFDIV_SHIFT;
refdiv = vco_refdiv[refdiv];
fbdiv = (reg & VCO_FBDIV_MASK) >> VCO_FBDIV_SHIFT;
@@ -188,9 +190,10 @@ static const struct clk_ops berlin2_avpll_vco_ops = {
.recalc_rate= berlin2_avpll_vco_recalc_rate,
 };
 
-struct clk * __init berlin2_avpll_vco_register(void __iomem *base,
-  const char *name, const char *parent_name,
-  u8 vco_flags, unsigned long flags)
+struct clk * __init berlin2_avpll_vco_register(struct regmap *regmap,
+  unsigned int offset, const char *name,
+  const char *parent_name, u8 vco_flags,
+  unsigned long flags)
 {
struct berlin2_avpll_vco *vco;
struct clk_init_data init;
@@ -199,7 +202,8 @@ struct clk * __init berlin2_avpll_vco_register(void __iomem 
*base,
if (!vco)
return ERR_PTR(-ENOMEM);
 
-   vco->base = base;
+   vco->regmap = regmap;
+   vco->offset = offset;
vco->flags = vco_flags;
vco->hw.init = 
init.name = name;
@@ -213,7 +217,8 @@ struct clk * __init berlin2_avpll_vco_register(void __iomem 
*base,
 
 struct berlin2_avpll_channel {
struct clk_hw hw;
-   void __iomem *base;
+   struct regmap *regmap;
+   unsigned int offset;
u8 flags;
u8 index;
 };
@@ -228,7 +233,7 @@ static int berlin2_avpll_channel_is_enabled(struct clk_hw 
*hw)
if (ch->index == 7)
return 1;
 
-   reg = readl_relaxed(ch->base + VCO_CTRL10);
+   regmap_read(ch->regmap, ch->offset + VCO_CTRL10, );
reg &= VCO_POWERUP_CH1 << ch->index;
 
return !!reg;
@@ -239,9 +244,9 @@ static int berlin2_avpll_channel_enable(struct clk_hw *hw)

[PATCH v2 10/11] ARM: berlin: remove useless chip and system ctrl compatibles in BG2CD

[Antoine Tenart]

Now that the rework to have one sub-node per device in the chip and
system controllers is done, their dedicated compatible can be removed.

Signed-off-by: Antoine Tenart 
---
 arch/arm/boot/dts/berlin2cd.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 240bfe24ae83..7dff8497606b 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -295,7 +295,7 @@
};
 
chip: chip-controller@ea {
-   compatible = "marvell,berlin2cd-chip-ctrl", 
"simple-mfd", "syscon";
+   compatible = "simple-mfd", "syscon";
reg = <0xea 0x400>;
 
chip_clk: clock {
@@ -402,7 +402,7 @@
};
 
sysctrl: system-controller@d000 {
-   compatible = "marvell,berlin2cd-system-ctrl", 
"simple-mfd", "syscon";
+   compatible = "simple-mfd", "syscon";
reg = <0xd000 0x100>;
 
sys_pinctrl: pin-controller {
-- 
2.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 v2 08/11] Documentation: bindings: update the berlin chip and system ctrl doc

[Antoine Tenart]

Now that the rework to have one sub-node per device in the chip and
system controllers is done, their dedicated compatible can be removed.

Signed-off-by: Antoine Tenart 
---
 Documentation/devicetree/bindings/arm/marvell,berlin.txt | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt 
b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
index 4a8ff8e14cb7..b76838ab4f51 100644
--- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -50,11 +50,7 @@ different functions which are described below.
 
 Required properties:
 - compatible:
-   * the first value should be one of:
-   "marvell,berlin2-chip-ctrl" for BG2
-   "marvell,berlin2cd-chip-ctrl" for BG2CD
-   "marvell,berlin2q-chip-ctrl" for BG2Q
-   * the second and third values must be:
+   * the first and second values must be:
"simple-mfd", "syscon"
 - reg: address and length of following register sets for
   BG2/BG2CD: chip control register set
@@ -67,25 +63,21 @@ individual registers dealing with pinmux, padmux, and reset.
 
 Required properties:
 - compatible:
-   * the first value should be one of:
-   "marvell,berlin2-system-ctrl" for BG2
-   "marvell,berlin2cd-system-ctrl" for BG2CD
-   "marvell,berlin2q-system-ctrl" for BG2Q
-   * the second and third values must be:
+   * the first and second values must be:
"simple-mfd", "syscon"
 - reg: address and length of the system control register set
 
 Example:
 
 chip: chip-control@ea {
-   compatible = "marvell,berlin2-chip-ctrl", "simple-mfd", "syscon";
+   compatible = "simple-mfd", "syscon";
reg = <0xea 0x400>;
 
/* sub-device nodes */
 };
 
 sysctrl: system-controller@d000 {
-   compatible = "marvell,berlin2-system-ctrl", "simple-mfd", "syscon";
+   compatible = "simple-mfd", "syscon";
reg = <0xd000 0x100>;
 
/* sub-device nodes */
-- 
2.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] pwm: imx-pwm: add explicit compatible strings and required clock properties

[Rob Herring]

On Fri, Mar 6, 2015 at 9:09 AM, Matt Porter  wrote:
> The imx-pwm binding contains language indicating compatible
> strings to be used that is not valid for all supported parts
> e.g. Should be "fsl,-pwm". Fix this by enumerating the
> valid compatible strings that represent the two versions of
> this peripheral in use.
>
> The binding is also missing the clocks/clock-names properties
> so document these,the two required ipg and per clocks, and add
> add these properties to the example.
>
> Signed-off-by: Matt Porter 
> ---
>  Documentation/devicetree/bindings/pwm/imx-pwm.txt | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt 
> b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> index b50d7a6d..30d2b82 100644
> --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> @@ -1,10 +1,16 @@
>  Freescale i.MX PWM controller
>
>  Required properties:
> -- compatible: should be "fsl,-pwm"
> +- compatible :
> +  - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
> +  - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27

This should be one of these and a more specific value as the example
below shows.

Rob

>  - reg: physical base address and length of the controller's registers
>  - #pwm-cells: should be 2. See pwm.txt in this directory for a description of
>the cells format.
> +- clocks : Clock specifiers for both ipg and per clocks.
> +- clock-names : Clock names should include both "ipg" and "per"
> +See the clock consumer binding,
> +   Documentation/devicetree/bindings/clock/clock-bindings.txt
>  - interrupts: The interrupt for the pwm controller
>
>  Example:
> @@ -13,5 +19,8 @@ pwm1: pwm@53fb4000 {
> #pwm-cells = <2>;
> compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
> reg = <0x53fb4000 0x4000>;
> +   clocks = < IMX5_CLK_PWM1_IPG_GATE>,
> +< IMX5_CLK_PWM1_HF_GATE>;
> +   clock-names = "ipg", "per";
> interrupts = <61>;
>  };
> --
> 1.8.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 05/11] ARM: berlin: rework the clock node for BG2

[Antoine Tenart]

With the introduction of the Berlin mfd controller driver, all drivers
previously sharing the chip and system controller nodes now have their
own sub-node.

Signed-off-by: Antoine Tenart 
---
 arch/arm/boot/dts/berlin2.dtsi | 43 +++---
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index fbe5c6b6502d..0cbe99da16dc 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -56,7 +56,7 @@
sdhci0: sdhci@ab {
compatible = "mrvl,pxav3-mmc";
reg = <0xab 0x200>;
-   clocks = < CLKID_SDIO0XIN>, < CLKID_SDIO0>;
+   clocks = <_clk CLKID_SDIO0XIN>, <_clk 
CLKID_SDIO0>;
clock-names = "io", "core";
interrupts = ;
status = "disabled";
@@ -65,7 +65,7 @@
sdhci1: sdhci@ab0800 {
compatible = "mrvl,pxav3-mmc";
reg = <0xab0800 0x200>;
-   clocks = < CLKID_SDIO1XIN>, < CLKID_SDIO1>;
+   clocks = <_clk CLKID_SDIO1XIN>, <_clk 
CLKID_SDIO1>;
clock-names = "io", "core";
interrupts = ;
status = "disabled";
@@ -75,7 +75,7 @@
compatible = "mrvl,pxav3-mmc";
reg = <0xab1000 0x200>;
interrupts = ;
-   clocks = < CLKID_NFC_ECC>, < CLKID_NFC>;
+   clocks = <_clk CLKID_NFC_ECC>, <_clk 
CLKID_NFC>;
clock-names = "io", "core";
pinctrl-0 = <_pmux>;
pinctrl-names = "default";
@@ -105,13 +105,13 @@
compatible = "arm,cortex-a9-twd-timer";
reg = <0xad0600 0x20>;
interrupts = ;
-   clocks = < CLKID_TWD>;
+   clocks = <_clk CLKID_TWD>;
};
 
eth1: ethernet@b9 {
compatible = "marvell,pxa168-eth";
reg = <0xb9 0x1>;
-   clocks = < CLKID_GETH1>;
+   clocks = <_clk CLKID_GETH1>;
interrupts = ;
/* set by bootloader */
local-mac-address = [00 00 00 00 00 00];
@@ -134,7 +134,7 @@
eth0: ethernet@e5 {
compatible = "marvell,pxa168-eth";
reg = <0xe5 0x1>;
-   clocks = < CLKID_GETH0>;
+   clocks = <_clk CLKID_GETH0>;
interrupts = ;
/* set by bootloader */
local-mac-address = [00 00 00 00 00 00];
@@ -233,7 +233,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c00 0x14>;
interrupts = <8>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
status = "okay";
};
@@ -242,7 +242,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c14 0x14>;
interrupts = <9>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
status = "okay";
};
@@ -251,7 +251,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c28 0x14>;
interrupts = <10>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
status = "disabled";
};
@@ -260,7 +260,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c3c 0x14>;
interrupts = <11>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk CLKID_CFG>;
clock-names = "timer";
status = "disabled";
};
@@ -269,7 +269,7 @@
compatible = "snps,dw-apb-timer";
reg = <0x2c50 0x14>;
interrupts = <12>;
-   clocks = < CLKID_CFG>;
+   clocks = <_clk 

Re: [PCI] BUG: unable to handle kernel

[Murali Karicheri]

On 03/06/2015 01:06 AM, Fengguang Wu wrote:

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git

commit 0b2af171520e5d5e7d5b5f479b90a6a5014d9df6
Author: Murali Karicheri
AuthorDate: Tue Mar 3 12:52:13 2015 -0500
Commit: Bjorn Helgaas
CommitDate: Tue Mar 3 14:42:58 2015 -0600

 PCI: Update DMA configuration from DT

 If there is a DT node available for the root bridge's parent device, use
 the DMA configuration from that device node.  For example, Keystone PCI
 devices would require dma_pfn_offset to be set correctly in the device
 structure of the PCI device in order to have the correct DMA mask.  The DT
 node will have dma-ranges defined for this.  Also support using the DT
 property dma-coherent to allow coherent DMA operation by the PCI device.

 Use the new helper function of_pci_dma_configure() to update the device DMA
 configuration.  This fixes DMA on systems where DMA addresses are a
 constant offset from CPU physical addresses.

 Tested-by: Suravee Suthikulpanit  (AMD 
Seattle)
 Signed-off-by: Murali Karicheri
 Signed-off-by: Bjorn Helgaas
 Reviewed-by: Catalin Marinas
 Acked-by: Will Deacon
 CC: Joerg Roedel
 CC: Grant Likely
 CC: Rob Herring
 CC: Russell King
 CC: Arnd Bergmann

+--+++-+
|  | bdc567f9c1 | 0b2af17152 | 
v4.0-rc2_030422 |
+--+++-+
| boot_successes   | 47 | 0  | 0
   |
| boot_failures| 33 | 20 | 12   
   |
| page_allocation_failure:order:#,mode | 33 ||  
   |
| backtrace:btrfs_test_extent_io   | 33 ||  
   |
| backtrace:init_btrfs_fs  | 33 ||  
   |
| backtrace:kernel_init_freeable   | 33 | 20 | 12   
   |
| BUG:unable_to_handle_kernel  | 0  | 20 | 12   
   |
| Oops | 0  | 20 | 12   
   |
| EIP_is_at_of_pci_dma_configure   | 0  | 20 | 12   
   |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 20 | 12   
   |
| backtrace:acpi_bus_scan  | 0  | 20 | 12   
   |
| backtrace:acpi_scan_init | 0  | 20 | 12   
   |
| backtrace:acpi_init  | 0  | 20 | 12   
   |
+--+++-+

[0.573023] pci_bus :00: root bus resource [mem 0x1400-0xfebf 
window]
[0.573381] pci :00:00.0: [8086:1237] type 00 class 0x06
[0.573381] pci :00:00.0: [8086:1237] type 00 class 0x06
[0.574397] BUG: unable to handle kernel
[0.574397] BUG: unable to handle kernel NULL pointer dereferenceNULL 
pointer dereference at 01c4
  at 01c4
[0.575439] IP:
[0.575439] IP: [<79a20c33>] of_pci_dma_configure+0x33/0x70
  [<79a20c33>] of_pci_dma_configure+0x33/0x70
[0.576231] *pde = 
[0.576231] *pde = 

[0.57] Oops:  [#1]
[0.57] Oops:  [#1] SMP SMP

[0.57] Modules linked in:
[0.57] Modules linked in:

[0.57] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.0.0-rc1-6-g0b2af17 #6
[0.57] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.0.0-rc1-6-g0b2af17 #6
[0.57] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[0.57] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[0.57] task: 7806 ti: 78068000 task.ti: 78068000
[0.57] task: 7806 ti: 78068000 task.ti: 78068000
[0.57] EIP: 0060:[<79a20c33>] EFLAGS: 00010246 CPU: 0
[0.57] EIP: 0060:[<79a20c33>] EFLAGS: 00010246 CPU: 0
[0.57] EIP is at of_pci_dma_configure+0x33/0x70
[0.57] EIP is at of_pci_dma_configure+0x33/0x70
[0.57] EAX:  EBX: 78011800 ECX:  EDX: 0005
[0.57] EAX:  EBX: 78011800 ECX:  EDX: 0005
[0.57] ESI: 781d8400 EDI: 781d8000 EBP: 78069cd0 ESP: 78069cc8
[0.57] ESI: 781d8400 EDI: 781d8000 EBP: 78069cd0 ESP: 78069cc8
[0.57]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[0.57]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[0.57] CR0: 8005003b CR2: 01c4 CR3: 0229f000 CR4: 06d0
[0.57] CR0: 8005003b CR2: 01c4 CR3: 0229f000 CR4: 06d0
[0.57] Stack:
[0.57] Stack:
[ 

[PATCH -next] locking/rwsem: don't spin in heavy contention

[Ming Lei]

Before commit b3fd4f03ca0b995(locking/rwsem: Avoid deceiving lock
spinners), rwsem_spin_on_owner() returns false if the owner is changed.
This commit just returns true under the situation, then kernel
softlock can be triggered easily in xfstest.

So this patch recovers to previous behaviour, and it should be
reasonable to stop spining in case of heavy contention.

The soft lockup can be reproduced easily in xfstests(generic/299)
over ext4:

[  236.417011] NMI watchdog: BUG: soft lockup - CPU#5 stuck for 23s! 
[kworker/5:80:3288]
[  236.417011] Modules linked in: nbd ipv6 kvm_intel kvm serio_raw
[  236.417011] CPU: 5 PID: 3288 Comm: kworker/5:80 Not tainted 
4.0.0-rc1-next-20150303+ #69
[  236.417011] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Bochs 01/01/2011
[  236.417011] Workqueue: dio/sda dio_aio_complete_work
[  236.417011] task: 8800b87c ti: 8800b703c000 task.ti: 
8800b703c000
[  236.417011] RIP: 0010:[]  [] 
__rcu_read_unlock+0x47/0x55
[  236.417011] RSP: 0018:8800b703fb98  EFLAGS: 0246
[  236.417011] RAX:  RBX: 8800b703fb48 RCX: 0003b080
[  236.417011] RDX: fffe0001 RSI: 880231f03a20 RDI: 8800bb755568
[  236.417011] RBP: 8800b703fba8 R08: 880227908078 R09: 8800b87c
[  236.417011] R10: 0001 R11: 0020 R12: 8800b703c000
[  236.417011] R13: 8800b87c R14: 000f R15: 0101
[  236.417011] FS:  () GS:88023eca() 
knlGS:
[  236.417011] CS:  0010 DS:  ES:  CR0: 8005003b
[  236.417011] CR2: 7f549369f948 CR3: ba891000 CR4: 07e0
[  236.417011] Stack:
[  236.417011]  fffe0001 8800bb755568 8800b703fbc8 
81073917
[  236.417011]  8800bb755568 8800bb755584 8800b703fc48 
814d1ba4
[  236.417011]  8800b703fbe8 8800b87c 8800b703fc78 
811cf51b
[  236.417011] Call Trace:
[  236.417011]  [] rwsem_spin_on_owner+0x2b/0x79
[  236.417011]  [] rwsem_down_write_failed+0xc0/0x2f1
[  236.417011]  [] ? start_this_handle+0x494/0x4bd
[  236.417011]  [] ? trace_preempt_on+0x12/0x2f
[  236.417011]  [] call_rwsem_down_write_failed+0x13/0x20
[  236.417011]  [] ? down_write+0x24/0x33
[  236.417011]  [] ext4_map_blocks+0x236/0x3cb
[  236.417011]  [] ? ext4_convert_unwritten_extents+0xd2/0x19c
[  236.417011]  [] ? __ext4_journal_start_sb+0x77/0xb8
[  236.417011]  [] ext4_convert_unwritten_extents+0xf9/0x19c
[  236.417011]  [] ext4_put_io_end+0x3a/0x5d
[  236.417011]  [] ext4_end_io_dio+0x2a/0x2c
[  236.417011]  [] dio_complete+0x97/0x12d
[  236.417011]  [] dio_aio_complete_work+0x21/0x23
[  236.417011]  [] process_one_work+0x160/0x299
[  236.417011]  [] worker_thread+0x1c7/0x29e
[  236.417011]  [] ?cancel_delayed_work_sync+0x15/0x15
[  236.417011]  [] ?cancel_delayed_work_sync+0x15/0x15
[  236.417011]  [] kthread+0xae/0xb6
[  236.417011]  [] ? __kthread_parkme+0x61/0x61
[  236.417011]  [] ret_from_fork+0x53/0x80
[  236.417011]  [] ? __kthread_parkme+0x61/0x61
[  236.417011] Code: 01 74 0a ff c8 89 83 10 07 00 00 eb 28 c7 83 10 07 00 00
00 00 00 80 66 8b 83 14 07 00 00 66 85 c0 74 08 48 89 df e8 62 40 00 00 
83 10 07 00 00 00 00 00 00 58 5b 5d c3 0f 1f 44 00 00 55 48

Cc: Davidlohr Bueso 
Cc: Peter Zijlstra (Intel) 
Cc: Jason Low 
Cc: Linus Torvalds 
Cc: Michel Lespinasse 
Cc: Paul E. McKenney 
Cc: Tim Chen 
Cc: Ingo Molnar 
Cc: "Theodore Ts'o" 
Signed-off-by: Ming Lei 
---
 kernel/locking/rwsem-xadd.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 06e2214..1e78c5b 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -358,8 +358,12 @@ bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct 
task_struct *owner)
}
rcu_read_unlock();
 
+   /*
+* When the owner is changed, it is a sign for heavy contention,
+* so stop spinning for avoiding kernel lockup.
+*/
if (READ_ONCE(sem->owner))
-   return true; /* new owner, continue spinning */
+   return false;
 
/*
 * When the owner is not set, the lock could be free or
-- 
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/

[PATCH v2 09/11] ARM: berlin: remove useless chip and system ctrl compatibles in BG2

[Antoine Tenart]

Now that the rework to have one sub-node per device in the chip and
system controllers is done, their dedicated compatible can be removed.

Signed-off-by: Antoine Tenart 
---
 arch/arm/boot/dts/berlin2.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 0cbe99da16dc..a80611999b37 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -351,7 +351,7 @@
};
 
chip: chip-controller@ea {
-   compatible = "marvell,berlin2-chip-ctrl", "simple-mfd", 
"syscon";
+   compatible = "simple-mfd", "syscon";
reg = <0xea 0x400>;
 
chip_clk: clock {
@@ -455,7 +455,7 @@
};
 
sysctrl: system-controller@d000 {
-   compatible = "marvell,berlin2-system-ctrl", 
"simple-mfd", "syscon";
+   compatible = "simple-mfd", "syscon";
reg = <0xd000 0x100>;
 
sys_pinctrl: pin-controller {
-- 
2.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: NMI watchdog triggering during load_balance

[David Ahern]

On 3/6/15 2:12 AM, Peter Zijlstra wrote:

On Thu, Mar 05, 2015 at 09:05:28PM -0700, David Ahern wrote:

Socket(s): 32
NUMA node(s):  4


Urgh, with 32 'cpus' per socket, you still do _8_ sockets per node, for
a total of 256 cpus per node.


Per the response to Mike, the system has 4 physical cpus. Each cpu has 
32 cores with 8 threads per core and 4 memory controllers (one mcu per 8 
cores). Yes there are 256 logical cpus per node.


David
--
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 01/11] clk: convert clock mux to accept regmap

[Antoine Tenart]

Rework the clk_mux helpers to either use an iomem base address or a
regmap.

Signed-off-by: Antoine Tenart 
---
 drivers/clk/clk-mux.c| 72 +---
 include/linux/clk-provider.h | 39 +++-
 2 files changed, 93 insertions(+), 18 deletions(-)

diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 69a094c3783d..360191155bbd 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -42,7 +42,11 @@ static u8 clk_mux_get_parent(struct clk_hw *hw)
 * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so
 * val = 0x4 really means "bit 2, index starts at bit 0"
 */
-   val = clk_readl(mux->reg) >> mux->shift;
+   if (mux->reg_type == CLK_REG_TYPE_IOMEM)
+   val = clk_readl(mux->reg.iomem) >> mux->shift;
+   else
+   regmap_read(mux->reg.regmap, mux->reg.offset, );
+
val &= mux->mask;
 
if (mux->table) {
@@ -83,20 +87,24 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
index++;
}
 
-   if (mux->lock)
-   spin_lock_irqsave(mux->lock, flags);
+   if (mux->reg_type == CLK_REG_TYPE_IOMEM && mux->reg.lock)
+   spin_lock_irqsave(mux->reg.lock, flags);
 
if (mux->flags & CLK_MUX_HIWORD_MASK) {
val = mux->mask << (mux->shift + 16);
} else {
-   val = clk_readl(mux->reg);
+   val = clk_readl(mux->reg.iomem);
val &= ~(mux->mask << mux->shift);
}
val |= index << mux->shift;
-   clk_writel(val, mux->reg);
 
-   if (mux->lock)
-   spin_unlock_irqrestore(mux->lock, flags);
+   if (mux->reg_type == CLK_REG_TYPE_IOMEM)
+   clk_writel(val, mux->reg.iomem);
+   else
+   regmap_write(mux->reg.regmap, mux->reg.offset, val);
+
+   if (mux->reg_type == CLK_REG_TYPE_IOMEM && mux->reg.lock)
+   spin_unlock_irqrestore(mux->reg.lock, flags);
 
return 0;
 }
@@ -113,10 +121,10 @@ const struct clk_ops clk_mux_ro_ops = {
 };
 EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
 
-struct clk *clk_register_mux_table(struct device *dev, const char *name,
+struct clk *__clk_register_mux_table(struct device *dev, const char *name,
const char **parent_names, u8 num_parents, unsigned long flags,
-   void __iomem *reg, u8 shift, u32 mask,
-   u8 clk_mux_flags, u32 *table, spinlock_t *lock)
+   union clk_reg reg, enum clk_reg_type reg_type, u8 shift,
+   u32 mask, u8 clk_mux_flags, u32 *table)
 {
struct clk_mux *mux;
struct clk *clk;
@@ -149,10 +157,10 @@ struct clk *clk_register_mux_table(struct device *dev, 
const char *name,
 
/* struct clk_mux assignments */
mux->reg = reg;
+   mux->reg_type = reg_type;
mux->shift = shift;
mux->mask = mask;
mux->flags = clk_mux_flags;
-   mux->lock = lock;
mux->table = table;
mux->hw.init = 
 
@@ -163,8 +171,37 @@ struct clk *clk_register_mux_table(struct device *dev, 
const char *name,
 
return clk;
 }
+
+struct clk *clk_register_mux_table(struct device *dev, const char *name,
+   const char **parent_names, u8 num_parents, unsigned long flags,
+   void __iomem *reg, u8 shift, u32 mask,
+   u8 clk_mux_flags, u32 *table, spinlock_t *lock)
+{
+   union clk_reg clk_reg;
+
+   clk_reg.iomem = reg;
+   clk_reg.lock = lock;
+   return __clk_register_mux_table(dev, name, parent_names, num_parents,
+   flags, clk_reg, CLK_REG_TYPE_IOMEM,
+   shift, mask, clk_mux_flags, table);
+}
 EXPORT_SYMBOL_GPL(clk_register_mux_table);
 
+struct clk *clk_register_mux_table_regmap(struct device *dev, const char *name,
+   const char **parent_names, u8 num_parents, unsigned long flags,
+   struct regmap *regmap, unsigned int offset, u8 shift, u32 mask,
+   u8 clk_mux_flags, u32 *table)
+{
+   union clk_reg clk_reg;
+
+   clk_reg.regmap = regmap;
+   clk_reg.offset = offset;
+   return __clk_register_mux_table(dev, name, parent_names, num_parents,
+   flags, clk_reg, CLK_REG_TYPE_REGMAP,
+   shift, mask, clk_mux_flags, table);
+}
+EXPORT_SYMBOL_GPL(clk_register_mux_table_regmap);
+
 struct clk *clk_register_mux(struct device *dev, const char *name,
const char **parent_names, u8 num_parents, unsigned long flags,
void __iomem *reg, u8 shift, u8 width,
@@ -178,6 +215,19 @@ struct clk *clk_register_mux(struct device *dev, const 
char *name,
 }
 EXPORT_SYMBOL_GPL(clk_register_mux);
 
+struct clk *clk_register_mux_regmap(struct device *dev, const char *name,
+   const char **parent_names, u8 num_parents, unsigned long 

Re: NMI watchdog triggering during load_balance

[David Ahern]

On 3/6/15 2:07 AM, Peter Zijlstra wrote:

On Thu, Mar 05, 2015 at 09:05:28PM -0700, David Ahern wrote:

Since each domain is a superset of the lower one each pass through
load_balance regularly repeats the processing of the previous domain (e.g.,
NODE domain repeats the cpus in the CPU domain). Then multiplying that
across 1024 cpus and it seems like a of duplication.


It is, _but_ each domain has an interval, bigger domains _should_ load
balance at a bigger interval (iow lower frequency), and all this is
lockless data gathering, so reusing stuff from the previous round could
be quite stale indeed.



Yes and I have twiddled the intervals. The defaults for min_interval and 
max_interval (msec):

SMT 1 2
MC  1 4
CPU 1 4
NODE 8 32

Increasing those values (e.g. moving NODE to 50 and 100) drops idle time 
cpu usage but does not solve the fundamental problem -- under load the 
balancing of domains seems to be lining up and the system comes to a 
halt in load balancing frenzy.


David
--
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 00/10] ARM: berlin: refactor chip and system controllers

[Antoine Tenart]

Hi,

Marvell Berlin SoCs have a chip control register set providing several
individual registers dealing with various controllers (pinctrl, reset,
clk). This chip controller is described by a single DT node since the
individual registers are spread among the chip control register bank.

Marvell Berlin also have a system control register set providing several
individual registers for pinctrl or adc.

Prior to this series, there was no proper way of probing properly the
devices using one of the chip and system controller nodes. The pinctrl
driver was probed using the DT and the reset controller had an initcall.

This series aims to handle these two nodes correctly, by using the newly
available simple-mfd compatible, to register all the sub-devices. Syscon
is also used to provide a regmap to the sub-node drivers, so that they
can access the registers of the controllers safely. In addition, the
clock driver will need the regmap early during the boot, so syscon is a
good choice here.

Reworks were done in the Berlin pin controller and in the Berlin reset
driver, to take the changes into account (proper compatibles, syscon
helpers, regmap use).

The actual clock driver still works with these modifications, and a
dedicated series will follow to convert the Berlin clock drivers to use
the regmap provided by syscon.

Applies on top of v4.0-rc1 and [1]. Tested on the Marvell BG2Q DMP.

Thanks!

Antoine

[1] https://patchwork.kernel.org/patch/5920831/

Changes since v1:
- Removed the custom MFD driver for Berlin and use simple-mfd
  instead.

Antoine Tenart (10):
  Documentation: bindings: update the Berlin controllers documentation
  ARM: berlin: select MFD_SYSCON by default
  reset: berlin: convert to a platform driver
  Documentation: bindings: move the Berlin reset documentation
  pinctrl: berlin: use the regmap provided by syscon
  pinctrl: berlin: use proper compatibles
  Documentation: bindings: move the Berlin pinctrl documentation
  ARM: berlin: rework chip and system controller nodes for BG2
  ARM: berlin: rework chip and system controller nodes for BG2CD
  ARM: berlin: rework chip and system controller nodes for BG2Q

 .../devicetree/bindings/arm/marvell,berlin.txt | 73 +-
 .../devicetree/bindings/pinctrl/berlin,pinctrl.txt | 43 +
 .../devicetree/bindings/reset/berlin,reset.txt | 23 +++
 arch/arm/boot/dts/berlin2.dtsi | 50 +--
 arch/arm/boot/dts/berlin2cd.dtsi   | 32 +++---
 arch/arm/boot/dts/berlin2q.dtsi| 70 -
 arch/arm/mach-berlin/Kconfig   |  1 +
 drivers/pinctrl/berlin/berlin-bg2.c| 26 +---
 drivers/pinctrl/berlin/berlin-bg2cd.c  | 26 +---
 drivers/pinctrl/berlin/berlin-bg2q.c   | 26 +---
 drivers/pinctrl/berlin/berlin.c|  9 ++-
 drivers/reset/reset-berlin.c   | 71 -
 12 files changed, 216 insertions(+), 234 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
 create mode 100644 Documentation/devicetree/bindings/reset/berlin,reset.txt

-- 
2.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: [RFC 0/3] hugetlbfs: optionally reserve all fs pages at mount time

[Michal Hocko]

On Mon 02-03-15 17:18:14, Mike Kravetz wrote:
> On 03/02/2015 03:10 PM, Andrew Morton wrote:
> >On Fri, 27 Feb 2015 14:58:08 -0800 Mike Kravetz  
> >wrote:
> >
> >>hugetlbfs allocates huge pages from the global pool as needed.  Even if
> >>the global pool contains a sufficient number pages for the filesystem
> >>size at mount time, those global pages could be grabbed for some other
> >>use.  As a result, filesystem huge page allocations may fail due to lack
> >>of pages.
> >
> >Well OK, but why is this a sufficiently serious problem to justify
> >kernel changes?  Please provide enough info for others to be able
> >to understand the value of the change.
> >
> 
> Thanks for taking a look.
> 
> Applications such as a database want to use huge pages for performance
> reasons.  hugetlbfs filesystem semantics with ownership and modes work
> well to manage access to a pool of huge pages.  However, the application
> would like some reasonable assurance that allocations will not fail due
> to a lack of huge pages.  Before starting, the application will ensure
> that enough huge pages exist on the system in the global pools.  What
> the application wants is exclusive use of a pool of huge pages.
> 
> One could argue that this is a system administration issue.  The global
> huge page pools are only available to users with root privilege.
> Therefore,  exclusive use of a pool of huge pages can be obtained by
> limiting access.  However, many applications are installed to run with
> elevated privilege to take advantage of resources like huge pages.  It
> is quite possible for one application to interfere another, especially
> in the case of something like huge pages where the pool size is mostly
> fixed.
> 
> Suggestions for other ways to approach this situation are appreciated.
> I saw the existing support for "reservations" within hugetlbfs and
> thought of extending this to cover the size of the filesystem.

Maybe I do not understand your usecase properly but wouldn't hugetlb
cgroup (CONFIG_CGROUP_HUGETLB) help to guarantee the same? Just
configure limits for different users/applications (inside different
groups) so that they never overcommit the existing pool. Would that work
for you?

-- 
Michal Hocko
SUSE Labs
--
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] pwm: imx-pwm: add explicit compatible strings and required clock properties

[Matt Porter]

The imx-pwm binding contains language indicating compatible
strings to be used that is not valid for all supported parts
e.g. Should be "fsl,-pwm". Fix this by enumerating the
valid compatible strings that represent the two versions of
this peripheral in use.

The binding is also missing the clocks/clock-names properties
so document these,the two required ipg and per clocks, and add
add these properties to the example.

Signed-off-by: Matt Porter 
---
 Documentation/devicetree/bindings/pwm/imx-pwm.txt | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt 
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index b50d7a6d..30d2b82 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -1,10 +1,16 @@
 Freescale i.MX PWM controller
 
 Required properties:
-- compatible: should be "fsl,-pwm"
+- compatible :
+  - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
+  - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
 - reg: physical base address and length of the controller's registers
 - #pwm-cells: should be 2. See pwm.txt in this directory for a description of
   the cells format.
+- clocks : Clock specifiers for both ipg and per clocks.
+- clock-names : Clock names should include both "ipg" and "per"
+See the clock consumer binding,
+   Documentation/devicetree/bindings/clock/clock-bindings.txt
 - interrupts: The interrupt for the pwm controller
 
 Example:
@@ -13,5 +19,8 @@ pwm1: pwm@53fb4000 {
#pwm-cells = <2>;
compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
reg = <0x53fb4000 0x4000>;
+   clocks = < IMX5_CLK_PWM1_IPG_GATE>,
+< IMX5_CLK_PWM1_HF_GATE>;
+   clock-names = "ipg", "per";
interrupts = <61>;
 };
-- 
1.8.4

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

Re: [PATCH 0/7] Freescale DPAA FMan FLIB(s)

[Jamal Hadi Salim]

Hi Emil,

On 03/05/15 10:04, Emil Medve wrote:

Hello Jamal,


On 03/05/2015 08:35 AM, Jamal Hadi Salim wrote:

Hi Emil,



No. All the kernel drivers/code we want to upstream is meant to stand on
its own and be used the "normal" Linux/Unix way



Ok, thanks - that was my only concern.
Note there is a lot of offload efforts going on in Linux right now.
Take a look at the proceedings from netdev01. You should take advantage
of that to shape the direction of your patches.
I have suffered at the hands of the sdk for this processor in the past;
it is just a bad idea to keep these SDKs around when Linux can express
the features sufficiently.
Note: The main thing i'd be interested in is when you get to offloading
the classifier/scheduler etc. I know you are focussing on just the 
ethernet level at the moment,


cheers,
jamal

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

Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id

[Christopher Covington]

On 03/05/2015 09:28 PM, Rob Clark wrote:
> On Thu, Mar 5, 2015 at 8:59 PM, Olof Johansson  wrote:
>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala  wrote:
>>>
>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman  wrote:
>>>
 Kumar Gala  writes:

> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
> on Qualcomm MSM platforms to determine which device tree should be
> utilized and passed to the kernel.
>
> Cc: 
> Signed-off-by: Kumar Gala 

 Is this the special magic that allows qcom bootloaders to take a kernel
 plus multiple DTBs and figure out which DTB to pass?

 Kevin
>>>
>>> yes
>>
>> That's a bummer.
>>
>> Luckily, the solution for upstream is still quite simple: Provide only
>> one devicetree, and it'll be used, right?
>>
> 
> I never managed to figure out how to get that to work (at least on my
> apq8074 dragonboard.. fortunately ifc6540 seems to work w/ appended
> dtb).. kind of a pita because it is a bit of a non-standard boot.img
> format too..

I think you're talking about the boot flow from plain poweron which I wish I
knew more about, but in case it's any help, here are some fastboot boot steps
what worked for me a while back.

http://elinux.org/Dragonboard/APQ8074

Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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/1] ARM: exynos_defconfig: Disable IOMMU support

[Javier Martinez Canillas]

Hello Inki,

On 03/06/2015 02:32 PM, Inki Dae wrote:
>> 
>> Another interesting data point is that the error in next-20150303 for
>> these 2 boards was the NULL pointer dereference in exynos_plane_destroy
>> that I got with 4.0-rc2 (when IOMMU is disabled) in Snow and Peach Pit.
> 
> I think the NULL pointer dereference issue may be fixed with below patch
> I merged to exynos-drm-fixes just a while ago,
> https://lkml.org/lkml/2015/2/17/434
> 
> Could you test it with this patch again?
>

Thanks, I tested v4.0-rc2 + the patch to disable IOMMU + the patch you
mentioned and the crash does not happen anymore in Peach Pit and Snow.

>> 
>> Another thing that may be useful to detect these issues early is to have
>> exynos-drm-next be pulled by linux-next since otherwise the integration
>> is not tested until the changes are picked by the DRM maintainer.
>> 

I know that I may sound like a broken record but could you please make
sure that your tree is included in linux-next?

That way the fix could be tested by all the machines that are testing
linux-next daily since right now Exynos will still be broken until you
send a pull request to the DRM maintainer.

So it would be nice to get the changes as soon as possible into -next
to avoid a recurrent error to mask other possible new issues.

Best regards,
Javier
--
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 02/10] ARM: berlin: select MFD_SYSCON by default

[Antoine Tenart]

The chip and system controller nodes handle sub-devices, such as the
clock, pinctrl or reset controllers. The drivers handling them need a
regmap provided by syscon. Select it by default when using a Berlin SoC.

Signed-off-by: Antoine Tenart 
---
 arch/arm/mach-berlin/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig
index 3e40a947f3ea..742d53a5f7f9 100644
--- a/arch/arm/mach-berlin/Kconfig
+++ b/arch/arm/mach-berlin/Kconfig
@@ -6,6 +6,7 @@ menuconfig ARCH_BERLIN
select DW_APB_ICTL
select DW_APB_TIMER_OF
select GENERIC_IRQ_CHIP
+   select MFD_SYSCON
select PINCTRL
 
 if ARCH_BERLIN
-- 
2.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 v2 07/10] Documentation: bindings: move the Berlin pinctrl documentation

[Antoine Tenart]

The Berlin pinctrl documentation was part of the Marvell Berlin SoC
documentation because the Berlin pinctrl configuration was inside the
chip and the system controllers. With the recent rework of the chip and
system controller handling (now an MFD driver registers all sub-devices
of the two soc and system controller nodes and each device has its own
sub-node), the documentation of the Berlin pinctrl driver can be moved
to the generic pinctrl documentation directory.

Signed-off-by: Antoine Tenart 
---
 .../devicetree/bindings/arm/marvell,berlin.txt | 37 ---
 .../devicetree/bindings/pinctrl/berlin,pinctrl.txt | 43 ++
 2 files changed, 43 insertions(+), 37 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt 
b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
index 8bf3f2075233..ece73c6ad973 100644
--- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -95,23 +95,6 @@ Clocks provided by core clocks shall be referenced by a 
clock specifier
 indexing one of the provided clocks. Refer to dt-bindings/clock/berlin.h
 for the corresponding index mapping.
 
-* Pin controller binding
-
-Pin control registers are part of both register sets, chip control and system
-control. The pins controlled are organized in groups, so no actual pin
-information is needed.
-
-A pin-controller node should contain subnodes representing the pin group
-configurations, one per function. Each subnode has the group name and the 
muxing
-function used.
-
-Be aware the Marvell Berlin datasheets use the keyword 'mode' for what is 
called
-a 'function' in the pin-controller subsystem.
-
-Required subnode-properties:
-- groups: a list of strings describing the group names.
-- function: a string describing the function used to mux the groups.
-
 Example:
 
 chip: chip-control@ea {
@@ -120,29 +103,9 @@ chip: chip-control@ea {
reg = <0xea 0x400>;
clocks = <>, < 0>;
clock-names = "refclk", "video_ext0";
-
-   spi1_pmux: spi1-pmux {
-   groups = "G0";
-   function = "spi1";
-   };
 };
 
 sysctrl: system-controller@d000 {
compatible = "marvell,berlin2-system-ctrl", "simple-mfd", "syscon";
reg = <0xd000 0x100>;
-
-   uart0_pmux: uart0-pmux {
-   groups = "GSM4";
-   function = "uart0";
-   };
-
-   uart1_pmux: uart1-pmux {
-   groups = "GSM5";
-   function = "uart1";
-   };
-
-   uart2_pmux: uart2-pmux {
-   groups = "GSM3";
-   function = "uart2";
-   };
 };
diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
new file mode 100644
index ..a8bb5e26019c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
@@ -0,0 +1,43 @@
+* Pin-controller driver for the Marvell Berlin SoCs
+
+Pin control registers are part of both chip controller and system
+controller register sets. Pin controller nodes should be a sub-node of
+either the chip controller or system controller node. The pins
+controlled are organized in groups, so no actual pin information is
+needed.
+
+A pin-controller node should contain subnodes representing the pin group
+configurations, one per function. Each subnode has the group name and
+the muxing function used.
+
+Be aware the Marvell Berlin datasheets use the keyword 'mode' for what
+is called a 'function' in the pin-controller subsystem.
+
+Required properties:
+- compatible: should be one of:
+   "marvell,berlin2-soc-pinctrl",
+   "marvell,berlin2-system-pinctrl",
+   "marvell,berlin2cd-soc-pinctrl",
+   "marvell,berlin2cd-system-pinctrl",
+   "marvell,berlin2q-soc-pinctrl",
+   "marvell,berlin2q-system-pinctrl"
+
+Required subnode-properties:
+- groups: a list of strings describing the group names.
+- function: a string describing the function used to mux the groups.
+
+Example:
+
+sys_pinctrl: pin-controller {
+   compatible = "marvell,berlin2q-system-pinctrl";
+
+   uart0_pmux: uart0-pmux {
+   groups = "GSM12";
+   function = "uart0";
+   };
+};
+
+ {
+   pinctrl-0 = <_pmux>;
+   pinctrl-names = "default";
+};
-- 
2.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 v2 09/10] ARM: berlin: rework chip and system controller nodes for BG2CD

[Antoine Tenart]

The chip and system controller nodes are now handled by the Berlin
controller mfd driver. Its sub-devices are then registered by the mfd
driver and let the drivers be probed properly, using their own
sub-nodes.

Rework the device tree to take this changes into account.

Signed-off-by: Antoine Tenart 
---
 arch/arm/boot/dts/berlin2cd.dtsi | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 81b670ac494a..4bca01ee94d6 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -84,7 +84,7 @@
compatible = "marvell,berlin2cd-usb-phy";
reg = <0xb74000 0x128>;
#phy-cells = <0>;
-   resets = < 0x178 23>;
+   resets = <_rst 0x178 23>;
status = "disabled";
};
 
@@ -92,7 +92,7 @@
compatible = "marvell,berlin2cd-usb-phy";
reg = <0xb78000 0x128>;
#phy-cells = <0>;
-   resets = < 0x178 24>;
+   resets = <_rst 0x178 24>;
status = "disabled";
};
 
@@ -294,17 +294,25 @@
};
};
 
-   chip: chip-control@ea {
-   compatible = "marvell,berlin2cd-chip-ctrl";
-   #clock-cells = <1>;
-   #reset-cells = <2>;
+   chip: chip-controller@ea {
+   compatible = "marvell,berlin2cd-chip-ctrl", 
"simple-mfd", "syscon";
reg = <0xea 0x400>;
+   #clock-cells = <1>;
clocks = <>;
clock-names = "refclk";
 
-   uart0_pmux: uart0-pmux {
-   groups = "G6";
-   function = "uart0";
+   soc_pinctrl: pin-controller {
+   compatible = "marvell,berlin2cd-soc-pinctrl";
+
+   uart0_pmux: uart0-pmux {
+   groups = "G6";
+   function = "uart0";
+   };
+   };
+
+   chip_rst: reset {
+   compatible = "marvell,berlin2-reset";
+   #reset-cells = <2>;
};
};
 
@@ -389,8 +397,12 @@
};
 
sysctrl: system-controller@d000 {
-   compatible = "marvell,berlin2cd-system-ctrl";
+   compatible = "marvell,berlin2cd-system-ctrl", 
"simple-mfd", "syscon";
reg = <0xd000 0x100>;
+
+   sys_pinctrl: pin-controller {
+   compatible = 
"marvell,berlin2cd-system-pinctrl";
+   };
};
 
sic: interrupt-controller@e000 {
-- 
2.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 v2 08/10] ARM: berlin: rework chip and system controller nodes for BG2

[Antoine Tenart]

The chip and system controller nodes are now handled by the Berlin
controller mfd driver. Its sub-devices are then registered by the mfd
driver and let the drivers be probed properly, using their own
sub-nodes.

Rework the device tree to take this changes into account.

Signed-off-by: Antoine Tenart 
---
 arch/arm/boot/dts/berlin2.dtsi | 50 ++
 1 file changed, 31 insertions(+), 19 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 63d00a63cfa6..fbe5c6b6502d 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -350,17 +350,25 @@
};
};
 
-   chip: chip-control@ea {
-   compatible = "marvell,berlin2-chip-ctrl";
-   #clock-cells = <1>;
-   #reset-cells = <2>;
+   chip: chip-controller@ea {
+   compatible = "marvell,berlin2-chip-ctrl", "simple-mfd", 
"syscon";
reg = <0xea 0x400>;
+   #clock-cells = <1>;
clocks = <>;
clock-names = "refclk";
 
-   emmc_pmux: emmc-pmux {
-   groups = "G26";
-   function = "emmc";
+   soc_pinctrl: pin-controller {
+   compatible = "marvell,berlin2-soc-pinctrl";
+
+   emmc_pmux: emmc-pmux {
+   groups = "G26";
+   function = "emmc";
+   };
+   };
+
+   chip_rst: reset {
+   compatible = "marvell,berlin2-reset";
+   #reset-cells = <2>;
};
};
 
@@ -442,22 +450,26 @@
};
 
sysctrl: system-controller@d000 {
-   compatible = "marvell,berlin2-system-ctrl";
+   compatible = "marvell,berlin2-system-ctrl", 
"simple-mfd", "syscon";
reg = <0xd000 0x100>;
 
-   uart0_pmux: uart0-pmux {
-   groups = "GSM4";
-   function = "uart0";
-   };
+   sys_pinctrl: pin-controller {
+   compatible = 
"marvell,berlin2-system-pinctrl";
 
-   uart1_pmux: uart1-pmux {
-   groups = "GSM5";
-   function = "uart1";
-   };
+   uart0_pmux: uart0-pmux {
+   groups = "GSM4";
+   function = "uart0";
+   };
+
+   uart1_pmux: uart1-pmux {
+   groups = "GSM5";
+   function = "uart1";
+   };
 
-   uart2_pmux: uart2-pmux {
-   groups = "GSM3";
-   function = "uart2";
+   uart2_pmux: uart2-pmux {
+   groups = "GSM3";
+   function = "uart2";
+   };
};
};
 
-- 
2.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 v2 05/10] pinctrl: berlin: use the regmap provided by syscon

[Antoine Tenart]

The Berlin pin controller nodes are now sub-nodes of the soc-controller
and the system-controller nodes. The register bank is managed by syscon,
which provides a regmap.

Remove the regmap setup from the Berlin pinctrl driver and use the one
provided by syscon.

Signed-off-by: Antoine Tenart 
---
 drivers/pinctrl/berlin/berlin-bg2.c   | 22 --
 drivers/pinctrl/berlin/berlin-bg2cd.c | 22 --
 drivers/pinctrl/berlin/berlin-bg2q.c  | 22 --
 drivers/pinctrl/berlin/berlin.c   |  9 ++---
 4 files changed, 6 insertions(+), 69 deletions(-)

diff --git a/drivers/pinctrl/berlin/berlin-bg2.c 
b/drivers/pinctrl/berlin/berlin-bg2.c
index b71a6fffef1b..368ec0b9b8ba 100644
--- a/drivers/pinctrl/berlin/berlin-bg2.c
+++ b/drivers/pinctrl/berlin/berlin-bg2.c
@@ -233,28 +233,6 @@ static int berlin2_pinctrl_probe(struct platform_device 
*pdev)
 {
const struct of_device_id *match =
of_match_device(berlin2_pinctrl_match, >dev);
-   struct regmap_config *rmconfig;
-   struct regmap *regmap;
-   struct resource *res;
-   void __iomem *base;
-
-   rmconfig = devm_kzalloc(>dev, sizeof(*rmconfig), GFP_KERNEL);
-   if (!rmconfig)
-   return -ENOMEM;
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
-
-   rmconfig->reg_bits = 32,
-   rmconfig->val_bits = 32,
-   rmconfig->reg_stride = 4,
-   rmconfig->max_register = resource_size(res);
-
-   regmap = devm_regmap_init_mmio(>dev, base, rmconfig);
-   if (IS_ERR(regmap))
-   return PTR_ERR(regmap);
 
return berlin_pinctrl_probe(pdev, match->data);
 }
diff --git a/drivers/pinctrl/berlin/berlin-bg2cd.c 
b/drivers/pinctrl/berlin/berlin-bg2cd.c
index 19ac5a22c947..6b9cae029ef7 100644
--- a/drivers/pinctrl/berlin/berlin-bg2cd.c
+++ b/drivers/pinctrl/berlin/berlin-bg2cd.c
@@ -176,28 +176,6 @@ static int berlin2cd_pinctrl_probe(struct platform_device 
*pdev)
 {
const struct of_device_id *match =
of_match_device(berlin2cd_pinctrl_match, >dev);
-   struct regmap_config *rmconfig;
-   struct regmap *regmap;
-   struct resource *res;
-   void __iomem *base;
-
-   rmconfig = devm_kzalloc(>dev, sizeof(*rmconfig), GFP_KERNEL);
-   if (!rmconfig)
-   return -ENOMEM;
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
-
-   rmconfig->reg_bits = 32,
-   rmconfig->val_bits = 32,
-   rmconfig->reg_stride = 4,
-   rmconfig->max_register = resource_size(res);
-
-   regmap = devm_regmap_init_mmio(>dev, base, rmconfig);
-   if (IS_ERR(regmap))
-   return PTR_ERR(regmap);
 
return berlin_pinctrl_probe(pdev, match->data);
 }
diff --git a/drivers/pinctrl/berlin/berlin-bg2q.c 
b/drivers/pinctrl/berlin/berlin-bg2q.c
index bd9662e57ad3..11aa10cc0e3e 100644
--- a/drivers/pinctrl/berlin/berlin-bg2q.c
+++ b/drivers/pinctrl/berlin/berlin-bg2q.c
@@ -395,28 +395,6 @@ static int berlin2q_pinctrl_probe(struct platform_device 
*pdev)
 {
const struct of_device_id *match =
of_match_device(berlin2q_pinctrl_match, >dev);
-   struct regmap_config *rmconfig;
-   struct regmap *regmap;
-   struct resource *res;
-   void __iomem *base;
-
-   rmconfig = devm_kzalloc(>dev, sizeof(*rmconfig), GFP_KERNEL);
-   if (!rmconfig)
-   return -ENOMEM;
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
-
-   rmconfig->reg_bits = 32,
-   rmconfig->val_bits = 32,
-   rmconfig->reg_stride = 4,
-   rmconfig->max_register = resource_size(res);
-
-   regmap = devm_regmap_init_mmio(>dev, base, rmconfig);
-   if (IS_ERR(regmap))
-   return PTR_ERR(regmap);
 
return berlin_pinctrl_probe(pdev, match->data);
 }
diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c
index 7f0b0f93242b..2e3a8b8858ec 100644
--- a/drivers/pinctrl/berlin/berlin.c
+++ b/drivers/pinctrl/berlin/berlin.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -295,13 +296,15 @@ int berlin_pinctrl_probe(struct platform_device *pdev,
 const struct berlin_pinctrl_desc *desc)
 {
struct device *dev = >dev;
+   struct device_node *parent_np = of_get_parent(dev->of_node);
struct berlin_pinctrl *pctrl;
struct regmap *regmap;
int ret;
 
-   regmap = dev_get_regmap(>dev, NULL);
-   if (!regmap)
-   return -ENODEV;
+   regmap = syscon_node_to_regmap(parent_np);
+   of_node_put(parent_np);
+   if 

[PATCH v2 04/10] Documentation: bindings: move the Berlin reset documentation

[Antoine Tenart]

The Berlin reset documentation was part of the Marvell Berlin SoC
documentation because the Berlin reset configuration was inside the chip
controller. With the recent rework of the chip and system controller
handling (now an MFD driver registers all sub-devices of the two soc and
system controller nodes and each device has its own sub-node), the
documentation of the Berlin reset driver can be moved to the generic
reset documentation directory.

Signed-off-by: Antoine Tenart 
---
 .../devicetree/bindings/arm/marvell,berlin.txt | 10 --
 .../devicetree/bindings/reset/berlin,reset.txt | 23 ++
 2 files changed, 23 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reset/berlin,reset.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt 
b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
index 3a7fce4dc4af..8bf3f2075233 100644
--- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -112,21 +112,11 @@ Required subnode-properties:
 - groups: a list of strings describing the group names.
 - function: a string describing the function used to mux the groups.
 
-* Reset controller binding
-
-A reset controller is part of the chip control registers set. The chip control
-node also provides the reset. The register set is not at the same offset 
between
-Berlin SoCs.
-
-Required property:
-- #reset-cells: must be set to 2
-
 Example:
 
 chip: chip-control@ea {
compatible = "marvell,berlin2-chip-ctrl", "simple-mfd", "syscon";
#clock-cells = <1>;
-   #reset-cells = <2>;
reg = <0xea 0x400>;
clocks = <>, < 0>;
clock-names = "refclk", "video_ext0";
diff --git a/Documentation/devicetree/bindings/reset/berlin,reset.txt 
b/Documentation/devicetree/bindings/reset/berlin,reset.txt
new file mode 100644
index ..514fee098b4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/berlin,reset.txt
@@ -0,0 +1,23 @@
+Marvell Berlin reset controller
+===
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller node must be a sub-node of the chip controller
+node on Berlin SoCs.
+
+Required properties:
+- compatible: should be "marvell,berlin2-reset"
+- #reset-cells: must be set to 2
+
+Example:
+
+chip_rst: reset {
+   compatible = "marvell,berlin2-reset";
+   #reset-cells = <2>;
+};
+
+_phy0 {
+   resets = <_rst 0x104 12>;
+};
-- 
2.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 v2 06/10] pinctrl: berlin: use proper compatibles

[Antoine Tenart]

The Berlin pin-controller driver was sharing the chip and system
controller nodes with the clock and the reset drivers. They all shared
the same compatible. With the introduction of the Marvell Berlin MFD
controller, the Berlin pin-controller driver has now its own node.
Update its compatibles to not share anymore the ones of the chip and
system controllers.

Signed-off-by: Antoine Tenart 
---
 drivers/pinctrl/berlin/berlin-bg2.c   | 4 ++--
 drivers/pinctrl/berlin/berlin-bg2cd.c | 4 ++--
 drivers/pinctrl/berlin/berlin-bg2q.c  | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/berlin/berlin-bg2.c 
b/drivers/pinctrl/berlin/berlin-bg2.c
index 368ec0b9b8ba..3769eaedf519 100644
--- a/drivers/pinctrl/berlin/berlin-bg2.c
+++ b/drivers/pinctrl/berlin/berlin-bg2.c
@@ -218,11 +218,11 @@ static const struct berlin_pinctrl_desc 
berlin2_sysmgr_pinctrl_data = {
 
 static const struct of_device_id berlin2_pinctrl_match[] = {
{
-   .compatible = "marvell,berlin2-chip-ctrl",
+   .compatible = "marvell,berlin2-soc-pinctrl",
.data = _soc_pinctrl_data
},
{
-   .compatible = "marvell,berlin2-system-ctrl",
+   .compatible = "marvell,berlin2-system-pinctrl",
.data = _sysmgr_pinctrl_data
},
{}
diff --git a/drivers/pinctrl/berlin/berlin-bg2cd.c 
b/drivers/pinctrl/berlin/berlin-bg2cd.c
index 6b9cae029ef7..9e11f191d643 100644
--- a/drivers/pinctrl/berlin/berlin-bg2cd.c
+++ b/drivers/pinctrl/berlin/berlin-bg2cd.c
@@ -161,11 +161,11 @@ static const struct berlin_pinctrl_desc 
berlin2cd_sysmgr_pinctrl_data = {
 
 static const struct of_device_id berlin2cd_pinctrl_match[] = {
{
-   .compatible = "marvell,berlin2cd-chip-ctrl",
+   .compatible = "marvell,berlin2cd-soc-pinctrl",
.data = _soc_pinctrl_data
},
{
-   .compatible = "marvell,berlin2cd-system-ctrl",
+   .compatible = "marvell,berlin2cd-system-pinctrl",
.data = _sysmgr_pinctrl_data
},
{}
diff --git a/drivers/pinctrl/berlin/berlin-bg2q.c 
b/drivers/pinctrl/berlin/berlin-bg2q.c
index 11aa10cc0e3e..ba7a8a8ad010 100644
--- a/drivers/pinctrl/berlin/berlin-bg2q.c
+++ b/drivers/pinctrl/berlin/berlin-bg2q.c
@@ -380,11 +380,11 @@ static const struct berlin_pinctrl_desc 
berlin2q_sysmgr_pinctrl_data = {
 
 static const struct of_device_id berlin2q_pinctrl_match[] = {
{
-   .compatible = "marvell,berlin2q-chip-ctrl",
+   .compatible = "marvell,berlin2q-soc-pinctrl",
.data = _soc_pinctrl_data,
},
{
-   .compatible = "marvell,berlin2q-system-ctrl",
+   .compatible = "marvell,berlin2q-system-pinctrl",
.data = _sysmgr_pinctrl_data,
},
{}
-- 
2.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 v2 03/10] reset: berlin: convert to a platform driver

[Antoine Tenart]

The Berlin reset controller was introduced without being a platform
driver because of a needed DT rework: the node describing the reset
controller also describes the pinctrl and clk controllers...

The DT issue being solved thanks to the addition of the Berlin
controller mfd driver, it is now possible to convert the Berlin reset
driver to a plaftorm driver.

Signed-off-by: Antoine Tenart 
---
 drivers/reset/reset-berlin.c | 71 +---
 1 file changed, 27 insertions(+), 44 deletions(-)

diff --git a/drivers/reset/reset-berlin.c b/drivers/reset/reset-berlin.c
index f8b48a13cf0b..5f414fa142ff 100644
--- a/drivers/reset/reset-berlin.c
+++ b/drivers/reset/reset-berlin.c
@@ -12,10 +12,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -25,8 +27,7 @@
container_of((p), struct berlin_reset_priv, rcdev)
 
 struct berlin_reset_priv {
-   void __iomem*base;
-   unsigned intsize;
+   struct regmap   *regmap;
struct reset_controller_dev rcdev;
 };
 
@@ -37,7 +38,7 @@ static int berlin_reset_reset(struct reset_controller_dev 
*rcdev,
int offset = id >> 8;
int mask = BIT(id & 0x1f);
 
-   writel(mask, priv->base + offset);
+   regmap_write(priv->regmap, offset, mask);
 
/* let the reset be effective */
udelay(10);
@@ -52,7 +53,6 @@ static struct reset_control_ops berlin_reset_ops = {
 static int berlin_reset_xlate(struct reset_controller_dev *rcdev,
  const struct of_phandle_args *reset_spec)
 {
-   struct berlin_reset_priv *priv = to_berlin_reset_priv(rcdev);
unsigned offset, bit;
 
if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
@@ -61,71 +61,54 @@ static int berlin_reset_xlate(struct reset_controller_dev 
*rcdev,
offset = reset_spec->args[0];
bit = reset_spec->args[1];
 
-   if (offset >= priv->size)
-   return -EINVAL;
-
if (bit >= BERLIN_MAX_RESETS)
return -EINVAL;
 
return (offset << 8) | bit;
 }
 
-static int __berlin_reset_init(struct device_node *np)
+static int berlin2_reset_probe(struct platform_device *pdev)
 {
+   struct device_node *parent_np = of_get_parent(pdev->dev.of_node);
struct berlin_reset_priv *priv;
-   struct resource res;
-   resource_size_t size;
-   int ret;
 
-   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
 
-   ret = of_address_to_resource(np, 0, );
-   if (ret)
-   goto err;
-
-   size = resource_size();
-   priv->base = ioremap(res.start, size);
-   if (!priv->base) {
-   ret = -ENOMEM;
-   goto err;
-   }
-   priv->size = size;
+   priv->regmap = syscon_node_to_regmap(parent_np);
+   of_node_put(parent_np);
+   if (IS_ERR(priv->regmap))
+   return PTR_ERR(priv->regmap);
 
priv->rcdev.owner = THIS_MODULE;
priv->rcdev.ops = _reset_ops;
-   priv->rcdev.of_node = np;
+   priv->rcdev.of_node = pdev->dev.of_node;
priv->rcdev.of_reset_n_cells = 2;
priv->rcdev.of_xlate = berlin_reset_xlate;
 
reset_controller_register(>rcdev);
 
return 0;
-
-err:
-   kfree(priv);
-   return ret;
 }
 
-static const struct of_device_id berlin_reset_of_match[] __initconst = {
-   { .compatible = "marvell,berlin2-chip-ctrl" },
-   { .compatible = "marvell,berlin2cd-chip-ctrl" },
-   { .compatible = "marvell,berlin2q-chip-ctrl" },
+static const struct of_device_id berlin_reset_of_match[] = {
+   { .compatible = "marvell,berlin2-reset" },
{ },
 };
+MODULE_DEVICE_TABLE(of, berlin_reset_of_match);
 
-static int __init berlin_reset_init(void)
-{
-   struct device_node *np;
-   int ret;
+static struct platform_driver berlin_reset_driver = {
+   .probe  = berlin2_reset_probe,
+   .driver = {
+   .name = "berlin2-reset",
+   .of_match_table = berlin_reset_of_match,
+   },
 
-   for_each_matching_node(np, berlin_reset_of_match) {
-   ret = __berlin_reset_init(np);
-   if (ret)
-   return ret;
-   }
+};
+module_platform_driver(berlin_reset_driver);
 
-   return 0;
-}
-arch_initcall(berlin_reset_init);
+MODULE_AUTHOR("Antoine Tenart ");
+MODULE_AUTHOR("Sebastian Hesselbarth ");
+MODULE_DESCRIPTION("Marvell Berlin reset driver");
+MODULE_LICENSE("GPL");
-- 
2.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 v2 10/10] ARM: berlin: rework chip and system controller nodes for BG2Q

[Antoine Tenart]

The chip and system controller nodes are now handled by the Berlin
controller mfd driver. Its sub-devices are then registered by the mfd
driver and let the drivers be probed properly, using their own
sub-nodes.

Rework the device tree to take this changes into account.

Signed-off-by: Antoine Tenart 
---
 arch/arm/boot/dts/berlin2q.dtsi | 70 -
 1 file changed, 41 insertions(+), 29 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index be5397288d24..006d382d44ff 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -127,7 +127,7 @@
compatible = "marvell,berlin2-usb-phy";
reg = <0xa2f400 0x128>;
#phy-cells = <0>;
-   resets = < 0x104 14>;
+   resets = <_rst 0x104 14>;
status = "disabled";
};
 
@@ -145,7 +145,7 @@
compatible = "marvell,berlin2-usb-phy";
reg = <0xb74000 0x128>;
#phy-cells = <0>;
-   resets = < 0x104 12>;
+   resets = <_rst 0x104 12>;
status = "disabled";
};
 
@@ -359,22 +359,30 @@
};
};
 
-   chip: chip-control@ea {
-   compatible = "marvell,berlin2q-chip-ctrl";
-   #clock-cells = <1>;
-   #reset-cells = <2>;
+   chip: chip-controller@ea {
+   compatible = "marvell,berlin2q-chip-ctrl", 
"simple-mfd", "syscon";
reg = <0xea 0x400>, <0xdd0170 0x10>;
+   #clock-cells = <1>;
clocks = <>;
clock-names = "refclk";
 
-   twsi0_pmux: twsi0-pmux {
-   groups = "G6";
-   function = "twsi0";
+   soc_pinctrl: pin-controller {
+   compatible = "marvell,berlin2q-soc-pinctrl";
+
+   twsi0_pmux: twsi0-pmux {
+   groups = "G6";
+   function = "twsi0";
+   };
+
+   twsi1_pmux: twsi1-pmux {
+   groups = "G7";
+   function = "twsi1";
+   };
};
 
-   twsi1_pmux: twsi1-pmux {
-   groups = "G7";
-   function = "twsi1";
+   chip_rst: reset {
+   compatible = "marvell,berlin2-reset";
+   #reset-cells = <2>;
};
};
 
@@ -525,28 +533,32 @@
};
};
 
-   sysctrl: pin-controller@d000 {
-   compatible = "marvell,berlin2q-system-ctrl";
+   sysctrl: system-controller@d000 {
+   compatible = "marvell,berlin2q-system-ctrl", 
"simple-mfd", "syscon";
reg = <0xd000 0x100>;
 
-   uart0_pmux: uart0-pmux {
-   groups = "GSM12";
-   function = "uart0";
-   };
+   sys_pinctrl: pin-controller {
+   compatible = 
"marvell,berlin2q-system-pinctrl";
 
-   uart1_pmux: uart1-pmux {
-   groups = "GSM14";
-   function = "uart1";
-   };
+   uart0_pmux: uart0-pmux {
+   groups = "GSM12";
+   function = "uart0";
+   };
 
-   twsi2_pmux: twsi2-pmux {
-   groups = "GSM13";
-   function = "twsi2";
-   };
+   uart1_pmux: uart1-pmux {
+   groups = "GSM14";
+   function = "uart1";
+   };
+
+   twsi2_pmux: twsi2-pmux {
+   groups = "GSM13";
+   function = "twsi2";
+   };
 
-   twsi3_pmux: twsi3-pmux 

[PATCH v2 01/10] Documentation: bindings: update the Berlin controllers documentation

[Antoine Tenart]

We're moving from a single node for multiple devices to a node with one
sub-node per sub-device, registered by simple-mfd. Update the
documentation to reflect the changes.

Signed-off-by: Antoine Tenart 
---
 .../devicetree/bindings/arm/marvell,berlin.txt | 26 +-
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt 
b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
index a99eb9eb14c0..3a7fce4dc4af 100644
--- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -49,10 +49,13 @@ chip control registers, so there should be a single DT node 
only providing the
 different functions which are described below.
 
 Required properties:
-- compatible: shall be one of
-   "marvell,berlin2-chip-ctrl" for BG2
-   "marvell,berlin2cd-chip-ctrl" for BG2CD
-   "marvell,berlin2q-chip-ctrl" for BG2Q
+- compatible:
+   * the first value should be one of:
+   "marvell,berlin2-chip-ctrl" for BG2
+   "marvell,berlin2cd-chip-ctrl" for BG2CD
+   "marvell,berlin2q-chip-ctrl" for BG2Q
+   * the second and third values must be:
+   "simple-mfd", "syscon"
 - reg: address and length of following register sets for
   BG2/BG2CD: chip control register set
   BG2Q: chip control register set and cpu pll registers
@@ -63,10 +66,13 @@ Marvell Berlin SoCs have a system control register set 
providing several
 individual registers dealing with pinmux, padmux, and reset.
 
 Required properties:
-- compatible: should be one of
-   "marvell,berlin2-system-ctrl" for BG2
-   "marvell,berlin2cd-system-ctrl" for BG2CD
-   "marvell,berlin2q-system-ctrl" for BG2Q
+- compatible:
+   * the first value should be one of:
+   "marvell,berlin2-system-ctrl" for BG2
+   "marvell,berlin2cd-system-ctrl" for BG2CD
+   "marvell,berlin2q-system-ctrl" for BG2Q
+   * the second and third values must be:
+   "simple-mfd", "syscon"
 - reg: address and length of the system control register set
 
 * Clock provider binding
@@ -118,7 +124,7 @@ Required property:
 Example:
 
 chip: chip-control@ea {
-   compatible = "marvell,berlin2-chip-ctrl";
+   compatible = "marvell,berlin2-chip-ctrl", "simple-mfd", "syscon";
#clock-cells = <1>;
#reset-cells = <2>;
reg = <0xea 0x400>;
@@ -132,7 +138,7 @@ chip: chip-control@ea {
 };
 
 sysctrl: system-controller@d000 {
-   compatible = "marvell,berlin2-system-ctrl";
+   compatible = "marvell,berlin2-system-ctrl", "simple-mfd", "syscon";
reg = <0xd000 0x100>;
 
uart0_pmux: uart0-pmux {
-- 
2.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: NMI watchdog triggering during load_balance

[David Ahern]

On 3/6/15 1:51 AM, Peter Zijlstra wrote:

On Thu, Mar 05, 2015 at 09:05:28PM -0700, David Ahern wrote:

Hi Peter/Mike/Ingo:

Does that make sense or am I off in the weeds?


How much of your story pertains to 3.18? I'm not particularly interested
in anything much older than that.



No. All of the data in the opening email are from 2.6.39. Each kernel 
(2.6.39, 3.8 and 3.18) has a different performance problem. I will look 
at 3.18 in depth soon, but from what I can see the fundamental concepts 
of the load balancing have not changed (e.g., my tracepoints from 2.6.39 
still apply to 3.18).


David
--
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: NMI watchdog triggering during load_balance

[David Ahern]

On 3/5/15 9:52 PM, Mike Galbraith wrote:

CPU970 attaching sched-domain:
   domain 0: span 968-975 level SIBLING
groups: 8 single CPU groups
domain 1: span 968-975 level MC
 groups: 1 group with 8 cpus
 domain 2: span 768-1023 level CPU
  groups: 4 groups with 256 cpus per group


Wow, that topology is horrid.  I'm not surprised that your box is
writhing in agony.  Can you twiddle that?



twiddle that how?

The system has 4 physical cpus (sockets). Each cpu has 32 cores with 8 
threads per core and each cpu has 4 memory controllers.


If I disable SCHED_MC and CGROUPS_SCHED (group scheduling) there is a 
noticeable improvement -- watchdog does not trigger and I do not get the 
rq locks held for 2-3 seconds. But there is still fairly high cpu usage 
for an idle system. Perhaps I should leave SCHED_MC on and disable 
SCHED_SMT; I'll try that today.


Thanks,
David
--
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 in 3.18][PPC] PA Semi fails to boot after: of/base: Fix PowerPC address parsing hack

[Steven Rostedt]

On Fri, 06 Mar 2015 15:18:42 +1100
Benjamin Herrenschmidt  wrote:

 
> Can you shoot me the DT (/proc/device-tree in a tarball) ?

Attached.

-- Steve



device-tree.tar.bz2
Description: application/bzip

Re: [PATCH 1/1] x86/fpu: math_state_restore() should not blindly disable irqs

[David Vrabel]

On 06/03/15 14:01, Oleg Nesterov wrote:
> On 03/06, Ingo Molnar wrote:
>>
>> * Oleg Nesterov  wrote:
>>
>>> On 03/06, Ingo Molnar wrote:

 * Oleg Nesterov  wrote:

> [...] The patch above looks "obviously safe", but perhaps I am
> paranoid too much...

 IMHO your hack above isn't really acceptable, even for a backport.
 So lets test the patch below (assuming it's the right thing to do)
 and move forward?
>>>
>>> OK, but please note that this patch is not beckportable. If you think
>>> that -stable doesn't need this fix, then I agree.
>>>
>>> If the caller is do_device_not_available(), then we can not enable
>>> irqs before __thread_fpu_begin() + restore_fpu_checking().
>>>
>>> 1. Preemption in between can destroy ->fpu.state initialized by
>>>fpu_finit(), __switch_to() will save the live (wrong) FPU state
>>>again.
>>>
>>> 2. kernel_fpu_begin() from irq right after __thread_fpu_begin() is
>>>not nice too. It will do __save_init_fpu() and this overwrites
>>>->fpu.state too.
>>>
>>> Starting from v4.0 it does kernel_fpu_disable(), but the older kernels
>>> do not.
>>>
>>> Ingo, this code is really horrible and fragile. We need to cleanup it
>>> step-by-step, imho.
>>
>> How about the patch from David Vrabel? That seems to solve the
>> irq-disable problem too, right?
> 
> I wasn't cc'ed, I guess you mean
> 
>   [PATCHv4] x86, fpu: remove the logic of non-eager fpu mem allocation at 
> the first usage
>   http://marc.info/?l=linux-kernel=142564237705311=2

This patch is from Suresh, and was originally against 3.10, so...

> Not sure I understand it correctly after the first quick look, but
> 
> 1. It conflicts with the recent changes in tip/x86/fpu
> 
> 2. fpu_ini() initializes current->thread.fpu.state. This looks unneeded,
>the kernel threads no longer have FPU context and do not abuse CPU.
> 
> 3. I can be easily wrong, but it looks buggy... Note that
>arch_dup_task_struct() doesn't allocate child->fpu.state if
>!tsk_used_math(parent).

...yes. It's bit-rotted a bit.

> No, I do not think this patch is a good idea. Perhaps I am wrong, but I
> think we need other changes. And they should start from init_fpu().

But the general principle of avoiding the allocation in the #NM handler
and hence avoiding the need to re-enable IRQs is still a good idea, yes?

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

[PATCH v1 1/1] sunrpc/cache: simplify qword_add

[Andy Shevchenko]

The commit 7572d3b29896 (lib/string_helpers.c: change semantics of
string_escape_mem) updates qword_add() to follow the changes in
lib/string_helpers.c. This patch simplifies the approach.

Andrew, I think this one can be folded in the mentioned commit by Rasmus.

Signed-off-by: Andy Shevchenko 
---
 net/sunrpc/cache.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
index 22c4418..4e46670 100644
--- a/net/sunrpc/cache.c
+++ b/net/sunrpc/cache.c
@@ -1068,16 +1068,16 @@ void qword_add(char **bpp, int *lp, char *str)
 {
char *bp = *bpp;
int len = *lp;
-   int ret, written;
+   int ret;
 
if (len < 0) return;
 
ret = string_escape_str(str, bp, len, ESCAPE_OCTAL, "\\ \n\t");
-   written = min(ret, len);
-   bp += written;
if (ret >= len)
+   bp += len;
len = -1;
else {
+   bp += ret;
len -= ret;
*bp++ = ' ';
len--;
-- 
2.1.4

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

Re: [PATCH v2 1/2] livepatch/module: Apply patch when loaded module is unformed

[Josh Poimboeuf]

On Fri, Mar 06, 2015 at 03:00:13PM +0100, Petr Mladek wrote:
> This brings me back to the original idea with that boolean that
> marks the state before and after the coming notifier (module_init).
> We could use a bitfield instead of the two booleans when requested.

Yeah, that would work.  Though I think one boolean is enough?

For example, just have a mod->klp_live which is initialized to false,
with its value set in the COMING notifier, and cleared in the GOING
notifier.

> Alternative solutions:
> 
> + reject new patches when a module is coming; this is ugly
> 
> + wait with adding new patch until the module leaves the COMING state;
> this might be dangerous or complicated; we would need to leave
> kgr_lock in the middle of the patch registration to avoid a deadlock
> with klp_module_init(); also we might need a waitqueue for each module
> which seems to be even bigger overhead than the two booleans
> 
> + always register/enable new patches and fix up the potential mess
> (registered patches order) in klp_module_init(); This is nasty and
> prone to regressions in the future development;
> 
> + add another MODULE_STATE where the kallsyms are visible but the
> module is not used yet; this looks to complex; the module states are
> checked on "many" locations
> 
> 
> I will wait with v3 over the weekend. I hope that it will bring fresh
> mind. Sigh, if I could have slept more with the baby twins.

Good luck!  In my experience, an entire weekend with babies is far from
restful ;-)

-- 
Josh
--
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/5] dt-bindings: mediatek: Add smi dts binding

[Sergei Shtylyov]

Hello.

On 3/6/2015 1:48 PM, yong...@mediatek.com wrote:


From: Yong Wu 



This patch add smi binding document.



Signed-off-by: Yong Wu 
---
  .../devicetree/bindings/soc/mediatek/mediatek,smi.txt   | 17 +
  1 file changed, 17 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/soc/mediatek/mediatek,smi.txt



diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,smi.txt 
b/Documentation/devicetree/bindings/soc/mediatek/mediatek,smi.txt
new file mode 100644
index 000..0fc9d1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,smi.txt
@@ -0,0 +1,17 @@
+SMI hardware block diagram please help check 

+
+Required properties:
+- compatible : must be "mediatek,mediatek,mt8173-smi-larb"


   One "mediatek," is enough. :-)


+- reg : the register of each local arbiter
+- clocks : the clocks of each local arbiter
+- clock-name: larb_sub*(3 clockes at most)


   clock-names.


+
+Example:
+   larb1:larb@1601 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x1601 0 0x1000>;
+   clocks = < MM_SMI_COMMON>,
+   < VDEC_CKEN>,


   Please align with the < above.


+< VDEC_LARB_CKEN>;


   Use tabs instead of spaces, please.


+   clock-names = "larb_sub0", "larb_sub1", "larb_sub2";
+   };


WBR, Sergei

--
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: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Borislav Petkov]

On Fri, Mar 06, 2015 at 11:41:57AM +, Kweh, Hock Leong wrote:
> # cat /any/path/capsule.bin > /sys/devices/platform/efi_capsule/capsule_load

This is straight-forward and clean.

> or doing:
> # echo "/any/path/capsule.bin" > 
> /sys/devices/platform/efi_capsule/capsule_load

This is strange and clumsy. So do the first one please.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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: sched: softlockups in multi_cpu_stop

[Sasha Levin]

On 03/06/2015 09:34 AM, Rafael David Tinoco wrote:
> Are you sure about this ? I have a core dump locked on the same place
> (state machine for powering cpu down for the task swap) from a 3.13 (+
> upstream patches) and this commit wasn't backported yet.

bisect took me to that same commit twice, and I'm running a -next with that
commit reverted and not seeing those hangs anymore.

I also didn't see the hang up until a month or so ago (which matches with that
commit date), and definitely not back in 3.13.


Thanks,
Sasha
--
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] livepatch: fix patched module loading race

[Josh Poimboeuf]

On Fri, Mar 06, 2015 at 08:37:26PM +0900, Masami Hiramatsu wrote:
> Actually, we can suppose this module unloading context is
> not changing universe. thus it is expected behavior, isn't it?

In the case of my proposed consistency model RFC, if the module
unloading task gets preempted, or if mod->exit() calls schedule(), its
task can switch to the new universe before it's done.

And for many modules it could also be possible for other contexts to
access the module's functions in the GOING state before mod->exit()
disables them.

-- 
Josh
--
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 4/6] arm64: kprobes instruction simulation support

[David Long]

On 03/06/15 06:39, Steve Capper wrote:

On 17 February 2015 at 23:11, David Long  wrote:

From: Sandeepa Prabhu 

Kprobes needs simulation of instructions that cannot be stepped
from different memory location, e.g.: those instructions
that uses PC-relative addressing. In simulation, the behaviour
of the instruction is implemented using a copy of pt_regs.

Following instruction catagories are simulated:
  - All branching instructions(conditional, register, and immediate)
  - Literal access instructions(load-literal, adr/adrp)

Conditional execution is limited to branching instructions in
ARM v8. If conditions at PSTATE do not match the condition fields
of opcode, the instruction is effectively NOP. Kprobes considers
this case as 'miss'.

Thanks to Will Cohen for assorted suggested changes.

Signed-off-by: Sandeepa Prabhu 
Signed-off-by: William Cohen 
Signed-off-by: David A. Long 
---


Hi,
Apologies for looking at these late (I was on holiday).

I've applied this series on top of 3.19, but I get the following compile error:
arch/arm64/kernel/kprobes-arm64.c:23:34: fatal error:
probes-simulate-insn.h: No such file or directory
  #include "probes-simulate-insn.h"
   ^
compilation terminated.
scripts/Makefile.build:257: recipe for target
'arch/arm64/kernel/kprobes-arm64.o' failed

Is something missing from this patch?

Cheers,
--
Steve



Yes Steve, the patch is missing three new files.  It passed my testing 
because I had not cleaned out non-checked-in files from my cloned repo. 
 I've put a preliminary version of a v6 patch that addresses other 
feedback in my own public repo, and will send out a new patch in the 
near future after more testing and additional tweaks.


-dl

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