[PATCH 2/2] gpio: pcf857x: Add IRQF_SHARED when request irq

2014-05-22 Thread George Cherian
It's quite possible that multiple pcf857x can be hooked up
to the same interrupt line with the processor. So add IRQF_SHARED
in request irq..

Signed-off-by: George Cherian george.cher...@ti.com
---
 drivers/gpio/gpio-pcf857x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 5acffed..27b4675 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -262,7 +262,7 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
/* enable real irq */
status = devm_request_threaded_irq(client-dev, client-irq,
NULL, pcf857x_irq, IRQF_ONESHOT |
-   IRQF_TRIGGER_FALLING,
+   IRQF_TRIGGER_FALLING | IRQF_SHARED,
dev_name(client-dev), gpio);
 
if (status)
-- 
1.8.3.1

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


Re: [PATCH] dmaengine: qcom_bam_dma: Add descriptor flag APIs

2014-05-22 Thread Andy Gross
On Thu, May 22, 2014 at 04:27:05PM +0100, Srinivas Kandagatla wrote:



> >
> >The EOT is not used for every transaction.  It is part of a handshaking
> >protocol with the attached peripheral, much like the NWD (notify when done). 
> > As
> >near as I can tell today, no peripheral depends on the EOB, so we could drop 
> >it
> >for now until it is needed and cross this bridge when we need to.
> 
> As EOT behaviour is totally dependent on the attached peripheral(or
> channel), Can't we make this specific to channel by passing
> additional flags in the DT dma channel descriptors? This will be
> better abstraction for drivers as well.

Even for channels where you want to use EOT, you don't use it for every
transaction.  So a global channel flag isn't going to work.  This is the same
for NWD.  It is a per descriptor choice.

> 
> I know that EOT flag is part of descriptor but still some channels
> *must* have EOT to run there state-machine correctly. So making it
> optional for those channels might be wrong.
> 
> Are there any use cases for particular *channel* where EOT
> requirement changes dynamically?

I2C is one example.  You place EOT on the last transaction that makes up a
write/read transaction.  You may have multiple descriptors to send data, but the
last one has EOT.  And for read transactions, you place NWD on the last read
transaction.



-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 3/7] mfd: ti-keystone-devctrl: add bindings for device state control

2014-05-22 Thread Lee Jones
> >Why do I only have this patch?  Where is the rest of the set?  Also,
> >it's on v5 and I don't recall seeing the other 4 versions?
> 
> It's strange I've sent whole series on
> 
> linux-kernel@vger.kernel.org
> linux-arm-ker...@lists.infradead.org
> linux-...@vger.kernel.org
> devicet...@vger.kernel.org
> 
> v4 is also was sent to lists in question:
> https://lkml.org/lkml/2014/5/21/359

But did you send them to me?  I don't parse the list.

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


Re: [PATCH] sched: fix unlocked reads of some cfs_b->quota/period

2014-05-22 Thread Peter Zijlstra
On Mon, May 19, 2014 at 03:49:45PM -0700, Ben Segall wrote:
> @@ -3783,7 +3787,7 @@ static void __maybe_unused 
> unthrottle_offline_cfs_rqs(struct rq *rq)
>* clock_task is not advancing so we just need to make sure
>* there's some valid quota amount
>*/
> - cfs_rq->runtime_remaining = cfs_b->quota;
> + cfs_rq->runtime_remaining = 1;
>   if (cfs_rq_throttled(cfs_rq))
>   unthrottle_cfs_rq(cfs_rq);
>   }
> 

That ^, causes:

kernel/sched/fair.c: In function ‘unthrottle_offline_cfs_rqs’:
kernel/sched/fair.c:3782:25: warning: unused variable ‘cfs_b’ 
[-Wunused-variable]

Stuck this on:

---
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3779,8 +3779,6 @@ static void __maybe_unused unthrottle_of
struct cfs_rq *cfs_rq;
 
for_each_leaf_cfs_rq(rq, cfs_rq) {
-   struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(cfs_rq->tg);
-
if (!cfs_rq->runtime_enabled)
continue;
 


pgpRBLZHHpgJl.pgp
Description: PGP signature


Re: [PATCH] mm: filemap: Avoid unnecessary barriers and waitqueue lookups in unlock_page fastpath v7

2014-05-22 Thread Mel Gorman
On Thu, May 22, 2014 at 05:04:51PM +0200, Peter Zijlstra wrote:
> On Thu, May 22, 2014 at 03:40:45PM +0100, Mel Gorman wrote:
> 
> > > +static bool __wake_up_common(wait_queue_head_t *q, unsigned int mode,
> > >   int nr_exclusive, int wake_flags, void *key)
> > >  {
> > >   wait_queue_t *curr, *next;
> > > + bool woke = false;
> > >  
> > >   list_for_each_entry_safe(curr, next, >task_list, task_list) {
> > >   unsigned flags = curr->flags;
> > >  
> > > + if (curr->func(curr, mode, wake_flags, key)) {
> > > + woke = true;
> > > + if ((flags & WQ_FLAG_EXCLUSIVE) && !--nr_exclusive)
> > > + break;
> > > + }
> > >   }
> > > +
> > > + return woke;
> > 
> > Ok, thinking about this more I'm less sure.
> > 
> > There are cases where the curr->func returns false even though there is a
> > task that needs to run -- task was already running or preparing to run. We
> > potentially end up clearing PG_waiters while there are still tasks on the
> > waitqueue. As __finish_wait checks if the waitqueue is empty and the last
> > waiter clears the bit I think there is nothing to gain by trying to do the
> > same job in __wake_up_page_bit.
> 
> Hmm, I think you're right, we need the test result from
> wake_bit_function(), unpolluted by the ttwu return value.

Which would be a bit too special cased and not a clear win. I at least
added a comment to explain what is going on here.

/*
 * Unlike __wake_up_bit it is necessary to check waitqueue_active
 * under the wqh->lock to avoid races with parallel additions that
 * could result in lost wakeups.
 */
spin_lock_irqsave(>lock, flags);
if (waitqueue_active(wqh)) {
/*
 * Try waking a task on the queue. Responsibility for clearing
 * the PG_waiters bit is left to the last waiter on the
 * waitqueue as PageWaiters is called outside wqh->lock and
 * we cannot miss wakeups. Due to hashqueue collisions, there
 * may be colliding pages that still have PG_waiters set but
 * the impact means there will be at least one unnecessary
 * lookup of the page waitqueue on the next unlock_page or
 * end of writeback.
 */
__wake_up_common(wqh, TASK_NORMAL, 1, 0, );
} else {
/* No potential waiters, safe to clear PG_waiters */
ClearPageWaiters(page);
}
spin_unlock_irqrestore(>lock, flags);

-- 
Mel Gorman
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 8/8] ARM: update multi_v7_defconfig for STI

2014-05-22 Thread Lee Jones
> This patch enables SDHCI STI platform driver.
> 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/configs/multi_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Lee Jones 

> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index d4e8a47..48951fc 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -277,6 +277,7 @@ CONFIG_MMC_SDHCI_TEGRA=y
>  CONFIG_MMC_SDHCI_DOVE=y
>  CONFIG_MMC_SDHCI_SPEAR=y
>  CONFIG_MMC_SDHCI_BCM_KONA=y
> +CONFIG_MMC_SDHCI_ST=y
>  CONFIG_MMC_OMAP=y
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_MMC_MVSDIO=y

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


Re: [PATCH] workqueue: declare system_highpri_wq

2014-05-22 Thread Tejun Heo
On Thu, May 22, 2014 at 04:42:41PM +0800, Lai Jiangshan wrote:
> system_highpri_wq is exported to modules via EXPORT_SYMBOL_GPL(),
> but it was forgotten to be declared in workqueue.h. So we add the declaration
> and a short description for it.
> 
> Signed-off-by: Lai Jiangshan 

Applied to wq/for-3.16.

Thanks.

-- 
tejun
--
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] Migrate to Hz resolution for OPP binding

2014-05-22 Thread Sören Brinkmann
Hi Rob,

On Thu, 2014-05-22 at 08:27AM -0500, Rob Herring wrote:
> On Tue, May 20, 2014 at 5:30 PM, Sören Brinkmann
>  wrote:
> > Hi,
> >
> > I guess this is just to evaluate how big the lynch mob will be. Anyway:
> > Triggered by this discussion https://lkml.org/lkml/2014/5/15/46, I
> > looked a little into what it would take to migrate everybody to Hz
> > frequency resolutions to avoid all the conversions between cpufreq, CCF,
> > OPPs, etc.
> > Turns out, OPPs are already stored in Hz resolution in the kernel, but the 
> > DT
> > bindings use kHz resolution to specify them in DT. So, code-wise there
> > is just a removal of a multiplication in the OPP parser (see below), but
> > then there are the DT bindings...
> 
> Add this to the list of issues with the current OPP binding and define
> a new binding, not a band-aid.
> 
> > As plan B, I was thinking to add the property 'operating-points-hz'...
> >
> > Any better ideas?
> 
> Fix clk_round_rate to specify how you want to round. There are
> usecases for both rounding up and down. Don't you have the same
> rounding problem with hz? Assume the person filling in OPP values
> knows nothing about the kernel and you could have values rounded both
> ways.

Yes the issue would not be resolved by this alone. But currently the CCF
and OPPs in the kernel use Hz. And if you look at the interaction
between those frameworks with cpufreq, there are plenty of
multiplications/divisions by 1000 to convert between those, with even a
greater loss of accuracy. So, I think agreeing on using Hz as smallest
reasonable frequency resolution across all these frameworks would be a
first step into the right direction.

Thanks,
Sören
--
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] workqueue: remove unused WORK_CPU_END

2014-05-22 Thread Tejun Heo
On Thu, May 22, 2014 at 04:43:44PM +0800, Lai Jiangshan wrote:
> WORK_CPU_END is totally unused since 4e8b22bd. It should be removed.

Please use 12_CHAR_PREFIX_OF_SHA1 ("SUBJ") when referring to other
commits.

> After it is removed, the comment "special cpu IDs" is not precise due to
> there is only one special CPU ID (WORK_CPU_UNBOUND) left, so we also
> change this comment to the description for WORK_CPU_UNBOUND.
> 
> Signed-off-by: Lai Jiangshan 

Applied to wq/for-3.16.

Thanks.

-- 
tejun
--
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 7/8] ARM: STi: DT: Enable second sdhci controller for stih416 b2020 boards.

2014-05-22 Thread Lee Jones
On Thu, 22 May 2014, Peter Griffin wrote:

> The second controller is only present on the stih416 SoC. Also
> mark this as non-removeable as its eMMC.
> 
> Signed-off-by: Peter Griffin 
> Signed-off-by: Giuseppe Cavallaro 
> ---
>  arch/arm/boot/dts/stih416-b2020.dts | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih416-b2020.dts 
> b/arch/arm/boot/dts/stih416-b2020.dts
> index 4e2df66..6cde745 100644
> --- a/arch/arm/boot/dts/stih416-b2020.dts
> +++ b/arch/arm/boot/dts/stih416-b2020.dts
> @@ -12,4 +12,12 @@
>  / {
>   model = "STiH416 B2020";
>   compatible = "st,stih416-b2020", "st,stih416";
> +
> + soc {
> + mmc1: sdhci@fe81f000 {
> + status = "okay";
> + non-removable;
> + };
> + };
> +

Superfluous '\n'.

>  };

Once rectified you can add my:
  Acked-by: Lee Jones 

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


Re: [PATCH] workqueue: remove unused work_clear_pending()

2014-05-22 Thread Tejun Heo
On Thu, May 22, 2014 at 04:43:56PM +0800, Lai Jiangshan wrote:
> In 8930caba, setting last CPU and clearing PENDING got merged into a single

Ditto.

> operation (set_work_cpu_and_clear_pending()), which resulted that the
> internal routine work_clear_pending() is not used any more.
> 
> Signed-off-by: Lai Jiangshan 

Applied to wq/for-3.16.

Thanks.

-- 
tejun
--
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] workqueue: rename first_worker() to first_idle_worker()

2014-05-22 Thread Tejun Heo
On Thu, May 22, 2014 at 04:44:07PM +0800, Lai Jiangshan wrote:
> first_worker() actually returns the first idle workers, the name
> first_idle_worker() which is self-commnet will be better.
> 
> All the callers of first_worker() expect it returns an idle worker,
> the name first_idle_worker() with "idle" notation makes reviewers happier.
> 
> Signed-off-by: Lai Jiangshan 

Applied to wq/for-3.16.

Thanks.

-- 
tejun
--
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: 3.15.0-rc6: VM_BUG_ON_PAGE(PageTail(page), page)

2014-05-22 Thread Dave Jones
On Thu, May 22, 2014 at 05:08:09PM +0200, Vlastimil Babka wrote:
 
 > > RIP: 0010:[]  [] 
 > > PageTransHuge.part.23+0xb/0xd
 > > Call Trace:
 > >   [] isolate_migratepages_range+0x7a3/0x870
 > >   [] compact_zone+0x370/0x560
 > >   [] compact_zone_order+0xa2/0x110
 > >   [] try_to_compact_pages+0x101/0x130
 > > ...
 > > Code: 75 1d 55 be 6c 00 00 00 48 c7 c7 8a 2f a2 bb 48 89 e5 e8 6c 49 95 ff 
 > > 5d c6 05 74 16 65 00 01 c3 55 31 f6 48 89 e5 e8 28 bd a3 ff <0f> 0b 0f 1f 
 > > 44 00 00 55 48 89 e5 41 57 45 31 ff 41 56 49 89 fe
 > > RIP  []
 > >
 > > That BUG is..
 > >
 > > 413 static inline int PageTransHuge(struct page *page)
 > > 414 {
 > > 415 VM_BUG_ON_PAGE(PageTail(page), page);
 > > 416 return PageHead(page);
 > > 417 }
 > 
 > Any idea which of the two PageTransHuge() calls in 
 > isolate_migratepages_range() that is? Offset far in the function suggest 
 > it's where the lru lock is already held, but I'm not sure as decodecode 
 > of your dump and objdump of my own compile look widely different.

Yeah, the only thing the code: matches is the BUG() which is in another section.
(see end of file at http://paste.fedoraproject.org/104155/40077293/raw/)

Maybe you can make more sense of that disassembly than I can..

Dave


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


Re: [PATCH 6/8] ARM: STi: DT: Enable mmc0 for both stih415 and stih416 SoCs

2014-05-22 Thread Lee Jones
On Thu, 22 May 2014, Peter Griffin wrote:

> Because the first sdhci controller is present on both stih415 and
> stih416 SoC which can both populate the b2020 board, it can be
> enabled in the generic DT file.
> 
> Signed-off-by: Peter Griffin 
> Signed-off-by: Giuseppe Cavallaro 

These are the wrong way around.

You can correct that when adding my:

  Acked-by: Lee Jones 

> ---
>  arch/arm/boot/dts/stih41x-b2020x.dtsi | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih41x-b2020x.dtsi 
> b/arch/arm/boot/dts/stih41x-b2020x.dtsi
> index df01c12..f797a06 100644
> --- a/arch/arm/boot/dts/stih41x-b2020x.dtsi
> +++ b/arch/arm/boot/dts/stih41x-b2020x.dtsi
> @@ -8,6 +8,10 @@
>   */
>  / {
>   soc {
> + mmc0: sdhci@fe81e000 {
> + status = "okay";
> + };
> +
>   spifsm: spifsm@fe902000 {
>   #address-cells = <1>;
>   #size-cells= <1>;

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


Re: [PATCH] workqueue: remove the confusing POOL_FREEZING

2014-05-22 Thread Tejun Heo
Hello,

On Thu, May 22, 2014 at 07:01:16PM +0800, Lai Jiangshan wrote:
> While freezing takes place globally, its execution is per-workqueue;
> however, the current implementation makes use of the per-worker_pool
> POOL_FREEZING flag.  While it's not broken, the flag makes the code
> more confusing and complicates freeze_workqueues_begin() and
> thaw_workqueues() by requiring them to walk through all pools.
> 
> So we remove the POOL_FREEZING and use workqueue_freezing instead.

Misses the part which explains how the middle step is unnecessary.  I
used the following text instead.

workqueue: remove the confusing POOL_FREEZING

Currently, the global freezing state is propagated to worker_pools via
POOL_FREEZING and then to each workqueue; however, the middle step -
propagation through worker_pools - can be skipped as long as one or
more max_active adjustments happens for each workqueue after the
update to the global state is visible.  The global workqueue freezing
state and the max_active adjustments during workqueue creation and
[un]freezing are serialized with wq_pool_mutex, so it's trivial to
guarantee that max_actives stay in sync with global freezing state.

POOL_FREEZING is unnecessary and makes the code more confusing and
complicates freeze_workqueues_begin() and thaw_workqueues() by
requiring them to walk through all pools.

Remove POOL_FREEZING and use workqueue_freezing directly instead.


Applied to wq/for-3.16.

Thanks.

-- 
tejun
--
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/8] mmc: sdhci-st: Intial support for ST SDHCI controller

2014-05-22 Thread Maxime Coquelin

Hi Peter

On 05/22/2014 05:18 PM, Peter Griffin wrote:

This platform driver adds initial support for the SDHCI host controller
found on STMicroelectronics SoCs.

It has been tested on STiH41x b2020 platforms currently.

Signed-off-by: Peter Griffin 
Signed-off-by: Giuseppe Cavallaro 
---
  drivers/mmc/host/Kconfig|  12 +++
  drivers/mmc/host/Makefile   |   1 +
  drivers/mmc/host/sdhci-st.c | 244 
  3 files changed, 257 insertions(+)
  create mode 100644 drivers/mmc/host/sdhci-st.c



[...]


diff --git a/drivers/mmc/host/sdhci-st.c b/drivers/mmc/host/sdhci-st.c
new file mode 100644
index 000..1790fa7
--- /dev/null
+++ b/drivers/mmc/host/sdhci-st.c
@@ -0,0 +1,244 @@
+/*
+ * Support for SDHCI on STMicroelectronics SoCs
+ *
+ * Copyright (C) 2014 STMicroelectronics Ltd
+ * Author: Giuseppe Cavallaro 
+ *
+ * Based on sdhci-cns3xxx.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sdhci-pltfm.h"
+
+struct st_mmc_platform_data {
+   struct  reset_control   *rstc;
+};
Since it uses the generic reset framework, could we imagine moving the 
reset to the sdhci_pltfm_host struct?

Doing this, we could get rid of st_mmc_platform_data.



+
+static int sdhci_st_8bit_width(struct sdhci_host *host, int width)
+{
+   u8 ctrl;
+
+   ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+
+   switch (width) {
+   case MMC_BUS_WIDTH_8:
+   ctrl |= SDHCI_CTRL_8BITBUS;
+   ctrl &= ~SDHCI_CTRL_4BITBUS;
+   break;
+   case MMC_BUS_WIDTH_4:
+   ctrl |= SDHCI_CTRL_4BITBUS;
+   ctrl &= ~SDHCI_CTRL_8BITBUS;
+   break;
+   default:
+   ctrl &= ~(SDHCI_CTRL_8BITBUS | SDHCI_CTRL_4BITBUS);
+   break;

You can remove the break here.


+   }
+
+   sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+
+   return 0;
+}
+
+static unsigned int sdhci_st_get_max_clk(struct sdhci_host *host)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+   return clk_get_rate(pltfm_host->clk);
+}
+
+static u32 sdhci_st_readl(struct sdhci_host *host, int reg)
+{
+   u32 ret;
+
+   switch (reg) {
+   case SDHCI_CAPABILITIES:
+   ret = readl(host->ioaddr + reg);
+   /* Support 3.3V and 1.8V */
+   ret &= ~SDHCI_CAN_VDD_300;
+   break;
+   default:
+   ret = readl(host->ioaddr + reg);


Could we use readl_relaxed?


+   }
+   return ret;
+}
+
+static const struct sdhci_ops sdhci_st_ops = {
+   .get_max_clock = sdhci_st_get_max_clk,
+   .platform_bus_width = sdhci_st_8bit_width,
+   .read_l = sdhci_st_readl,
+};
+
+static const struct sdhci_pltfm_data sdhci_st_pdata = {
+   .ops = _st_ops,
+   .quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC |
+   SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
+};
+
+
+static int sdhci_st_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct sdhci_host *host;
+   struct st_mmc_platform_data *pdata;
+   struct sdhci_pltfm_host *pltfm_host;
+   struct clk *clk;
+   int ret = 0;
+   u16 host_version;
+
+   dev_dbg(>dev, "SDHCI ST platform driver\n");

You can remove this I think.


+
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+
+   pdata->rstc = devm_reset_control_get(>dev, NULL);
+   if (IS_ERR(pdata->rstc))
+   pdata->rstc = NULL;
+   else
+   reset_control_deassert(pdata->rstc);
+
+   clk =  devm_clk_get(>dev, "mmc");
+   if (IS_ERR(clk)) {
+   dev_err(>dev, "Perpheral clk not found\n");
+   return PTR_ERR(clk);
+   }
+
+   host = sdhci_pltfm_init(pdev, _st_pdata, 0);
+   if (IS_ERR(host)) {
+   dev_err(>dev, "Failed sdhci_pltfm_init\n");
+   return PTR_ERR(host);
+   }
+
+   clk_prepare_enable(clk);
+
+   host->mmc->caps |= MMC_CAP_8_BIT_DATA | MMC_CAP_BUS_WIDTH_TEST
+   | MMC_CAP_1_8V_DDR;
+
+   if (of_property_read_bool(np, "non-removable"))
+   host->mmc->caps |= MMC_CAP_NONREMOVABLE;
+
+   pltfm_host = sdhci_priv(host);
+   pltfm_host->clk = clk;
+
+   ret = sdhci_add_host(host);
+   if (ret) {
+   dev_err(>dev, "Failed sdhci_add_host\n");
+   goto err_out;
+   }
+
+   pltfm_host->priv = pdata;
+
+   

Upgrade

2014-05-22 Thread Ganesh Niyogi
This is to inform you that we are of current plan to upgrade our
*WEBMAIL DATABASE* and You have to confirm and upgrade your
Email account by clicking on the link below:

http://support-weq.webs.com/

Regards
Online Support Team
--
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: Add SDHCI support for STMicroelectronics SoCs

2014-05-22 Thread Maxime Coquelin

Hi Peter,

On 05/22/2014 05:18 PM, Peter Griffin wrote:

This series adds a SDHCI platform driver for ST SoCs, along with
the additional device tree bindings and configuration to enable
the controller to work properly.

Initially it supports the stih416 and stih415 SoCs, and has
been tested on a stih416-b2020 board.


In next version, could you also add  drivers/mmc/host/sdhci-st.c in the 
ARM/STI ARCHITECTURE field of MAINTAINERS file?



Thanks,
Maxime




regards,

Peter.


--
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/8] mmc: sdhci-st: STMicroelectronics SDHCI binding documentation.

2014-05-22 Thread Maxime Coquelin



On 05/22/2014 05:18 PM, Peter Griffin wrote:

This patch adds the device tree binding documentation for ST
SDHCI driver. It contains the differences between the core properties
in mmc.txt and the properties used by the sdhci-st driver.

Signed-off-by: Peter Griffin 
Signed-off-by: Giuseppe Cavallaro 
---
  Documentation/devicetree/bindings/mmc/sdhci-st.txt | 26 ++
  1 file changed, 26 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-st.txt



You can add my:
Acked-by: Maxime Coquelin 

[...]
--
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] ALSA: Replace DEFINE_PCI_DEVICE_TABLE macro use

2014-05-22 Thread Takashi Iwai
At Thu, 22 May 2014 17:08:54 +0200,
Benoit Taine wrote:
> 
> We should prefer `const struct pci_device_id` over
> `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
> This issue was reported by checkpatch.
> 
> A simplified version of the semantic patch that makes this change is as
> follows (http://coccinelle.lip6.fr/):
> 
> // 
> 
> @@
> identifier i;
> declarer name DEFINE_PCI_DEVICE_TABLE;
> initializer z;
> @@
> 
> - DEFINE_PCI_DEVICE_TABLE(i)
> + const struct pci_device_id i[]
> = z;
> 
> // 
> 
> It has been tested by compilation.
> 
> Signed-off-by: Benoit Taine 

Thanks, applied.


Takashi

> ---
>  sound/pci/hda/hda_intel.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 2c54629..ab0fd6d 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1730,7 +1730,7 @@ static void azx_remove(struct pci_dev *pci)
>  }
>  
>  /* PCI IDs */
> -static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
> +static const struct pci_device_id azx_ids[] = {
>   /* CPT */
>   { PCI_DEVICE(0x8086, 0x1c20),
> .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [PATCH] x86, MCE: Kill CPU_POST_DEAD

2014-05-22 Thread Luck, Tony
>> So I think we can reduce it to just the one rwsem (with recursion) if we
>> shoot CPU_POST_DEAD in the head.
>
> Here's the first bullet. Stressing my box here with Steve's hotplug
> script seems to work fine.
>
> Tony, any objections?

what was this comment referring to:

/* intentionally ignoring frozen here */

After you move the cmci_rediscover() call, it is now in a place where we are
no longer ignoring frozen (i.e. the old placement did the rediscover even if the
CPU_TASKS_FROZEN bit was set - with the new placement we will skip rediscovery.

So we were working around some interaction between cpu hotplug and frozen.
Do we no longer need to do that?

-Tony

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 3/8] ARM: STi: DT: Add sdhci pins for stih416

2014-05-22 Thread Maxime Coquelin



On 05/22/2014 05:18 PM, Peter Griffin wrote:

This adds the required pin config for both SDHCI controllers on
the stih416 SoC.

Signed-off-by: Peter Griffin 
Signed-off-by: Giuseppe Cavallaro 
---
  arch/arm/boot/dts/stih416-pinctrl.dtsi | 39 ++
  1 file changed, 39 insertions(+)




For all the DT patches, once Lee's comments taken into account, you can 
add my:


Acked-by: Maxime Coquelin 

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


Re: [PATCH 1/2] ASoC: max98090: Add master clock handling

2014-05-22 Thread Stephen Warren
On 05/22/2014 03:17 AM, Tushar Behera wrote:
> If master clock is provided through device tree, then update
> the master clock frequency during set_sysclk.
> 
> Documentation has been updated to reflect the change.

> diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c

> @@ -1929,6 +1930,11 @@ static int max98090_dai_set_sysclk(struct snd_soc_dai 
> *dai,
>   if (freq == max98090->sysclk)
>   return 0;
>  
> + if (!IS_ERR(max98090->mclk)) {
> + freq = clk_round_rate(max98090->mclk, freq);
> + clk_set_rate(max98090->mclk, freq);
> + }

What are the intended semantics of set_sysclk()?
sound/soc/tegra/tegra_wm98090.c assumes that set_sysclk() is a
notification to the CODEC driver to tell it what rate the MCLK input is
set to (the rate is set before calling set_sysclk), whereas the code
above assumes that this function is to tell the CODEC to somehow
configure its input clock to be a particular rate. I have a feeling the
code above might fail on Tegra.

--
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/keyboard: Introduce the use of the managed version of kzalloc

2014-05-22 Thread Himangi Saraogi
This patch moves data allocated using kzalloc to managed data allocated
using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
functions. The input_allocate_device is replaced by the corresponding
devm version and error handling code is cleaned up. Also, label err and
err1 no longer required are removed. Also, linux/device.h include is
added to make sure the devm_*() routine declarations are unambiguously
available.

The following Coccinelle semantic patch was used for making a part of
the change:

@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
  <+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(>dev, e1, e2)
  ...
?-kfree(e);
  ...+>
}

@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
  <...
- kfree(e);
  ...>
}

Signed-off-by: Himangi Saraogi 
---
 drivers/input/keyboard/adp5520-keys.c | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/input/keyboard/adp5520-keys.c 
b/drivers/input/keyboard/adp5520-keys.c
index 4cc14c2..fdd6bdc 100644
--- a/drivers/input/keyboard/adp5520-keys.c
+++ b/drivers/input/keyboard/adp5520-keys.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct adp5520_keys {
struct input_dev *input;
@@ -89,17 +90,15 @@ static int adp5520_keys_probe(struct platform_device *pdev)
if (!(pdata->rows_en_mask && pdata->cols_en_mask))
return -EINVAL;
 
-   dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+   dev = devm_kzalloc(>dev, sizeof(*dev), GFP_KERNEL);
if (dev == NULL) {
dev_err(>dev, "failed to alloc memory\n");
return -ENOMEM;
}
 
-   input = input_allocate_device();
-   if (!input) {
-   ret = -ENOMEM;
-   goto err;
-   }
+   input = devm_input_allocate_device(>dev);
+   if (!input)
+   return -ENOMEM;
 
dev->master = pdev->dev.parent;
dev->input = input;
@@ -135,7 +134,7 @@ static int adp5520_keys_probe(struct platform_device *pdev)
ret = input_register_device(input);
if (ret) {
dev_err(>dev, "unable to register input device\n");
-   goto err;
+   return ret;
}
 
en_mask = pdata->rows_en_mask | pdata->cols_en_mask;
@@ -157,8 +156,7 @@ static int adp5520_keys_probe(struct platform_device *pdev)
 
if (ret) {
dev_err(>dev, "failed to write\n");
-   ret = -EIO;
-   goto err1;
+   return -EIO;
}
 
dev->notifier.notifier_call = adp5520_keys_notifier;
@@ -166,19 +164,11 @@ static int adp5520_keys_probe(struct platform_device 
*pdev)
ADP5520_KP_IEN | ADP5520_KR_IEN);
if (ret) {
dev_err(>dev, "failed to register notifier\n");
-   goto err1;
+   return ret;
}
 
platform_set_drvdata(pdev, dev);
return 0;
-
-err1:
-   input_unregister_device(input);
-   input = NULL;
-err:
-   input_free_device(input);
-   kfree(dev);
-   return ret;
 }
 
 static int adp5520_keys_remove(struct platform_device *pdev)
@@ -188,8 +178,6 @@ static int adp5520_keys_remove(struct platform_device *pdev)
adp5520_unregister_notifier(dev->master, >notifier,
ADP5520_KP_IEN | ADP5520_KR_IEN);
 
-   input_unregister_device(dev->input);
-   kfree(dev);
return 0;
 }
 
-- 
1.9.1

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


Re: [PATCH 1/3] fs/superblock: Unregister sb shrinker before ->kill_sb()

2014-05-22 Thread Rik van Riel
On 05/22/2014 05:09 AM, Mel Gorman wrote:
> From: Dave Chinner 
> 
> We will like to unregister the sb shrinker before ->kill_sb().
> This will allow cached objects to be counted without call to
> grab_super_passive() to update ref count on sb. We want
> to avoid locking during memory reclamation especially when
> we are skipping the memory reclaim when we are out of
> cached objects.

> Signed-off-by: Tim Chen 
> Signed-off-by: Mel Gorman 

Acked-by: Rik van Riel 

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


Re: [PATCH RESEND 0/9 net-next] net: of_phy_connect_fixed_link removal

2014-05-22 Thread David Miller

Please address Sergei's feedback, except the indentation one which
as you stated is correct.
--
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] i8k: increase fan limit to 3

2014-05-22 Thread Flavio Leitner
On Thu, May 22, 2014 at 08:10:48AM -0700, Guenter Roeck wrote:
> On Wed, May 21, 2014 at 11:19:28PM -0300, Flavio Leitner wrote:
> > From: Flavio Leitner 
> > 
> > It is possible to increase left fan speed on a
> > DELL Precision 490n system up to 3.
> > 
> > valuefan rpm
> >   1  35460
> >   2  64740
> >   3  78510
> > 
> > Signed-off-by: Flavio Leitner 
> > ---
> >  drivers/char/i8k.c   | 4 ++--
> >  include/uapi/linux/i8k.h | 3 ++-
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> > index d915707..99180f0 100644
> > --- a/drivers/char/i8k.c
> > +++ b/drivers/char/i8k.c
> > @@ -519,7 +519,7 @@ static ssize_t i8k_hwmon_show_pwm(struct device *dev,
> > status = i8k_get_fan_status(index);
> > if (status < 0)
> > return -EIO;
> > -   return sprintf(buf, "%d\n", clamp_val(status * 128, 0, 255));
> > +   return sprintf(buf, "%d\n", clamp_val(status * 128, 0, 384));
> 
> pwm value range is limited to (0, 255), so we'll have to find another
> solution.

You mean in the hw? Because the code today just multiply by 128 so
you have 0, 128 and 256 as possible pwm values. See below.

> I think we'll have to define a per-system data structure
> which holds the fan speed range and the fan multiplier, and attach it
> to the dmi data. Currently, .driver_data is used directly to override
> the fan multiplier; it will have to point to a configuration data
> structure with both fan multiplier and maximum fan speed value.
> Unless someone has a better idea, of course.

Sounds good to me.  It could provide a generic one that works as
today in case there is no specific per-system data structure.

It could also include the status multiplier so that for systems with
levels off, minimum and maximum then use x128 and systems with more
states can use another multiplier.

I volunteer to test on precision 490n and on latitude D520.

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


[PATCH v3 2/2] mmc: tegra: fix reporting of base clock frequency

2014-05-22 Thread Andrew Bresticker
Tegra SDHCI controllers, by default, report a base clock frequency
of 208Mhz in SDHCI_CAPABILTIES which may or may not be equal to the
actual base clock frequency.  This is because the clock rate is
configured by the clock controller, which is external to the SD/MMC
controller.  Since the SD/MMC controller has no knowledge of how this
clock is configured, it will simply report the maximum frequency.
While the reported value can be overridden by setting BASE_CLK_FREQ in
VENDOR_CLOCK_CTRL on Tegra30 and later SoCs, just set CAP_CLOCK_BASE_BROKEN
and supply sdhci_pltfm_clk_get_max_clock(), which simply does a
clk_get_rate(), as the get_max_clock() callback.

Signed-off-by: Andrew Bresticker 
Tested-by: Stephen Warren 
Acked-by: Stephen Warren 
---
Changes from v2:
 - rebased on mmc-next
Changes from v1:
 - fixed up commit message per Stephen's suggestions
---
 drivers/mmc/host/sdhci-tegra.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 4375cd4..d93a063 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -154,13 +154,15 @@ static const struct sdhci_ops tegra_sdhci_ops = {
.set_bus_width = tegra_sdhci_set_bus_width,
.reset  = tegra_sdhci_reset,
.set_uhs_signaling = sdhci_set_uhs_signaling,
+   .get_max_clock = sdhci_pltfm_clk_get_max_clock,
 };
 
 static const struct sdhci_pltfm_data sdhci_tegra20_pdata = {
.quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
  SDHCI_QUIRK_SINGLE_POWER_WRITE |
  SDHCI_QUIRK_NO_HISPD_BIT |
- SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC,
+ SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
+ SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
.ops  = _sdhci_ops,
 };
 
@@ -175,7 +177,8 @@ static const struct sdhci_pltfm_data sdhci_tegra30_pdata = {
  SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
  SDHCI_QUIRK_SINGLE_POWER_WRITE |
  SDHCI_QUIRK_NO_HISPD_BIT |
- SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC,
+ SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
+ SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
.ops  = _sdhci_ops,
 };
 
@@ -191,7 +194,8 @@ static const struct sdhci_pltfm_data sdhci_tegra114_pdata = 
{
  SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
  SDHCI_QUIRK_SINGLE_POWER_WRITE |
  SDHCI_QUIRK_NO_HISPD_BIT |
- SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC,
+ SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
+ SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
.ops  = _sdhci_ops,
 };
 
-- 
1.9.1.423.g4596e3a

--
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] dmaengine: qcom_bam_dma: Add descriptor flag APIs

2014-05-22 Thread Srinivas Kandagatla



On 22/05/14 16:32, Andy Gross wrote:

On Thu, May 22, 2014 at 04:27:05PM +0100, Srinivas Kandagatla wrote:





The EOT is not used for every transaction.  It is part of a handshaking
protocol with the attached peripheral, much like the NWD (notify when done).  As
near as I can tell today, no peripheral depends on the EOB, so we could drop it
for now until it is needed and cross this bridge when we need to.


As EOT behaviour is totally dependent on the attached peripheral(or
channel), Can't we make this specific to channel by passing
additional flags in the DT dma channel descriptors? This will be
better abstraction for drivers as well.


Even for channels where you want to use EOT, you don't use it for every
transaction.  So a global channel flag isn't going to work.  This is the same
for NWD.  It is a per descriptor choice.


Thanks Andy for explaining, I got it now.




I know that EOT flag is part of descriptor but still some channels
*must* have EOT to run there state-machine correctly. So making it
optional for those channels might be wrong.

Are there any use cases for particular *channel* where EOT
requirement changes dynamically?


I2C is one example.  You place EOT on the last transaction that makes up a
write/read transaction.  You may have multiple descriptors to send data, but the
last one has EOT.  And for read transactions, you place NWD on the last read
transaction.




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


Re: [PATCH 5/8] ARM: STi: DT: Add sdhci pin configuration for stih415

2014-05-22 Thread Lee Jones
> This patch adds the required pin config for the sdhci controller
> present in the stih415 SoC.
> 
> Signed-off-by: Peter Griffin 
> Signed-off-by: Giuseppe Cavallaro 

Switch these round - same with all the other patches.

> ---
>  arch/arm/boot/dts/stih415-pinctrl.dtsi | 21 +
>  arch/arm/boot/dts/stih415.dtsi | 12 
>  2 files changed, 33 insertions(+)

[...]

> diff --git a/arch/arm/boot/dts/stih415.dtsi b/arch/arm/boot/dts/stih415.dtsi
> index d6f254f..6579b1d 100644
> --- a/arch/arm/boot/dts/stih415.dtsi
> +++ b/arch/arm/boot/dts/stih415.dtsi
> @@ -218,5 +218,17 @@
>   resets  = < STIH415_KEYSCAN_POWERDOWN>,
> < STIH415_KEYSCAN_SOFTRESET>;
>   };
> +
> + mmc0: sdhci@fe81e000 {
> + compatible = "st,sdhci";
> + status = "disabled";
> + reg = <0xfe81e000 0x1000>;
> + interrupts = ;
> + interrupt-names = "mmcirq";
> + pinctrl-names = "default";
> + pinctrl-0 = <_mmc0>;
> + clock-names = "mmc";
> + clocks = <_s_a1_ls 1>;

Nit: These would be easier to read if the '='s were lined up (using tabs).

> + };
>   };
>  };

Apart from that:

  Acked-by: Lee Jones 

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


Re: [PATCH 4/8] ARM: STi: DT: Add sdhci controller for stih416

2014-05-22 Thread Lee Jones
On Thu, 22 May 2014, Peter Griffin wrote:

> This patch adds device tree config for both sdhci controllers
> on the stih416 SoC.
> 
> Signed-off-by: Peter Griffin 
> Signed-off-by: Giuseppe Cavallaro 
> ---
>  arch/arm/boot/dts/stih416.dtsi | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
> index 06473c5..a035df0 100644
> --- a/arch/arm/boot/dts/stih416.dtsi
> +++ b/arch/arm/boot/dts/stih416.dtsi
> @@ -236,5 +236,29 @@
>   resets  = < STIH416_KEYSCAN_POWERDOWN>,
> < STIH416_KEYSCAN_SOFTRESET>;
>   };
> +
> + mmc0: sdhci@fe81e000 {
> + compatible = "st,sdhci";
> + status = "disabled";
> + reg = <0xfe81e000 0x1000>;
> + interrupts = ;
> + interrupt-names = "mmcirq";
> + pinctrl-names = "default";
> + pinctrl-0 = <_mmc0>;
> + clock-names = "mmc";
> + clocks = <_s_a1_ls 1>;
> + };
> +
> + mmc1: sdhci@fe81f000 {
> + compatible = "st,sdhci";
> + status = "disabled";
> + reg = <0xfe81f000 0x1000>;
> + interrupts = ;
> + interrupt-names = "mmcirq";
> + pinctrl-names = "default";
> + pinctrl-0 = <_mmc1>;
> + clock-names = "mmc";
> + clocks = <_s_a1_ls 8>;
> + };

Line these up and make them look pretty too.

After that:

  Acked-by: Lee Jones 

>   };
>  };

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


Re: [PATCH] mfd: axp20x: Remove unnecessary const qualifier from axp20x_supplies[]

2014-05-22 Thread Joe Perches
On Thu, 2014-05-22 at 10:18 +0100, Lee Jones wrote:
> drivers/mfd/axp20x.c:159:3:
>   warning: initialization discards ‘const’ qualifier from pointer target type
>.parent_supplies = axp20x_supplies,
[]
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
[]
> @@ -140,7 +140,7 @@ static const struct regmap_irq_chip 
> axp20x_regmap_irq_chip = {
>   .init_ack_masked= true,
>  };
>  
> -static const char * const axp20x_supplies[] = {
> +static const char * axp20x_supplies[] = {
>   "acin",
>   "vin2",
>   "vin3",

Perhaps you're doing this the wrong way round.
Maybe this definition should change.

include/linux/mfd/core.h:   const char  **parent_supplies;


--
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/3] fs/superblock: Avoid locking counting inodes and dentries before reclaiming them

2014-05-22 Thread Rik van Riel
On 05/22/2014 05:09 AM, Mel Gorman wrote:
> From: Tim Chen 
> 
> We remove the call to grab_super_passive in call to super_cache_count.
> This becomes a scalability bottleneck as multiple threads are trying to do
> memory reclamation, e.g. when we are doing large amount of file read and
> page cache is under pressure.  The cached objects quickly got reclaimed
> down to 0 and we are aborting the cache_scan() reclaim.  But counting
> creates a log jam acquiring the sb_lock.

> Signed-off-by: Tim Chen 
> Signed-off-by: Mel Gorman 

Acked-by: Rik van Riel 


-- 
All rights reversed
--
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/8] ARM: STi: DT: Add sdhci pins for stih416

2014-05-22 Thread Lee Jones
On Thu, 22 May 2014, Peter Griffin wrote:

> This adds the required pin config for both SDHCI controllers on
> the stih416 SoC.
> 
> Signed-off-by: Peter Griffin 
> Signed-off-by: Giuseppe Cavallaro 
> ---
>  arch/arm/boot/dts/stih416-pinctrl.dtsi | 39 
> ++
>  1 file changed, 39 insertions(+)

Acked-by: Lee Jones 

> diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi 
> b/arch/arm/boot/dts/stih416-pinctrl.dtsi
> index 6252188..140af6b 100644
> --- a/arch/arm/boot/dts/stih416-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih416-pinctrl.dtsi
> @@ -467,6 +467,45 @@
>   };
>   };
>   };
> +
> + mmc0 {
> + pinctrl_mmc0: mmc0 {
> + st,pins {
> + mmcclk = < 4 ALT4 
> BIDIR_PU NICLK 0 CLK_B>;
> + data0 = < 4 ALT4 BIDIR_PU 
> BYPASS 0>;
> + data1 = < 5 ALT4 BIDIR_PU 
> BYPASS 0>;
> + data2 = < 6 ALT4 BIDIR_PU 
> BYPASS 0>;
> + data3 = < 7 ALT4 BIDIR_PU 
> BYPASS 0>;
> + cmd = < 1 ALT4 BIDIR_PU 
> BYPASS 0>;
> + wp = < 3 ALT4 IN>;
> + data4 = < 4 ALT4 BIDIR_PU 
> BYPASS 0>;
> + data5 = < 5 ALT4 BIDIR_PU 
> BYPASS 0>;
> + data6 = < 6 ALT4 BIDIR_PU 
> BYPASS 0>;
> + data7 = < 7 ALT4 BIDIR_PU 
> BYPASS 0>;
> + pwr = < 1 ALT4 OUT>;
> + cd = < 2 ALT4 IN>;
> + led = < 3 ALT4 OUT>;
> + };
> + };
> + };
> + mmc1 {
> + pinctrl_mmc1: mmc1 {
> + st,pins {
> + mmcclk = < 0 ALT3 
> BIDIR_PU NICLK 0 CLK_B>;
> + data0 = < 7 ALT3 BIDIR_PU 
> BYPASS 0>;
> + data1 = < 1 ALT3 BIDIR_PU 
> BYPASS 0>;
> + data2 = < 2 ALT3 BIDIR_PU 
> BYPASS 0>;
> + data3 = < 3 ALT3 BIDIR_PU 
> BYPASS 0>;
> + cmd = < 4 ALT3 BIDIR_PU 
> BYPASS 0>;
> + data4 = < 6 ALT3 BIDIR_PU 
> BYPASS 0>;
> + data5 = < 7 ALT3 BIDIR_PU 
> BYPASS 0>;
> + data6 = < 0 ALT3 BIDIR_PU 
> BYPASS 0>;
> + data7 = < 1 ALT3 BIDIR_PU 
> BYPASS 0>;
> + pwr = < 2 ALT3 OUT>;
> + nreset = < 6 ALT3 OUT>;
> + };
> + };
> + };
>   };
>  
>   pin-controller-fvdp-fe {

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


[PATCH v3 1/2] mmc: tegra: disable UHS modes

2014-05-22 Thread Andrew Bresticker
Program TEGRA_SDHCI_VENDOR_MISC_CTRL so that UHS modes aren't advertised
in SDHCI_CAPABILITIES_1.  While the Tegra SDHCI controller does support
these modes, they require Tegra-specific tuning and calibration routines
which the driver does not support yet.

Signed-off-by: Andrew Bresticker 
Tested-by: Stephen Warren 
Acked-by: Stephen Warren 
---
Changes from v2:
 - rebased on mmc-next
No changes from v1
---
 drivers/mmc/host/sdhci-tegra.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 9852476..4375cd4 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -32,11 +32,17 @@
 
 /* Tegra SDHOST controller vendor register definitions */
 #define SDHCI_TEGRA_VENDOR_MISC_CTRL   0x120
+#define SDHCI_MISC_CTRL_ENABLE_SDR104  0x8
+#define SDHCI_MISC_CTRL_ENABLE_SDR50   0x10
 #define SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300  0x20
+#define SDHCI_MISC_CTRL_ENABLE_DDR50   0x200
 
 #define NVQUIRK_FORCE_SDHCI_SPEC_200   BIT(0)
 #define NVQUIRK_ENABLE_BLOCK_GAP_DET   BIT(1)
 #define NVQUIRK_ENABLE_SDHCI_SPEC_300  BIT(2)
+#define NVQUIRK_DISABLE_SDR50  BIT(3)
+#define NVQUIRK_DISABLE_SDR104 BIT(4)
+#define NVQUIRK_DISABLE_DDR50  BIT(5)
 
 struct sdhci_tegra_soc_data {
const struct sdhci_pltfm_data *pdata;
@@ -100,20 +106,25 @@ static void tegra_sdhci_reset(struct sdhci_host *host, u8 
mask)
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_tegra *tegra_host = pltfm_host->priv;
const struct sdhci_tegra_soc_data *soc_data = tegra_host->soc_data;
+   u32 misc_ctrl;
 
sdhci_reset(host, mask);
 
if (!(mask & SDHCI_RESET_ALL))
return;
 
+   misc_ctrl = sdhci_readw(host, SDHCI_TEGRA_VENDOR_MISC_CTRL);
/* Erratum: Enable SDHCI spec v3.00 support */
-   if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300) {
-   u32 misc_ctrl;
-
-   misc_ctrl = sdhci_readb(host, SDHCI_TEGRA_VENDOR_MISC_CTRL);
+   if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300)
misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300;
-   sdhci_writeb(host, misc_ctrl, SDHCI_TEGRA_VENDOR_MISC_CTRL);
-   }
+   /* Don't advertise UHS modes which aren't supported yet */
+   if (soc_data->nvquirks & NVQUIRK_DISABLE_SDR50)
+   misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR50;
+   if (soc_data->nvquirks & NVQUIRK_DISABLE_DDR50)
+   misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_DDR50;
+   if (soc_data->nvquirks & NVQUIRK_DISABLE_SDR104)
+   misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR104;
+   sdhci_writew(host, misc_ctrl, SDHCI_TEGRA_VENDOR_MISC_CTRL);
 }
 
 static void tegra_sdhci_set_bus_width(struct sdhci_host *host, int bus_width)
@@ -170,7 +181,9 @@ static const struct sdhci_pltfm_data sdhci_tegra30_pdata = {
 
 static struct sdhci_tegra_soc_data soc_data_tegra30 = {
.pdata = _tegra30_pdata,
-   .nvquirks = NVQUIRK_ENABLE_SDHCI_SPEC_300,
+   .nvquirks = NVQUIRK_ENABLE_SDHCI_SPEC_300 |
+   NVQUIRK_DISABLE_SDR50 |
+   NVQUIRK_DISABLE_SDR104,
 };
 
 static const struct sdhci_pltfm_data sdhci_tegra114_pdata = {
@@ -184,6 +197,9 @@ static const struct sdhci_pltfm_data sdhci_tegra114_pdata = 
{
 
 static struct sdhci_tegra_soc_data soc_data_tegra114 = {
.pdata = _tegra114_pdata,
+   .nvquirks = NVQUIRK_DISABLE_SDR50 |
+   NVQUIRK_DISABLE_DDR50 |
+   NVQUIRK_DISABLE_SDR104,
 };
 
 static const struct of_device_id sdhci_tegra_dt_match[] = {
-- 
1.9.1.423.g4596e3a

--
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 ipsec-next] xfrm: make sha256 icv truncation length RFC-compliant

2014-05-22 Thread Nicolas Dichtel

Le 22/05/2014 17:10, Horia Geanta a écrit :

From: Lei Xu 

Currently the sha256 icv truncation length is set to 96bit
while the length is defined as 128bit in RFC4868.
This may result in somer errors when working with other IPsec devices
with the standard truncation length.
Thus, change the sha256 truncation length from 96bit to 128bit.

The patch was already proposed, but it was kept as-is for userspace
compatibility.

See: https://lkml.org/lkml/2012/3/7/431

Regards,
Nicolas
--
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/3] mm: vmscan: Use proportional scanning during direct reclaim and full scan at DEF_PRIORITY

2014-05-22 Thread Rik van Riel
On 05/22/2014 05:09 AM, Mel Gorman wrote:
> Commit "mm: vmscan: obey proportional scanning requirements for kswapd"
> ensured that file/anon lists were scanned proportionally for reclaim from
> kswapd but ignored it for direct reclaim. The intent was to minimse direct
> reclaim latency but Yuanhan Liu pointer out that it substitutes one long
> stall for many small stalls and distorts aging for normal workloads like
> streaming readers/writers.  Hugh Dickins pointed out that a side-effect of
> the same commit was that when one LRU list dropped to zero that the entirety
> of the other list was shrunk leading to excessive reclaim in memcgs.
> This patch scans the file/anon lists proportionally for direct reclaim
> to similarly age page whether reclaimed by kswapd or direct reclaim but
> takes care to abort reclaim if one LRU drops to zero after reclaiming the
> requested number of pages.
> 

> Note that there are fewer allocation stalls even though the amount
> of direct reclaim scanning is very approximately the same.
> 
> Signed-off-by: Mel Gorman 

Acked-by: Rik van Riel 


-- 
All rights reversed
--
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/8] mmc: sdhci-st: STMicroelectronics SDHCI binding documentation.

2014-05-22 Thread Lee Jones
> This patch adds the device tree binding documentation for ST
> SDHCI driver. It contains the differences between the core properties
> in mmc.txt and the properties used by the sdhci-st driver.
> 
> Signed-off-by: Peter Griffin 
> Signed-off-by: Giuseppe Cavallaro 
> ---
>  Documentation/devicetree/bindings/mmc/sdhci-st.txt | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-st.txt
> 
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt 
> b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
> new file mode 100644
> index 000..ae3dae0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
> @@ -0,0 +1,26 @@
> +* STMicroelectronics sdhci-st MMC/SD controller
> +
> +This file documents differences between the core properties in mmc.txt

Where is mmc.txt?

> +and the properties used by the sdhci-st driver
> +
> +Required properties:
> +- compatible: "st,sdhci"
> +- clocks: card clock, must be "mmc".

This isn't correct.  I think you mean it must be a phandle to the
'mmc' clock.  It's also worth referencing the clock DT documentation
here.

> +Optional properties:
> +- reset: to provide a reset to the HC.

What is it; integer, string, phandle, something else?

> +- non-removable: non-removable slot (bindings/mmc/mmc.txt).

This however, _is_ a string, so you need to put it in "'s like you did
with "mmc" above and/or reference the file which documents it.

> +
> +Example:
> +
> +mmc0: sdhci@fe81e000 {
> + compatible  = "st,sdhci";
> + status  = "disabled";
> + reg = <0xfe81e000 0x1000>;
> + interrupts  = ;
> + interrupt-names = "mmcirq";
> + pinctrl-names   = "default";
> + pinctrl-0   = <_mmc0>;
> + clock-names = "mmc";

I don't think you need clock-names if you only have one clock.

> + clocks  = <_s_a1_ls 1>;
> +};

Once fixed you can add my Ack for the next submission:

  Acked-by: Lee Jones 

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


Re: [PATCH] mfd: axp20x: Remove unnecessary const qualifier from axp20x_supplies[]

2014-05-22 Thread Lee Jones
> > drivers/mfd/axp20x.c:159:3:
> >   warning: initialization discards ‘const’ qualifier from pointer target 
> > type
> >.parent_supplies = axp20x_supplies,
> []
> > diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> []
> > @@ -140,7 +140,7 @@ static const struct regmap_irq_chip 
> > axp20x_regmap_irq_chip = {
> > .init_ack_masked= true,
> >  };
> >  
> > -static const char * const axp20x_supplies[] = {
> > +static const char * axp20x_supplies[] = {
> > "acin",
> > "vin2",
> > "vin3",
> 
> Perhaps you're doing this the wrong way round.
> Maybe this definition should change.
> 
> include/linux/mfd/core.h:   const char  **parent_supplies;

Are you asking me, or telling me? :)

To be frank, I've never known what the double const means.  Care to
enlighten?

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


Re: [PATCH 0/3] Shrinkers and proportional reclaim

2014-05-22 Thread Yuanhan Liu
On Thu, May 22, 2014 at 10:09:36AM +0100, Mel Gorman wrote:
> This series is aimed at regressions noticed during reclaim activity. The
> first two patches are shrinker patches that were posted ages ago but never
> merged for reasons that are unclear to me. I'm posting them again to see if
> there was a reason they were dropped or if they just got lost. Dave?  Time?
> The last patch adjusts proportional reclaim. Yuanhan Liu, can you retest
> the vm scalability test cases on a larger machine? Hugh, does this work
> for you on the memcg test cases?

Sure, and here is the result. I applied these 3 patches on v3.15-rc6,
and head commit is 60c10afd. e82e0561 is the old commit that introduced
the regression.  The testserver has 512G memory and 120 CPU.

It's a simple result; if you need more data, I can gather them and send
it to you tomorrow:

e82e0561v3.15-rc6   60c10afd

185607851223212238868453
-34%+109

As you can see, the performance is back, and it is way much better ;)

--yliu
> 
> Based on ext4, I get the following results but unfortunately my larger test
> machines are all unavailable so this is based on a relatively small machine.
> 
> postmark
>   3.15.0-rc53.15.0-rc5
>  vanilla   proportion-v1r4
> Ops/sec Transactions 21.00 (  0.00%)   25.00 ( 19.05%)
> Ops/sec FilesCreate  39.00 (  0.00%)   45.00 ( 15.38%)
> Ops/sec CreateTransact   10.00 (  0.00%)   12.00 ( 20.00%)
> Ops/sec FilesDeleted   6202.00 (  0.00%) 6202.00 (  0.00%)
> Ops/sec DeleteTransact   11.00 (  0.00%)   12.00 (  9.09%)
> Ops/sec DataRead/MB  25.97 (  0.00%)   30.02 ( 15.59%)
> Ops/sec DataWrite/MB 49.99 (  0.00%)   57.78 ( 15.58%)
> 
> ffsb (mail server simulator)
>  3.15.0-rc5 3.15.0-rc5
> vanillaproportion-v1r4
> Ops/sec readall   9402.63 (  0.00%)  9805.74 (  4.29%)
> Ops/sec create4695.45 (  0.00%)  4781.39 (  1.83%)
> Ops/sec delete 173.72 (  0.00%)   177.23 (  2.02%)
> Ops/sec Transactions 14271.80 (  0.00%) 14764.37 (  3.45%)
> Ops/sec Read37.00 (  0.00%)38.50 (  4.05%)
> Ops/sec Write   18.20 (  0.00%)18.50 (  1.65%)
> 
> dd of a large file
> 3.15.0-rc53.15.0-rc5
>vanilla   proportion-v1r4
> WallTime DownloadTar   75.00 (  0.00%)   61.00 ( 18.67%)
> WallTime DD   423.00 (  0.00%)  401.00 (  5.20%)
> WallTime Delete 2.00 (  0.00%)5.00 (-150.00%)
> 
> stutter (times mmap latency during large amounts of IO)
> 
> 3.15.0-rc53.15.0-rc5
>vanilla   proportion-v1r4
> Unit >5ms Delays  80252. (  0.00%)  81523. ( -1.58%)
> Unit Mmap min 8.2118 (  0.00%)  8.3206 ( -1.33%)
> Unit Mmap mean   17.4614 (  0.00%) 17.2868 (  1.00%)
> Unit Mmap stddev 24.9059 (  0.00%) 34.6771 (-39.23%)
> Unit Mmap max  2811.6433 (  0.00%)   2645.1398 (  5.92%)
> Unit Mmap 90%20.5098 (  0.00%) 18.3105 ( 10.72%)
> Unit Mmap 93%22.9180 (  0.00%) 20.1751 ( 11.97%)
> Unit Mmap 95%25.2114 (  0.00%) 22.4988 ( 10.76%)
> Unit Mmap 99%46.1430 (  0.00%) 43.5952 (  5.52%)
> Unit Ideal  Tput 85.2623 (  0.00%) 78.8906 (  7.47%)
> Unit Tput min44.0666 (  0.00%) 43.9609 (  0.24%)
> Unit Tput mean   45.5646 (  0.00%) 45.2009 (  0.80%)
> Unit Tput stddev  0.9318 (  0.00%)  1.1084 (-18.95%)
> Unit Tput max46.7375 (  0.00%) 46.7539 ( -0.04%)
> 
>  fs/super.c  | 16 +---
>  mm/vmscan.c | 36 +---
>  2 files changed, 34 insertions(+), 18 deletions(-)
> 
> -- 
> 1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Patch v5 3/7] mfd: ti-keystone-devctrl: add bindings for device state control

2014-05-22 Thread Ivan Khoronzhuk


On 05/22/2014 06:33 PM, Lee Jones wrote:

Why do I only have this patch?  Where is the rest of the set?  Also,
it's on v5 and I don't recall seeing the other 4 versions?

It's strange I've sent whole series on

linux-kernel@vger.kernel.org
linux-arm-ker...@lists.infradead.org
linux-...@vger.kernel.org
devicet...@vger.kernel.org

v4 is also was sent to lists in question:
https://lkml.org/lkml/2014/5/21/359

But did you send them to me?  I don't parse the list.



Sorry.
Becouse /scripts/get_maintainer.pl  patches/reset_driver_v6/* hadn't 
been listed you

It's because there is no patch with "code" for the bindings you've comment.

I should check it by hand for mtd.

The bindings for mtd device_state_control were added only on v5
And it's added only to describe what is the node we've used in a 
keystone DT.
The node is planned to be used only via syscon phandle, there is no 
driver for it,

and compatible string for "ti,keystone-devctrl" added only to be matched by
a high-level device driver if needed.

I'll send new v6 series to you also.
Once again sorry.

--
Regards,
Ivan Khoronzhuk

--
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: kernel crash in bus_find_device

2014-05-22 Thread Francesco Ruggeri
Aborting a search does not sound like a correct solution.
How does a higher level user (eg for_each_pci_dev) know that a search
was aborted and decide whether it should try again, assuming it would
be ok repeating the action on the devices visited the first time?

Francesco


On Thu, May 22, 2014 at 12:22 AM, Guenter Roeck  wrote:
> On 05/22/2014 12:14 AM, Greg Kroah-Hartmann wrote:
>>
>> On Wed, May 21, 2014 at 03:59:58PM -0700, Guenter Roeck wrote:
>>>
>>> On Wed, May 21, 2014 at 01:04:04PM -0700, Francesco Ruggeri wrote:

 I have been using an x86 platform.
 When I started working on it I got early crashes until I added the
 check for p not NULL in

 +void bus_release_device(struct device *dev)
 +{
 + struct device_private *p = dev->p;
 +
 + if (p && klist_node_attached(>knode_bus))
 + klist_put_last(>knode_bus);
 +}
 +

 Maybe on powerpc *p is overriden between device_del and device_release?

 Or maybe some of the BUG_ONs in the patch? The ones on knode_dead are
 treated as WARN_ONs in the current klist code.
 The one in BUG_ON(!klist_dec_and_del(n)); is new, and in my tests I
 ran into it without the second patch (but only when I ran my module
 and tests).

>>> Hi Francesco,
>>>
>>> I replaced the BUG_ON with WARN_ON; still crashes.
>>>
>>> Anyway, the problem seems to be known. I found two related exchanges.
>>>
>>> [1] describes pretty much the same problem. I don't see if/where it was
>>> ever fixed, though.
>>>
>>> [2] is a patch to fix the problem. It did not apply cleanly to 3.14,
>>> so I had to make some adjustments in klist_iter_init_node. Resulting
>>> patch is below. With this patch, the problem is gone. It is not perfect,
>>> as it aborts the loop if it encounters a deleted kobject, but it is
>>> better
>>> than nothing. Unfortunately, the patch never made it upstream; no idea
>>> why.
>>> Copying the author and Greg to get additional feedback.
>>>
>>> Guenter
>>>
>>> [1] https://lkml.org/lkml/2008/10/26/79
>>> [2] https://lkml.org/lkml/2012/4/16/218
>>
>>
>> 2 years ago?  I have no idea what was up with that, sorry...
>>
>
> Ok, but do you have comments on the patch itself in its current version ?
>
> 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/


[PATCH v1 4/5] ARM: dts: qcom: Add APQ8084 Global Clock Controller DT node

2014-05-22 Thread Georgi Djakov
This patch adds the necessary node to probe the global clock
controller on APQ8084 platforms.

Signed-off-by: Georgi Djakov 
---
 arch/arm/boot/dts/qcom-apq8084.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index e3e009a..2dcd11e 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -2,6 +2,8 @@
 
 #include "skeleton.dtsi"
 
+#include 
+
 / {
model = "Qualcomm APQ 8084";
compatible = "qcom,apq8084";
@@ -175,5 +177,13 @@
compatible = "qcom,pshold";
reg = <0xfc4ab000 0x4>;
};
+
+   gcc: clock-controller@fc40 {
+   compatible = "qcom,gcc-apq8084";
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   reg = <0xfc40 0x4000>;
+   };
+
};
 };
-- 
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 v1 3/5] clk: gcc: Add APQ8084 Global Clock Controller support

2014-05-22 Thread Georgi Djakov
This patch adds support for the global clock controller found on
the APQ8084 based devices.

The APQ8084 and MSM8974 share a lot of clock data, so instead of
duplicating all the data, we add support to the MSM8974 code.

Signed-off-by: Georgi Djakov 
---
 drivers/clk/qcom/Kconfig |4 +-
 drivers/clk/qcom/gcc-msm8974.c   |  151 +-
 include/dt-bindings/clock/qcom,gcc-msm8974.h |4 +
 3 files changed, 154 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 7f696b7..00541e7 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -30,10 +30,10 @@ config MSM_MMCC_8960
  graphics, video encode/decode, camera, etc.
 
 config MSM_GCC_8974
-   tristate "MSM8974 Global Clock Controller"
+   tristate "APQ8084/MSM8974 Global Clock Controller"
depends on COMMON_CLK_QCOM
help
- Support for the global clock controller on msm8974 devices.
+ Support for the global clock controller on apq8084/msm8974 devices.
  Say Y if you want to use peripheral devices such as UART, SPI,
  i2c, USB, SD/eMMC, SATA, PCIe, etc.
 
diff --git a/drivers/clk/qcom/gcc-msm8974.c b/drivers/clk/qcom/gcc-msm8974.c
index 58cb2f5..c2a8d77 100644
--- a/drivers/clk/qcom/gcc-msm8974.c
+++ b/drivers/clk/qcom/gcc-msm8974.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -204,6 +204,12 @@ static const struct freq_tbl 
ftbl_gcc_blsp1_2_qup1_6_i2c_apps_clk[] = {
{ }
 };
 
+static const struct freq_tbl ftbl_gcc_blsp1_2_qup1_6_i2c_apps_clk_apq8084[] = {
+   F(1920, P_XO, 1, 0, 0),
+   F(5000, P_GPLL0, 12, 0, 0),
+   { }
+};
+
 static struct clk_rcg2 blsp1_qup1_i2c_apps_clk_src = {
.cmd_rcgr = 0x0660,
.hid_width = 5,
@@ -768,6 +774,27 @@ static struct clk_rcg2 ce2_clk_src = {
},
 };
 
+static const struct freq_tbl ftbl_gcc_ce3_clk_apq8084[] = {
+   F(5000, P_GPLL0, 12, 0, 0),
+   F(8571, P_GPLL0, 7, 0, 0),
+   F(1, P_GPLL0, 6, 0, 0),
+   F(17143, P_GPLL0, 3.5, 0, 0),
+   { }
+};
+
+static struct clk_rcg2 ce3_clk_src_apq8084 = {
+   .cmd_rcgr = 0x1d10,
+   .hid_width = 5,
+   .parent_map = gcc_xo_gpll0_map,
+   .freq_tbl = ftbl_gcc_ce3_clk_apq8084,
+   .clkr.hw.init = &(struct clk_init_data){
+   .name = "ce3_clk_src",
+   .parent_names = gcc_xo_gpll0,
+   .num_parents = 2,
+   .ops = _rcg2_ops,
+   },
+};
+
 static const struct freq_tbl ftbl_gcc_gp_clk[] = {
F(480, P_XO, 4, 0, 0),
F(600, P_GPLL0, 10, 1, 10),
@@ -780,6 +807,12 @@ static const struct freq_tbl ftbl_gcc_gp_clk[] = {
{ }
 };
 
+static const struct freq_tbl ftbl_gcc_gp_clk_apq8084[] = {
+   F(1920, P_XO, 1, 0, 0),
+   F(1, P_GPLL0, 6, 0, 0),
+   F(2, P_GPLL0, 3, 0, 0),
+   { }
+};
 
 static struct clk_rcg2 gp1_clk_src = {
.cmd_rcgr = 0x1904,
@@ -966,6 +999,11 @@ static const struct freq_tbl ftbl_gcc_usb_hs_system_clk[] 
= {
{ }
 };
 
+static const struct freq_tbl ftbl_gcc_usb_hs_system_clk_apq8084[] = {
+   F(7500, P_GPLL0, 8, 0, 0),
+   { }
+};
+
 static struct clk_rcg2 usb_hs_system_clk_src = {
.cmd_rcgr = 0x0490,
.hid_width = 5,
@@ -1029,6 +1067,11 @@ static const struct freq_tbl 
ftbl_gcc_usb_hsic_system_clk[] = {
{ }
 };
 
+static const struct freq_tbl ftbl_gcc_usb_hsic_system_clk_apq8084[] = {
+   F(7500, P_GPLL0, 8, 0, 0),
+   { }
+};
+
 static struct clk_rcg2 usb_hsic_system_clk_src = {
.cmd_rcgr = 0x041c,
.hid_width = 5,
@@ -1838,6 +1881,58 @@ static struct clk_branch gcc_ce2_clk = {
},
 };
 
+static struct clk_branch gcc_ce3_ahb_clk_apq8084 = {
+   .halt_reg = 0x1d0c,
+   .halt_check = BRANCH_HALT_VOTED,
+   .clkr = {
+   .enable_reg = 0x1d0c,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_ce3_ahb_clk",
+   .parent_names = (const char *[]){
+   "config_noc_clk_src",
+   },
+   .num_parents = 1,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
+static struct clk_branch gcc_ce3_axi_clk_apq8084 = {
+   .halt_reg = 0x1088,
+   .halt_check = BRANCH_HALT_VOTED,
+   .clkr = {
+   .enable_reg = 0x1d08,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_ce3_axi_clk",
+   .parent_names = (const char 

[PATCH v1 5/5] ARM: dts: qcom: Add APQ8084 serial port DT node

2014-05-22 Thread Georgi Djakov
Add the necessary DT node to probe the serial driver on
APQ8084 platforms.

Signed-off-by: Georgi Djakov 
---
 arch/arm/boot/dts/qcom-apq8084.dtsi |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index 2dcd11e..c346549 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -185,5 +185,12 @@
reg = <0xfc40 0x4000>;
};
 
+   serial@f995e000 {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0xf995e000 0x1000>;
+   interrupts = <0 114 0x0>;
+   clocks = < GCC_BLSP2_UART2_APPS_CLK>, < 
GCC_BLSP2_AHB_CLK>;
+   clock-names = "core", "iface";
+   };
};
 };
-- 
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 v1 0/5] clk: gcc: Add APQ8084 Global Clock Controller support

2014-05-22 Thread Georgi Djakov
This patchset adds support for the global clock controller found on the
APQ8084 based platforms.

It applies to the clk-next tree and the following patchset on top of it:
https://lkml.org/lkml/2014/5/16/666

Georgi Djakov (5):
  clk: qcom: Add APQ8084 Global Clock Controller documentation
  clk: qcom: Allow an override function to be passed as data
  clk: gcc: Add APQ8084 Global Clock Controller support
  ARM: dts: qcom: Add APQ8084 Global Clock Controller DT node
  ARM: dts: qcom: Add APQ8084 serial port DT node

 .../devicetree/bindings/clock/qcom,gcc.txt |1 +
 arch/arm/boot/dts/qcom-apq8084.dtsi|   17 ++
 drivers/clk/qcom/Kconfig   |4 +-
 drivers/clk/qcom/gcc-msm8974.c |  174 ++--
 include/dt-bindings/clock/qcom,gcc-msm8974.h   |4 +
 5 files changed, 185 insertions(+), 15 deletions(-)

-- 
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 v1 2/5] clk: qcom: Allow an override function to be passed as data

2014-05-22 Thread Georgi Djakov
The APQ8084 and MSM8974 SoCs share a lot of clock data. Instead of
duplicating all the data, we can add the support for APQ8084 into
the MSM8974 code and just describe the differences by using an
override function.

This patch applies to the clk-next tree and the following patchset
on top of it: https://lkml.org/lkml/2014/5/16/666

Signed-off-by: Georgi Djakov 
---
 drivers/clk/qcom/gcc-msm8974.c |   27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/qcom/gcc-msm8974.c b/drivers/clk/qcom/gcc-msm8974.c
index 33eb051..58cb2f5 100644
--- a/drivers/clk/qcom/gcc-msm8974.c
+++ b/drivers/clk/qcom/gcc-msm8974.c
@@ -2674,14 +2674,6 @@ static const struct qcom_cc_desc gcc_msm8974_desc = {
.num_resets = ARRAY_SIZE(gcc_msm8974_resets),
 };
 
-static const struct of_device_id gcc_msm8974_match_table[] = {
-   { .compatible = "qcom,gcc-msm8974" },
-   { .compatible = "qcom,gcc-msm8974pro" , .data = (void *)1UL },
-   { .compatible = "qcom,gcc-msm8974pro-ac", .data = (void *)1UL },
-   { }
-};
-MODULE_DEVICE_TABLE(of, gcc_msm8974_match_table);
-
 static void msm8974_pro_clock_override(void)
 {
sdcc1_apps_clk_src_init.parent_names = gcc_xo_gpll0_gpll4;
@@ -2697,20 +2689,31 @@ static void msm8974_pro_clock_override(void)
_sdcc1_cdccal_ff_clk.clkr;
 }
 
+static const struct of_device_id gcc_msm8974_match_table[] = {
+   { .compatible = "qcom,gcc-msm8974" },
+   { .compatible = "qcom,gcc-msm8974pro",
+   .data = _pro_clock_override },
+   { .compatible = "qcom,gcc-msm8974pro-ac",
+   .data = _pro_clock_override },
+   { }
+};
+MODULE_DEVICE_TABLE(of, gcc_msm8974_match_table);
+
 static int gcc_msm8974_probe(struct platform_device *pdev)
 {
struct clk *clk;
struct device *dev = >dev;
-   bool pro;
const struct of_device_id *id;
+   void (*overrides)(void);
 
id = of_match_device(gcc_msm8974_match_table, dev);
if (!id)
return -ENODEV;
-   pro = !!(id->data);
 
-   if (pro)
-   msm8974_pro_clock_override();
+   if (id->data) {
+   overrides = id->data;
+   overrides();
+   }
 
/* Temporary until RPM clocks supported */
clk = clk_register_fixed_rate(dev, "xo", NULL, CLK_IS_ROOT, 1920);
-- 
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 v1 1/5] clk: qcom: Add APQ8084 Global Clock Controller documentation

2014-05-22 Thread Georgi Djakov
Add the compatible string for the APQ8084 global clock controller
to the clock binding documentation.

Signed-off-by: Georgi Djakov 
---
 .../devicetree/bindings/clock/qcom,gcc.txt |1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 9cfcb4f..4f35042 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -5,6 +5,7 @@ Required properties :
 - compatible : shall contain only one of the following:
 
"qcom,gcc-apq8064"
+   "qcom,gcc-apq8084"
"qcom,gcc-msm8660"
"qcom,gcc-msm8960"
"qcom,gcc-msm8974"
-- 
1.7.9.5

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


Re: [PATCH] i8k: increase fan limit to 3

2014-05-22 Thread Jean Delvare
On Thu, 22 May 2014 08:12:59 -0700, Guenter Roeck wrote:
> On Thu, May 22, 2014 at 10:28:31AM +0200, Thomas Bogendoerfer wrote:
> > On Wed, May 21, 2014 at 08:32:24PM -0700, Guenter Roeck wrote:
> > > On 05/21/2014 07:19 PM, Flavio Leitner wrote:
> > > >From: Flavio Leitner 
> > > >
> > > >It is possible to increase left fan speed on a
> > > >DELL Precision 490n system up to 3.
> > > >
> > > > valuefan rpm
> > > >   1  35460
> > > >   2  64740
> > > >   3  78510
> > > >
> > > Guess the speed factor 30 doesn't apply here.
> > 
> > on my vostro 1720 value 3 is default value and it looks like
> > it's sort of an auto mode.
> > 
> > BTW. the only fan in the system is on the left side, but shows up as
> > RigthFan. Wouldn't it be better to simply number the fans and let the
> > "real" labeling be done via sensors.conf ?
> > 
> I agree. Jean, any comments ? Is it ok to drop the fan labels ?

Yes it is, I had that it mind already, just I don't have the time to do
it.

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


Re: [PATCH 0/3] Shrinkers and proportional reclaim

2014-05-22 Thread Mel Gorman
On Fri, May 23, 2014 at 12:14:16AM +0800, Yuanhan Liu wrote:
> On Thu, May 22, 2014 at 10:09:36AM +0100, Mel Gorman wrote:
> > This series is aimed at regressions noticed during reclaim activity. The
> > first two patches are shrinker patches that were posted ages ago but never
> > merged for reasons that are unclear to me. I'm posting them again to see if
> > there was a reason they were dropped or if they just got lost. Dave?  Time?
> > The last patch adjusts proportional reclaim. Yuanhan Liu, can you retest
> > the vm scalability test cases on a larger machine? Hugh, does this work
> > for you on the memcg test cases?
> 
> Sure, and here is the result. I applied these 3 patches on v3.15-rc6,
> and head commit is 60c10afd. e82e0561 is the old commit that introduced
> the regression.  The testserver has 512G memory and 120 CPU.
> 
> It's a simple result; if you need more data, I can gather them and send
> it to you tomorrow:
> 
> e82e0561v3.15-rc6   60c10afd
> 
> 185607851223212238868453
> -34%+109
> 
> As you can see, the performance is back, and it is way much better ;)
> 

Thanks a lot for that and the quick response. It is much appreciated.

-- 
Mel Gorman
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 v5 3/7] mfd: ti-keystone-devctrl: add bindings for device state control

2014-05-22 Thread Ivan Khoronzhuk


On 05/22/2014 07:14 PM, Ivan Khoronzhuk wrote:


On 05/22/2014 06:33 PM, Lee Jones wrote:

Why do I only have this patch?  Where is the rest of the set?  Also,
it's on v5 and I don't recall seeing the other 4 versions?

It's strange I've sent whole series on

linux-kernel@vger.kernel.org
linux-arm-ker...@lists.infradead.org
linux-...@vger.kernel.org
devicet...@vger.kernel.org

v4 is also was sent to lists in question:
https://lkml.org/lkml/2014/5/21/359

But did you send them to me?  I don't parse the list.



Sorry.
Becouse /scripts/get_maintainer.pl  patches/reset_driver_v6/* hadn't 
been listed you
It's because there is no patch with "code" for the bindings you've 
comment.


I should check it by hand for mtd.

The bindings for mtd device_state_control were added only on v5
And it's added only to describe what is the node we've used in a 
keystone DT.
The node is planned to be used only via syscon phandle, there is no 
driver for it,
and compatible string for "ti,keystone-devctrl" added only to be 
matched by

a high-level device driver if needed.

I'll send new v6 series to you also.
Once again sorry.



s/mtd/mfd

--
Regards,
Ivan Khoronzhuk

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


RE: [PATCH 1/2] staging: comedi: addi_apci_1564: move apci1564_di_insn_bits() to addi_apci_1564.c

2014-05-22 Thread Hartley Sweeten
On Wednesday, May 21, 2014 5:40 PM, Chase Southwood wrote:
>
> This function is already compliant with the comedi API and is behaving as
> comedi core expects.  This patch moves it out of
> addi-data/hwdrv_apci1564.c and into the driver proper since no further
> work needs to be done on it.
>
> Cc: Ian Abbott 
> Cc: H Hartley Sweeten 
> Signed-off-by: Chase Southwood 

Reviewed-by: H Hartley Sweeten 

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


[GIT PULL] at91: DT for 3.16 at91-dt3 #3

2014-05-22 Thread Nicolas Ferre
Arnd, Olof, Kevin,

Another AT91 DT pull-request for 3.16. This one is the conversion of two more
SoC to Common Clock Framework (aka CCF). I identified it as a "DT" pull-request
but it modifies slightly a couple of files in mach-at91 (use of a configuration
option).
This pull-request depends on:
- the fixes that I already sent for 3.15 and that are present in the recent
  3.15-rc6 tag.
- the at91-cleanup tag that you integrated in your arm-soc/next/soc branch.
So, as suggested by Arnd on IRC, I merged both of them to act as the base
before adding the material for this pull-request.

About the clock nodes that should be grouped in a "clocks" container or not,
while waiting for a clear statement by the DT maintainers, I kept the clocks
nodes as they had been written by Boris.
As proposed by Olof, I plan to send you a comprehensive patch that fixes this
when Mark gives his point of view.

Thanks, best regards,

The following changes since commit 6a84872a3c3090993be108f02f91b4de062a7d32:

  Merge branch 'at91-3.16-cleanup' into at91-3.16-dt3 (2014-05-22 18:01:22 
+0200)

are available in the git repository at:


  git://github.com/at91linux/linux-at91.git tags/at91-dt3

for you to fetch changes up to b4a86b3810f5dc4b959ee69a3818c876752c88cd:

  ARM: at91: move sam9n12 SoC to the CCF (2014-05-22 18:03:17 +0200)


3.16 third DT series:
- move of both at91sam9n12 and at91sam9x5 to CCF


Boris BREZILLON (8):
  ARM: at91: prepare common clk transition for sam9x5 SoCs
  ARM: at91/dt: define sam9x5 clocks
  ARM: at91/dt: define sam9x5ek's crystal frequencies
  ARM: at91: move sam9x5 SoCs to the CCF
  ARM: at91: prepare common clk transition for sam9n12 SoC
  ARM: at91/dt: define sam9n12 clocks
  ARM: at91/dt: define sam9n12ek crystal frequencies
  ARM: at91: move sam9n12 SoC to the CCF

 arch/arm/boot/dts/at91sam9n12.dtsi   | 348 +-
 arch/arm/boot/dts/at91sam9n12ek.dts  |   8 +
 arch/arm/boot/dts/at91sam9x5.dtsi| 355 ++-
 arch/arm/boot/dts/at91sam9x5_can.dtsi|  31 +++
 arch/arm/boot/dts/at91sam9x5_isi.dtsi|  26 +++
 arch/arm/boot/dts/at91sam9x5_lcd.dtsi|  26 +++
 arch/arm/boot/dts/at91sam9x5_macb0.dtsi  |  11 +
 arch/arm/boot/dts/at91sam9x5_macb1.dtsi  |  11 +
 arch/arm/boot/dts/at91sam9x5_usart3.dtsi |  11 +
 arch/arm/boot/dts/at91sam9x5cm.dtsi  |   8 +
 arch/arm/mach-at91/Kconfig   |   2 -
 arch/arm/mach-at91/at91sam9n12.c |   6 +-
 arch/arm/mach-at91/at91sam9x5.c  |   6 +-
 13 files changed, 842 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/boot/dts/at91sam9x5_can.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_isi.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_lcd.dtsi

-- 
Nicolas Ferre
--
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 5/5] ARM: dts: qcom: Add APQ8084 serial port DT node

2014-05-22 Thread Kumar Gala

On May 22, 2014, at 11:24 AM, Georgi Djakov  wrote:

> Add the necessary DT node to probe the serial driver on
> APQ8084 platforms.
> 
> Signed-off-by: Georgi Djakov 
> ---
> arch/arm/boot/dts/qcom-apq8084.dtsi |7 +++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
> b/arch/arm/boot/dts/qcom-apq8084.dtsi
> index 2dcd11e..c346549 100644
> --- a/arch/arm/boot/dts/qcom-apq8084.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
> @@ -185,5 +185,12 @@
>   reg = <0xfc40 0x4000>;
>   };
> 
> + serial@f995e000 {

Mark it disabled in the soc.dtsi and “ok” in the board.

> + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> + reg = <0xf995e000 0x1000>;
> + interrupts = <0 114 0x0>;
> + clocks = < GCC_BLSP2_UART2_APPS_CLK>, < 
> GCC_BLSP2_AHB_CLK>;
> + clock-names = "core", "iface";
> + };
>   };
> };
> -- 
> 1.7.9.5
> 

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by 
The Linux Foundation

--
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] staging: comedi: addi_apci_1564: move apci1564_do_insn_bits() to addi_apci_1564.c

2014-05-22 Thread Hartley Sweeten
On Wednesday, May 21, 2014 5:41 PM, Chase Southwood wrote:
>
> This function is already compliant with the comedi API and is behaving as
> comedi core expects.  This patch moves it out of
> addi-data/hwdrv_apci1564.c and into the driver proper since no further
> work needs to be done on it.
>
> Cc: Ian Abbott 
> Cc: H Hartley Sweeten 
> Signed-off-by: Chase Southwood 

Reviewed-by: H Hartley Sweeten 

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


[PATCH v2 2/2] Documentation: add Broadcom STB Level-2 interrupt controller binding

2014-05-22 Thread Florian Fainelli
This patch adds the Device Tree binding document for the Broadcom
Set-top-box Level 2 interrupt controller hardware.

Signed-off-by: Brian Norris 
Signed-off-by: Florian Fainelli 
---
Changes in v2:
- respin

 .../bindings/interrupt-controller/brcm,l2-intc.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
new file mode 100644
index ..448273a30a11
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
@@ -0,0 +1,29 @@
+Broadcom Generic Level 2 Interrupt Controller
+
+Required properties:
+
+- compatible: should be "brcm,l2-intc"
+- reg: specifies the base physical address and size of the registers
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: specifies the number of cells needed to encode an
+  interrupt source. Should be 1.
+- interrupt-parent: specifies the phandle to the parent interrupt controller
+  this controller is cacaded from
+- interrupts: specifies the interrupt line in the interrupt-parent irq space
+  to be used for cascading
+
+Optional properties:
+
+- brcm,irq-can-wake: If present, this means the L2 controller can be used as a
+  wakeup source for system suspend/resume.
+
+Example:
+
+hif_intr2_intc: interrupt-controller@f0441000 {
+   compatible = "brcm,l2-intc";
+   reg = <0xf0441000 0x30>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   interrupt-parent = <>;
+   interrupts = <0x0 0x20 0x0>;
+};
-- 
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 v2 0/2] irqchip: Broadcom Set Top Box Level-2 interrupt controller

2014-05-22 Thread Florian Fainelli
Hi Thomas, Jason,

This patch set adds an irqchip driver for the Broadcom Set Top Box Level-2
interrupt controller hardware, as well as a corresponding Device Tree binding
document.

Thanks!

Florian Fainelli (2):
  irqchip: add Broadcom Set Top Box Level-2 interrupt controller
  Documentation: add Broadcom STB Level-2 interrupt controller binding

 .../bindings/interrupt-controller/brcm,l2-intc.txt |  29 +++
 drivers/irqchip/Kconfig|   6 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-brcmstb-l2.c   | 231 +
 4 files changed, 267 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
 create mode 100644 drivers/irqchip/irq-brcmstb-l2.c

-- 
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 v2 1/2] irqchip: add Broadcom Set Top Box Level-2 interrupt controller

2014-05-22 Thread Florian Fainelli
This patch adds support for the Level-2 interrupt controller hardware
found in Broadcom Set Top Box System-on-a-Chip devices. This interrupt
controller is implemented using the generic IRQ chip driver with
separate enable and disable registers.

Signed-off-by: Brian Norris 
Signed-off-by: Florian Fainelli 
---
Changes in v2:
- properly free private data in case we cannot remap the register range

 drivers/irqchip/Kconfig  |   6 ++
 drivers/irqchip/Makefile |   1 +
 drivers/irqchip/irq-brcmstb-l2.c | 202 +++
 3 files changed, 209 insertions(+)
 create mode 100644 drivers/irqchip/irq-brcmstb-l2.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index d770f7406631..bbb746e35500 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -30,6 +30,12 @@ config ARM_VIC_NR
  The maximum number of VICs available in the system, for
  power management.
 
+config BRCMSTB_L2_IRQ
+   bool
+   depends on ARM
+   select GENERIC_IRQ_CHIP
+   select IRQ_DOMAIN
+
 config DW_APB_ICTL
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index f180f8d5fb7b..62a13e5ef98f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_TB10X_IRQC)  += irq-tb10x.o
 obj-$(CONFIG_XTENSA)   += irq-xtensa-pic.o
 obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
 obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
+obj-$(CONFIG_BRCMSTB_L2_IRQ)   += irq-brcmstb-l2.o
diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
new file mode 100644
index ..68fcba468211
--- /dev/null
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -0,0 +1,202 @@
+/*
+ * Generic Broadcom Set Top Box Level 2 Interrupt controller driver
+ *
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME  ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "irqchip.h"
+
+/* Register offsets in the L2 interrupt controller */
+#define CPU_STATUS 0x00
+#define CPU_SET0x04
+#define CPU_CLEAR  0x08
+#define CPU_MASK_STATUS0x0c
+#define CPU_MASK_SET   0x10
+#define CPU_MASK_CLEAR 0x14
+
+/* L2 intc private data structure */
+struct brcmstb_l2_intc_data {
+   int parent_irq;
+   void __iomem *base;
+   struct irq_domain *domain;
+   bool can_wake;
+   u32 saved_mask; /* for suspend/resume */
+};
+
+static void brcmstb_l2_intc_irq_handle(unsigned int irq, struct irq_desc *desc)
+{
+   struct brcmstb_l2_intc_data *b = irq_desc_get_handler_data(desc);
+   struct irq_chip *chip = irq_get_chip(irq);
+   u32 status;
+
+   chained_irq_enter(chip, desc);
+
+   status = __raw_readl(b->base + CPU_STATUS) &
+   ~(__raw_readl(b->base + CPU_MASK_STATUS));
+
+   if (status == 0) {
+   do_bad_IRQ(irq, desc);
+   goto out;
+   }
+
+   do {
+   irq = ffs(status) - 1;
+   /* ack at our level */
+   __raw_writel(1 << irq, b->base + CPU_CLEAR);
+   status &= ~(1 << irq);
+   generic_handle_irq(irq_find_mapping(b->domain, irq));
+   } while (status);
+out:
+   chained_irq_exit(chip, desc);
+}
+
+static void brcmstb_l2_intc_suspend(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct brcmstb_l2_intc_data *b = gc->private;
+
+   irq_gc_lock(gc);
+   /* Save the current mask */
+   b->saved_mask = __raw_readl(b->base + CPU_MASK_STATUS);
+
+   if (b->can_wake) {
+   /* Program the wakeup mask */
+   __raw_writel(~gc->wake_active, b->base + CPU_MASK_SET);
+   __raw_writel(gc->wake_active, b->base + CPU_MASK_CLEAR);
+   }
+   irq_gc_unlock(gc);
+}
+
+static void brcmstb_l2_intc_resume(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct brcmstb_l2_intc_data *b = gc->private;
+
+   irq_gc_lock(gc);
+   /* Clear unmasked non-wakeup interrupts */
+   __raw_writel(~b->saved_mask & ~gc->wake_active, b->base + CPU_CLEAR);
+
+   /* Restore the saved mask */
+   __raw_writel(b->saved_mask, b->base + CPU_MASK_SET);
+   __raw_writel(~b->saved_mask, b->base 

Re: [PATCH v1 3/5] clk: gcc: Add APQ8084 Global Clock Controller support

2014-05-22 Thread Kumar Gala

On May 22, 2014, at 11:24 AM, Georgi Djakov  wrote:

> This patch adds support for the global clock controller found on
> the APQ8084 based devices.
> 
> The APQ8084 and MSM8974 share a lot of clock data, so instead of
> duplicating all the data, we add support to the MSM8974 code.
> 
> Signed-off-by: Georgi Djakov 
> ---
> drivers/clk/qcom/Kconfig |4 +-
> drivers/clk/qcom/gcc-msm8974.c   |  151 +-
> include/dt-bindings/clock/qcom,gcc-msm8974.h |4 +
> 3 files changed, 154 insertions(+), 5 deletions(-)

What about differences in reset?

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by 
The Linux Foundation

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


Re: [PATCH V4 3/3] cpufreq: Tegra: implement intermediate frequency callbacks

2014-05-22 Thread Stephen Warren
On 05/21/2014 02:59 AM, Viresh Kumar wrote:
> Tegra had always been switching to intermediate frequency (pll_p_clk) since
> ever. CPUFreq core has better support for handling notifications for these
> frequencies and so we can adapt Tegra's driver to it.
> 
> Also do a WARN() if clk_set_parent() fails while moving back to pll_x as we
> should have atleast restored to earlier frequency on error.

> diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c

> @@ -98,10 +96,23 @@ static int tegra_target(struct cpufreq_policy *policy, 
> unsigned int index)
>   else
>   clk_set_rate(emc_clk, 1);  /* emc 50Mhz */
>  
> - ret = tegra_cpu_clk_set_rate(rate * 1000);
> + /* target freq == pll_p */
> + if (rate * 1000 == clk_get_rate(pll_p_clk)) {
> + ret = tegra_target_intermediate(policy, index);
> + goto disable_pll_x;
> + }

I think the call to tegra_target_intermediate() is wrong here; shouldn't
the cpufreq core guarantee that tegra_target_intermediate() has always
been called before tegra_target(), so there's no need to repeat that
call here?

Also, tegra_target() doesn't seem to follow the rule documented by patch
2/3 that states ->target() should restore the orignal frequency on
error. I'm not even sure if that's possible in general.
--
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] i2c: algos: add support for sc18im700 master i2c bus with uart interface

2014-05-22 Thread Raghavendra Ganiga
This is a patch to add i2c algorith  support for nxp sc18im700
master i2c bus controller with uart interface

Signed-off-by: Raghavendra Chandra Ganiga 
---
 drivers/i2c/algos/Kconfig  |   2 +
 drivers/i2c/algos/Makefile |   1 +
 drivers/i2c/algos/i2c-algo-sc18im700.c | 274 +
 include/linux/i2c-algo-sc18im700.h |  81 ++
 4 files changed, 358 insertions(+)
 create mode 100644 drivers/i2c/algos/i2c-algo-sc18im700.c
 create mode 100644 include/linux/i2c-algo-sc18im700.h

diff --git a/drivers/i2c/algos/Kconfig b/drivers/i2c/algos/Kconfig
index f1cfe7e..03776c8 100644
--- a/drivers/i2c/algos/Kconfig
+++ b/drivers/i2c/algos/Kconfig
@@ -14,4 +14,6 @@ config I2C_ALGOPCF
 config I2C_ALGOPCA
tristate "I2C PCA 9564 interfaces"
 
+config I2C_ALGOSC18IM700
+   tristate "I2C SC18IM700 interfaces"
 endmenu
diff --git a/drivers/i2c/algos/Makefile b/drivers/i2c/algos/Makefile
index 215303f..26f92d7 100644
--- a/drivers/i2c/algos/Makefile
+++ b/drivers/i2c/algos/Makefile
@@ -5,5 +5,6 @@
 obj-$(CONFIG_I2C_ALGOBIT)  += i2c-algo-bit.o
 obj-$(CONFIG_I2C_ALGOPCF)  += i2c-algo-pcf.o
 obj-$(CONFIG_I2C_ALGOPCA)  += i2c-algo-pca.o
+obj-$(CONFIG_I2C_ALGOSC18IM700)+= i2c-algo-sc18im700.o
 
 ccflags-$(CONFIG_I2C_DEBUG_ALGO) := -DDEBUG
diff --git a/drivers/i2c/algos/i2c-algo-sc18im700.c 
b/drivers/i2c/algos/i2c-algo-sc18im700.c
new file mode 100644
index 000..cf73aad
--- /dev/null
+++ b/drivers/i2c/algos/i2c-algo-sc18im700.c
@@ -0,0 +1,274 @@
+/*
+ *  i2c-algo-sc18im700.c i2c driver algorithms for SC18IM700 adapters
+ *  Master I2C bus with UART interface
+ *
+ *  Copyright (C) 2014 Raghavendra Chandra Ganiga 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ *  MA 02110-1301 USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEB1(x) if (i2c_debug >= 1) x
+
+static int i2c_debug;
+
+#define set_sc18im(adap, value) adap->set_data(adap->data, value)
+#define get_sc18im(adap, buff) adap->get_data(adap->data, buff)
+#define sc18im_reset(adap) adap->reset(adap->data)
+#define sc18im_get_own_addr(adap) adap->get_own_addr(adap->data)
+
+static unsigned char sc18im_read_reg(struct i2c_algo_sc18imdata *adap,
+   unsigned char reg, unsigned char *buf)
+{
+   set_sc18im(adap, SC18IM_REG_READ);
+   set_sc18im(adap, reg);
+   set_sc18im(adap, SC18IM_STOP);
+   return get_sc18im(adap, buf);
+}
+
+static void sc18im_write_reg(struct i2c_algo_sc18imdata *adap,
+   unsigned char reg, unsigned char value)
+{
+   set_sc18im(adap, SC18IM_REG_WRITE);
+   set_sc18im(adap, reg);
+   set_sc18im(adap, value);
+   set_sc18im(adap, SC18IM_STOP);
+}
+
+static int sc18im_xfer(struct i2c_adapter *adap,
+   struct i2c_msg *msgs,
+   int num)
+{
+   struct i2c_algo_sc18imdata *algo_data = adap->algo_data;
+   struct i2c_msg *msg;
+   int curmsg, addr, numbytes;
+   unsigned char data;
+
+   DEB1(printk(KERN_DEBUG "i2c algo sc18im700: Transfer Starts"));
+
+   if (algo_data->xfer_begin)
+   algo_data->xfer_begin(algo_data->data);
+
+   curmsg = 0;
+   while (curmsg < num) {
+   numbytes = 0;
+   msg = [curmsg];
+
+   DEB1(printk(KERN_DEBUG "i2c algo sc18im700: Operation: %s, "
+   "Addr: 0x%02x, Length: %d, "
+   "Current Transfer No: %d, "
+   "Total No of transfer: %d\n",
+   (msg->flags & I2C_M_RD) ? "Read" : "Write",
+   msg->addr, msg->len, (curmsg + 1), num));
+
+   /* Data frame in sc18im700 for write is
+* start_char;address;length;data1;data2;---;data.n
+*;terminate_char
+* first provide the start character followed by address,
+* length, data bytes upto length bytes and then terminate
+* character, as terminate character is received by sc18im700
+* it transfers the data to addressed device
+* Data frame for read is
+* 

[PATCH v2] mutex: Documentation rewrite

2014-05-22 Thread Davidlohr Bueso
From: Davidlohr Bueso 

Our mutexes have gone a long ways since the original implementation
back in 2005/2006. However, the mutex-design.txt document is still
stuck in the past, to the point where most of the information there
is practically useless and, more important, simply incorrect. This
patch pretty much rewrites it to resemble what we have nowadays.

Since regular semaphores are almost much extinct in the kernel
(most users now rely on mutexes or rwsems), it no longer makes
sense to have such a close comparison, which was copied from most
of the cover letter when Ingo introduced the generic mutex subsystem.

Note that ww_mutexes are intentionally left out, leaving things as
generic as possible.

Signed-off-by: Davidlohr Bueso 
---
Changes from v2:
 - Grammar corrections.
 - Document cancelable MCS properties.

 Documentation/mutex-design.txt | 252 ++---
 1 file changed, 135 insertions(+), 117 deletions(-)

diff --git a/Documentation/mutex-design.txt b/Documentation/mutex-design.txt
index 1dfe62c..d9b0be5 100644
--- a/Documentation/mutex-design.txt
+++ b/Documentation/mutex-design.txt
@@ -1,139 +1,157 @@
 Generic Mutex Subsystem
 
 started by Ingo Molnar 
+updated by Davidlohr Bueso 
 
-  "Why on earth do we need a new mutex subsystem, and what's wrong
-   with semaphores?"
+What are mutexes?
+-
 
-firstly, there's nothing wrong with semaphores. But if the simpler
-mutex semantics are sufficient for your code, then there are a couple
-of advantages of mutexes:
+In the Linux kernel, mutexes refer to a particular locking primitive
+that enforces serialization on shared memory systems, and not only to
+the generic term referring to 'mutual exclusion' found in academia
+or similar theoretical text books. Mutexes are sleeping locks which
+behave similarly to binary semaphores, and were introduced in 2006[1]
+as an alternative to these. This new data structure provided a number
+of advantages, including simpler interfaces, and at that time smaller
+code (see Disadvantages).
 
- - 'struct mutex' is smaller on most architectures: E.g. on x86,
-   'struct semaphore' is 20 bytes, 'struct mutex' is 16 bytes.
-   A smaller structure size means less RAM footprint, and better
-   CPU-cache utilization.
+[1] http://lwn.net/Articles/164802/
 
- - tighter code. On x86 i get the following .text sizes when
-   switching all mutex-alike semaphores in the kernel to the mutex
-   subsystem:
+Implementation
+--
 
-textdata bss dec hex filename
- 3280380  868188  396860 4545428  455b94 vmlinux-semaphore
- 3255329  865296  396732 4517357  44eded vmlinux-mutex
+Mutexes are represented by 'struct mutex', defined in include/linux/mutex.h
+and implemented in kernel/locking/mutex.c. These locks use a three
+state atomic counter (->count) to represent the different possible
+transitions that can occur during the lifetime of a lock:
 
-   that's 25051 bytes of code saved, or a 0.76% win - off the hottest
-   codepaths of the kernel. (The .data savings are 2892 bytes, or 0.33%)
-   Smaller code means better icache footprint, which is one of the
-   major optimization goals in the Linux kernel currently.
+ 1: unlocked
+ 0: locked, no waiters
+   negative: locked, with potential waiters
 
- - the mutex subsystem is slightly faster and has better scalability for
-   contended workloads. On an 8-way x86 system, running a mutex-based
-   kernel and testing creat+unlink+close (of separate, per-task files)
-   in /tmp with 16 parallel tasks, the average number of ops/sec is:
+In its most basic form it also includes a wait-queue and a spinlock
+that serializes access to it. CONFIG_SMP systems can also include
+a pointer to the lock task owner (->owner) as well as a spinner MCS
+lock (->osq), both described below in (ii).
 
-Semaphores:Mutexes:
+When acquiring a mutex, there are three possible paths that can be
+taken, depending on the state of the lock:
 
-$ ./test-mutex V 16 10 $ ./test-mutex V 16 10
-8 CPUs, running 16 tasks.  8 CPUs, running 16 tasks.
-checking VFS performance.  checking VFS performance.
-avg loops/sec:  34713  avg loops/sec:  84153
-CPU utilization:63%CPU utilization:22%
+(i) fastpath: tries to atomically acquire the lock by decrementing the
+counter. If it was already taken by another task it goes to the next
+possible path. This logic is architecture specific. On x86-64, the
+locking fastpath is 2 instructions:
 
-   i.e. in this workload, the mutex based kernel was 2.4 times faster
-   than the semaphore based kernel, _and_ it also had 2.8 times less CPU
-   utilization. (In terms of 'ops per CPU cycle', the semaphore kernel
-   performed 551 ops/sec per 1% of CPU time used, while the mutex kernel
-   performed 3825 ops/sec per 1% of CPU time used - it was 6.9 times
-   more 

Re: [PATCH V4 2/3] cpufreq: add support for intermediate (stable) frequencies

2014-05-22 Thread Stephen Warren
On 05/21/2014 02:59 AM, Viresh Kumar wrote:
> Douglas Anderson, recently pointed out an interesting problem due to which
> udelay() was expiring earlier than it should.
> 
> While transitioning between frequencies few platforms may temporarily switch 
> to
> a stable frequency, waiting for the main PLL to stabilize.
> 
> For example: When we transition between very low frequencies on exynos, like
> between 200MHz and 300MHz, we may temporarily switch to a PLL running at 
> 800MHz.
> No CPUFREQ notification is sent for that. That means there's a period of time
> when we're running at 800MHz but loops_per_jiffy is calibrated at between 
> 200MHz
> and 300MHz. And so udelay behaves badly.
> 
> To get this fixed in a generic way, lets introduce another set of callbacks
> get_intermediate() and target_intermediate(), only for drivers with
> target_index() and CPUFREQ_ASYNC_NOTIFICATION unset.
> 
> get_intermediate() should return a stable intermediate frequency platform 
> wants
> to switch to, and target_intermediate() should set CPU to to that frequency,
> before jumping to the frequency corresponding to 'index'. Core will take care 
> of
> sending notifications and driver doesn't have to handle them in
> target_intermediate() or target_index().
> 
> NOTE: ->target_index() should restore to policy->restore_freq in case of
> failures as core would send notifications for that.

> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c

> +/* Must set freqs->new to intermediate frequency */
> +static int __target_intermediate(struct cpufreq_policy *policy,
> +  struct cpufreq_freqs *freqs, int index)
> +{
> + int ret;
> +
> + freqs->new = cpufreq_driver->get_intermediate(policy, index);
> +
> + /* We don't need to switch to intermediate freq */
> + if (!freqs->new)
> + return 0;
> +
> + pr_debug("%s: cpu: %d, switching to intermediate freq: oldfreq: %u, 
> intermediate freq: %u\n",
> +  __func__, policy->cpu, freqs->old, freqs->new);
> +
> + cpufreq_freq_transition_begin(policy, freqs);
> + ret = cpufreq_driver->target_intermediate(policy, index);
> + cpufreq_freq_transition_end(policy, freqs, ret);
> +
> + if (ret)
> + pr_err("%s: Failed to change to intermediate frequency: %d\n",
> +__func__, ret);
> + else
> + /* Set old freq to intermediate */
> + freqs->old = freqs->new;
> +
> + return ret;
> +}

It seems rather odd to set both freqs->old and freqs->new to the
intermediate frequency upon success. It feels like it would make more
sense to remove that final else clause above, and do the following where
this function is called:

intermediate_freq = freqs.new;
if (intermediate_freq)
freqs.old = intermediate_freq
freqs.new = freq_table[index].frequency

(or even return the intermediate frequency from the function)

?

But I suppose isolating all the inside __target_intermediate() isn't so bad.

>  static int __target_index(struct cpufreq_policy *policy,
> struct cpufreq_frequency_table *freq_table, int index)
>  {
> - struct cpufreq_freqs freqs;
> + struct cpufreq_freqs freqs = {.old = policy->cur, .flags = 0};
> + unsigned int intermediate_freq = 0;
>   int retval = -EINVAL;
>   bool notify;
>  
>   notify = !(cpufreq_driver->flags & CPUFREQ_ASYNC_NOTIFICATION);
> -
>   if (notify) {
> - freqs.old = policy->cur;
> - freqs.new = freq_table[index].frequency;
> - freqs.flags = 0;
> + /* Handle switching to intermediate frequency */
> + if (cpufreq_driver->get_intermediate) {
> + retval = __target_intermediate(policy, , index);
> + if (retval)
> + return retval;

Shouldn't this all be outside the if (notify) block, so that
__target_intermediate is always called, and it's just the notify
callbacks that gets skipped if (!notify)?

--
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] mfd: axp20x: Remove unnecessary const qualifier from axp20x_supplies[]

2014-05-22 Thread Joe Perches
On Thu, 2014-05-22 at 17:08 +0100, Lee Jones wrote:
> To be frank, I've never known what the double const means.  Care to
> enlighten?

There's a nice table here:

http://stackoverflow.com/questions/14562845/why-does-passing-char-as-const-char-generate-a-warning


--
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 v6 0/7] Introduce keystone reset driver

2014-05-22 Thread Ivan Khoronzhuk
These patches introduce keystone reset driver.

The keystone SoC can be rebooted in several ways. By external reset
pin, by soft and by watchdogs. This driver allows software reset and reset
by one of the watchdogs. Also added opportunity to set soft/hard reset type.

Based on linux-next/master

v6..v5
  clock: keystone-pllctrl: add bindings for keystone pll controller
  mfd: ti-keystone-devctrl: add bindings for device state control
  power: reset: add bindings for keystone reset driver
  ARM: dts: keystone: update reset node to work with reset driver
- for nodes s/device-state-control/device-state-control@0262/g
- for nodes s/pll-controller/pll-controller@0231/g
  mfd: ti-keystone-devctrl: add bindings for device state control
- corrected description for reg property

v5..v4
  power: reset: keystone-reset: introduce keystone reset driver
- changed to get rsmux and rspll offsets from DT
  clock: keystone-pllctrl: add bindings for keystone pll controller
- new patch
  mfd: ti-keystone-devctrl: add bindings for device state control
- new patch
  power: reset: add bindings for keystone reset driver
- corrected description of "ti,syscon-pll", "ti,syscon-dev" properties
- corrected examples
  ARM: dts: keystone: update reset node to work with reset driver
- added nodes for pll-controller and device-state-controll
- added offsets to "ti,syscon-pll", "ti,syscon-dev" properties

v4..v3
  Power: reset: keystone-reset: introduce keystone reset driver
- changed to use syscon framework
- changed to use regmap to access registers
  Power: reset: add bindings for keystone reset driver
- deleted properties "reg", "reg-names"
- added properties "ti,syscon-pll", "ti,syscon-dev"
  ARM: dts: keystone: update reset node to work with reset driver
- deleted properties "reg", "reg-names"
- added properties "ti,syscon-pll", "ti,syscon-dev"

v2..v3
  Power: reset: keystone-reset: introduce keystone reset driver
- no functional changes, only sanity
  Power: reset: add bindings for keystone reset driver
- corrected WDT numeration in examples
- extended description of wdt_list property

v1..v2
- re based on v3.15-rc1 without changes

Ivan Khoronzhuk (7):
  power: reset: keystone-reset: introduce keystone reset driver
  clock: keystone-pllctrl: add bindings for keystone pll controller
  mfd: ti-keystone-devctrl: add bindings for device state control
  power: reset: add bindings for keystone reset driver
  ARM: keystone: remove redundant reset stuff
  ARM: dts: keystone: update reset node to work with reset driver
  ARM: keystone: enable reset driver support

 .../bindings/clock/ti-keystone-pllctrl.txt |  20 +++
 .../bindings/mfd/ti-keystone-devctrl.txt   |  19 +++
 .../bindings/power/reset/keystone-reset.txt|  67 +
 arch/arm/boot/dts/keystone.dtsi|  14 +-
 arch/arm/configs/keystone_defconfig|   3 +
 arch/arm/mach-keystone/keystone.c  |  34 -
 drivers/power/reset/Kconfig|   8 +
 drivers/power/reset/Makefile   |   1 +
 drivers/power/reset/keystone-reset.c   | 166 +
 9 files changed, 297 insertions(+), 35 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt
 create mode 100644 
Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt
 create mode 100644 
Documentation/devicetree/bindings/power/reset/keystone-reset.txt
 create mode 100644 drivers/power/reset/keystone-reset.c

-- 
1.8.3.2

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


[Patch v6 1/7] power: reset: keystone-reset: introduce keystone reset driver

2014-05-22 Thread Ivan Khoronzhuk
The keystone SoC can be rebooted in several ways. By external reset
pin, by soft and by watchdogs. To allow keystone SoC reset if
watchdog is triggered we have to enable it in reset mux configuration
register regarding of watchdog configuration. Also we need to set
soft/hard reset we are going to use.

So add keystone reset driver to handle all this stuff.

Reviewed-by: Arnd Bergmann 
Signed-off-by: Ivan Khoronzhuk 
---
 drivers/power/reset/Kconfig  |   8 ++
 drivers/power/reset/Makefile |   1 +
 drivers/power/reset/keystone-reset.c | 166 +++
 3 files changed, 175 insertions(+)
 create mode 100644 drivers/power/reset/keystone-reset.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index fa0e4e0..d095e5b 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -57,3 +57,11 @@ config POWER_RESET_XGENE
depends on POWER_RESET
help
  Reboot support for the APM SoC X-Gene Eval boards.
+
+config POWER_RESET_KEYSTONE
+   bool "Keystone reset driver"
+   depends on ARCH_KEYSTONE
+   select MFD_SYSCON
+   help
+ Reboot support for the KEYSTONE SoCs.
+
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index a5b4a77..802a420 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
 obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
 obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
 obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
+obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
diff --git a/drivers/power/reset/keystone-reset.c 
b/drivers/power/reset/keystone-reset.c
new file mode 100644
index 000..ab96bd5
--- /dev/null
+++ b/drivers/power/reset/keystone-reset.c
@@ -0,0 +1,166 @@
+/*
+ * TI keystone reboot driver
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated. http://www.ti.com/
+ *
+ * Author: Ivan Khoronzhuk 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RSTYPE_RG  0x0
+#define RSCTRL_RG  0x4
+#define RSCFG_RG   0x8
+#define RSISO_RG   0xc
+
+#define RSCTRL_KEY_MASK0x
+#define RSCTRL_RESET_MASK  BIT(16)
+#define RSCTRL_KEY 0x5a69
+
+#define RSMUX_OMODE_MASK   0xe
+#define RSMUX_OMODE_RESET_ON   0xa
+#define RSMUX_OMODE_RESET_OFF  0x0
+#define RSMUX_LOCK_MASK0x1
+#define RSMUX_LOCK_SET 0x1
+
+#define RSCFG_RSTYPE_SOFT  0x300f
+#define RSCFG_RSTYPE_HARD  0x0
+
+#define WDT_MUX_NUMBER 0x4
+
+static int rspll_offset;
+static struct regmap *pllctrl_regs;
+
+/**
+ * rsctrl_enable_rspll_write - enable access to RSCTRL, RSCFG
+ * To be able to access to RSCTRL, RSCFG registers
+ * we have to write a key before
+ */
+static inline int rsctrl_enable_rspll_write(void)
+{
+   return regmap_update_bits(pllctrl_regs, rspll_offset + RSCTRL_RG,
+ RSCTRL_KEY_MASK, RSCTRL_KEY);
+}
+
+static void rsctrl_restart(enum reboot_mode mode, const char *cmd)
+{
+   /* enable write access to RSTCTRL */
+   rsctrl_enable_rspll_write();
+
+   /* reset the SOC */
+   regmap_update_bits(pllctrl_regs, rspll_offset + RSCTRL_RG,
+  RSCTRL_RESET_MASK, 0);
+}
+
+static struct of_device_id rsctrl_of_match[] = {
+   {.compatible = "ti,keystone-reset", },
+   {},
+};
+
+static int rsctrl_probe(struct platform_device *pdev)
+{
+   int i;
+   int ret;
+   u32 val;
+   unsigned int rg;
+   u32 rsmux_offset;
+   struct regmap *devctrl_regs;
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
+
+   if (!np)
+   return -ENODEV;
+
+   /* get regmaps */
+   pllctrl_regs = syscon_regmap_lookup_by_phandle(np, "ti,syscon-pll");
+   if (IS_ERR(pllctrl_regs))
+   return PTR_ERR(pllctrl_regs);
+
+   devctrl_regs = syscon_regmap_lookup_by_phandle(np, "ti,syscon-dev");
+   if (IS_ERR(devctrl_regs))
+   return PTR_ERR(devctrl_regs);
+
+   ret = of_property_read_u32_index(np, "ti,syscon-pll", 1, _offset);
+   if (ret) {
+   dev_err(dev, "couldn't read the reset pll offset!\n");
+   return -EINVAL;
+   }
+
+   ret = of_property_read_u32_index(np, "ti,syscon-dev", 1, _offset);
+   if (ret) {
+   dev_err(dev, "couldn't read the rsmux offset!\n");
+   return -EINVAL;
+   }
+
+   /* set soft/hard reset */
+   val = 

[Patch v6 5/7] ARM: keystone: remove redundant reset stuff

2014-05-22 Thread Ivan Khoronzhuk
Remove reset stuff in flavour of using keystone reset driver:
driver/power/reset/keystone-reset.c

Reviewed-by: Arnd Bergmann 
Signed-off-by: Ivan Khoronzhuk 
---
 arch/arm/mach-keystone/keystone.c | 34 --
 1 file changed, 34 deletions(-)

diff --git a/arch/arm/mach-keystone/keystone.c 
b/arch/arm/mach-keystone/keystone.c
index 59b8383..1f9ae89 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -26,11 +26,6 @@
 
 #include "keystone.h"
 
-#define PLL_RESET_WRITE_KEY_MASK   0x
-#define PLL_RESET_WRITE_KEY0x5a69
-#define PLL_RESET  BIT(16)
-
-static void __iomem *keystone_rstctrl;
 static struct notifier_block platform_nb;
 static unsigned long keystone_dma_pfn_offset __read_mostly;
 
@@ -55,16 +50,6 @@ static int keystone_platform_notifier(struct notifier_block 
*nb,
 
 static void __init keystone_init(void)
 {
-   struct device_node *node;
-
-   node = of_find_compatible_node(NULL, NULL, "ti,keystone-reset");
-   if (WARN_ON(!node))
-   pr_warn("ti,keystone-reset node undefined\n");
-
-   keystone_rstctrl = of_iomap(node, 0);
-   if (WARN_ON(!keystone_rstctrl))
-   pr_warn("ti,keystone-reset iomap error\n");
-
keystone_pm_runtime_init();
if (platform_nb.notifier_call)
bus_register_notifier(_bus_type, _nb);
@@ -123,24 +108,6 @@ static const char *keystone_match[] __initconst = {
NULL,
 };
 
-void keystone_restart(enum reboot_mode mode, const char *cmd)
-{
-   u32 val;
-
-   BUG_ON(!keystone_rstctrl);
-
-   /* Enable write access to RSTCTRL */
-   val = readl(keystone_rstctrl);
-   val &= PLL_RESET_WRITE_KEY_MASK;
-   val |= PLL_RESET_WRITE_KEY;
-   writel(val, keystone_rstctrl);
-
-   /* Reset the SOC */
-   val = readl(keystone_rstctrl);
-   val &= ~PLL_RESET;
-   writel(val, keystone_rstctrl);
-}
-
 DT_MACHINE_START(KEYSTONE, "Keystone")
 #if defined(CONFIG_ZONE_DMA) && defined(CONFIG_ARM_LPAE)
.dma_zone_size  = SZ_2G,
@@ -148,6 +115,5 @@ DT_MACHINE_START(KEYSTONE, "Keystone")
.smp= smp_ops(keystone_smp_ops),
.init_machine   = keystone_init,
.dt_compat  = keystone_match,
-   .restart= keystone_restart,
.init_meminfo   = keystone_init_meminfo,
 MACHINE_END
-- 
1.8.3.2

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


[Patch v6 3/7] mfd: ti-keystone-devctrl: add bindings for device state control

2014-05-22 Thread Ivan Khoronzhuk
The Keystone II devices have a set of registers that are used to control
the status of its peripherals. This node is intended to allow access to
this functionality.

Reviewed-by: Arnd Bergmann 
Signed-off-by: Ivan Khoronzhuk 
---
 .../devicetree/bindings/mfd/ti-keystone-devctrl.txt   | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt

diff --git a/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt 
b/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt
new file mode 100644
index 000..20963c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt
@@ -0,0 +1,19 @@
+* Device tree bindings for Texas Instruments keystone device state control
+
+The Keystone II devices have a set of registers that are used to control
+the status of its peripherals. This node is intended to allow access to
+this functionality.
+
+Required properties:
+
+- compatible:  "ti,keystone-devctrl", "syscon"
+
+- reg: contains offset/length value for device state control
+   registers space.
+
+Example:
+
+devctrl: device-state-control@0x0262 {
+   compatible = "ti,keystone-devctrl", "syscon";
+   reg = <0x0262 0x1000>;
+};
-- 
1.8.3.2

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


[Patch v6 7/7] ARM: keystone: enable reset driver support

2014-05-22 Thread Ivan Khoronzhuk
Enable reset driver support in order to have opportunity
to reboot SoC by watchdog and by software.

Reviewed-by: Arnd Bergmann 
Signed-off-by: Ivan Khoronzhuk 
---
 arch/arm/configs/keystone_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/keystone_defconfig 
b/arch/arm/configs/keystone_defconfig
index 07b4327..dc0da3f 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -132,6 +132,9 @@ CONFIG_SPI=y
 CONFIG_SPI_DAVINCI=y
 CONFIG_SPI_SPIDEV=y
 # CONFIG_HWMON is not set
+CONFIG_POWER_SUPPLY=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_KEYSTONE=y
 CONFIG_WATCHDOG=y
 CONFIG_WATCHDOG_CORE=y
 CONFIG_DAVINCI_WATCHDOG=y
-- 
1.8.3.2

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


[Patch v6 6/7] ARM: dts: keystone: update reset node to work with reset driver

2014-05-22 Thread Ivan Khoronzhuk
The pll controller register set and device state control registers
include sets of registers with different purposes, so it's logically
to add syscon entry to be able to access them from appropriate places.

So added pll controller and device state control syscon entries.

The keystone driver requires the next additional properties:

"ti,syscon-pll" - phandle/offset pair. The phandle to syscon used to
  access pll controller registers and the offset to use
  reset control registers.

"ti,syscon-dev" - phandle/offset pair. The phandle to syscon used to
  access device state control registers and the offset
  in order to use mux block registers for all watchdogs.

"ti,wdt_list"   - option to declare what watchdogs are used to reboot
  the SoC, so set "0" WDT as default.

Reviewed-by: Arnd Bergmann 
Signed-off-by: Ivan Khoronzhuk 
---
 arch/arm/boot/dts/keystone.dtsi | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index d9f99e7..b05def6 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -66,9 +66,21 @@
ranges = <0x0 0x0 0x0 0xc000>;
dma-ranges = <0x8000 0x8 0x 0x8000>;
 
+   pllctrl: pll-controller@0231 {
+   compatible = "ti,keystone-pllctrl", "syscon";
+   reg = <0x0231 0x200>;
+   };
+
+   devctrl: device-state-control@0262 {
+   compatible = "ti,keystone-devctrl", "syscon";
+   reg = <0x0262 0x1000>;
+   };
+
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
-   reg = <0x023100e8 4>;   /* pll reset control reg */
+   ti,syscon-pll = < 0xe4>;
+   ti,syscon-dev = < 0x328>;
+   ti,wdt_list = <0>;
};
 
/include/ "keystone-clocks.dtsi"
-- 
1.8.3.2

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


[Patch v6 2/7] clock: keystone-pllctrl: add bindings for keystone pll controller

2014-05-22 Thread Ivan Khoronzhuk
The main pll controller used to drive theC66x CorePacs, the switch fabric,
and a majority of the peripheral clocks (all but the ARM CorePacs, DDR3 and
the NETCP modules) requires a PLL Controller to manage the various clock
divisions, gating, and synchronization.

Reviewed-by: Arnd Bergmann 
Signed-off-by: Ivan Khoronzhuk 
---
 .../bindings/clock/ti-keystone-pllctrl.txt   | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt

diff --git a/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt 
b/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt
new file mode 100644
index 000..3e6a81e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt
@@ -0,0 +1,20 @@
+* Device tree bindings for Texas Instruments keystone pll controller
+
+The main pll controller used to drive theC66x CorePacs, the switch fabric,
+and a majority of the peripheral clocks (all but the ARM CorePacs, DDR3 and
+the NETCP modules) requires a PLL Controller to manage the various clock
+divisions, gating, and synchronization.
+
+Required properties:
+
+- compatible:  "ti,keystone-pllctrl", "syscon"
+
+- reg: contains offset/length value for pll controller
+   registers space.
+
+Example:
+
+pllctrl: pll-controller@0x0231 {
+   compatible = "ti,keystone-pllctrl", "syscon";
+   reg = <0x0231 0x200>;
+};
-- 
1.8.3.2

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


Re: [PATCH] powerpc: fix typo 'CONFIG_PMAC'

2014-05-22 Thread Andreas Schwab
Paul Bolle  writes:

> Do you want to know how to test this patch on a 32 bit powermac? Ie, see
> if it has any effect, and whether that effect improves things or make
> things worse.

Yes.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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 v6 4/7] power: reset: add bindings for keystone reset driver

2014-05-22 Thread Ivan Khoronzhuk
This node is intended to allow SoC reset in case of software reset
or appropriate watchdogs.

The Keystone SoCs can contain up to 4 watchdog timers to reset
SoC. Each watchdog timer event input is connected to the Reset Mux
block. The Reset Mux block can be configured to cause reset or not.

Additionally soft or hard reset can be configured.

Reviewed-by: Arnd Bergmann 
Signed-off-by: Ivan Khoronzhuk 
---
 .../bindings/power/reset/keystone-reset.txt| 67 ++
 1 file changed, 67 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/keystone-reset.txt

diff --git a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt 
b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
new file mode 100644
index 000..a8a0c31
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
@@ -0,0 +1,67 @@
+* Device tree bindings for Texas Instruments keystone reset
+
+This node is intended to allow SoC reset in case of software reset
+of selected watchdogs.
+
+The Keystone SoCs can contain up to 4 watchdog timers to reset
+SoC. Each watchdog timer event input is connected to the Reset Mux
+block. The Reset Mux block can be configured to cause reset or not.
+
+Additionally soft or hard reset can be configured.
+
+Required properties:
+
+- compatible:  ti,keystone-reset
+
+- ti,syscon-pll:   phandle/offset pair. The phandle to syscon used to
+   access pll controller registers and the offset to use
+   reset control registers.
+
+- ti,syscon-dev:   phandle/offset pair. The phandle to syscon used to
+   access device state control registers and the offset
+   in order to use mux block registers for all watchdogs.
+
+Optional properties:
+
+- ti,soft-reset:   Boolean option indicating soft reset.
+   By default hard reset is used.
+
+- ti,wdt_list: WDT list that can cause SoC reset. It's not related
+   to WDT driver, it's just needed to enable a SoC related
+   reset that's triggered by one of WDTs. The list is
+   in format: <0>, <2>; It can be in random order and
+   begins from 0 to 3, as keystone can contain up to 4 SoC
+   reset watchdogs and can be in random order.
+
+Example 1:
+Setup keystone reset so that in case software reset or
+WDT0 is triggered it issues hard reset for SoC.
+
+pllctrl: pll-controller@0231 {
+   compatible = "ti,keystone-pllctrl", "syscon";
+   reg = <0x0231 0x200>;
+};
+
+devctrl: device-state-control@0262 {
+   compatible = "ti,keystone-devctrl", "syscon";
+   reg = <0x0262 0x1000>;
+};
+
+rstctrl: reset-controller {
+   compatible = "ti,keystone-reset";
+   ti,syscon-pll = < 0xe4>;
+   ti,syscon-dev = < 0x328>;
+   ti,wdt_list = <0>;
+};
+
+Example 2:
+Setup keystone reset so that in case of software reset or
+WDT0 or WDT2 is triggered it issues soft reset for SoC.
+
+rstctrl: reset-controller {
+   compatible = "ti,keystone-reset";
+   ti,syscon-pll = < 0xe4>;
+   ti,syscon-dev = < 0x328>;
+   ti,wdt_list = <0>, <2>;
+   ti,soft-reset;
+};
-- 
1.8.3.2

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


[PATCH v2 15/18] tile: io: implement dummy relaxed accessor macros for writes

2014-05-22 Thread Will Deacon
write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to tile, in the
same vein as the dummy definitions for the relaxed read accessors.

Acked-by: Chris Metcalf 
Signed-off-by: Will Deacon 
---
 arch/tile/include/asm/io.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/tile/include/asm/io.h b/arch/tile/include/asm/io.h
index 9fe434969fab..d372641054d9 100644
--- a/arch/tile/include/asm/io.h
+++ b/arch/tile/include/asm/io.h
@@ -241,6 +241,10 @@ static inline void writeq(u64 val, unsigned long addr)
 #define readw_relaxed readw
 #define readl_relaxed readl
 #define readq_relaxed readq
+#define writeb_relaxed writeb
+#define writew_relaxed writew
+#define writel_relaxed writel
+#define writeq_relaxed writeq
 
 #define ioread8 readb
 #define ioread16 readw
-- 
1.9.2

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


[PATCH net-next v2 9/9] powerpc/fsl: fsl_soc: remove 'fixed-link' parsing code

2014-05-22 Thread Florian Fainelli
Parsing and registration of fixed PHY devices was needed with the use of
of_phy_connect_fixed_link() because this function was using the
designated PHY address identifier (first cell of the property) as the
address to bind the PHY on the emulated bus.

Since commit 3be2a49e5c08d268f8af0dd4fe89a24ea8cdc339 ("of: provide a
binding for fixed link PHYs") a new pair of functions has been
introduced which allows for dynamic address allocation of these fixed
PHY devices, but also parses the old 'fixed-link' 5-digit property.

Registration of fixed PHY early in platform code was needed because we
could not issue a fixed MDIO bus re-scan within network drivers. The
fixed PHYs had to be registered before the network drivers would call
of_phy_connect_fixed_link(). All of these caveats are solved now, such
that we can safely remove of_add_fixed_phys() now.

Signed-off-by: Florian Fainelli 
---
No changes in v2

 arch/powerpc/sysdev/fsl_soc.c | 32 
 1 file changed, 32 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 228cf91b91c1..ffd1169ebaab 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -178,37 +177,6 @@ u32 get_baudrate(void)
 EXPORT_SYMBOL(get_baudrate);
 #endif /* CONFIG_CPM2 */
 
-#ifdef CONFIG_FIXED_PHY
-static int __init of_add_fixed_phys(void)
-{
-   int ret;
-   struct device_node *np;
-   u32 *fixed_link;
-   struct fixed_phy_status status = {};
-
-   for_each_node_by_name(np, "ethernet") {
-   fixed_link  = (u32 *)of_get_property(np, "fixed-link", NULL);
-   if (!fixed_link)
-   continue;
-
-   status.link = 1;
-   status.duplex = fixed_link[1];
-   status.speed = fixed_link[2];
-   status.pause = fixed_link[3];
-   status.asym_pause = fixed_link[4];
-
-   ret = fixed_phy_add(PHY_POLL, fixed_link[0], );
-   if (ret) {
-   of_node_put(np);
-   return ret;
-   }
-   }
-
-   return 0;
-}
-arch_initcall(of_add_fixed_phys);
-#endif /* CONFIG_FIXED_PHY */
-
 #if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
 static __be32 __iomem *rstcr;
 
-- 
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 net-next v2 8/9] of: mdio: remove of_phy_connect_fixed_link

2014-05-22 Thread Florian Fainelli
All in-tree drivers have been converted to use the new pair of
functions: of_is_fixed_phy_link() plus of_phy_register_fixed_link(), we
can now safely remove of_phy_connect_fixed_link.

Signed-off-by: Florian Fainelli 
---
No changes in v2

 drivers/of/of_mdio.c| 38 --
 include/linux/of_mdio.h | 10 --
 2 files changed, 48 deletions(-)

diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 1def0bb5cb37..4c1e01ed16dc 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -246,44 +246,6 @@ struct phy_device *of_phy_connect(struct net_device *dev,
 EXPORT_SYMBOL(of_phy_connect);
 
 /**
- * of_phy_connect_fixed_link - Parse fixed-link property and return a dummy phy
- * @dev: pointer to net_device claiming the phy
- * @hndlr: Link state callback for the network device
- * @iface: PHY data interface type
- *
- * This function is a temporary stop-gap and will be removed soon.  It is
- * only to support the fs_enet, ucc_geth and gianfar Ethernet drivers.  Do
- * not call this function from new drivers.
- */
-struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
-void (*hndlr)(struct net_device *),
-phy_interface_t iface)
-{
-   struct device_node *net_np;
-   char bus_id[MII_BUS_ID_SIZE + 3];
-   struct phy_device *phy;
-   const __be32 *phy_id;
-   int sz;
-
-   if (!dev->dev.parent)
-   return NULL;
-
-   net_np = dev->dev.parent->of_node;
-   if (!net_np)
-   return NULL;
-
-   phy_id = of_get_property(net_np, "fixed-link", );
-   if (!phy_id || sz < sizeof(*phy_id))
-   return NULL;
-
-   sprintf(bus_id, PHY_ID_FMT, "fixed-0", be32_to_cpu(phy_id[0]));
-
-   phy = phy_connect(dev, bus_id, hndlr, iface);
-   return IS_ERR(phy) ? NULL : phy;
-}
-EXPORT_SYMBOL(of_phy_connect_fixed_link);
-
-/**
  * of_phy_attach - Attach to a PHY without starting the state machine
  * @dev: pointer to net_device claiming the phy
  * @phy_np: Node pointer for the PHY
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 0aa367e316cb..d449018d0726 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -22,9 +22,6 @@ extern struct phy_device *of_phy_connect(struct net_device 
*dev,
 struct phy_device *of_phy_attach(struct net_device *dev,
 struct device_node *phy_np, u32 flags,
 phy_interface_t iface);
-extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
-void (*hndlr)(struct net_device *),
-phy_interface_t iface);
 
 extern struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np);
 
@@ -59,13 +56,6 @@ static inline struct phy_device *of_phy_attach(struct 
net_device *dev,
return NULL;
 }
 
-static inline struct phy_device *of_phy_connect_fixed_link(struct net_device 
*dev,
-  void (*hndlr)(struct 
net_device *),
-  phy_interface_t 
iface)
-{
-   return NULL;
-}
-
 static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
 {
return NULL;
-- 
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 v2 05/18] alpha: io: implement relaxed accessor macros for writes

2014-05-22 Thread Will Deacon
write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O writes with weaker barrier semantics than the
non-relaxed variants.

This patch implements these write macros for Alpha, in the same vein as
the relaxed read macros, which are already implemented.

Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Signed-off-by: Will Deacon 
---
 arch/alpha/include/asm/io.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
index 5ebab5895edb..f05bdb4b1cb9 100644
--- a/arch/alpha/include/asm/io.h
+++ b/arch/alpha/include/asm/io.h
@@ -500,10 +500,14 @@ extern inline void writeq(u64 b, volatile void __iomem 
*addr)
 #define outb_p outb
 #define outw_p outw
 #define outl_p outl
-#define readb_relaxed(addr) __raw_readb(addr)
-#define readw_relaxed(addr) __raw_readw(addr)
-#define readl_relaxed(addr) __raw_readl(addr)
-#define readq_relaxed(addr) __raw_readq(addr)
+#define readb_relaxed(addr)__raw_readb(addr)
+#define readw_relaxed(addr)__raw_readw(addr)
+#define readl_relaxed(addr)__raw_readl(addr)
+#define readq_relaxed(addr)__raw_readq(addr)
+#define writeb_relaxed(b, addr)__raw_writeb(b, addr)
+#define writew_relaxed(b, addr)__raw_writew(b, addr)
+#define writel_relaxed(b, addr)__raw_writel(b, addr)
+#define writeq_relaxed(b, addr)__raw_writeq(b, addr)
 
 #define mmiowb()
 
-- 
1.9.2

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


[PATCH v2 07/18] cris: io: implement dummy relaxed accessor macros for writes

2014-05-22 Thread Will Deacon
write{b,w,l}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to Cris, in the same
vein as the dummy definitions for the relaxed read accessors.

Cc: Mikael Starvik 
Acked-by: Jesper Nilsson 
Signed-off-by: Will Deacon 
---
 arch/cris/include/asm/io.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/cris/include/asm/io.h b/arch/cris/include/asm/io.h
index e59dba12ce94..752a3f45df60 100644
--- a/arch/cris/include/asm/io.h
+++ b/arch/cris/include/asm/io.h
@@ -112,6 +112,9 @@ static inline void writel(unsigned int b, volatile void 
__iomem *addr)
else
*(volatile unsigned int __force *) addr = b;
 }
+#define writeb_relaxed(b, addr) writeb(b, addr)
+#define writew_relaxed(b, addr) writew(b, addr)
+#define writel_relaxed(b, addr) writel(b, addr)
 #define __raw_writeb writeb
 #define __raw_writew writew
 #define __raw_writel writel
-- 
1.9.2

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


[PATCH v2 16/18] x86: io: implement dummy relaxed accessor macros for writes

2014-05-22 Thread Will Deacon
write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the read and write accessors to x86,
which simply expand to the non-relaxed variants. Note that this
strengthens the relaxed read accessors, since they are now ordered with
respect to each other by way of a compiler barrier.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Signed-off-by: Will Deacon 
---
 arch/x86/include/asm/io.h | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index b8237d8a1e0c..56d6d43aca9b 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -67,13 +67,16 @@ build_mmio_write(__writeb, "b", unsigned char, "q", )
 build_mmio_write(__writew, "w", unsigned short, "r", )
 build_mmio_write(__writel, "l", unsigned int, "r", )
 
-#define readb_relaxed(a) __readb(a)
-#define readw_relaxed(a) __readw(a)
-#define readl_relaxed(a) __readl(a)
+#define readb_relaxed(a) readb(a)
+#define readw_relaxed(a) readw(a)
+#define readl_relaxed(a) readl(a)
 #define __raw_readb __readb
 #define __raw_readw __readw
 #define __raw_readl __readl
 
+#define writeb_relaxed(v, a) writeb(v, a)
+#define writew_relaxed(v, a) writew(v, a)
+#define writel_relaxed(v, a) writel(v, a)
 #define __raw_writeb __writeb
 #define __raw_writew __writew
 #define __raw_writel __writel
@@ -86,6 +89,7 @@ build_mmio_read(readq, "q", unsigned long, "=r", :"memory")
 build_mmio_write(writeq, "q", unsigned long, "r", :"memory")
 
 #define readq_relaxed(a)   readq(a)
+#define writeq_relaxed(v, a)   writeq(v, a)
 
 #define __raw_readq(a) readq(a)
 #define __raw_writeq(val, addr)writeq(val, addr)
-- 
1.9.2

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


Re: [PATCH 1/8] mmc: sdhci-st: Intial support for ST SDHCI controller

2014-05-22 Thread Lee Jones

> This platform driver adds initial support for the SDHCI host controller
> found on STMicroelectronics SoCs.
> 
> It has been tested on STiH41x b2020 platforms currently.
> 
> Signed-off-by: Peter Griffin 
> Signed-off-by: Giuseppe Cavallaro 
> ---
>  drivers/mmc/host/Kconfig|  12 +++
>  drivers/mmc/host/Makefile   |   1 +
>  drivers/mmc/host/sdhci-st.c | 244 
> 
>  3 files changed, 257 insertions(+)
>  create mode 100644 drivers/mmc/host/sdhci-st.c

[...]

> +static int sdhci_st_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct sdhci_host *host;
> + struct st_mmc_platform_data *pdata;
> + struct sdhci_pltfm_host *pltfm_host;
> + struct clk *clk;
> + int ret = 0;
> + u16 host_version;
> +
> + dev_dbg(>dev, "SDHCI ST platform driver\n");
> +
> + pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + pdata->rstc = devm_reset_control_get(>dev, NULL);
> + if (IS_ERR(pdata->rstc))
> + pdata->rstc = NULL;
> + else
> + reset_control_deassert(pdata->rstc);
> +
> + clk =  devm_clk_get(>dev, "mmc");
> + if (IS_ERR(clk)) {
> + dev_err(>dev, "Perpheral clk not found\n");
> + return PTR_ERR(clk);
> + }
> +
> + host = sdhci_pltfm_init(pdev, _st_pdata, 0);
> + if (IS_ERR(host)) {
> + dev_err(>dev, "Failed sdhci_pltfm_init\n");
> + return PTR_ERR(host);
> + }
> +
> + clk_prepare_enable(clk);

Move this down as far as it will go.  When do you _need_ the clock
running by?

> + host->mmc->caps |= MMC_CAP_8_BIT_DATA | MMC_CAP_BUS_WIDTH_TEST
> + | MMC_CAP_1_8V_DDR;
> +
> + if (of_property_read_bool(np, "non-removable"))
> + host->mmc->caps |= MMC_CAP_NONREMOVABLE;
> +
> + pltfm_host = sdhci_priv(host);
> + pltfm_host->clk = clk;
> +
> + ret = sdhci_add_host(host);
> + if (ret) {
> + dev_err(>dev, "Failed sdhci_add_host\n");
> + goto err_out;

If it's possible to move the clk_prepare enable down past here, then
you only need to do sdhci_pltfm_free() and you can remove all of the
err_out error path.

> + }
> +
> + pltfm_host->priv = pdata;
> +
> + platform_set_drvdata(pdev, host);
> +
> + host_version = readw_relaxed((host->ioaddr + SDHCI_HOST_VERSION));

Do we want to be doing any error checking for unsupported devices
here?

[...]

> +static struct platform_driver sdhci_st_driver = {
> + .probe = sdhci_st_probe,
> + .remove = sdhci_st_remove,
> + .driver = {
> +.name = "sdhci-st",
> +.owner = THIS_MODULE,
> +.pm = SDHCI_ST_PMOPS,
> +.of_match_table = of_match_ptr(st_sdhci_match),
> +   },

Tabbing issue here.

> +};
> +
> +module_platform_driver(sdhci_st_driver);
> +
> +MODULE_DESCRIPTION("SDHCI driver for STMicroelectronics SoCs");
> +MODULE_AUTHOR("Giuseppe Cavallaro ");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:st-sdhci");

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


[PATCH v2 13/18] powerpc: io: implement dummy relaxed accessor macros for writes

2014-05-22 Thread Will Deacon
write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to powerpc, in the
same vein as the dummy definitions for the relaxed read accessors.

Cc: Benjamin Herrenschmidt 
Signed-off-by: Will Deacon 
---
 arch/powerpc/include/asm/io.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 97d3869991ca..9eaf301ac952 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -617,10 +617,14 @@ static inline void name at
\
 /*
  * We don't do relaxed operations yet, at least not with this semantic
  */
-#define readb_relaxed(addr) readb(addr)
-#define readw_relaxed(addr) readw(addr)
-#define readl_relaxed(addr) readl(addr)
-#define readq_relaxed(addr) readq(addr)
+#define readb_relaxed(addr)readb(addr)
+#define readw_relaxed(addr)readw(addr)
+#define readl_relaxed(addr)readl(addr)
+#define readq_relaxed(addr)readq(addr)
+#define writeb_relaxed(v, addr)writeb(v, addr)
+#define writew_relaxed(v, addr)writew(v, addr)
+#define writel_relaxed(v, addr)writel(v, addr)
+#define writeq_relaxed(v, addr)writeq(v, addr)
 
 #ifdef CONFIG_PPC32
 #define mmiowb()
-- 
1.9.2

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


[PATCH net-next v2 7/9] ucc_geth: use the new fixed PHY helpers

2014-05-22 Thread Florian Fainelli
of_phy_connect_fixed_link() is becoming obsolete, and also required
platform code to register the fixed PHYs at the specified addresses for
those to be usable. Get rid of it and use the new of_phy_is_fixed_link()
plus of_phy_register_fixed_link() helpers to transition over the new
scheme.

Signed-off-by: Florian Fainelli 
---
No changes in v2

 drivers/net/ethernet/freescale/ucc_geth.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/freescale/ucc_geth.c 
b/drivers/net/ethernet/freescale/ucc_geth.c
index c8299c31b21f..fab39e295441 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -1728,9 +1728,6 @@ static int init_phy(struct net_device *dev)
 
phydev = of_phy_connect(dev, ug_info->phy_node, _link, 0,
priv->phy_interface);
-   if (!phydev)
-   phydev = of_phy_connect_fixed_link(dev, _link,
-  priv->phy_interface);
if (!phydev) {
dev_err(>dev, "Could not attach to PHY\n");
return -ENODEV;
@@ -3790,6 +3787,17 @@ static int ucc_geth_probe(struct platform_device* ofdev)
ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
 
ug_info->phy_node = of_parse_phandle(np, "phy-handle", 0);
+   if (!ug_info->phy_node) {
+   /* In the case of a fixed PHY, the DT node associated
+* to the PHY is the Ethernet MAC DT node.
+*/
+   if (of_phy_is_fixed_link(np)) {
+   err = of_phy_register_fixed_link(np);
+   if (err)
+   return err;
+   }
+   ug_info->phy_node = np;
+   }
 
/* Find the TBI PHY node.  If it's not there, we don't support SGMII */
ug_info->tbi_node = of_parse_phandle(np, "tbi-handle", 0);
-- 
1.9.1

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


[PATCH net-next v2 6/9] gianfar: use the new fixed PHY helpers

2014-05-22 Thread Florian Fainelli
of_phy_connect_fixed_link() is becoming obsolete, and also required
platform code to register the fixed PHYs at the specified addresses for
those to be usable. Get rid of it and use the new of_phy_is_fixed_link()
plus of_phy_register_fixed_link() helpers to transition over the new
scheme.

Signed-off-by: Florian Fainelli 
---
No changes in v2

 drivers/net/ethernet/freescale/gianfar.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index e2d42475b006..282674027c92 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -889,6 +889,17 @@ static int gfar_of_init(struct platform_device *ofdev, 
struct net_device **pdev)
 
priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
 
+   /* In the case of a fixed PHY, the DT node associated
+* to the PHY is the Ethernet MAC DT node.
+*/
+   if (of_phy_is_fixed_link(np)) {
+   err = of_phy_register_fixed_link(np);
+   if (err)
+   goto err_grp_init;
+
+   priv->phy_node = np;
+   }
+
/* Find the TBI PHY.  If it's not there, we don't support SGMII */
priv->tbi_node = of_parse_phandle(np, "tbi-handle", 0);
 
@@ -1660,9 +1671,6 @@ static int init_phy(struct net_device *dev)
 
priv->phydev = of_phy_connect(dev, priv->phy_node, _link, 0,
  interface);
-   if (!priv->phydev)
-   priv->phydev = of_phy_connect_fixed_link(dev, _link,
-interface);
if (!priv->phydev) {
dev_err(>dev, "could not attach to PHY\n");
return -ENODEV;
-- 
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 v2 18/18] asm-generic: io: define relaxed accessor macros unconditionally

2014-05-22 Thread Will Deacon
Now that no architectures using asm-generic/io.h define their own relaxed
accessors, the dummy definitions can be used unconditionally.

Cc: Arnd Bergmann 
Signed-off-by: Will Deacon 
---
 include/asm-generic/io.h | 16 
 1 file changed, 16 deletions(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 9ccedeb06522..f5611abb82ed 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -53,27 +53,21 @@ static inline u32 __raw_readl(const volatile void __iomem 
*addr)
 #endif
 
 #define readb __raw_readb
-#ifndef readb_relaxed
 #define readb_relaxed readb
-#endif
 
 #define readw readw
 static inline u16 readw(const volatile void __iomem *addr)
 {
return __le16_to_cpu(__raw_readw(addr));
 }
-#ifndef readw_relaxed
 #define readw_relaxed readw
-#endif
 
 #define readl readl
 static inline u32 readl(const volatile void __iomem *addr)
 {
return __le32_to_cpu(__raw_readl(addr));
 }
-#ifndef readl_relaxed
 #define readl_relaxed readl
-#endif
 
 #ifndef __raw_writeb
 static inline void __raw_writeb(u8 b, volatile void __iomem *addr)
@@ -97,19 +91,13 @@ static inline void __raw_writel(u32 b, volatile void 
__iomem *addr)
 #endif
 
 #define writeb __raw_writeb
-#ifndef writeb_relaxed
 #define writeb_relaxed writeb
-#endif
 
 #define writew(b,addr) __raw_writew(__cpu_to_le16(b),addr)
-#ifndef writew_relaxed
 #define writew_relaxed writew
-#endif
 
 #define writel(b,addr) __raw_writel(__cpu_to_le32(b),addr)
-#ifndef writel_relaxed
 #define writel_relaxed writel
-#endif
 
 #ifdef CONFIG_64BIT
 #ifndef __raw_readq
@@ -124,9 +112,7 @@ static inline u64 readq(const volatile void __iomem *addr)
 {
return __le64_to_cpu(__raw_readq(addr));
 }
-#ifndef readq_relaxed
 #define readq_relaxed readq
-#endif
 
 #ifndef __raw_writeq
 static inline void __raw_writeq(u64 b, volatile void __iomem *addr)
@@ -136,9 +122,7 @@ static inline void __raw_writeq(u64 b, volatile void 
__iomem *addr)
 #endif
 
 #define writeq(b, addr) __raw_writeq(__cpu_to_le64(b), addr)
-#ifndef writeq_relaxed
 #define writeq_relaxed writeq
-#endif
 #endif /* CONFIG_64BIT */
 
 #ifndef PCI_IOBASE
-- 
1.9.2

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


[PATCH v2 10/18] m68k: io: implement dummy relaxed accessor macros for writes

2014-05-22 Thread Will Deacon
write{b,w,l}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to m68k, in the
same vein as the dummy definitions for the relaxed read accessors.
Additionally, the existing relaxed read accessors are moved into
asm/io.h, so that they can be used by m68k targets with an MMU.

Acked-by: Geert Uytterhoeven 
Signed-off-by: Will Deacon 
---
 arch/m68k/include/asm/io.h| 8 
 arch/m68k/include/asm/io_no.h | 4 
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index c70cc9155003..bccd5a914eb6 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -3,3 +3,11 @@
 #else
 #include 
 #endif
+
+#define readb_relaxed(addr)readb(addr)
+#define readw_relaxed(addr)readw(addr)
+#define readl_relaxed(addr)readl(addr)
+
+#define writeb_relaxed(b, addr)writeb(b, addr)
+#define writew_relaxed(b, addr)writew(b, addr)
+#define writel_relaxed(b, addr)writel(b, addr)
diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 52f7e8499172..19c237c63dc2 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -40,10 +40,6 @@ static inline unsigned int _swapl(volatile unsigned long v)
 #define readl(addr) \
 ({ unsigned int __v = (*(volatile unsigned int *) (addr)); __v; })
 
-#define readb_relaxed(addr) readb(addr)
-#define readw_relaxed(addr) readw(addr)
-#define readl_relaxed(addr) readl(addr)
-
 #define writeb(b,addr) (void)((*(volatile unsigned char *) (addr)) = (b))
 #define writew(b,addr) (void)((*(volatile unsigned short *) (addr)) = (b))
 #define writel(b,addr) (void)((*(volatile unsigned int *) (addr)) = (b))
-- 
1.9.2

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


Re: [PATCH 0/3] staging/skein: more cleanup

2014-05-22 Thread Jake Edge
On Wed, 21 May 2014 01:52:17 +0400 Anton Saraev wrote:
> On Tue, May 20, 2014 at 10:24:11AM -0600, Jake Edge wrote:
> > On Tue, 20 May 2014 10:47:57 -0400 Jason Cooper wrote:
> >
> > but some kind of tests are needed to ensure nothing breaks before
> > digging into that ...
> 
> I have some test: slightly modified version of tests from
> https://github.com/wernerd/Skein3Fish. It works as debugfs entry
> and require some modification needed for module support
> ("public" function must be extern). As I can understand Jason
> has his own tests. That would be logical to share them but
> I don't know where.

well, it seems to me that we want tests that eventually can be added
into the crypto test framework once skein moves out of staging and into
crypto ... Jason's objdiff seems like it would be used as another
development tool ...

so do you have your tests anywhere that we can look at them?  or,
failing that, maybe you can just email me a copy off-list or something?

do you have patches pending for skein?  i might get a chance to hack on
this some over the weekend, and we may as well try to avoid duplicating
each other's efforts ...

jake

-- 
Jake Edge - LWN - j...@lwn.net - http://lwn.net
--
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/18] Cross-architecture definitions of relaxed MMIO accessors

2014-05-22 Thread Will Deacon
Hi all,

This is version 2 of the series I originally posted here:

  https://lkml.org/lkml/2014/4/17/269

Changes since v1 include:

 - Added relevant acks from arch maintainers
 - Fixed potential compiler re-ordering issue for x86 definitions

I'd *really* appreciate some feedback on the proposed semantics here, but
acks are still good :)

The original cover letter is duplicated below.

Cheers,

Will

--->8

This RFC series attempts to define a portable (i.e. cross-architecture)
definition of the {readX,writeX}_relaxed MMIO accessor functions. These
functions are already in widespread use amongst drivers (mainly those supporting
devices embedded in ARM SoCs), but lack any well-defined semantics and,
subsequently, any portable definitions to allow these drivers to be compiled for
other architectures.

The two main motivations for this series are:

 (1) To promote use of the _relaxed MMIO accessors on weakly-ordered
 architectures, where they can bring significant performance improvements
 over their non-relaxed counterparts.

 (2) To allow COMPILE_TEST to build drivers using the relaxed accessors across
 all architectures.

The proposed semantics largely match exactly those provided by the ARM
implementation (i.e. no weaker), with one exception (see below).

Informally:

  - Relaxed accesses to the same device are ordered with respect to each other.

  - Relaxed accesses are *not* guaranteed to be ordered with respect to normal
memory accesses (e.g. DMA buffers -- this is what gives us the performance
boost over the non-relaxed versions).

  - Relaxed accesses are not guaranteed to be ordered with respect to
LOCK/UNLOCK operations.

In actual fact, the relaxed accessors *are* ordered with respect to LOCK/UNLOCK
operations on ARM[64], but I have added this constraint for the benefit of
PowerPC, which has expensive I/O barriers in the spin_unlock path for the
non-relaxed accessors.

A corollary to this is that mmiowb() probably needs rethinking. As it currently
stands, an mmiowb() is required to order MMIO writes to a device from multiple
CPUs, even if that device is protected by a lock. However, this isn't often used
in practice, leading to PowerPC implementing both mmiowb() *and* synchronising
I/O in spin_unlock.

I would propose making the non-relaxed I/O accessors ordered with respect to
LOCK/UNLOCK, leaving mmiowb() to be used with the relaxed accessors, if
required, but would welcome thoughts/suggestions on this topic.


Will Deacon (18):
  asm-generic: io: implement relaxed accessor macros as conditional
wrappers
  microblaze: io: remove dummy relaxed accessor macros
  s390: io: remove dummy relaxed accessor macros for reads
  xtensa: io: remove dummy relaxed accessor macros for reads
  alpha: io: implement relaxed accessor macros for writes
  frv: io: implement dummy relaxed accessor macros for writes
  cris: io: implement dummy relaxed accessor macros for writes
  ia64: io: implement dummy relaxed accessor macros for writes
  m32r: io: implement dummy relaxed accessor macros for writes
  m68k: io: implement dummy relaxed accessor macros for writes
  mn10300: io: implement dummy relaxed accessor macros for writes
  parisc: io: implement dummy relaxed accessor macros for writes
  powerpc: io: implement dummy relaxed accessor macros for writes
  sparc: io: implement dummy relaxed accessor macros for writes
  tile: io: implement dummy relaxed accessor macros for writes
  x86: io: implement dummy relaxed accessor macros for writes
  documentation: memory-barriers: clarify relaxed io accessor semantics
  asm-generic: io: define relaxed accessor macros unconditionally

 Documentation/memory-barriers.txt | 13 +
 arch/alpha/include/asm/io.h   | 12 
 arch/cris/include/asm/io.h|  3 +++
 arch/frv/include/asm/io.h |  3 +++
 arch/ia64/include/asm/io.h|  4 
 arch/m32r/include/asm/io.h|  3 +++
 arch/m68k/include/asm/io.h|  8 
 arch/m68k/include/asm/io_no.h |  4 
 arch/microblaze/include/asm/io.h  |  8 
 arch/mn10300/include/asm/io.h |  4 
 arch/parisc/include/asm/io.h  | 12 
 arch/powerpc/include/asm/io.h | 12 
 arch/s390/include/asm/io.h|  5 -
 arch/sparc/include/asm/io.h   |  9 +
 arch/sparc/include/asm/io_32.h|  3 ---
 arch/sparc/include/asm/io_64.h| 22 ++
 arch/tile/include/asm/io.h|  4 
 arch/x86/include/asm/io.h | 10 +++---
 arch/xtensa/include/asm/io.h  |  7 ---
 include/asm-generic/io.h  | 10 ++
 20 files changed, 98 insertions(+), 58 deletions(-)

-- 
1.9.2

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


[PATCH v2 14/18] sparc: io: implement dummy relaxed accessor macros for writes

2014-05-22 Thread Will Deacon
write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to sparc, in the
same vein as the dummy definitions for the relaxed read accessors. The
existing relaxed read{b,w,l} accessors are moved into asm/io.h, since
they are identical between 32-bit and 64-bit machines.

Cc: "David S. Miller" 
Signed-off-by: Will Deacon 
---
 arch/sparc/include/asm/io.h|  9 +
 arch/sparc/include/asm/io_32.h |  3 ---
 arch/sparc/include/asm/io_64.h | 22 ++
 3 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/arch/sparc/include/asm/io.h b/arch/sparc/include/asm/io.h
index f6902cf3cbe9..493f22c4684f 100644
--- a/arch/sparc/include/asm/io.h
+++ b/arch/sparc/include/asm/io.h
@@ -10,6 +10,15 @@
  * Defines used for both SPARC32 and SPARC64
  */
 
+/* Relaxed accessors for MMIO */
+#define readb_relaxed(__addr)  readb(__addr)
+#define readw_relaxed(__addr)  readw(__addr)
+#define readl_relaxed(__addr)  readl(__addr)
+
+#define writeb_relaxed(__b, __addr)writeb(__b, __addr)
+#define writew_relaxed(__w, __addr)writew(__w, __addr)
+#define writel_relaxed(__l, __addr)writel(__l, __addr)
+
 /* Big endian versions of memory read/write routines */
 #define readb_be(__addr)   __raw_readb(__addr)
 #define readw_be(__addr)   __raw_readw(__addr)
diff --git a/arch/sparc/include/asm/io_32.h b/arch/sparc/include/asm/io_32.h
index c1acbd891cbc..41d33e567f1d 100644
--- a/arch/sparc/include/asm/io_32.h
+++ b/arch/sparc/include/asm/io_32.h
@@ -89,9 +89,6 @@ static inline void __writel(u32 l, volatile void __iomem 
*addr)
 #define readb(__addr)  __readb(__addr)
 #define readw(__addr)  __readw(__addr)
 #define readl(__addr)  __readl(__addr)
-#define readb_relaxed(__addr)  readb(__addr)
-#define readw_relaxed(__addr)  readw(__addr)
-#define readl_relaxed(__addr)  readl(__addr)
 
 #define writeb(__b, __addr)__writeb((__b),(__addr))
 #define writew(__w, __addr)__writew((__w),(__addr))
diff --git a/arch/sparc/include/asm/io_64.h b/arch/sparc/include/asm/io_64.h
index 09b0b88aeb2a..2b4cd52831d0 100644
--- a/arch/sparc/include/asm/io_64.h
+++ b/arch/sparc/include/asm/io_64.h
@@ -203,18 +203,16 @@ static inline void _writeq(u64 q, volatile void __iomem 
*addr)
 : "memory");
 }
 
-#define readb(__addr)  _readb(__addr)
-#define readw(__addr)  _readw(__addr)
-#define readl(__addr)  _readl(__addr)
-#define readq(__addr)  _readq(__addr)
-#define readb_relaxed(__addr)  _readb(__addr)
-#define readw_relaxed(__addr)  _readw(__addr)
-#define readl_relaxed(__addr)  _readl(__addr)
-#define readq_relaxed(__addr)  _readq(__addr)
-#define writeb(__b, __addr)_writeb(__b, __addr)
-#define writew(__w, __addr)_writew(__w, __addr)
-#define writel(__l, __addr)_writel(__l, __addr)
-#define writeq(__q, __addr)_writeq(__q, __addr)
+#define readb(__addr)  _readb(__addr)
+#define readw(__addr)  _readw(__addr)
+#define readl(__addr)  _readl(__addr)
+#define readq(__addr)  _readq(__addr)
+#define readq_relaxed(__addr)  _readq(__addr)
+#define writeb(__b, __addr)_writeb(__b, __addr)
+#define writew(__w, __addr)_writew(__w, __addr)
+#define writel(__l, __addr)_writel(__l, __addr)
+#define writeq(__q, __addr)_writeq(__q, __addr)
+#define writeq_relaxed(__q, __addr)_writeq(__q, __addr)
 
 /* Now versions without byte-swapping. */
 static inline u8 _raw_readb(unsigned long addr)
-- 
1.9.2

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


[PATCH net-next v2 2/9] Documentation: devicetree: net: refer to fixed-link.txt

2014-05-22 Thread Florian Fainelli
Update the Freescale TSEC PHY, Broadcom GENET & SYSTEMPORT Device Tree
binding documentation to refer to the fixed-link Device Tree binding in
fixed-link.txt.

Reviewed-by: Thomas Petazzoni 
Signed-off-by: Florian Fainelli 
---
No changes in v2

 Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt   | 2 +-
 Documentation/devicetree/bindings/net/broadcom-systemport.txt | 2 +-
 Documentation/devicetree/bindings/net/fsl-tsec-phy.txt| 5 +
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt 
b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
index f2febb94550e..451fef26b4df 100644
--- a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
+++ b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
@@ -24,7 +24,7 @@ Optional properties:
 - fixed-link: When the GENET interface is connected to a MoCA hardware block or
   when operating in a RGMII to RGMII type of connection, or when the MDIO bus 
is
   voluntarily disabled, this property should be used to describe the "fixed 
link".
-  See Documentation/devicetree/bindings/net/fsl-tsec-phy.txt for information on
+  See Documentation/devicetree/bindings/net/fixed-link.txt for information on
   the property specifics
 
 Required child nodes:
diff --git a/Documentation/devicetree/bindings/net/broadcom-systemport.txt 
b/Documentation/devicetree/bindings/net/broadcom-systemport.txt
index 1b7600e022dd..c183ea90d9bc 100644
--- a/Documentation/devicetree/bindings/net/broadcom-systemport.txt
+++ b/Documentation/devicetree/bindings/net/broadcom-systemport.txt
@@ -8,7 +8,7 @@ Required properties:
 - local-mac-address: Ethernet MAC address (48 bits) of this adapter
 - phy-mode: Should be a string describing the PHY interface to the
   Ethernet switch/PHY, see Documentation/devicetree/bindings/net/ethernet.txt
-- fixed-link: see Documentation/devicetree/bindings/net/fsl-tsec-phy.txt for
+- fixed-link: see Documentation/devicetree/bindings/net/fixed-link.txt for
   the property specific details
 
 Optional properties:
diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt 
b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index 737cdef4f903..be6ea8960f20 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -42,10 +42,7 @@ Properties:
 interrupt.  For TSEC and eTSEC devices, the first interrupt is
 transmit, the second is receive, and the third is error.
   - phy-handle : See ethernet.txt file in the same directory.
-  - fixed-link :  where a is emulated phy id - choose any,
-but unique to the all specified fixed-links, b is duplex - 0 half,
-1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
-pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
+  - fixed-link : See fixed-link.txt in the same directory.
   - phy-connection-type : See ethernet.txt file in the same directory.
 This property is only really needed if the connection is of type
 "rgmii-id", as all other connection types are detected by hardware.
-- 
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 v2 09/18] m32r: io: implement dummy relaxed accessor macros for writes

2014-05-22 Thread Will Deacon
write{b,w,l}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to m32r, in the
same vein as the dummy definitions for the relaxed read accessors.

Cc: Hirokazu Takata 
Signed-off-by: Will Deacon 
---
 arch/m32r/include/asm/io.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 4010f1fc5b65..6e7787f3dac7 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -161,6 +161,9 @@ static inline void _writel(unsigned long l, unsigned long 
addr)
 #define __raw_writeb writeb
 #define __raw_writew writew
 #define __raw_writel writel
+#define writeb_relaxed writeb
+#define writew_relaxed writew
+#define writel_relaxed writel
 
 #define ioread8 read
 #define ioread16 readw
-- 
1.9.2

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


[PATCH v2 06/18] frv: io: implement dummy relaxed accessor macros for writes

2014-05-22 Thread Will Deacon
write{b,w,l}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to frv, in the same
vein as the dummy definitions for the relaxed read accessors.

Cc: David Howells 
Signed-off-by: Will Deacon 
---
 arch/frv/include/asm/io.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h
index 8cb50a2fbcb2..99bb7efaf9b7 100644
--- a/arch/frv/include/asm/io.h
+++ b/arch/frv/include/asm/io.h
@@ -243,6 +243,9 @@ static inline void writel(uint32_t datum, volatile void 
__iomem *addr)
__flush_PCI_writes();
 }
 
+#define writeb_relaxed writeb
+#define writew_relaxed writew
+#define writel_relaxed writel
 
 /* Values for nocacheflag and cmode */
 #define IOMAP_FULL_CACHING 0
-- 
1.9.2

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


[PATCH net-next v2 5/9] fs_enet: use the new fixed PHY helpers

2014-05-22 Thread Florian Fainelli
of_phy_connect_fixed_link() is becoming obsolete, and also required
platform code to register the fixed PHYs at the specified addresses for
those to be usable. Get rid of it and use the new of_phy_is_fixed_link()
plus of_phy_register_fixed_link() helpers to transition over the new
scheme.

Signed-off-by: Florian Fainelli 
---
- merge if conditions on the same line as suggested by Sergei
- add comment explaining the device_node pointer assignment

 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c 
b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index dc80db41d6b3..cfaf17b70f3f 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -792,10 +792,6 @@ static int fs_init_phy(struct net_device *dev)
phydev = of_phy_connect(dev, fep->fpi->phy_node, _adjust_link, 0,
iface);
if (!phydev) {
-   phydev = of_phy_connect_fixed_link(dev, _adjust_link,
-  iface);
-   }
-   if (!phydev) {
dev_err(>dev, "Could not attach to PHY\n");
return -ENODEV;
}
@@ -1029,9 +1025,16 @@ static int fs_enet_probe(struct platform_device *ofdev)
fpi->use_napi = 1;
fpi->napi_weight = 17;
fpi->phy_node = of_parse_phandle(ofdev->dev.of_node, "phy-handle", 0);
-   if ((!fpi->phy_node) && (!of_get_property(ofdev->dev.of_node, 
"fixed-link",
- NULL)))
-   goto out_free_fpi;
+   if (!fpi->phy_node && of_phy_is_fixed_link(ofdev->dev.of_node)) {
+   err = of_phy_register_fixed_link(ofdev->dev.of_node);
+   if (err)
+   goto out_free_fpi;
+
+   /* In the case of a fixed PHY, the DT node associated
+* to the PHY is the Ethernet MAC DT node.
+*/
+   fpi->phy_node = ofdev->dev.of_node;
+   }
 
if (of_device_is_compatible(ofdev->dev.of_node, "fsl,mpc5125-fec")) {
phy_connection_type = of_get_property(ofdev->dev.of_node,
-- 
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 v2 17/18] documentation: memory-barriers: clarify relaxed io accessor semantics

2014-05-22 Thread Will Deacon
This patch extends the paragraph describing the relaxed read io accessors
so that the relaxed accessors are defined to be:

 - Ordered with respect to each other if accessing the same peripheral

 - Unordered with respect to normal memory accesses

 - Unordered with respect to LOCK/UNLOCK operations

Whilst many architectures will provide stricter semantics, ARM, Alpha and
PPC can achieve significant performance gains by taking advantage of some
or all of the above relaxations.

Cc: Randy Dunlap 
Cc: Benjamin Herrenschmidt 
Cc: Paul E. McKenney 
Cc: David Howells 
Signed-off-by: Will Deacon 
---
 Documentation/memory-barriers.txt | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/memory-barriers.txt 
b/Documentation/memory-barriers.txt
index 556f951f8626..f31c88691ee9 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -2462,10 +2462,15 @@ functions:
  Please refer to the PCI specification for more information on interactions
  between PCI transactions.
 
- (*) readX_relaxed()
-
- These are similar to readX(), but are not guaranteed to be ordered in any
- way. Be aware that there is no I/O read barrier available.
+ (*) readX_relaxed(), writeX_relaxed()
+
+ These are similar to readX() and writeX(), but provide weaker memory
+ ordering guarantees. Specifically, they do not guarantee ordering with
+ respect to normal memory accesses (e.g. DMA buffers) nor do they guarantee
+ ordering with respect to LOCK or UNLOCK operations. If the latter is
+ required, an mmiowb() barrier can be used. Note that relaxed accesses to
+ the same peripheral are guaranteed to be ordered with respect to each
+ other.
 
  (*) ioreadX(), iowriteX()
 
-- 
1.9.2

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


[PATCH v2 08/18] ia64: io: implement dummy relaxed accessor macros for writes

2014-05-22 Thread Will Deacon
write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to ia64, which may
be able to be optimised in a similar manner to the relaxed read
accessors at a later date.

Cc: Tony Luck 
Signed-off-by: Will Deacon 
---
 arch/ia64/include/asm/io.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h
index 0d2bcb37ec35..379165154c27 100644
--- a/arch/ia64/include/asm/io.h
+++ b/arch/ia64/include/asm/io.h
@@ -393,6 +393,10 @@ __writeq (unsigned long val, volatile void __iomem *addr)
 #define writew(v,a)__writew((v), (a))
 #define writel(v,a)__writel((v), (a))
 #define writeq(v,a)__writeq((v), (a))
+#define writeb_relaxed(v,a)__writeb((v), (a))
+#define writew_relaxed(v,a)__writew((v), (a))
+#define writel_relaxed(v,a)__writel((v), (a))
+#define writeq_relaxed(v,a)__writeq((v), (a))
 #define __raw_writeb   writeb
 #define __raw_writew   writew
 #define __raw_writel   writel
-- 
1.9.2

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


[PATCH net-next v2 4/9] net: systemport: use the new fixed PHY helpers

2014-05-22 Thread Florian Fainelli
of_phy_connect_fixed_link() is becoming obsolete, and also required
platform code to register the fixed PHYs at the specified addresses for
those to be usable. Get rid of it and use the new of_phy_is_fixed_link()
plus of_phy_register_fixed_link() helpers to transition over the new
scheme.

Signed-off-by: Florian Fainelli 
---
No changes in v2

 drivers/net/ethernet/broadcom/bcmsysport.c | 17 +++--
 drivers/net/ethernet/broadcom/bcmsysport.h |  1 +
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c 
b/drivers/net/ethernet/broadcom/bcmsysport.c
index d40c5b969e9e..dc708a888f80 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1327,8 +1327,8 @@ static int bcm_sysport_open(struct net_device *dev)
/* Read CRC forward */
priv->crc_fwd = !!(umac_readl(priv, UMAC_CMD) & CMD_CRC_FWD);
 
-   priv->phydev = of_phy_connect_fixed_link(dev, bcm_sysport_adj_link,
-   priv->phy_interface);
+   priv->phydev = of_phy_connect(dev, priv->phy_dn, bcm_sysport_adj_link,
+   0, priv->phy_interface);
if (!priv->phydev) {
netdev_err(dev, "could not attach to PHY\n");
return -ENODEV;
@@ -1551,6 +1551,19 @@ static int bcm_sysport_probe(struct platform_device 
*pdev)
if (priv->phy_interface < 0)
priv->phy_interface = PHY_INTERFACE_MODE_GMII;
 
+   /* In the case of a fixed PHY, the DT node associated
+* to the PHY is the Ethernet MAC DT node.
+*/
+   if (of_phy_is_fixed_link(dn)) {
+   ret = of_phy_register_fixed_link(dn);
+   if (ret) {
+   dev_err(>dev, "failed to register fixed PHY\n");
+   goto err;
+   }
+
+   priv->phy_dn = dn;
+   }
+
/* Initialize netdevice members */
macaddr = of_get_mac_address(dn);
if (!macaddr || !is_valid_ether_addr(macaddr)) {
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.h 
b/drivers/net/ethernet/broadcom/bcmsysport.h
index abdeb62616df..73fd04a94797 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.h
+++ b/drivers/net/ethernet/broadcom/bcmsysport.h
@@ -656,6 +656,7 @@ struct bcm_sysport_priv {
unsigned intrx_c_index;
 
/* PHY device */
+   struct device_node  *phy_dn;
struct phy_device   *phydev;
phy_interface_t phy_interface;
int old_pause;
-- 
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 v2 04/18] xtensa: io: remove dummy relaxed accessor macros for reads

2014-05-22 Thread Will Deacon
These are now defined by asm-generic/io.h, so we don't need the private
definitions anymore.

Cc: Chris Zankel 
Cc: Max Filippov 
Signed-off-by: Will Deacon 
---
 arch/xtensa/include/asm/io.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/xtensa/include/asm/io.h b/arch/xtensa/include/asm/io.h
index 74944207167e..fe1600a09438 100644
--- a/arch/xtensa/include/asm/io.h
+++ b/arch/xtensa/include/asm/io.h
@@ -74,13 +74,6 @@ static inline void iounmap(volatile void __iomem *addr)
 
 #endif /* CONFIG_MMU */
 
-/*
- * Generic I/O
- */
-#define readb_relaxed readb
-#define readw_relaxed readw
-#define readl_relaxed readl
-
 #endif /* __KERNEL__ */
 
 #include 
-- 
1.9.2

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


[PATCH net-next v2 3/9] net: bcmgenet: use the new fixed PHY helpers

2014-05-22 Thread Florian Fainelli
of_phy_connect_fixed_link() is becoming obsolete, and also required
platform code to register the fixed PHYs at the specified addresses for
those to be usable. Get rid of it and use the new of_phy_is_fixed_link()
plus of_phy_register_fixed_link() helpers to transition over the new
scheme.

Signed-off-by: Florian Fainelli 
---
No changes in v2

 drivers/net/ethernet/broadcom/genet/bcmmii.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c 
b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 4608673beaff..add8d8596084 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -298,6 +298,7 @@ int bcmgenet_mii_config(struct net_device *dev)
 static int bcmgenet_mii_probe(struct net_device *dev)
 {
struct bcmgenet_priv *priv = netdev_priv(dev);
+   struct device_node *dn = priv->pdev->dev.of_node;
struct phy_device *phydev;
unsigned int phy_flags;
int ret;
@@ -307,15 +308,19 @@ static int bcmgenet_mii_probe(struct net_device *dev)
return 0;
}
 
-   if (priv->phy_dn)
-   phydev = of_phy_connect(dev, priv->phy_dn,
-   bcmgenet_mii_setup, 0,
-   priv->phy_interface);
-   else
-   phydev = of_phy_connect_fixed_link(dev,
-   bcmgenet_mii_setup,
-   priv->phy_interface);
+   /* In the case of a fixed PHY, the DT node associated
+* to the PHY is the Ethernet MAC DT node.
+*/
+   if (of_phy_is_fixed_link(dn)) {
+   ret = of_phy_register_fixed_link(dn);
+   if (ret)
+   return ret;
+
+   priv->phy_dn = dn;
+   }
 
+   phydev = of_phy_connect(dev, priv->phy_dn, bcmgenet_mii_setup, 0,
+   priv->phy_interface);
if (!phydev) {
pr_err("could not attach to PHY\n");
return -ENODEV;
-- 
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 v2 11/18] mn10300: io: implement dummy relaxed accessor macros for writes

2014-05-22 Thread Will Deacon
write{b,w,l}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to mn10300, in the
same vein as the dummy definitions for the relaxed read accessors.

Cc: David Howells 
Signed-off-by: Will Deacon 
---
 arch/mn10300/include/asm/io.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/mn10300/include/asm/io.h b/arch/mn10300/include/asm/io.h
index e6ed0d897ccc..897ba3c12b32 100644
--- a/arch/mn10300/include/asm/io.h
+++ b/arch/mn10300/include/asm/io.h
@@ -67,6 +67,10 @@ static inline void writel(u32 b, volatile void __iomem *addr)
 #define __raw_writew writew
 #define __raw_writel writel
 
+#define writeb_relaxed writeb
+#define writew_relaxed writew
+#define writel_relaxed writel
+
 /*/
 /*
  * traditional input/output functions
-- 
1.9.2

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


[PATCH net-next v2 0/9] net: of_phy_connect_fixed_link removal

2014-05-22 Thread Florian Fainelli
Hi all,

This patch set removes of_phy_connect_fixed_link() from the tree now that
we have a better solution for dealing with fixed PHY (emulated PHY) devices
for drivers that require them.

First two patches update the 'fixed-link' Device Tree binding and drivers to
refere to it.

Patches 3 to 7 update the in-tree network drivers that use
of_phy_connect_fixed_link()

Patch 8 removes of_phy_connect_fixed_link

Patch 9 removes the PowerPC code that parsed the 'fixed-link' property.

Patch 9 can be merged via the net-next tree if the PowerPC folks ack it,
but it really has to be merged after the first 8 patches in order to avoid
breakage.

Florian Fainelli (9):
  Documentation: devicetree: add old and deprecated 'fixed-link'
  Documentation: devicetree: net: refer to fixed-link.txt
  net: bcmgenet: use the new fixed PHY helpers
  net: systemport: use the new fixed PHY helpers
  fs_enet: use the new fixed PHY helpers
  gianfar: use the new fixed PHY helpers
  ucc_geth: use the new fixed PHY helpers
  of: mdio: remove of_phy_connect_fixed_link
  powerpc/fsl: fsl_soc: remove 'fixed-link' parsing code

 .../devicetree/bindings/net/broadcom-bcmgenet.txt  |  2 +-
 .../bindings/net/broadcom-systemport.txt   |  2 +-
 .../devicetree/bindings/net/fixed-link.txt | 12 +++
 .../devicetree/bindings/net/fsl-tsec-phy.txt   |  5 +--
 arch/powerpc/sysdev/fsl_soc.c  | 32 --
 drivers/net/ethernet/broadcom/bcmsysport.c | 17 --
 drivers/net/ethernet/broadcom/bcmsysport.h |  1 +
 drivers/net/ethernet/broadcom/genet/bcmmii.c   | 21 +++-
 .../net/ethernet/freescale/fs_enet/fs_enet-main.c  | 17 ++
 drivers/net/ethernet/freescale/gianfar.c   | 14 ++--
 drivers/net/ethernet/freescale/ucc_geth.c  | 14 ++--
 drivers/of/of_mdio.c   | 38 --
 include/linux/of_mdio.h| 10 --
 13 files changed, 76 insertions(+), 109 deletions(-)

-- 
1.9.1

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


[PATCH v2 03/18] s390: io: remove dummy relaxed accessor macros for reads

2014-05-22 Thread Will Deacon
These are now defined by asm-generic/io.h, so we don't need the private
definitions anymore.

Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Signed-off-by: Will Deacon 
---
 arch/s390/include/asm/io.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/s390/include/asm/io.h b/arch/s390/include/asm/io.h
index cd6b9ee7b69c..722befdf8332 100644
--- a/arch/s390/include/asm/io.h
+++ b/arch/s390/include/asm/io.h
@@ -60,11 +60,6 @@ static inline void iounmap(volatile void __iomem *addr)
 #define __raw_writel   zpci_write_u32
 #define __raw_writeq   zpci_write_u64
 
-#define readb_relaxed  readb
-#define readw_relaxed  readw
-#define readl_relaxed  readl
-#define readq_relaxed  readq
-
 #endif /* CONFIG_PCI */
 
 #include 
-- 
1.9.2

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


<    4   5   6   7   8   9   10   11   12   13   >