Re: [RFC][PATCH v2] sched/rt: Use IPI to trigger RT task push migration instead of pulling

2015-02-24 Thread Hillf Danton
> +static void try_to_push_tasks(void *arg)
> +{
> + struct rt_rq *rt_rq = arg;
> + struct rq *rq, *next_rq;
> + int next_cpu = -1;
> + int next_prio = MAX_PRIO + 1;
> + int this_prio;
> + int src_prio;
> + int prio;
> + int this_cpu;
> + int success;
> + int cpu;
> +
> + /* Make sure we can see csd_cpu */
> + smp_rmb();
> +
> + this_cpu = rt_rq->push_csd_cpu;
> +
> + /* Paranoid check */
> + BUG_ON(this_cpu != smp_processor_id());
> +
> + rq = cpu_rq(this_cpu);
> +
> + /*
> +  * If there's nothing to push here, then see if another queue
> +  * can push instead.
> +  */
> + if (!has_pushable_tasks(rq))
> + goto pass_the_ipi;
> +
> + raw_spin_lock(>lock);
> + success = push_rt_task(rq);
> + raw_spin_unlock(>lock);
> +
> + if (success)
> + goto done;

The latency, 150us over a 20 hour run, goes up if we goto done directly?
Hillf
> +
> + /* Nothing was pushed, try another queue */
> +pass_the_ipi:
> +
> + /*
> +  * We use the priority that determined to send to this CPU
> +  * even if the priority for this CPU changed. This is used
> +  * to determine what other CPUs to send to, to keep from
> +  * doing a ping pong from each CPU.
> +  */
> + this_prio = rt_rq->push_csd_prio;
> + src_prio = rt_rq->highest_prio.curr;
> +
> + for_each_cpu(cpu, rq->rd->rto_mask) {
> + if (this_cpu == cpu)
> + continue;
> +
> + /*
> +  * This function was called because some rq lowered its
> +  * priority. It then searched for the highest priority
> +  * rq that had overloaded tasks and sent an smp function
> +  * call to that cpu to call this function to push its
> +  * tasks. But when it got here, the task was either
> +  * already pushed, or due to affinity, could not move
> +  * the overloaded task.
> +  *
> +  * Now we need to see if there's another overloaded rq that
> +  * has an RT task that can migrate to that CPU.
> +  *
> +  * We need to be careful, we do not want to cause a ping
> +  * pong between this CPU and another CPU that has an RT task
> +  * that can migrate, but not to the CPU that lowered its
> +  * priority. Since the lowering priority CPU finds the highest
> +  * priority rq to send to, we will ignore any rq that is of 
> higher
> +  * priority than this current one. That is, if a rq scheduled a
> +  * task of higher priority, the schedule itself would do the
> +  * push or pull then. We can safely ignore higher priority rqs.
> +  * And if there's one that is the same priority, since the CPUS
> +  * are searched in order we will ignore CPUS of the same 
> priority
> +  * unless the CPU number is greater than this CPU's number.
> +  */
> + next_rq = cpu_rq(cpu);
> +
> + /* Use a single read for the next prio for decision making */
> + prio = READ_ONCE(next_rq->rt.highest_prio.next);
> +
> + /* Looking for highest priority */
> + if (prio >= next_prio)
> + continue;
> +
> + /* Make sure that the rq can push to the source rq */
> + if (prio >= src_prio)
> + continue;
> +
> + /* If the prio is higher than the current prio, ignore it */
> + if (prio < this_prio)
> + continue;
> +
> + /*
> +  * If the prio is equal to the current prio, only use it
> +  * if the cpu number is greater than the current cpu.
> +  * This prevents a ping pong effect.
> +  */
> + if (prio == this_prio && cpu < this_cpu)
> + continue;
> +
> + next_prio = prio;
> + next_cpu = cpu;
> + }
> +
> + /* Nothing found, do nothing */
> + if (next_cpu < 0)
> + goto done;
> +
> + /*
> +  * Now we can not send another smp async function due to locking,
> +  * use irq_work instead.
> +  */
> +
> + rt_rq->push_csd_cpu = next_cpu;
> + rt_rq->push_csd_prio = next_prio;
> +
> + /* Make sure the next cpu is seen on remote CPU */
> + smp_mb();
> +
> + irq_work_queue_on(_rq->push_csd_work, next_cpu);
> +
> + return;
> +
> +done:
> + rt_rq->push_csd_pending = 0;
> +
> + /* Now make sure the src CPU can see this update */
> + smp_wmb();
> +}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kasan, module, vmalloc: rework shadow allocation for modules

2015-02-24 Thread Andrey Ryabinin
On 02/25/2015 09:25 AM, Rusty Russell wrote:
> Andrey Ryabinin  writes:
>> On 02/23/2015 11:26 AM, Rusty Russell wrote:
>>> Andrey Ryabinin  writes:
 On 02/20/2015 03:15 AM, Rusty Russell wrote:
> Andrey Ryabinin  writes:
>> On 02/19/2015 02:10 AM, Rusty Russell wrote:
>>> This is not portable.  Other archs don't use vmalloc, or don't use
>>> (or define) MODULES_VADDR.  If you really want to hook here, you'd
>>> need a new flag (or maybe use PAGE_KERNEL_EXEC after an audit).
>>>
>>
>> Well, instead of explicit (addr >= MODULES_VADDR && addr < MODULES_END)
>> I could hide this into arch-specific function: 
>> 'kasan_need_to_allocate_shadow(const void *addr)'
>> or make make all those functions weak and allow arch code to redefine 
>> them.
>
> That adds another layer of indirection.  And how would the caller of
> plain vmalloc() even know what to return?
>

 I think I don't understand what do you mean here. vmalloc() callers 
 shouldn't know
 anything about kasan/shadow.
>>>
>>> How else would kasan_need_to_allocate_shadow(const void *addr) work for
>>> architectures which don't have a reserved vmalloc region for modules?
>>>
>>
>>
>> I think I need to clarify what I'm doing.
>>
>> Address sanitizer algorithm in short:
>> -
>> Every memory access is transformed by the compiler in the following way:
>>
>> Before:
>>  *address = ...;
>>
>> after:
>>
>>  if (memory_is_poisoned(address)) {
>>  report_error(address, access_size);
>>  }
>>  *address = ...;
>>
>> where memory_is_poisoned():
>>  bool memory_is_poisoned(unsigned long addr)
>>  {
>>  s8 shadow_value = *(s8 *)kasan_mem_to_shadow((void *)addr);
>>  if (unlikely(shadow_value)) {
>>  s8 last_accessible_byte = addr & KASAN_SHADOW_MASK;
>>  return unlikely(last_accessible_byte >= shadow_value);
>>  }
>>  return false;
>>  }
>> --
>>
>> So shadow memory should be present for every accessible address in kernel
>> otherwise it will be unhandled page fault on reading shadow value.
>>
>> Shadow for vmalloc addresses (on x86_64) is readonly mapping of one zero 
>> page.
>> Zero byte in shadow means that it's ok to access to that address.
>> Currently we don't catch bugs in vmalloc because most of such bugs could be 
>> caught
>> in more simple way with CONFIG_DEBUG_PAGEALLOC.
>> That's why we don't need RW shadow for vmalloc, it just one zero page that 
>> readonly
>> mapped early on boot for the whole [kasan_mem_to_shadow(VMALLOC_START, 
>> kasan_mem_to_shadow(VMALLOC_END)] range
>> So every access to vmalloc range assumed to be valid.
>>
>> To catch out of bounds accesses in global variables we need to fill shadow 
>> corresponding
>> to variable's redzone with non-zero (negative) values.
>> So for kernel image and modules we need a writable shadow.
>>
>> If some arch don't have separate address range for modules and it uses 
>> general vmalloc()
>> shadow for vmalloc should be writable, so it means that shadow has to be 
>> allocated
>> for every vmalloc() call.
>>
>> In such arch kasan_need_to_allocate_shadow(const void *addr) should return 
>> true for every vmalloc address:
>> bool kasan_need_to_allocate_shadow(const void *addr)
>> {
>>  return addr >= VMALLOC_START && addr < VMALLOC_END;
>> }
> 
> Thanks for the explanation.
> 
>> All above means that current code is not very portable.
>> And 'kasan_module_alloc(p, size) after module alloc' approach is not portable
>> too. This won't work for arches that use [VMALLOC_START, VMALLOC_END] 
>> addresses for modules,
>> because now we need to handle all vmalloc() calls.
> 
> I'm confused.  That's what you do now, and it hasn't been a problem,
> has it?  The problem is on the freeing from interrupt context...
> 

It's not problem now. It's only about portability.


> How about:
> 
> #define VM_KASAN  0x0080  /* has shadow kasan map */
> 
> Set that in kasan_module_alloc():
> 
> if (ret) {
> struct vm_struct *vma = find_vm_area(addr);
> 
> BUG_ON(!vma);
> /* Set VM_KASAN so vfree() can free up shadow. */
> vma->flags |= VM_KASAN;
> }
> 
> And check that in __vunmap():
> 
> if (area->flags & VM_KASAN)
> kasan_module_free(addr);
> 
> That is portable, and is actually a fairly small patch on what you
> have at the moment.
> 
> What am I missing?
> 

That is not portable.
Architectures that don't have separate region for modules should allocate shadow
for every vmalloc() call, not only for modules.
For x86_64 it is enough to call kasan_module_alloc() only in module_alloc().
For some other architectures kasan_module_alloc() ( 
kasan_vmalloc()/kasan_alloc_shadow() would be better name in this case)
should be 

Re: [PATCH v4 1/3] mmc: dw_mmc: update clock after host reach a stable voltage

2015-02-24 Thread Alim Akhtar
Hi Doug,


On Fri, Feb 20, 2015 at 5:19 AM, Doug Anderson  wrote:
> Alim and Addy,
>
> On Sun, Feb 15, 2015 at 3:28 PM, Alim Akhtar  wrote:
>> Hi Addy,
>>
>> On Sat, Feb 14, 2015 at 11:47 AM, Addy Ke  wrote:
>>> As show in mmc_power_up(), in MMC_POWER_UP state, the voltage isn't
>>> stable and we may get 'data busy' which can't be cleaned by resetting
>>> all blocks. So we should not send command to update clock in this state.
>>>
>>> Signed-off-by: Addy Ke 
>>> ---
>>>  drivers/mmc/host/dw_mmc.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 4d2e3c2..3472f9b 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -1102,7 +1102,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
>>> struct mmc_ios *ios)
>>> drv_data->set_ios(slot->host, ios);
>>>
>>> /* Slot specific timing and width adjustment */
>>> -   dw_mci_setup_bus(slot, false);
>>> +   if (ios->power_mode != MMC_POWER_UP)
>>> +   dw_mci_setup_bus(slot, false);
>>>
>> This looks a HACK to me.
>> If stabilizing host voltage regulator is the problem, can you try out
>> below patch, and see if this resolve your issue?
>
> Actually, IMHO Alim's patch is more of a hack than Addy's.  There's
> already a 10ms delay between "power up" and "power on" in the MMC core
> in mmc_power_up() state.  That delay is commented as:
>
Well, my suggestion (adding 5ms in switch_volatge) was based on DW_MMC
databook (V2.41a) section "7.4.1.2 Voltage switch Normal Scenario"
step #7 which says:" After the 5ms timer expires, the host voltage
regulator is stable".

PS: I have limited to no access of my mails and workstation until
March 9th, so replies will be slow.

>   /*
>* This delay should be sufficient to allow the power supply
>* to reach the minimum voltage.
>*/
>   mmc_delay(10);
>
> That means that assuming that the voltage is stable in MMC_POWER_UP is
> not valid anyway.
>
>
> Addy's patch certainly needs more comments.  In another context Olof 
> suggested:
>
> /*
>  * Skip bus setup while voltage is still stabilizing. Instead,
>  * bus setup will be done at MMC_POWER_ON.
>  */
>
>
> ...thinking about this more, though: really the voltage should be
> stabilized when the regulator call returns (see my comments below).
> In actuality the "right" fix might be to just rearrange this function
> a little not to turn the clock on _before_ we even try to turn the
> voltage on.
>
> I've got that coded up but I'm still testing it...  If you want to try
> it too, you can find it at
> .
>
> Note that without my patch I find that I _really_ need Addy's patch to
> make sure that the card isn't busy in setup_bus.  With my patch Addy's
> code catches the card busy less often.  I'm still trying to see if
> there's a way to totally remove the need for his setup_bus and still
> trying to grok all the patches flying around...
>
>
>> ===
>> [PATCH] mmc: dw_mmc: Wait for host voltage regulator to be stable
>>
>> Signed-off-by: Alim Akhtar 
>> ---
>>  drivers/mmc/host/dw_mmc.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 4d2e3c2..dc10fbb 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -1202,6 +1202,9 @@ static int dw_mci_switch_voltage(struct mmc_host
>> *mmc, struct mmc_ios *ios)
>>   }
>>   mci_writel(host, UHS_REG, uhs);
>>
>> + /* wait for 5ms so that host voltage regulator is stable */
>> + usleep_range(5000, 5500);
>> +
>
> Alim: if you have some other instance where you actually need VQMMC to
> stabilize it should probably be done in a different way.  If I
> understand correctly it is the regulator core's job to make sure that
> voltage is stable before returning.  If you have a gpio-regulator you
> may be able to use "startup-delay-us" to specify how long the
> regulator takes to come up.  You could also look at
> 'regulator-enable-ramp-delay'
>
> -Doug



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


Re: [PATCH v3 0/3] epoll: introduce round robin wakeup mode

2015-02-24 Thread Ingo Molnar

* Jason Baron  wrote:

> Hi,
> 
> When we are sharing a wakeup source among multiple epoll 
> fds, we end up with thundering herd wakeups, since there 
> is currently no way to add to the wakeup source 
> exclusively. This series introduces a new EPOLL_ROTATE 
> flag to allow for round robin exclusive wakeups.
> 
> I believe this patch series addresses the two main 
> concerns that were raised in prior postings. Namely, that 
> it affected code (and potentially performance) of the 
> core kernel wakeup functions, even in cases where it was 
> not strictly needed, and that it could lead to wakeup 
> starvation (since we were are no longer waking up all 
> waiters). It does so by adding an extra layer of 
> indirection, whereby waiters are attached to a 'psuedo' 
> epoll fd, which in turn is attached directly to the 
> wakeup source.

>   sched/wait: add __wake_up_rotate()

>  include/linux/wait.h   |  1 +
>  kernel/sched/wait.c| 27 ++

So the scheduler bits are looking good to me in principle, 
because they just add a new round-robin-rotating wakeup 
variant and don't disturb the others.

Is there consensus on the epoll ABI changes? With Davide 
Libenzi inactive eventpoll appears to be without a 
dedicated maintainer since 2011 or so. Is there anyone who 
knows the code and its usages in detail and does final ABI 
decisions on eventpoll - Andrew, Al or Linus?

Thanks,

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


Re: [PATCH 0/2] fix ehrpwm tbclk data on am33xx and am43xx

2015-02-24 Thread Tero Kristo

On 02/24/2015 07:15 PM, Tony Lindgren wrote:

* Vignesh R  [150209 22:43]:

In am33xx and am43xx, ehrpwm tbclk is derived from functional clock of
PWMSS. The schematics and TRMs show that there is only one input clock to
the PWMSS. But currently, tbclk is wrongly shown to be deriving from
dpll_per_m2_ck instead of functional clock l4ls_gclk in the DT.

Fixing ehrpwm tbclk data to reflect the right clk source.
Tested on beaglebone and am437x-gp-evm.

Vignesh R (2):
   ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx
   ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx

  arch/arm/boot/dts/am33xx-clocks.dtsi |  6 +++---
  arch/arm/boot/dts/am43xx-clocks.dtsi | 12 ++--
  2 files changed, 9 insertions(+), 9 deletions(-)


Tero, care to check this one too and ack if OK?


These look fine also, just verified from TRM. These two were actually 
buried in my mailbox, sorry about that.


Acked-by: Tero Kristo 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kernel/module.c: fix typos in message about unused symbols

2015-02-24 Thread Yannick Guerrini

Le 25/02/2015 01:44, Rusty Russell a écrit :

Yannick Guerrini  writes:

Fix typos in pr_warn message about unused symbols

Signed-off-by: Yannick Guerrini 

Thanks.  AFAICT you changed "evalute" to "evaluate", "mainlinglist" to
"mailing list" and added a "to".

Applied,
Rusty.


Exactly, I forgot to specify. Sorry for my mistake.

Best,
Yannick Guerrini
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [E1000-devel] [PATCH] ixgbe: make VLAN filter conditional in SR-IOV case

2015-02-24 Thread Hiroshi Shimamoto
> On Wed, 2015-02-25 at 00:51 +, Hiroshi Shimamoto wrote:
> > > Subject: Re: [E1000-devel] [PATCH] ixgbe: make VLAN filter
> > conditional in SR-IOV case
> > >
> > > On Thu, 2014-11-13 at 08:28 +, Hiroshi Shimamoto wrote:
> > > > From: Hiroshi Shimamoto 
> > > >
> > > > Disable hardware VLAN filtering if netdev->features VLAN flag is
> > > > dropped.
> > > >
> > > > In SR-IOV case, there is a use case which needs to disable VLAN
> > > > filter.
> > > > For example, we need to make a network function with VF in
> > virtualized
> > > > environment. That network function may be a software switch, a
> > router
> > > > or etc. It means that that network function will be an end point
> > which
> > > > terminates many VLANs.
> > > >
> > > > In the current implementation, VLAN filtering always be turned on
> > and
> > > > VF can receive only 63 VLANs. It means that only 63 VLANs can be
> > used
> > > > and it's not enough at all for building a virtual router.
> > > >
> > > > With this patch, if the user turns VLAN filtering off on the host,
> > VF
> > > > can receive every VLAN packet.
> > > > The behavior is changed only if VLAN filtering is turned off by
> > > > ethtool.
> > > >
> > > > Signed-off-by: Hiroshi Shimamoto 
> > > > CC: Choi, Sy Jong 
> > > > ---
> > > >  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 10 ++
> > > >  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c |  4 
> > > >  2 files changed, 14 insertions(+)
> > >
> > > Thanks Hiroshi, I will add your patch to my queue.
> >
> > How about this patch?
> > It hasn't been in your tree,.
> > Is there any issue?
> 
> This patch was dropped for two reasons.  First was Ben Hutchings issues
> with the patch needed to be addressed.  Second, was due to a possible
> security hole which is why VLAN filtering was not disabled in SRIOV
> mode, where isolation is lost between VMs.
> 
> If you want to continue going forward with this change, a warning
> message should be added, at least, warning the user of the possible
> security issues.

okay, I understand.
I will submit a patch which has warning message.

thanks,
Hiroshi



0001-media-vb2-Fill-vb2_buffer-with-bytesused-from-user.patch

2015-02-24 Thread Sudip JAIN
Dear Maintainer,

PFA attached patch that prevents user from being returned garbage bytesused 
value from vb2 framework.

Regards,
Sudip Jain
 From 804e76f89d73d10b9fd7b25a48a6edc31faa40a9 Mon Sep 17 00:00:00 2001
From: Sudip Jain 
Date: Wed, 25 Feb 2015 12:24:53 +0530
Subject: [PATCH] media: vb2: Fill vb2_buffer with bytesused from user

In vb2_qbuf for dmabuf memory type, userside bytesused is not copied in
vb2 buffer. This leads to garbage value being copied from __qbuf_dmabuf()
back to user in __fill_v4l2_buffer().

As a default case, the vb2 framework must return the default value to the user,
if the driver's buffer prepare function prefers not to modify/update.

Change-Id: Ieda389403898935f59c2e2994106f3e5238cfefd
Signed-off-by: Sudip Jain 
---
 drivers/media/v4l2-core/videobuf2-core.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
index 5e47ba4..54fe9c9 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -919,6 +919,8 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b
 	b->m.planes[plane].m.fd;
 v4l2_planes[plane].length =
 	b->m.planes[plane].length;
+v4l2_planes[plane].bytesused =
+	b->m.planes[plane].bytesused;
 v4l2_planes[plane].data_offset =
 	b->m.planes[plane].data_offset;
 			}
@@ -943,6 +945,7 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b
 		if (b->memory == V4L2_MEMORY_DMABUF) {
 			v4l2_planes[0].m.fd = b->m.fd;
 			v4l2_planes[0].length = b->length;
+			v4l2_planes[0].bytesused = b->bytesused;
 			v4l2_planes[0].data_offset = 0;
 		}
 
-- 
1.7.9.5



Re: [PATCH 0/2] ARM: DRA7x/OMAP5: Clock: DPLL Clock fixes

2015-02-24 Thread Tero Kristo

On 02/24/2015 06:27 PM, Tony Lindgren wrote:

* Ravikumar Kattekola  [150219 08:13]:

On 1/31/2015 10:36 PM, Ravikumar Kattekola wrote:

Fix bypass clock source for a few DPLLs.

On DRA7x/OMAP5, for a few DPLLs, both CLKINP and CLKINPULOW are connected
to a mux and the output from mux is routed to the bypass clkout.
Add a mux-clock as bypass clock with CLKINP and CLKINPULOW as parents.

Tested against:
tree: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
branch: master
On:
CPU  : OMAP5432 ES2.0
Board: OMAP5432 uEVM
and
CPU  : DRA752 ES1.0
Board: DRA7xx


Ravikumar Kattekola (2):
   ARM: DRA7x: dts: Fix the bypass clock source for dpll_iva and others
   ARM: OMAP5: dts: Fix the bypass clock source for dpll_iva and others

  arch/arm/boot/dts/dra7xx-clocks.dtsi   |   90 
  arch/arm/boot/dts/omap54xx-clocks.dtsi |   41 +--
  2 files changed, 118 insertions(+), 13 deletions(-)


Hi Benoit,
 Can these fixes be looked into for 3.20-rc?


Seem like valid fixes to me. Tero, care to take a look at these and ack
if OK?


Yes, both are good to go.

Acked-by: Tero Kristo 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/15] twl4030_charger: use runtime_pm to keep usb phy active while charging.

2015-02-24 Thread Lee Jones
On Tue, 24 Feb 2015, NeilBrown wrote:

> The twl4030 usb phy needs to be active while we are using
> the USB VBUS as a current source for charging.
> In particular, the usb3v1 regulator must be enabled and the
> PHY_PWR_PHYPWD bit must be set to keep the phy powered.
> 
> commit ab37813f4093a5f59cb8e083cde277289dc72ed3
> twl4030_charger: Allow charger to control the regulator that feeds it
> 
> Gave the charger control over the regulator, but didn't resolve
> the PHY_PWR_PHYPWD issue.
> 
> Now that both of these are controlled by runtime_pm in
> phy-twl4030-usb, we can simply take a runtime_pm reference to the USB
> phy whenever the charger wants to use it as a current source.
> 
> So this patch reverts the above commit, and adds the necessary
> runtime_pm calls.
> 
> Signed-off-by: NeilBrown 
> ---
>  drivers/mfd/twl-core.c  |9 -

Acked-by: Lee Jones 

>  drivers/power/twl4030_charger.c |   18 +-
>  2 files changed, 9 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index 489674a2497e..831696ee2472 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -788,9 +788,8 @@ add_children(struct twl4030_platform_data *pdata, 
> unsigned irq_base,
>   static struct regulator_consumer_supply usb1v8 = {
>   .supply =   "usb1v8",
>   };
> - static struct regulator_consumer_supply usb3v1[] = {
> - { .supply = "usb3v1" },
> - { .supply = "bci3v1" },
> + static struct regulator_consumer_supply usb3v1 = {
> + .supply =   "usb3v1",
>   };
>  
>   /* First add the regulators so that they can be used by transceiver */
> @@ -818,7 +817,7 @@ add_children(struct twl4030_platform_data *pdata, 
> unsigned irq_base,
>   return PTR_ERR(child);
>  
>   child = add_regulator_linked(TWL4030_REG_VUSB3V1,
> -   _fixed, usb3v1, 2,
> +   _fixed, , 1,
> features);
>   if (IS_ERR(child))
>   return PTR_ERR(child);
> @@ -838,7 +837,7 @@ add_children(struct twl4030_platform_data *pdata, 
> unsigned irq_base,
>   if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) && child) {
>   usb1v5.dev_name = dev_name(child);
>   usb1v8.dev_name = dev_name(child);
> - usb3v1[0].dev_name = dev_name(child);
> + usb3v1.dev_name = dev_name(child);
>   }
>   }
>  
> diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
> index 51321f0c5548..11f352a5ef55 100644
> --- a/drivers/power/twl4030_charger.c
> +++ b/drivers/power/twl4030_charger.c
> @@ -22,7 +22,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #define TWL4030_BCIMSTATEC   0x02
>  #define TWL4030_BCIICHG  0x08
> @@ -94,7 +93,6 @@ struct twl4030_bci {
>   struct work_struct  work;
>   int irq_chg;
>   int irq_bci;
> - struct regulator*usb_reg;
>   int usb_enabled;
>  
>   unsigned long   event;
> @@ -208,7 +206,7 @@ static int twl4030_charger_enable_usb(struct twl4030_bci 
> *bci, bool enable)
>  {
>   int ret;
>  
> - if (enable) {
> + if (enable && !IS_ERR_OR_NULL(bci->transceiver)) {
>   /* Check for USB charger connected */
>   if (!twl4030_bci_have_vbus(bci))
>   return -ENODEV;
> @@ -222,14 +220,9 @@ static int twl4030_charger_enable_usb(struct twl4030_bci 
> *bci, bool enable)
>   return -EACCES;
>   }
>  
> - /* Need to keep regulator on */
> + /* Need to keep phy powered */
>   if (!bci->usb_enabled) {
> - ret = regulator_enable(bci->usb_reg);
> - if (ret) {
> - dev_err(bci->dev,
> - "Failed to enable regulator\n");
> - return ret;
> - }
> + pm_runtime_get_sync(bci->transceiver->dev);
>   bci->usb_enabled = 1;
>   }
>  
> @@ -244,7 +237,8 @@ static int twl4030_charger_enable_usb(struct twl4030_bci 
> *bci, bool enable)
>   } else {
>   ret = twl4030_clear_set_boot_bci(TWL4030_BCIAUTOUSB, 0);
>   if (bci->usb_enabled) {
> - regulator_disable(bci->usb_reg);
> + pm_runtime_mark_last_busy(bci->transceiver->dev);
> + pm_runtime_put_autosuspend(bci->transceiver->dev);
>   bci->usb_enabled = 0;
>   }
>   

Re: [PATCH 1/3] x86_64, entry: Remove a bogus ret_from_fork optimization

2015-02-24 Thread Ingo Molnar

* Andy Lutomirski  wrote:

> ret_from_fork checks TIF_IA32 to determine whether pt_regs and the
> related state make sense for ret_from_sys_call.  This is entirely
> the wrong check.  TS_COMPAT would make a little more sense, but
> there's really no point in keeping this optimization at all.
> 
> This fixes a return to the wrong user CS if we came from int 0x80 in
> a 64-bit task.
> 
> Signed-off-by: Andy Lutomirski 

Acked-by: Ingo Molnar 

Thanks,

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


Re: [PATCH v8 7/7] x86, mm: Add set_memory_wt() for WT

2015-02-24 Thread Ingo Molnar

* Toshi Kani  wrote:

> +int set_pages_array_wt(struct page **pages, int addrinarray)
> +{
> + return _set_pages_array(pages, addrinarray, _PAGE_CACHE_MODE_WT);
> +}
> +EXPORT_SYMBOL(set_pages_array_wt);

So by default we make new APIs EXPORT_SYMBOL_GPL(): we 
don't want proprietary modules mucking around with new code 
PAT interfaces, we only want modules we can analyze and fix 
in detail.

Thanks,

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


Re: [PATCH 1/3 v5] kernel/fork.c: new function for max_threads

2015-02-24 Thread Heinrich Schuchardt
On 24.02.2015 23:16, David Rientjes wrote:
> On Tue, 24 Feb 2015, Heinrich Schuchardt wrote:
> 
>>> I'm afraid I don't understand this.  The intent of the patch is to 
>>> separate the max_threads logic into a new function, correct?  If that's 
>>> true, then I don't understand why UINT_MAX is being introduced into this 
>>> path and passed to the new function when it is ignored.
>>>
>>> I think it would be better to simply keep passing mempages to fork_init() 
>>> and then pass it to set_max_threads() where max_threads actually gets set 
>>> using the argument passed.  At least, the code would then match the intent 
>>> of the patch.
>>>
>> Please, read patch 2/3 which provides support for the argument,
>> and patch 3/3 that finally needs it.
>>
> 
> The problem is with the structure of your patchset.  You want three 
> patches.  There's one bugfix patch, a preparation patch, and a feature 
> patch.  The bugfix patch should come first so that it can be applied, 
> possibly, to stable kernels and doesn't depend on unnecessary preparation 
> patches for features.
> 
> 1/3: change the implementation of fork_init(), with commentary, to avoid 
> the divide by zero on certain arches, enforce the limits, and deal with 
> variable types to prevent overflow.  This is the most urgent patch and 
> fixes a bug.
> 
> 2/3: simply extract the fixed fork_init() implementation into a new 
> set_max_threads() in preparation to use it for threads-max, (hint: 
> UINT_MAX and ignored arguments should not appear in this patch),
> 
> 3/3: use the new set_max_threads() implementation for threads-max with an 
> update to the documentation.
> 
Hello Ingo,

the current structure of the patch set is based on your suggestion in
https://lkml.org/lkml/2015/2/22/22

Would you agree with the sequence of patches proposed by David?

Best regards

Heinrich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RESEND PATCH v2 7/9] mfd: rtsx: add support for rts524A

2015-02-24 Thread Lee Jones
On Wed, 25 Feb 2015, 敬锐 wrote:

> 
> On 02/16/2015 10:28 PM, Lee Jones wrote:
> >
> > +static int rts524a_optimize_phy(struct rtsx_pcr *pcr)
> > +{
> > +   int err;
> > +
> > +   err = rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3,
> > +   D3_DELINK_MODE_EN, 0x00);
> > +   if (err < 0)
> > +   return err;
> > +
> > +   rtsx_pci_write_phy_register(pcr, PHY_PCR,
> > +   PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 |
> > +   PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 | PHY_PCR_RSSI_EN);
> > +   rtsx_pci_write_phy_register(pcr, PHY_SSCCR3,
> > +   PHY_SSCCR3_STEP_IN | PHY_SSCCR3_CHECK_DELAY);
> > +
> > +   if (is_version(pcr, 0x524A, IC_VER_A)) {
> > +   rtsx_pci_write_phy_register(pcr, PHY_SSCCR3,
> > +   PHY_SSCCR3_STEP_IN | PHY_SSCCR3_CHECK_DELAY);
> > +   rtsx_pci_write_phy_register(pcr, PHY_SSCCR2,
> > +   PHY_SSCCR2_PLL_NCODE | PHY_SSCCR2_TIME0 |
> > +   PHY_SSCCR2_TIME2_WIDTH);
> > +   rtsx_pci_write_phy_register(pcr, PHY_ANA1A,
> > +   PHY_ANA1A_TXR_LOOPBACK | PHY_ANA1A_RXT_BIST |
> > +   PHY_ANA1A_TXR_BIST | PHY_ANA1A_REV);
> > +   rtsx_pci_write_phy_register(pcr, PHY_ANA1D,
> > +   PHY_ANA1D_DEBUG_ADDR);
> > +   rtsx_pci_write_phy_register(pcr, PHY_DIG1E,
> > +   PHY_DIG1E_REV | PHY_DIG1E_D0_X_D1 |
> > +   PHY_DIG1E_RX_ON_HOST | PHY_DIG1E_RCLK_REF_HOST |
> > +   PHY_DIG1E_RCLK_TX_EN_KEEP |
> > +   PHY_DIG1E_RCLK_TX_TERM_KEEP |
> > +   PHY_DIG1E_RCLK_RX_EIDLE_ON | PHY_DIG1E_TX_TERM_KEEP |
> > +   PHY_DIG1E_RX_TERM_KEEP | PHY_DIG1E_TX_EN_KEEP |
> > +   PHY_DIG1E_RX_EN_KEEP);
> > +   }
> > +
> > +   rtsx_pci_write_phy_register(pcr, PHY_ANA08,
> > +   PHY_ANA08_RX_EQ_DCGAIN | PHY_ANA08_SEL_RX_EN |
> > +   PHY_ANA08_RX_EQ_VAL | PHY_ANA08_SCP | PHY_ANA08_SEL_IPI);
> > To the uninitiated this function is mostly randomness.  How about some
> > nice comments to illuminate?
> I'm not clear with these setting either, it is used to fix some phy 
> setting, the default phy setting
> it not stable on some special platform, so we have to modify them by driver,
> newer version of chip will change its default value to more stable 
> configure, so some value is
> no need to setting for Version B/C...

That doesn't help me in any way.  Use the datasheet, look-up the
values and insert a nice, succinct explanation of what you're doing
and why it's required please.

-- 
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: [E1000-devel] [PATCH] ixgbe: make VLAN filter conditional in SR-IOV case

2015-02-24 Thread Jeff Kirsher
On Wed, 2015-02-25 at 00:51 +, Hiroshi Shimamoto wrote:
> > Subject: Re: [E1000-devel] [PATCH] ixgbe: make VLAN filter
> conditional in SR-IOV case
> > 
> > On Thu, 2014-11-13 at 08:28 +, Hiroshi Shimamoto wrote:
> > > From: Hiroshi Shimamoto 
> > >
> > > Disable hardware VLAN filtering if netdev->features VLAN flag is
> > > dropped.
> > >
> > > In SR-IOV case, there is a use case which needs to disable VLAN
> > > filter.
> > > For example, we need to make a network function with VF in
> virtualized
> > > environment. That network function may be a software switch, a
> router
> > > or etc. It means that that network function will be an end point
> which
> > > terminates many VLANs.
> > >
> > > In the current implementation, VLAN filtering always be turned on
> and
> > > VF can receive only 63 VLANs. It means that only 63 VLANs can be
> used
> > > and it's not enough at all for building a virtual router.
> > >
> > > With this patch, if the user turns VLAN filtering off on the host,
> VF
> > > can receive every VLAN packet.
> > > The behavior is changed only if VLAN filtering is turned off by
> > > ethtool.
> > >
> > > Signed-off-by: Hiroshi Shimamoto 
> > > CC: Choi, Sy Jong 
> > > ---
> > >  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 10 ++
> > >  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c |  4 
> > >  2 files changed, 14 insertions(+)
> > 
> > Thanks Hiroshi, I will add your patch to my queue.
> 
> How about this patch?
> It hasn't been in your tree,.
> Is there any issue?

This patch was dropped for two reasons.  First was Ben Hutchings issues
with the patch needed to be addressed.  Second, was due to a possible
security hole which is why VLAN filtering was not disabled in SRIOV
mode, where isolation is lost between VMs.

If you want to continue going forward with this change, a warning
message should be added, at least, warning the user of the possible
security issues.


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


Re: [PATCH v6 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save

2015-02-24 Thread Lee Jones
On Wed, 07 Jan 2015, Vignesh R wrote:

> In one shot mode, sequencer automatically disables all enabled steps at
> the end of each cycle. (both ADC steps and TSC steps) Hence these steps
> need not be saved in reg_se_cache for clearing these steps at a later
> stage.
> Also, when ADC wakes up Sequencer should not be busy executing any of the
> config steps except for the charge step. Previously charge step was 1 ADC
> clock cycle and hence it was ignored.
> TSC steps are always disabled at the end of each conversion cycle, hence
> there is no need to explicitly disable TSC steps by writing 0 to REG_SE.
> 
> Signed-off-by: Vignesh R 
> ---
> 
> v5:
>  - Remove unnecessary clearing of REG_SE
> 
>  drivers/mfd/ti_am335x_tscadc.c   | 13 +
>  include/linux/mfd/ti_am335x_tscadc.h |  1 +
>  2 files changed, 6 insertions(+), 8 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
> index 467c80e1c4ae..e4e4b22eebc9 100644
> --- a/drivers/mfd/ti_am335x_tscadc.c
> +++ b/drivers/mfd/ti_am335x_tscadc.c
> @@ -68,12 +68,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
> *tsadc)
>   DEFINE_WAIT(wait);
>   u32 reg;
>  
> - /*
> -  * disable TSC steps so it does not run while the ADC is using it. If
> -  * write 0 while it is running (it just started or was already running)
> -  * then it completes all steps that were enabled and stops then.
> -  */
> - tscadc_writel(tsadc, REG_SE, 0);
>   reg = tscadc_readl(tsadc, REG_ADCFSM);
>   if (reg & SEQ_STATUS) {
>   tsadc->adc_waiting = true;
> @@ -86,8 +80,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
> *tsadc)
>   spin_lock_irq(>reg_lock);
>   finish_wait(>reg_se_wait, );
>  
> + /*
> +  * Sequencer should either be idle or
> +  * busy applying the charge step.
> +  */
>   reg = tscadc_readl(tsadc, REG_ADCFSM);
> - WARN_ON(reg & SEQ_STATUS);
> + WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP));
>   tsadc->adc_waiting = false;
>   }
>   tsadc->adc_in_use = true;
> @@ -96,7 +94,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
> *tsadc)
>  void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
>  {
>   spin_lock_irq(>reg_lock);
> - tsadc->reg_se_cache |= val;
>   am335x_tscadc_need_adc(tsadc);
>  
>   tscadc_writel(tsadc, REG_SE, val);
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h 
> b/include/linux/mfd/ti_am335x_tscadc.h
> index 3f4e994ace2b..1fd50dcfe47c 100644
> --- a/include/linux/mfd/ti_am335x_tscadc.h
> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> @@ -128,6 +128,7 @@
>  
>  /* Sequencer Status */
>  #define SEQ_STATUS BIT(5)
> +#define CHARGE_STEP  0x11
>  
>  #define ADC_CLK  300
>  #define TOTAL_STEPS  16

-- 
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 RFC 1/4] mm: throttle MADV_FREE

2015-02-24 Thread Minchan Kim
On Wed, Feb 25, 2015 at 09:08:09AM +0900, Minchan Kim wrote:
> Hi Michal,
> 
> On Tue, Feb 24, 2015 at 04:43:18PM +0100, Michal Hocko wrote:
> > On Tue 24-02-15 17:18:14, Minchan Kim wrote:
> > > Recently, Shaohua reported that MADV_FREE is much slower than
> > > MADV_DONTNEED in his MADV_FREE bomb test. The reason is many of
> > > applications went to stall with direct reclaim since kswapd's
> > > reclaim speed isn't fast than applications's allocation speed
> > > so that it causes lots of stall and lock contention.
> > 
> > I am not sure I understand this correctly. So the issue is that there is
> > huge number of MADV_FREE on the LRU and they are not close to the tail
> > of the list so the reclaim has to do a lot of work before it starts
> > dropping them?
> 
> No, Shaohua already tested deactivating of hinted pages to head/tail
> of inactive anon LRU and he said it didn't solve his problem.
> I thought main culprit was scanning/rotating/throttling in
> direct reclaim path.

I investigated my workload and found most of slowness came from swapin.

1) dontneed: 1,612 swapin
2) madvfree: 879,585 swapin

If we find hinted pages were already swapped out when syscall is called,
it's pointless to keep the pages in pte. Instead, free the cold page
because swapin is more expensive than (alloc page + zeroing).

I tested below quick fix and reduced swapin from 879,585 to 1,878.
Elapsed time was

1) dontneed: 6.10user 233.50system 0:50.44elapsed
2) madvfree + below patch: 6.70user 339.14system 1:04.45elapsed

Although it was not good as throttling, it's better than old and
it's orthogoral with throttling so I hope to merge this first
than arguable throttling. Any comments?

diff --git a/mm/madvise.c b/mm/madvise.c
index 6d0fcb8921c2..d41ae76d3e54 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -274,7 +274,9 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long 
addr,
spinlock_t *ptl;
pte_t *pte, ptent;
struct page *page;
+   swp_entry_t entry;
unsigned long next;
+   int rss = 0;
 
next = pmd_addr_end(addr, end);
if (pmd_trans_huge(*pmd)) {
@@ -293,9 +295,19 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
long addr,
for (; addr != end; pte++, addr += PAGE_SIZE) {
ptent = *pte;
 
-   if (!pte_present(ptent))
+   if (pte_none(ptent))
continue;
 
+   if (!pte_present(ptent)) {
+   entry = pte_to_swp_entry(ptent);
+   if (non_swap_entry(entry))
+   continue;
+   rss--;
+   free_swap_and_cache(entry);
+   pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
+   continue;
+   }
+
page = vm_normal_page(vma, addr, ptent);
if (!page)
continue;
@@ -326,6 +338,14 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
long addr,
set_pte_at(mm, addr, pte, ptent);
tlb_remove_tlb_entry(tlb, pte, addr);
}
+
+   if (rss) {
+   if (current->mm == mm)
+   sync_mm_rss(mm);
+
+   add_mm_counter(mm, MM_SWAPENTS, rss);
+   }
+
arch_leave_lazy_mmu_mode();
pte_unmap_unlock(pte - 1, ptl);
 next:
-- 
1.9.1


> 
> > 
> > > This patch throttles MADV_FREEing so it works only if there
> > > are enough pages in the system which will not trigger backgroud/
> > > direct reclaim. Otherwise, MADV_FREE falls back to MADV_DONTNEED
> > > because there is no point to delay freeing if we know system
> > > is under memory pressure.
> > 
> > Hmm, this is still conforming to the documentation because the kernel is
> > free to free pages at its convenience. I am not sure this is a good
> > idea, though. Why some MADV_FREE calls should be treated differently?
> 
> It's hint for VM to free pages so I think it's okay to free them instantly
> sometime if it can save more important thing like system stall.
> IOW, madvise is just hint, not a strict rule.
> 
> > Wouldn't that lead to hard to predict behavior? E.g. LIFO reused blocks
> > would work without long stalls most of the time - except when there is a
> > memory pressure.
> 
> True.
> 
> > 
> > Comparison to MADV_DONTNEED is not very fair IMHO because the scope of the
> > two calls is different.
> 
> I agree it's not a apple to apple comparison.
> 
> Acutally, MADV_FREE moves the cost from hot path(ie, system call path)
> to slow path(ie, reclaim context) so it would be slower if there are
> much memory pressure continuously due to a lot overhead of freeing pages
> in reclaim context. So, it would be good if kernel detects it nicely
> and prevent the situation. This patch aims for that.
> 
> > 
> > > When I test the patch on my 3G machine + 12 CPU + 8G swap,
> > > test: 12 processes
> > > 
> > > loop = 5;
> > > mmap(512M);
> 

Re: regression in 4.0.0-rc1 with r8169 ethernet

2015-02-24 Thread Bjorn Helgaas
[+cc Jiang, Thomas, Lv, Rafael, linux-pci, linux-acpi]

On Tue, Feb 24, 2015 at 9:47 PM, Dave Airlie  wrote:
> Hey,
>
> just booted an old AMD rs780 box with new kernel and my ethernet
> failed to come up!
>
> Looks like the MAC addr is all ff's because the PCI bridge windows are
> messed up.
>
> I've attached two dmesg one from a 3.19.0-rc6 I had on it, and one
> failing from the 4.0.0-rc1 time.
>
> b24e2bdde4af656bb0679a101265ebb8f8735d3c is latest Linus commit in
> that tree (I have some radeon patches on top).
>
> motherboard is a Gigabyte GA-MA78GM-S2H, lspci also attached.

Here's the dmesg diff that looks relevant to me:

-pci_bus :00: root bus resource [io  0x-0x0cf7]
-pci_bus :00: root bus resource [io  0x0d00-0x]
-pci_bus :00: root bus resource [mem 0x000a-0x000b]
-pci_bus :00: root bus resource [mem 0x000c-0x000d]
-pci_bus :00: root bus resource [mem 0xfed4-0xfed44fff]
-pci_bus :00: root bus resource [mem 0x7ff0-0xfebf]
+pci_bus :00: root bus resource [io  0x0cf8-0x0cff]
+pci_bus :00: root bus resource [io  0x-0x0cf7 window]
+pci_bus :00: root bus resource [io  0x0d00-0x window]
+pci_bus :00: root bus resource [mem 0x000a-0x000b window]
+pci_bus :00: root bus resource [mem 0x000c-0x000d window]
+pci_bus :00: root bus resource [mem 0xfed4-0xfed44fff window]

What's interesting is:

* v3.19 ignored [io  0x0cf8-0x0cff], but v4.0 includes it.  I think
it's wrong to include it because that's the configuration space
address/data registers, so it's consumed by the host bridge and not
produced on the downstream side.

* v3.19 includes [mem 0x7ff0-0xfebf], but v4.0 does not.  This
is what's screwing up the devices.

I think all the windows should be marked as ACPI_PRODUCER in _CRS
since the space is "produced" on the downstream side of the bridge.
The [io  0x0cf8-0x0cff] region should probably be marked
ACPI_CONSUMER, and maybe that accounts for why v3.19 ignores it.  But
I haven't found the code that does that yet.

I suspect this is all related to the ACPI resource parsing rework.  I
looked through that briefly, but no issues jumped out at me, so this
is just a heads-up in case it is obvious to you guys.

Dave, it'd be useful if you could collect an acpidump so we can look
at the _CRS data in more detail.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] OMAPDSS: restore "name" sysfs entry.

2015-02-24 Thread Tomi Valkeinen
On 24/02/15 22:31, NeilBrown wrote:
> On Tue, 24 Feb 2015 12:40:32 +0200 Tomi Valkeinen 
> wrote:
> 
>> Hi,
>>
>> On 24/02/15 11:37, NeilBrown wrote:
>>>
>>>
>>> commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b
>>> OMAPDSS: rename display-sysfs 'name' entry
>>>
>>> broke the xorg X server on my device as it couldn't find the display
>>> any more.  It needs the 'name' file and now there isn't one.
>>>
>>> That commit claims that 'name' is not compatible with i2c or spi.
>>> i2c does register it own 'name' file, but spi does not, hence my
>>> problem - I have an spi display.
>>>
>>> So create a special case for i2c: add the name attribute for non-i2c
>>> devices.
>>
>> What X driver is that? What's it doing with the display name? Is it just
>> using the display name to show something for the user, and the returned
>> value can be essentially any string?
>>
>>  Tomi
>>
>>
> /usr/lib/xorg/modules/drivers/omapfb_drv.so
> from package xserver-xorg-video-omap3 in Debian.
> 
> I don't know where the main upstream source is, but here:
> 
> https://gitorious.org/gnutoo-s-programs-for-shr/xf86-video-omapfb/source/28c006c94e57ea71df11ec4fff79d7ffcfc4860f:src/omapfb-output-dss.c#L258
> 
> is the code which reads
>/sys/devices/platform/omapdss/display0/name
> and fails if that file cannot be opened.

Thanks. Unfortunately it looks to me that the omapfb_drv uses the
display name to configure things, and as in i2c's case the 'name' is not
the correct dss name, X will probably fail in interesting ways.

Of course, it's already broken in that way, so this fix improves the
situation for non-i2c displays. I'll have a look if I can figure out how
to fix this for all displays.

 Tomi




signature.asc
Description: OpenPGP digital signature


[ANNOUNCE] Git v2.3.1

2015-02-24 Thread Junio C Hamano
The latest maintenance release Git v2.3.1 is now available at
the usual places.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.3.1'
tag and the 'maint' branch that the tag points at:

  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Git v2.3.1 Release Notes


Fixes since v2.3


 * The interactive "show a list and let the user choose from it"
   interface "add -i" used showed and prompted to the user even when
   the candidate list was empty, against which the only "choice" the
   user could have made was to choose nothing.

 * "git apply --whitespace=fix" used to under-allocate the memory
   when the fix resulted in a longer text than the original patch.

 * "git log --help" used to show rev-list options that are irrelevant
   to the "log" command.

 * The error message from "git commit", when a non-existing author
   name was given as value to the "--author=" parameter, has been
   reworded to avoid misunderstanding.

 * A broken pack .idx file in the receiving repository prevented the
   dumb http transport from fetching a good copy of it from the other
   side.

 * The documentation incorrectly said that C(opy) and R(ename) are the
   only ones that can be followed by the score number in the output in
   the --raw format.

 * Fix a misspelled conditional that is always true.

 * Code to read branch name from various files in .git/ directory
   would have misbehaved if the code to write them left an empty file.

 * The "git push" documentation made the "--repo=" option
   easily misunderstood.

 * After attempting and failing a password-less authentication
   (e.g. kerberos), libcURL refuses to fall back to password based
   Basic authentication without a bit of help/encouragement.

 * Setting diff.submodule to 'log' made "git format-patch" produce
   broken patches.

 * "git rerere" (invoked internally from many mergy operations) did
   not correctly signal errors when told to update the working tree
   files and failed to do so for whatever reason.

 * "git blame HEAD -- missing" failed to correctly say "HEAD" when it
   tried to say "No such path 'missing' in HEAD".

Also contains typofixes, documentation updates and trivial code clean-ups.



Changes since v2.3.0 are as follows:

Alexander Kuleshov (1):
  add -i: return from list_and_choose if there is no candidate

Doug Kelly (2):
  t4255: test am submodule with diff.submodule
  format-patch: ignore diff.submodule setting

Jeff King (7):
  git-compat-util: add xstrdup_or_null helper
  builtin/apply.c: use xstrdup_or_null instead of null_strdup
  builtin/commit.c: use xstrdup_or_null instead of envdup
  use xstrdup_or_null to replace ternary conditionals
  dumb-http: do not pass NULL path to parse_pack_index
  read_and_strip_branch: fix typo'd address-of operator
  do not check truth value of flex arrays

Jonathan Nieder (1):
  rerere: error out on autoupdate failure

Junio C Hamano (6):
  apply.c: typofix
  apply: make update_pre_post_images() sanity check the given postlen
  apply: count the size of postimage correctly
  Documentation: what does "git log --indexed-objects" even mean?
  diff-format doc: a score can follow M for rewrite
  Git 2.3.1

Lukas Fleischer (1):
  blame.c: fix garbled error message

Michael J Gruber (2):
  commit: reword --author error message
  git-push.txt: document the behavior of --repo

brian m. carlson (1):
  remote-curl: fall back to Basic auth if Negotiate fails

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: dsa: Introduce dsa_is_port_initialized

2015-02-24 Thread Guenter Roeck
To avoid race conditions when using the ds->ports[] array,
we need to check if the accessed port has been initialized.
Introduce and use helper function dsa_is_port_initialized
for that purpose and use it where needed.

Signed-off-by: Guenter Roeck 
---
Applies to net-next on top of Florian's patches adding HW bridging support
to dsa.

 include/net/dsa.h | 5 +
 net/dsa/dsa.c | 4 ++--
 net/dsa/slave.c   | 5 +
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 92be3479..c542c13 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -165,6 +165,11 @@ static inline bool dsa_is_cpu_port(struct dsa_switch *ds, 
int p)
return !!(ds->index == ds->dst->cpu_switch && p == ds->dst->cpu_port);
 }
 
+static inline bool dsa_is_port_initialized(struct dsa_switch *ds, int p)
+{
+   return ds->phys_port_mask & (1 << p) && ds->ports[p];
+}
+
 static inline u8 dsa_upstream_port(struct dsa_switch *ds)
 {
struct dsa_switch_tree *dst = ds->dst;
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 9c208f0..a1d1f07 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -374,7 +374,7 @@ static int dsa_switch_suspend(struct dsa_switch *ds)
 
/* Suspend slave network devices */
for (i = 0; i < DSA_MAX_PORTS; i++) {
-   if (!(ds->phys_port_mask & (1 << i)))
+   if (!dsa_is_port_initialized(ds, i))
continue;
 
ret = dsa_slave_suspend(ds->ports[i]);
@@ -400,7 +400,7 @@ static int dsa_switch_resume(struct dsa_switch *ds)
 
/* Resume slave network devices */
for (i = 0; i < DSA_MAX_PORTS; i++) {
-   if (!(ds->phys_port_mask & (1 << i)))
+   if (!dsa_is_port_initialized(ds, i))
continue;
 
ret = dsa_slave_resume(ds->ports[i]);
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index b5a4d89..a47305c 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -222,10 +222,7 @@ static u32 dsa_slave_br_port_mask(struct dsa_switch *ds,
u32 mask = 0;
 
for (port = 0; port < DSA_MAX_PORTS; port++) {
-   if (!((1 << port) & ds->phys_port_mask))
-   continue;
-
-   if (!ds->ports[port])
+   if (!dsa_is_port_initialized(ds, port))
continue;
 
p = netdev_priv(ds->ports[port]);
-- 
2.1.0

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


Re: [PATCH] perf tools: Fix pthread_attr_setaffinity_np build error

2015-02-24 Thread Adrian Hunter

On 24/02/2015 4:31 p.m., Josh Boyer wrote:

On Tue, Feb 24, 2015 at 8:52 AM, Adrian Hunter  wrote:

On 24/02/15 15:32, Josh Boyer wrote:

On Tue, Feb 24, 2015 at 5:46 AM, Adrian Hunter  wrote:

Feature detection for pthread_attr_setaffinity_np was failing,
producing this error:

In file included from bench/futex-hash.c:17:0:
bench/futex.h:73:19: error: conflicting types for 'pthread_attr_setaffinity_np'
  static inline int pthread_attr_setaffinity_np(pthread_attr_t *attr,
^
In file included from bench/futex.h:72:0,
  from bench/futex-hash.c:17:
/usr/include/pthread.h:407:12: note: previous declaration of 
'pthread_attr_setaffinity_np' was here
  extern int pthread_attr_setaffinity_np (pthread_attr_t *__attr,
 ^
make[3]: *** [bench/futex-hash.o] Error 1
make[2]: *** [bench] Error 2
make[2]: *** Waiting for unfinished jobs

This was because compiling test-pthread-attr-setaffinity-np.c
failed due to the function arguments:

test-pthread-attr-setaffinity-np.c: In function 'main':
test-pthread-attr-setaffinity-np.c:11:2: warning: null argument where non-null 
required (argument 3) [-Wnonnull]
   ret = pthread_attr_setaffinity_np(_attr, 0, NULL);
   ^
So fix the arguments.


Erm, I sent a different fix for this a while ago.  It's queued in some
-tip tree.  The feature test wasn't defining _GNU_SOURCE, which is
required for pthread_attr_setaffinity_np.  Once that was set (passed
via -D in the Makefile), the feature test worked fine.

Did you have to use your patch on top of the fix already queued?


Yes.

The error (warning + Werror) I got definitely seemed to be about the use of
NULL as an argument.


Hm, ok.  Which compiler/glibc are you using?  Curious that I'm not
seeing that issue.


4.8.2

You could also see if you have the __nonnull attribute in the header e.g.

extern int pthread_attr_setaffinity_np (pthread_attr_t *__attr,
size_t __cpusetsize,
const cpu_set_t *__cpuset)
 __THROW __nonnull ((1, 3));

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


[Patch V6 01/10] MAINTAINERS: Add QCOM audio ASoC maintainer

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

Add maintainers for the Qualcomm Technologies
sound drivers.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 
ddc5a8cf9a8ac0078f8ca1bc99d9c48f8197214a..9514b794b74d7fb93072bbdbaefaaa79df38c5fd
 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5254,6 +5254,13 @@ F:   drivers/char/ipmi/
 F: include/linux/ipmi*
 F: include/uapi/linux/ipmi*
 
+QCOM AUDIO (ASoC) DRIVERS
+M: Patrick Lai 
+M: Banajit Goswami 
+L: alsa-de...@alsa-project.org (moderated for non-subscribers)
+S: Supported
+F: sound/soc/qcom/
+
 IPS SCSI RAID DRIVER
 M: Adaptec OEM Raid Solutions 
 L: linux-s...@vger.kernel.org
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[Patch V6 04/10] ASoC: qcom: add LPASS header files

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

Add the LPASS header files for ipq806x SOC.  This
includes the register definitions for the ipq806x
LPAIF, and the structure definition for the driver
data.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/qcom/lpass-lpaif-ipq806x.h | 172 +++
 sound/soc/qcom/lpass.h   |  51 +++
 2 files changed, 223 insertions(+)
 create mode 100644 sound/soc/qcom/lpass-lpaif-ipq806x.h
 create mode 100644 sound/soc/qcom/lpass.h

diff --git a/sound/soc/qcom/lpass-lpaif-ipq806x.h 
b/sound/soc/qcom/lpass-lpaif-ipq806x.h
new file mode 100644
index 
..dc423b425e60ebb11cd0ce78da2574ed27c2
--- /dev/null
+++ b/sound/soc/qcom/lpass-lpaif-ipq806x.h
@@ -0,0 +1,172 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ *
+ * lpass-lpaif-ipq806x.h -- Definitions for the QTi LPAIF in the ipq806x LPASS
+ */
+
+#ifndef __LPASS_LPAIF_H__
+#define __LPASS_LPAIF_H__
+
+#define LPAIF_BANK_OFFSET  0x1000
+
+/* LPAIF I2S */
+
+#define LPAIF_I2SCTL_REG_BASE  0x0010
+#define LPAIF_I2SCTL_REG_STRIDE0x4
+#define LPAIF_I2SCTL_REG_ADDR(addr, port) \
+   (LPAIF_I2SCTL_REG_BASE + (addr) + (LPAIF_I2SCTL_REG_STRIDE * (port)))
+
+enum lpaif_i2s_ports {
+   LPAIF_I2S_PORT_MIN  = 0,
+
+   LPAIF_I2S_PORT_CODEC_SPK= 0,
+   LPAIF_I2S_PORT_CODEC_MIC= 1,
+   LPAIF_I2S_PORT_SEC_SPK  = 2,
+   LPAIF_I2S_PORT_SEC_MIC  = 3,
+   LPAIF_I2S_PORT_MI2S = 4,
+
+   LPAIF_I2S_PORT_MAX  = 4,
+   LPAIF_I2S_PORT_NUM  = 5,
+};
+
+#define LPAIF_I2SCTL_REG(port) LPAIF_I2SCTL_REG_ADDR(0x0, (port))
+
+#define LPAIF_I2SCTL_LOOPBACK_MASK 0x8000
+#define LPAIF_I2SCTL_LOOPBACK_SHIFT15
+#define LPAIF_I2SCTL_LOOPBACK_DISABLE  (0 << LPAIF_I2SCTL_LOOPBACK_SHIFT)
+#define LPAIF_I2SCTL_LOOPBACK_ENABLE   (1 << LPAIF_I2SCTL_LOOPBACK_SHIFT)
+
+#define LPAIF_I2SCTL_SPKEN_MASK0x4000
+#define LPAIF_I2SCTL_SPKEN_SHIFT   14
+#define LPAIF_I2SCTL_SPKEN_DISABLE (0 << LPAIF_I2SCTL_SPKEN_SHIFT)
+#define LPAIF_I2SCTL_SPKEN_ENABLE  (1 << LPAIF_I2SCTL_SPKEN_SHIFT)
+
+#define LPAIF_I2SCTL_SPKMODE_MASK  0x3C00
+#define LPAIF_I2SCTL_SPKMODE_SHIFT 10
+#define LPAIF_I2SCTL_SPKMODE_NONE  (0 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD0   (1 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD1   (2 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD2   (3 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD3   (4 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_QUAD01(5 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_QUAD23(6 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_6CH   (7 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_8CH   (8 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+
+#define LPAIF_I2SCTL_SPKMONO_MASK  0x0200
+#define LPAIF_I2SCTL_SPKMONO_SHIFT 9
+#define LPAIF_I2SCTL_SPKMONO_STEREO(0 << LPAIF_I2SCTL_SPKMONO_SHIFT)
+#define LPAIF_I2SCTL_SPKMONO_MONO  (1 << LPAIF_I2SCTL_SPKMONO_SHIFT)
+
+#define LPAIF_I2SCTL_WSSRC_MASK0x0004
+#define LPAIF_I2SCTL_WSSRC_SHIFT   2
+#define LPAIF_I2SCTL_WSSRC_INTERNAL(0 << LPAIF_I2SCTL_WSSRC_SHIFT)
+#define LPAIF_I2SCTL_WSSRC_EXTERNAL(1 << LPAIF_I2SCTL_WSSRC_SHIFT)
+
+#define LPAIF_I2SCTL_BITWIDTH_MASK 0x0003
+#define LPAIF_I2SCTL_BITWIDTH_SHIFT0
+#define LPAIF_I2SCTL_BITWIDTH_16   (0 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+#define LPAIF_I2SCTL_BITWIDTH_24   (1 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+#define LPAIF_I2SCTL_BITWIDTH_32   (2 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+
+/* LPAIF IRQ */
+
+#define LPAIF_IRQ_REG_BASE 0x3000
+#define LPAIF_IRQ_REG_STRIDE   0x1000
+#define LPAIF_IRQ_REG_ADDR(addr, port) \
+   (LPAIF_IRQ_REG_BASE + (addr) + (LPAIF_IRQ_REG_STRIDE * (port)))
+
+enum lpaif_irq_ports {
+   LPAIF_IRQ_PORT_MIN  = 0,
+
+   LPAIF_IRQ_PORT_HOST = 0,
+   LPAIF_IRQ_PORT_ADSP = 1,
+
+   LPAIF_IRQ_PORT_MAX  = 2,
+   LPAIF_IRQ_PORT_NUM  = 3,
+};
+
+#define LPAIF_IRQEN_REG(port)  LPAIF_IRQ_REG_ADDR(0x0, (port))
+#define LPAIF_IRQSTAT_REG(port)LPAIF_IRQ_REG_ADDR(0x4, (port))
+#define LPAIF_IRQCLEAR_REG(port)   

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

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

Add documentation to the sound directory of the
device-tree bindings for the QTi LPASS CPU DAI
device.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 .../devicetree/bindings/sound/qcom,lpass-cpu.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt

diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt 
b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt
new file mode 100644
index 
..e7c6e9321863f022ebf0d51b75d7bb83c10b9062
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt
@@ -0,0 +1,49 @@
+* Qualcomm Technologies LPASS CPU DAI
+
+This node models the Qualcomm Technologies Low-Power Audio SubSystem (LPASS).
+
+Required properties:
+
+- compatible   : "qcom,lpass-cpu"
+- clocks   : Must contain an entry for each entry in clock-names.
+- clock-names  : A list which must include the following entries:
+   * "ahbix-clk"
+   * "mi2s-osr-clk"
+   * "mi2s-bit-clk"
+- interrupts   : Must contain an entry for each entry in
+ interrupt-names.
+- interrupt-names  : A list which must include the following entries:
+   * "lpass-irq-lpaif"
+- pinctrl-N: One property must exist for each entry in
+ pinctrl-names.  See ../pinctrl/pinctrl-bindings.txt
+ for details of the property values.
+- pinctrl-names: Must contain a "default" entry.
+- reg  : Must contain an address for each entry in reg-names.
+- reg-names: A list which must include the following entries:
+   * "lpass-lpaif"
+
+Required subnodes:
+
+- qcom,adsp: Audio DSP sub-node
+
+Optional Audio DSP subnode properties:
+
+- status   : "disabled" indicates the adsp is not available.
+
+Example:
+
+lpass@2810 {
+   compatible = "qcom,lpass-cpu";
+   clocks = < AHBIX_CLK>, < MI2S_OSR_CLK>, < MI2S_BIT_CLK>;
+   clock-names = "ahbix-clk", "mi2s-osr-clk", "mi2s-bit-clk";
+   interrupts = <0 85 1>;
+   interrupt-names = "lpass-irq-lpaif";
+   pinctrl-names = "default", "idle";
+   pinctrl-0 = <_default>;
+   pinctrl-1 = <_idle>;
+   reg = <0x2810 0x1>;
+   reg-names = "lpass-lpaif";
+   qcom,adsp {
+   status = "disabled";
+   };
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[Patch V6 05/10] ASoC: qcom: Add LPASS CPU DAI driver

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

Add the CPU DAI driver for the Qualcomm
Technologies low-power audio subsystem (LPASS).

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/qcom/lpass-cpu.c | 508 +
 1 file changed, 508 insertions(+)
 create mode 100644 sound/soc/qcom/lpass-cpu.c

diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
new file mode 100644
index 
..44ba7e34915e2cac91c51fecbcb8516805e99f56
--- /dev/null
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -0,0 +1,508 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ *
+ * lpass-cpu.c -- ALSA SoC CPU DAI driver for QTi LPASS
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "lpass-lpaif-ipq806x.h"
+#include "lpass.h"
+
+static int lpass_cpu_daiops_set_sysclk(struct snd_soc_dai *dai, int clk_id,
+   unsigned int freq, int dir)
+{
+   struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+   int ret;
+
+   ret = clk_set_rate(drvdata->mi2s_osr_clk, freq);
+   if (ret)
+   dev_err(dai->dev, "%s() error setting mi2s osrclk to %u: %d\n",
+   __func__, freq, ret);
+
+   return ret;
+}
+
+static int lpass_cpu_daiops_startup(struct snd_pcm_substream *substream,
+   struct snd_soc_dai *dai)
+{
+   struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+   int ret;
+
+   ret = clk_prepare_enable(drvdata->mi2s_osr_clk);
+   if (ret) {
+   dev_err(dai->dev, "%s() error in enabling mi2s osr clk: %d\n",
+   __func__, ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(drvdata->mi2s_bit_clk);
+   if (ret) {
+   dev_err(dai->dev, "%s() error in enabling mi2s bit clk: %d\n",
+   __func__, ret);
+   clk_disable_unprepare(drvdata->mi2s_osr_clk);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void lpass_cpu_daiops_shutdown(struct snd_pcm_substream *substream,
+   struct snd_soc_dai *dai)
+{
+   struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+
+   clk_disable_unprepare(drvdata->mi2s_bit_clk);
+   clk_disable_unprepare(drvdata->mi2s_osr_clk);
+}
+
+static int lpass_cpu_daiops_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params, struct snd_soc_dai *dai)
+{
+   struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+   snd_pcm_format_t format = params_format(params);
+   unsigned int channels = params_channels(params);
+   unsigned int rate = params_rate(params);
+   unsigned int regval;
+   int bitwidth, ret;
+
+   bitwidth = snd_pcm_format_width(format);
+   if (bitwidth < 0) {
+   dev_err(dai->dev, "%s() invalid bit width given: %d\n",
+   __func__, bitwidth);
+   return bitwidth;
+   }
+
+   regval = LPAIF_I2SCTL_LOOPBACK_DISABLE |
+   LPAIF_I2SCTL_WSSRC_INTERNAL;
+
+   switch (bitwidth) {
+   case 16:
+   regval |= LPAIF_I2SCTL_BITWIDTH_16;
+   break;
+   case 24:
+   regval |= LPAIF_I2SCTL_BITWIDTH_24;
+   break;
+   case 32:
+   regval |= LPAIF_I2SCTL_BITWIDTH_32;
+   break;
+   default:
+   dev_err(dai->dev, "%s() invalid bitwidth given: %d\n",
+   __func__, bitwidth);
+   return -EINVAL;
+   }
+
+   switch (channels) {
+   case 1:
+   regval |= LPAIF_I2SCTL_SPKMODE_SD0;
+   regval |= LPAIF_I2SCTL_SPKMONO_MONO;
+   break;
+   case 2:
+   regval |= LPAIF_I2SCTL_SPKMODE_SD0;
+   regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+   break;
+   case 4:
+   regval |= LPAIF_I2SCTL_SPKMODE_QUAD01;
+   regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+   break;
+   case 6:
+   regval |= LPAIF_I2SCTL_SPKMODE_6CH;
+   regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+   break;
+   case 8:
+   regval |= LPAIF_I2SCTL_SPKMODE_8CH;
+   regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+   break;
+  

[Patch V6 00/10] ASoC: QCOM: Add support for ipq806x SOC

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

This patch series adds support for I2S audio playback on the Storm board, which
contains a Qualcomm Technologies ipq806x SOC and a Maxim max98357a DAC/amp.

The ipq806x SOC has audio-related hardware blocks in its low-power audio
subsystem (or LPASS).  One of the relevant blocks in the LPASS is its low-power
audio interface (or LPAIF).  This contains an MI2S port, which is what these
drivers are configured to use.  The LPAIF also contains a DMA engine that is
dedicated to moving audio samples into the transmit FIFO of the MI2S port.

One bus from the MI2S port of the SOC is connected to the DAC/amp for stereo
playback.  This bus is configured so that the SOC is bus master and consists of
DATA, LRCLK, and BCLK.  The DAC/amp does not need MCLK to operate.  In addition,
a single GPIO pin from the SOC is connected to the same DAC/amp, which gives
enable/disable control over the DAC/amp.

The specific drivers added are:
  * a CPU DAI driver for controlling the MI2S port
  * a platform driver for controlling the LPAIF DMA engine
  * a machine driver that instantiates a dai-link for playback

The LPASS also contains clocks that need to be controlled.  Those drivers have
been submitted as a separate patch series:  
  [PATCH v3 0/8] qcom audio clock control drivers
  http://lkml.org/lkml/2015/1/19/656

Even though the ipq806x LPASS does not contain an audio DSP, other SOCs do have
one.  For those SOCs, the audio DSP typically controls the hardware blocks in
the LPASS.  Hence, different CPU DAI driver(s) would need to be used in order to
facilitate audio with the DSP.  As such, the LPASS DT contains an adsp subnode,
which is disabled for this SOC.  The same subnode should be enabled and
populated for other SOCs that do contain an audio DSP.  Not using the audio DSP
would require different CPU DAI driver(s), in addition to possible bootloader
and/or firmware changes.

Corresponding additions to the device tree for the ipq806x SOC and its
documentation has also been added.  Also, as this is a new directory, the
MAINTAINERS file has been updated as well.

= Changes since V5
  [Patch V5 00/12] ASoC: QCOM: Add support for ipq806x SOC
  http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/087832.html

  * Correctly use Storm as the build target label and DT binding label.
  * Added audio DSP sub-node to the LPASS device tree, disabled for this SOC.
  * Added logic to CPU DAI driver to fail the probe() if a DSP is present.
  * Use the standard naming convention for the DAI link properties.
  * General code cleanup.

= Changes since V4
  [Patch V4 00/10] ASoC: QCOM: Add support for ipq806x SOC
  http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/087499.html

  * Replaced simple-card with a machine driver to resolve the system clock
configuration, rather than having the CPU DAI driver do it.
  * Added header files to avoid indirect header dependencies and implicit
forward declarations.
  * Tweaked the ISR to match the conventions of the surrounding code.
  * Removed the usage of the low-power memory as it is not needed.
  * Removed the use of the DRV_NAME constant.
  * Added explicit dependency on gpiolib for the codec driver.
  * Moved the MODULE_DEVICE_TABLE macro inside the CONFIG_OF conditional.
  * Modified the documentation to reflect the changes.
  * General code cleanup.

= Changes since V3
  [Patch V3 00/10] ASoC: QCOM: Add support for ipq806x SOC
  http://mailman.alsa-project.org/pipermail/alsa-devel/2014-December/085694.html

  * Placed the content of the inline functions into the callbacks.
  * Replaced use of readl/writel register access functions with regmap access
functions.  Notable exception is the ISR, which uses ioread32/iowrite32.
  * Rearranged the sequencing of the hardware block enables to fit within the
ASoC framework callbacks, while remaining functional.
REQ 1: The hardware requires the enable sequence to be:
   LPAIF-DMA[enable],then LPAIF-MI2S[enable], then DAC-GPIO[enable]
REQ 2: The hardware requires the disable sequence to be:
   DAC-GPIO[disable], then LPAIF-MI2S[disable]
  * Corrected the implementation of the pointer callback.
  * Utilize the LPM to buffer audio samples, rather than memory external to
LPASS.
  * Corrected the interrupt clearing in the ISR.
  * Implemented a default system clock (defined by the simple-card DT node), and
optional LPASS DT node modifiers that can alter the system clock in order to
expand the range of available bit clock frequencies.
  * Addressed all of the remaining issues raised by Mark Brown.
  * General code cleanup.

= Changes since V2
  [Patch v2 00/11] ASoC: QCOM: Add support for ipq806x SOC
  http://mailman.alsa-project.org/pipermail/alsa-devel/2014-December/085186.html

  * Removed the PCM platform driver from the DTS platform and tied it to the CPU
DAI driver.
  * Changed I2S pinctrl to use generic naming convention and moved control to

[Patch V6 03/10] ASoC: qcom: Document Storm bindings

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

Add documentation to the sound directory of the
device-tree bindings for the soundcard of the
Storm board.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 Documentation/devicetree/bindings/sound/storm.txt | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/storm.txt

diff --git a/Documentation/devicetree/bindings/sound/storm.txt 
b/Documentation/devicetree/bindings/sound/storm.txt
new file mode 100644
index 
..2a308e9c4cd3f9550c0b7078200a14a787f02858
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/storm.txt
@@ -0,0 +1,23 @@
+* Sound complex for Storm boards
+
+Models a soundcard for Storm boards with the Qualcomm Technologies IPQ806x SOC
+connected to a MAX98357A DAC via I2S.
+
+Required properties:
+
+- compatible   : "google,storm"
+- cpu  : Phandle of the CPU DAI
+- codec: Phandle of the codec DAI
+
+Optional properties:
+
+- qcom,model   : The user-visible name of this sound card.
+
+Example:
+
+sound {
+   compatible = "google,storm";
+   qcom,model = "ipq806x-storm";
+   cpu = <_cpu>;
+   codec = <>;
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[Patch V6 06/10] ASoC: qcom: Add LPASS platform driver

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

Add platform driver for the Qualcomm Technologies
low-power audio subsystem (LPASS) ports.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/qcom/lpass-platform.c | 526 
 1 file changed, 526 insertions(+)
 create mode 100644 sound/soc/qcom/lpass-platform.c

diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
new file mode 100644
index 
..2fa6280dfb234b213904ad73dfad91c7f575538c
--- /dev/null
+++ b/sound/soc/qcom/lpass-platform.c
@@ -0,0 +1,526 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ *
+ * lpass-platform.c -- ALSA SoC platform driver for QTi LPASS
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "lpass-lpaif-ipq806x.h"
+#include "lpass.h"
+
+#define LPASS_PLATFORM_BUFFER_SIZE (16 * 1024)
+#define LPASS_PLATFORM_PERIODS 2
+
+static struct snd_pcm_hardware lpass_platform_pcm_hardware = {
+   .info   =   SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID |
+   SNDRV_PCM_INFO_INTERLEAVED |
+   SNDRV_PCM_INFO_PAUSE |
+   SNDRV_PCM_INFO_RESUME,
+   .formats=   SNDRV_PCM_FMTBIT_S16 |
+   SNDRV_PCM_FMTBIT_S24 |
+   SNDRV_PCM_FMTBIT_S32,
+   .rates  =   SNDRV_PCM_RATE_8000_192000,
+   .rate_min   =   8000,
+   .rate_max   =   192000,
+   .channels_min   =   1,
+   .channels_max   =   8,
+   .buffer_bytes_max   =   LPASS_PLATFORM_BUFFER_SIZE,
+   .period_bytes_max   =   LPASS_PLATFORM_BUFFER_SIZE /
+   LPASS_PLATFORM_PERIODS,
+   .period_bytes_min   =   LPASS_PLATFORM_BUFFER_SIZE /
+   LPASS_PLATFORM_PERIODS,
+   .periods_min=   LPASS_PLATFORM_PERIODS,
+   .periods_max=   LPASS_PLATFORM_PERIODS,
+   .fifo_size  =   0,
+};
+
+static int lpass_platform_pcmops_open(struct snd_pcm_substream *substream)
+{
+   struct snd_pcm_runtime *runtime = substream->runtime;
+   struct snd_soc_pcm_runtime *soc_runtime = substream->private_data;
+   int ret;
+
+   snd_soc_set_runtime_hwparams(substream, _platform_pcm_hardware);
+
+   runtime->dma_bytes = lpass_platform_pcm_hardware.buffer_bytes_max;
+
+   ret = snd_pcm_hw_constraint_integer(runtime,
+   SNDRV_PCM_HW_PARAM_PERIODS);
+   if (ret < 0) {
+   dev_err(soc_runtime->dev, "%s() setting constraints failed: 
%d\n",
+   __func__, ret);
+   return -EINVAL;
+   }
+
+   snd_pcm_set_runtime_buffer(substream, >dma_buffer);
+
+   return 0;
+}
+
+static int lpass_platform_pcmops_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *soc_runtime = substream->private_data;
+   struct lpass_data *drvdata =
+   snd_soc_platform_get_drvdata(soc_runtime->platform);
+   snd_pcm_format_t format = params_format(params);
+   unsigned int channels = params_channels(params);
+   unsigned int regval;
+   int bitwidth;
+   int ret;
+
+   bitwidth = snd_pcm_format_width(format);
+   if (bitwidth < 0) {
+   dev_err(soc_runtime->dev, "%s() invalid bit width given: %d\n",
+   __func__, bitwidth);
+   return bitwidth;
+   }
+
+   regval = LPAIF_RDMACTL_BURSTEN_INCR4 |
+   LPAIF_RDMACTL_AUDINTF_MI2S |
+   LPAIF_RDMACTL_FIFOWM_8;
+
+   switch (bitwidth) {
+   case 16:
+   switch (channels) {
+   case 1:
+   case 2:
+   regval |= LPAIF_RDMACTL_WPSCNT_ONE;
+   break;
+   case 4:
+   regval |= LPAIF_RDMACTL_WPSCNT_TWO;
+   break;
+   case 6:
+   regval |= LPAIF_RDMACTL_WPSCNT_THREE;
+ 

[Patch V6 08/10] ASoC: qcom: Add ability to build QCOM drivers

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

Define the LPASS platform driver, the LPASS
CPU DAI driver and the Storm machine driver
configurations, and how to build them.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/qcom/Kconfig  | 23 +++
 sound/soc/qcom/Makefile | 11 +++
 2 files changed, 34 insertions(+)
 create mode 100644 sound/soc/qcom/Kconfig
 create mode 100644 sound/soc/qcom/Makefile

diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
new file mode 100644
index 
..90e686be613a5ef7689582a9d085835d2fe12678
--- /dev/null
+++ b/sound/soc/qcom/Kconfig
@@ -0,0 +1,23 @@
+config SND_SOC_QCOM
+   tristate "ASoC support for QCOM platforms"
+   help
+  Say Y or M if you want to add support to use audio devices
+  in Qualcomm Technologies SOC-based platforms.
+
+config SND_SOC_LPASS_CPU
+   tristate
+   depends on SND_SOC_QCOM
+
+config SND_SOC_LPASS_PLATFORM
+   tristate
+   depends on SND_SOC_QCOM
+
+config SND_SOC_STORM
+   tristate "ASoC I2S support for Storm boards"
+   depends on (ARCH_QCOM && SND_SOC_QCOM) || COMPILE_TEST
+   select SND_SOC_LPASS_CPU
+   select SND_SOC_LPASS_PLATFORM
+   select SND_SOC_MAX98357A
+   help
+  Say Y or M if you want add support for SoC audio on the
+  Qualcomm Technologies IPQ806X-based Storm board.
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
new file mode 100644
index 
..c5ce96c761c47b3a1b98e27d863fe0b5b9bc019e
--- /dev/null
+++ b/sound/soc/qcom/Makefile
@@ -0,0 +1,11 @@
+# Platform
+snd-soc-lpass-cpu-objs := lpass-cpu.o
+snd-soc-lpass-platform-objs := lpass-platform.o
+
+obj-$(CONFIG_SND_SOC_LPASS_CPU) += snd-soc-lpass-cpu.o
+obj-$(CONFIG_SND_SOC_LPASS_PLATFORM) += snd-soc-lpass-platform.o
+
+# Machine
+snd-soc-storm-objs := storm.o
+
+obj-$(CONFIG_SND_SOC_STORM) += snd-soc-storm.o
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[Patch V6 09/10] ASoC: Allow for building QCOM drivers

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

Allow for the Qualcomm Technologies ASoC drivers
to build.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/Kconfig  | 1 +
 sound/soc/Makefile | 1 +
 2 files changed, 2 insertions(+)

diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 
dcc79aa0236b548bfe5408fe56689241fc597e97..3ba52da18bc69a9bb41c84627cfc7d08f47e3bf0
 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -47,6 +47,7 @@ source "sound/soc/kirkwood/Kconfig"
 source "sound/soc/intel/Kconfig"
 source "sound/soc/mxs/Kconfig"
 source "sound/soc/pxa/Kconfig"
+source "sound/soc/qcom/Kconfig"
 source "sound/soc/rockchip/Kconfig"
 source "sound/soc/samsung/Kconfig"
 source "sound/soc/sh/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index 
5b3c8f67c8db7a29ff7199a6103d445428978125..974ba708b4826a03077a58251434a311542d5e3c
 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_SND_SOC) += nuc900/
 obj-$(CONFIG_SND_SOC)  += omap/
 obj-$(CONFIG_SND_SOC)  += kirkwood/
 obj-$(CONFIG_SND_SOC)  += pxa/
+obj-$(CONFIG_SND_SOC)  += qcom/
 obj-$(CONFIG_SND_SOC)  += rockchip/
 obj-$(CONFIG_SND_SOC)  += samsung/
 obj-$(CONFIG_SND_SOC)  += sh/
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[Patch V6 07/10] ASoC: qcom: Add Storm machine driver

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

Add machine driver for the Storm board with the
IPQ806X SOC connected to the MAX98357A DAC.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/qcom/storm.c | 162 +
 1 file changed, 162 insertions(+)
 create mode 100644 sound/soc/qcom/storm.c

diff --git a/sound/soc/qcom/storm.c b/sound/soc/qcom/storm.c
new file mode 100644
index 
..5b981af4aa38a6a3bba926b3dd877239eefe8cb0
--- /dev/null
+++ b/sound/soc/qcom/storm.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ *
+ * storm.c -- ALSA SoC machine driver for QTi ipq806x-based Storm board
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define STORM_SYSCLK_MULT  4
+
+static int storm_ops_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *soc_runtime = substream->private_data;
+   struct snd_soc_card *card = soc_runtime->card;
+   snd_pcm_format_t format = params_format(params);
+   unsigned int rate = params_rate(params);
+   unsigned int sysclk_freq;
+   int bitwidth, ret;
+
+   bitwidth = snd_pcm_format_width(format);
+   if (bitwidth < 0) {
+   dev_err(card->dev, "%s() invalid bit width given: %d\n",
+   __func__, bitwidth);
+   return bitwidth;
+   }
+
+   /*
+* as the CPU DAI is the I2S bus master and no system clock is needed by
+* the MAX98357a DAC, simply set the system clock to be a constant
+* multiple of the bit clock for the clock divider
+*/
+   sysclk_freq = rate * bitwidth * 2 * STORM_SYSCLK_MULT;
+
+   ret = snd_soc_dai_set_sysclk(soc_runtime->cpu_dai, 0, sysclk_freq, 0);
+   if (ret) {
+   dev_err(card->dev, "%s() error setting sysclk to %u: %d\n",
+   __func__, sysclk_freq, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static struct snd_soc_ops storm_soc_ops = {
+   .hw_params  = storm_ops_hw_params,
+};
+
+static struct snd_soc_dai_link storm_dai_link = {
+   .name   = "Primary",
+   .stream_name= "Primary",
+   .codec_dai_name = "HiFi",
+   .ops= _soc_ops,
+};
+
+static struct snd_soc_card storm_soc_card = {
+   .name   = "ipq806x-storm",
+   .dev= NULL,
+};
+
+static int storm_parse_of(struct snd_soc_card *card)
+{
+   struct snd_soc_dai_link *dai_link = card->dai_link;
+   struct device_node *np = card->dev->of_node;
+
+   dai_link->cpu_of_node = of_parse_phandle(np, "cpu", 0);
+   if (!dai_link->cpu_of_node) {
+   dev_err(card->dev, "%s() error getting cpu phandle\n",
+   __func__);
+   return -EINVAL;
+   }
+   dai_link->platform_of_node = dai_link->cpu_of_node;
+
+   dai_link->codec_of_node = of_parse_phandle(np, "codec", 0);
+   if (!dai_link->codec_of_node) {
+   dev_err(card->dev, "%s() error getting codec phandle\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int storm_platform_probe(struct platform_device *pdev)
+{
+   struct snd_soc_card *card = _soc_card;
+   int ret;
+
+   if (card->dev) {
+   dev_err(>dev, "%s() error, existing soundcard\n",
+   __func__);
+   return -ENODEV;
+   }
+   card->dev = >dev;
+   platform_set_drvdata(pdev, card);
+
+   ret = snd_soc_of_parse_card_name(card, "qcom,model");
+   if (ret) {
+   dev_err(>dev, "%s() error parsing card name: %d\n",
+   __func__, ret);
+   return ret;
+   }
+
+   card->dai_link  = _dai_link;
+   card->num_links = 1;
+
+   ret = storm_parse_of(card);
+   if (ret) {
+   dev_err(>dev, "%s() error resolving dai links: %d\n",
+   __func__, ret);
+   return ret;
+   }
+
+   ret = devm_snd_soc_register_card(>dev, card);
+   if (ret == -EPROBE_DEFER) {
+   card->dev = NULL;
+   return ret;
+   } else if (ret) {
+   dev_err(>dev, "%s() error registering soundcard: %d\n",
+   

[Patch V6 10/10] ARM: dts: Model IPQ LPASS audio hardware

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

Model the Qualcomm Technologies LPASS hardware for
the ipq806x SOC.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 
cb225dafe97cd83c9ae4cc19482ed55d4a71b8b3..dd5cbb33cc2d89be57494e05b7477352358affa5
 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -2,6 +2,7 @@
 
 #include "skeleton.dtsi"
 #include 
+#include 
 #include 
 
 / {
@@ -96,6 +97,24 @@
cpu-offset = <0x8>;
};
 
+   lpass@2810 {
+   compatible = "qcom,lpass-cpu";
+   status = "disabled";
+   clocks = < AHBIX_CLK>,
+   < MI2S_OSR_CLK>,
+   < MI2S_BIT_CLK>;
+   clock-names = "ahbix-clk",
+   "mi2s-osr-clk",
+   "mi2s-bit-clk";
+   interrupts = <0 85 1>;
+   interrupt-names = "lpass-irq-lpaif";
+   reg = <0x2810 0x1>;
+   reg-names = "lpass-lpaif";
+   qcom,adsp {
+   status = "disabled";
+   };
+   };
+
acc0: clock-controller@2088000 {
compatible = "qcom,kpss-acc-v1";
reg = <0x02088000 0x1000>, <0x02008000 0x1000>;
@@ -273,6 +292,13 @@
qcom,controller-type = "pmic-arbiter";
};
 
+   lcc: clock-controller@2800 {
+   compatible = "qcom,lcc-ipq8064";
+   reg = <0x2800 0x1000>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
gcc: clock-controller@90 {
compatible = "qcom,gcc-ipq8064";
reg = <0x0090 0x4000>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[Patch] ASoC: max98357a: Use standard DAI names

2015-02-24 Thread Kenneth Westfield
From: Kenneth Westfield 

Use the standard naming convention for the codec DAI.

Signed-off-by: Kenneth Westfield 
---

based on next/topic/max98357a branch

 sound/soc/codecs/max98357a.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c
index 
4ee23fbc4e1237268ae104319a9cfe4fc369934e..bf3e933ee895752352e90f610195f39fc6cc058f
 100644
--- a/sound/soc/codecs/max98357a.c
+++ b/sound/soc/codecs/max98357a.c
@@ -85,9 +85,9 @@ static struct snd_soc_dai_ops max98357a_dai_ops = {
 };
 
 static struct snd_soc_dai_driver max98357a_dai_driver = {
-   .name = "max98357a",
+   .name = "HiFi",
.playback = {
-   .stream_name= "max98357a-playback",
+   .stream_name= "HiFi Playback",
.formats= SNDRV_PCM_FMTBIT_S16 |
SNDRV_PCM_FMTBIT_S24 |
SNDRV_PCM_FMTBIT_S32,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


Re: [PATCH 2/3 v4] resource: Add new flag IORESOURCE_MEM_WARN

2015-02-24 Thread Boaz Harrosh
On 02/24/2015 07:04 PM, Dan Williams wrote:
> On Tue, Feb 24, 2015 at 7:00 AM, Boaz Harrosh  wrote:
>>
>> Resource providers set this flag if they want
>> that request_region will print a warning in dmesg
>> if this particular memory resource is locked by a driver.
>>
>> Thous acting as a Protocol Police about experimental
>> devices that did not pass a committee approval.
>>
>> The Only user of  this flag is x86/kernel/e820.c that
>> wants to WARN about UNKNOWN memory types.
>>
>> NOTE: It would be preferred if I defined a general flag say
>>   IORESOURCE_WARN, where any kind of resource provider
>>   can WARN on use, but we have run out of flags in the
>>   32bit long systems. So I defined a free bit from the
>>   resource specific flags for mem resources. This is
>>   why I need to check if this is a memory resource first
>>   so not to conflict with other resource specific flags.
>>   (Though actually no one is using this specific bit)
>>
>> CC: Thomas Gleixner 
>> CC: Ingo Molnar 
>> CC: "H. Peter Anvin" 
>> CC: x...@kernel.org
>> CC: Dan Williams 
>> CC: Andrew Morton 
>> CC: Bjorn Helgaas 
>> CC: Vivek Goyal 
>> Signed-off-by: Boaz Harrosh 
>> ---
>>  arch/x86/kernel/e820.c | 3 +++
>>  include/linux/ioport.h | 1 +
>>  kernel/resource.c  | 9 -
>>  3 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
>> index 1a8a1c3..105bb37 100644
>> --- a/arch/x86/kernel/e820.c
>> +++ b/arch/x86/kernel/e820.c
>> @@ -961,6 +961,9 @@ void __init e820_reserve_resources(void)
>>
>> res->flags = IORESOURCE_MEM;
>>
>> +   if (_is_unknown_type(e820.map[i].type))
>> +   res->flags |= IORESOURCE_MEM_WARN;
>> +
>> /*
>>  * don't register the region that could be conflicted with
>>  * pci device BAR resource and insert them later in
>> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
>> index 2c525022..f78972b 100644
>> --- a/include/linux/ioport.h
>> +++ b/include/linux/ioport.h
>> @@ -90,6 +90,7 @@ struct resource {
>>  #define IORESOURCE_MEM_32BIT   (3<<3)
>>  #define IORESOURCE_MEM_SHADOWABLE  (1<<5)  /* dup: 
>> IORESOURCE_SHADOWABLE */
>>  #define IORESOURCE_MEM_EXPANSIONROM(1<<6)
>> +#define IORESOURCE_MEM_WARN(1<<7)  /* WARN if requested by 
>> driver */
>>
>>  /* PnP I/O specific bits (IORESOURCE_BITS) */
>>  #define IORESOURCE_IO_16BIT_ADDR   (1<<0)
>> diff --git a/kernel/resource.c b/kernel/resource.c
>> index 19f2357..4bab16f 100644
>> --- a/kernel/resource.c
>> +++ b/kernel/resource.c
>> @@ -1075,8 +1075,15 @@ struct resource * __request_region(struct resource 
>> *parent,
>> break;
>> if (conflict != parent) {
>> parent = conflict;
>> -   if (!(conflict->flags & IORESOURCE_BUSY))
>> +   if (!(conflict->flags & IORESOURCE_BUSY)) {
>> +   if (unlikely(
> 
> No need for unlikely(), this isn't a hot path.
> 
>> +   (resource_type(conflict) == 
>> IORESOURCE_MEM)
>> +   && (conflict->flags & 
>> IORESOURCE_MEM_WARN)))
>> +   pr_warn("request region with unknown 
>> memory type [mem %#010llx-%#010llx] %s\n",
>> +   conflict->start, 
>> conflict->end,
>> +   conflict->name);
> 
> I think this should also dump the res->name to identify who is requesting it.
> 

OK Will send a version 4

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


Non-linear Remap Vs. VM Cleanup: Performance Hit

2015-02-24 Thread D. Cooper Stevenson

Hello All,

I read the Linus's release for RC1. One of his favorite features in the 
release are, "actually some vm cleanups, where this release is getting 
rid of the largely unused non-linear remapping code (replaced with just 
emulating it with lots of smaller mappings) and unifies the NUMA and 
PROTNONE handling for page tables."


I understand that non-linear page remapping is unused (and, presumably, 
reduces the code base size) but according to the remap_file_pages man 
page (http://man7.org/linux/man-pages/man2/remap_file_pages.2.html) 
non-linear system will be, "eventually be replaced by a slower in-kernel 
emulation."


Was this a change of necessity? What gives?

Also, would you please Cc: me on your replies as I am not a member of 
the mailing list?



Best Regards,


-Cooper
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] intel_idle: Make the auto-demotion flag generic

2015-02-24 Thread Srinidhi Kasagar
Disabling core and module C6 auto-demotion helps other Intel
platforms other than just Baytrail.

Signed-off-by: Srinidhi Kasagar 
---
 drivers/idle/intel_idle.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 9cceacb92f9d..c99a099a9cdc 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -89,7 +89,7 @@ struct idle_cpu {
 * Indicate which enable bits to clear here.
 */
unsigned long auto_demotion_disable_flags;
-   bool byt_auto_demotion_disable_flag;
+   bool auto_demotion_disable_flag;
bool disable_promotion_to_c1e;
 };
 
@@ -674,7 +674,7 @@ static const struct idle_cpu idle_cpu_snb = {
 static const struct idle_cpu idle_cpu_byt = {
.state_table = byt_cstates,
.disable_promotion_to_c1e = true,
-   .byt_auto_demotion_disable_flag = true,
+   .auto_demotion_disable_flag = true,
 };
 
 static const struct idle_cpu idle_cpu_ivb = {
@@ -884,7 +884,7 @@ static int __init intel_idle_cpuidle_driver_init(void)
if (icpu->auto_demotion_disable_flags)
on_each_cpu(auto_demotion_disable, NULL, 1);
 
-   if (icpu->byt_auto_demotion_disable_flag) {
+   if (icpu->auto_demotion_disable_flag) {
wrmsrl(MSR_CC6_DEMOTION_POLICY_CONFIG, 0);
wrmsrl(MSR_MC6_DEMOTION_POLICY_CONFIG, 0);
}
-- 
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] kasan, module, vmalloc: rework shadow allocation for modules

2015-02-24 Thread Rusty Russell
Andrey Ryabinin  writes:
> On 02/23/2015 11:26 AM, Rusty Russell wrote:
>> Andrey Ryabinin  writes:
>>> On 02/20/2015 03:15 AM, Rusty Russell wrote:
 Andrey Ryabinin  writes:
> On 02/19/2015 02:10 AM, Rusty Russell wrote:
>> This is not portable.  Other archs don't use vmalloc, or don't use
>> (or define) MODULES_VADDR.  If you really want to hook here, you'd
>> need a new flag (or maybe use PAGE_KERNEL_EXEC after an audit).
>>
>
> Well, instead of explicit (addr >= MODULES_VADDR && addr < MODULES_END)
> I could hide this into arch-specific function: 
> 'kasan_need_to_allocate_shadow(const void *addr)'
> or make make all those functions weak and allow arch code to redefine 
> them.

 That adds another layer of indirection.  And how would the caller of
 plain vmalloc() even know what to return?

>>>
>>> I think I don't understand what do you mean here. vmalloc() callers 
>>> shouldn't know
>>> anything about kasan/shadow.
>> 
>> How else would kasan_need_to_allocate_shadow(const void *addr) work for
>> architectures which don't have a reserved vmalloc region for modules?
>> 
>
>
> I think I need to clarify what I'm doing.
>
> Address sanitizer algorithm in short:
> -
> Every memory access is transformed by the compiler in the following way:
>
> Before:
>   *address = ...;
>
> after:
>
>   if (memory_is_poisoned(address)) {
>   report_error(address, access_size);
>   }
>   *address = ...;
>
> where memory_is_poisoned():
>   bool memory_is_poisoned(unsigned long addr)
>   {
>   s8 shadow_value = *(s8 *)kasan_mem_to_shadow((void *)addr);
>   if (unlikely(shadow_value)) {
>   s8 last_accessible_byte = addr & KASAN_SHADOW_MASK;
>   return unlikely(last_accessible_byte >= shadow_value);
>   }
>   return false;
>   }
> --
>
> So shadow memory should be present for every accessible address in kernel
> otherwise it will be unhandled page fault on reading shadow value.
>
> Shadow for vmalloc addresses (on x86_64) is readonly mapping of one zero page.
> Zero byte in shadow means that it's ok to access to that address.
> Currently we don't catch bugs in vmalloc because most of such bugs could be 
> caught
> in more simple way with CONFIG_DEBUG_PAGEALLOC.
> That's why we don't need RW shadow for vmalloc, it just one zero page that 
> readonly
> mapped early on boot for the whole [kasan_mem_to_shadow(VMALLOC_START, 
> kasan_mem_to_shadow(VMALLOC_END)] range
> So every access to vmalloc range assumed to be valid.
>
> To catch out of bounds accesses in global variables we need to fill shadow 
> corresponding
> to variable's redzone with non-zero (negative) values.
> So for kernel image and modules we need a writable shadow.
>
> If some arch don't have separate address range for modules and it uses 
> general vmalloc()
> shadow for vmalloc should be writable, so it means that shadow has to be 
> allocated
> for every vmalloc() call.
>
> In such arch kasan_need_to_allocate_shadow(const void *addr) should return 
> true for every vmalloc address:
> bool kasan_need_to_allocate_shadow(const void *addr)
> {
>   return addr >= VMALLOC_START && addr < VMALLOC_END;
> }

Thanks for the explanation.

> All above means that current code is not very portable.
> And 'kasan_module_alloc(p, size) after module alloc' approach is not portable
> too. This won't work for arches that use [VMALLOC_START, VMALLOC_END] 
> addresses for modules,
> because now we need to handle all vmalloc() calls.

I'm confused.  That's what you do now, and it hasn't been a problem,
has it?  The problem is on the freeing from interrupt context...

How about:

#define VM_KASAN0x0080  /* has shadow kasan map */

Set that in kasan_module_alloc():

if (ret) {
struct vm_struct *vma = find_vm_area(addr);

BUG_ON(!vma);
/* Set VM_KASAN so vfree() can free up shadow. */
vma->flags |= VM_KASAN;
}

And check that in __vunmap():

if (area->flags & VM_KASAN)
kasan_module_free(addr);

That is portable, and is actually a fairly small patch on what you
have at the moment.

What am I missing?

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


Re: [PATCH v2] scripts: checkpatch.pl: add 2 new checks on memset calls

2015-02-24 Thread Joe Perches
On Wed, 2015-02-25 at 08:08 +0200, Aya Mahfouz wrote:
> What is the next step?

Ideally, you understanding why the suggested patch
is an improvement over the patch you proposed.

Beyond that, submit a patch.  Then submit more...

cheers, Joe

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


Re: [PATCH v2] scripts: checkpatch.pl: add 2 new checks on memset calls

2015-02-24 Thread Aya Mahfouz
On Tue, Feb 24, 2015 at 09:45:43PM -0800, Joe Perches wrote:
> On Wed, 2015-02-25 at 06:59 +0200, Aya Mahfouz wrote:
> > On Tue, Feb 24, 2015 at 08:41:23PM -0800, Joe Perches wrote:
> > > On Wed, 2015-02-25 at 06:35 +0200, Aya Mahfouz wrote:
> > > > On Tue, Feb 24, 2015 at 07:10:52PM -0800, Joe Perches wrote:
> > > > > On Wed, 2015-02-25 at 04:40 +0200, Aya Mahfouz wrote:
> > > > > > This patch adds 2 new checks on memset calls in the file
> > > > > > checkpatch.pl as follows:
> > > []
> > > > ok, I didn't see your suggestion, sorry.
> > > 
> > > No worries.
> > > 
> > > > Can you look at the following
> > > > modification before sending the third patch? I don't use $stat because
> > > > I get false positives with it.
> > > 
> > > Please describe the false positives.
> > > 
> > > 
> > 
> > ok, here are the relevant warnings issued by checkpatch.pl when using
> > $stat for the file drivers/staging/rtl8188eu/os_dep/ioctl_linux.c.
> > The only correct results are lines 95, 830, 1031, 1040, 1908. 
> > 
> > WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
> > #95: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:95:
> > +   memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN);
> > 
> > 
> > WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
> > #775: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:775:
> > +}
> 
> []
> 
> Try this:
> ---
>  scripts/checkpatch.pl | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index d124359..9127c65 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -4890,10 +4890,11 @@ sub process {
>   }
>   }
>  
> -# Check for misused memsets
> +# Check for misused memsets then check for memset(foo, 0x00|0xff, ETH_ALEN)
> +# calls that could be eth_zero_addr(foo)|eth_broadcast_addr(foo)
>   if ($^V && $^V ge 5.10.0 &&
>   defined $stat &&
> - $stat =~ 
> /^\+(?:.*?)\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*$FuncArg\s*\)/s) {
> + $stat =~ 
> /^\+(?:\s*$Ident\s*=)?\s*memset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*$FuncArg\s*\)/s)
>  {
>  
>   my $ms_addr = $2;
>   my $ms_val = $7;
> @@ -4901,10 +4902,22 @@ sub process {
>  
>   if ($ms_size =~ /^(0x|)0$/i) {
>   ERROR("MEMSET",
> -   "memset to 0's uses 0 as the 2nd 
> argument, not the 3rd\n" . "$here\n$stat\n");
> +   "memset to 0's uses 0 as the 2nd 
> argument, not the 3rd\n" . "$here\n$line\n");
>   } elsif ($ms_size =~ /^(0x|)1$/i) {
>   WARN("MEMSET",
> -  "single byte memset is suspicious. Swapped 
> 2nd/3rd argument?\n" . "$here\n$stat\n");
> +  "single byte memset is suspicious. Swapped 
> 2nd/3rd argument?\n" . "$here\n$line\n");
> + } elsif ($ms_val =~ /^(?:0x)?0+$/i &&
> +  $ms_size =~ /^ETH_ALEN$/ &&
> +  WARN("PREFER_ETH_ADDR",
> +  "Prefer eth_zero_addr() over memset() if 
> the second address is 0\n" . $herecurr) &&
> +  $fix) {
> + $fixed[$fixlinenr] =~ 
> s/\bmemset\s*\(\s*\Q$ms_addr\E\s*,\s*\Q$ms_val\E\s*,\s*ETH_ALEN\s*\)/eth_zero_addr($ms_addr)/;
> + } elsif ($ms_val =~ /^(?:0xff|255)$/i &&
> +  $ms_size =~ /^ETH_ALEN$/ &&
> +  WARN("PREFER_ETH_ADDR",
> +   "Prefer eth_broadcast_addr() over 
> memset() if the second address is 0xff\n" . $herecurr) &&
> +  $fix) {
> + $fixed[$fixlinenr] =~ 
> s/\bmemset\s*\(\s*\Q$ms_addr\E\s*,\s*\Q$ms_val\E\s*,\s*ETH_ALEN\s*\)/eth_broadcast_addr($ms_addr)/;
>   }
>   }
>  
> 
> 

Yes, this patch works smoothly. I'm not getting the false positives now.
What is the next step?

-- 
Kind Regards,
Aya Saif El-yazal Mahfouz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fib_trie: Add proc entry for next-hop exceptions

2015-02-24 Thread Chris Rorvick
On Tue, Feb 24, 2015 at 11:33 PM, David Miller  wrote:
> From: Chris Rorvick 
> Date: Tue, 24 Feb 2015 23:27:12 -0600
>
>> Exceptions are added to the FIB in response to ICMP redirects and to
>> account for PMTU, but there is little visibility into what the current
>> exceptions are.  Add a proc entry for listing the current next-hop
>> exceptions
>>
>> Signed-off-by: Chris Rorvick 
>
> Procfs exportation of networking information is deprecated.
>
> New pieces of information should be provided via netlink.

Ah, OK.  So is the premise of this patch still interesting or am I
just ignorant?  It seems like knowing whether or not you're
accumulating a lot of exceptions is interesting and I could not figure
out how to do that.

Thanks for the feedback.

Regards,

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/9] mfd: rtsx: update driving settings

2015-02-24 Thread micky_ching
From: Micky Ching 

update card drive settings, This setting can be used for rts5249
rts524A and rts525A.

Signed-off-by: Micky Ching 
Acked-by: Lee Jones 
---
 drivers/mfd/rts5249.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 225ad55..2fe2854 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -36,16 +36,16 @@ static u8 rts5249_get_ic_version(struct rtsx_pcr *pcr)
 static void rts5249_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
 {
u8 driving_3v3[4][3] = {
-   {0x11, 0x11, 0x11},
+   {0x11, 0x11, 0x18},
{0x55, 0x55, 0x5C},
-   {0x99, 0x99, 0x92},
-   {0x99, 0x99, 0x92},
+   {0xFF, 0xFF, 0xFF},
+   {0x96, 0x96, 0x96},
};
u8 driving_1v8[4][3] = {
+   {0xC4, 0xC4, 0xC4},
{0x3C, 0x3C, 0x3C},
-   {0xB3, 0xB3, 0xB3},
{0xFE, 0xFE, 0xFE},
-   {0xC4, 0xC4, 0xC4},
+   {0xB3, 0xB3, 0xB3},
};
u8 (*driving)[3], drive_sel;
 
@@ -341,7 +341,7 @@ void rts5249_init_params(struct rtsx_pcr *pcr)
 
pcr->flags = 0;
pcr->card_drive_sel = RTSX_CARD_DRIVE_DEFAULT;
-   pcr->sd30_drive_sel_1v8 = CFG_DRIVER_TYPE_C;
+   pcr->sd30_drive_sel_1v8 = CFG_DRIVER_TYPE_B;
pcr->sd30_drive_sel_3v3 = CFG_DRIVER_TYPE_B;
pcr->aspm_en = ASPM_L1_EN;
pcr->tx_initial_phase = SET_CLOCK_PHASE(1, 29, 16);
-- 
1.9.1

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


[PATCH v3 3/9] mfd: rtsx: update PETXCFG address

2015-02-24 Thread micky_ching
From: Micky Ching 

PETXCFG is defined at 0xFF03, the old 0xFE49 not used any more.

Signed-off-by: Micky Ching 
Acked-by: Lee Jones 
---
 drivers/mfd/rts5227.c| 6 ++
 drivers/mfd/rts5249.c| 6 ++
 include/linux/mfd/rtsx_pci.h | 2 +-
 3 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 3240740..1f387d4 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -118,11 +118,9 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
rts5227_fill_driving(pcr, OUTPUT_3V3);
/* Configure force_clock_req */
if (pcr->flags & PCR_REVERSE_SOCKET)
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
-   AUTOLOAD_CFG_BASE + 3, 0xB8, 0xB8);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8);
else
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
-   AUTOLOAD_CFG_BASE + 3, 0xB8, 0x88);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
 
return rtsx_pci_send_cmd(pcr, 100);
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index cf425cc..225ad55 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -116,11 +116,9 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
/* Configure driving */
rts5249_fill_driving(pcr, OUTPUT_3V3);
if (pcr->flags & PCR_REVERSE_SOCKET)
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
-   AUTOLOAD_CFG_BASE + 3, 0xB0, 0xB0);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0xB0);
else
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
-   AUTOLOAD_CFG_BASE + 3, 0xB0, 0x80);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0x80);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
 
return rtsx_pci_send_cmd(pcr, 100);
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index e81f2bb..87cff60 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -572,7 +572,6 @@
 #define MSGTXDATA2 0xFE46
 #define MSGTXDATA3 0xFE47
 #define MSGTXCTL   0xFE48
-#define PETXCFG0xFE49
 #define LTR_CTL0xFE4A
 #define OBFF_CFG   0xFE4C
 
@@ -606,6 +605,7 @@
 #define DUMMY_REG_RESET_0  0xFE90
 
 #define AUTOLOAD_CFG_BASE  0xFF00
+#define PETXCFG0xFF03
 
 #define PM_CTRL1   0xFF44
 #define PM_CTRL2   0xFF45
-- 
1.9.1

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


[PATCH v3 2/9] mfd: rtsx: place register address and values togather

2015-02-24 Thread micky_ching
From: Micky Ching 

It is more readable to place register address and values define
togather. The values define add two leading space indicate belong
to the register address defined above.

Signed-off-by: Micky Ching 
Acked-by: Lee Jones 
---
 include/linux/mfd/rtsx_pci.h | 836 +++
 1 file changed, 369 insertions(+), 467 deletions(-)

diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index a9c2a14..e81f2bb 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -28,74 +28,72 @@
 
 #define MAX_RW_REG_CNT 1024
 
-/* PCI Operation Register Address */
 #define RTSX_HCBAR 0x00
 #define RTSX_HCBCTLR   0x04
+#define   STOP_CMD (0x01 << 28)
+#define   READ_REG_CMD 0
+#define   WRITE_REG_CMD1
+#define   CHECK_REG_CMD2
+
 #define RTSX_HDBAR 0x08
+#define   SG_INT   0x04
+#define   SG_END   0x02
+#define   SG_VALID 0x01
+#define   SG_NO_OP 0x00
+#define   SG_TRANS_DATA(0x02 << 4)
+#define   SG_LINK_DESC (0x03 << 4)
 #define RTSX_HDBCTLR   0x0C
+#define   SDMA_MODE0x00
+#define   ADMA_MODE(0x02 << 26)
+#define   STOP_DMA (0x01 << 28)
+#define   TRIG_DMA (0x01 << 31)
+
 #define RTSX_HAIMR 0x10
-#define RTSX_BIPR  0x14
-#define RTSX_BIER  0x18
+#define   HAIMR_TRANS_START(0x01 << 31)
+#define   HAIMR_READ   0x00
+#define   HAIMR_WRITE  (0x01 << 30)
+#define   HAIMR_READ_START (HAIMR_TRANS_START | HAIMR_READ)
+#define   HAIMR_WRITE_START(HAIMR_TRANS_START | HAIMR_WRITE)
+#define   HAIMR_TRANS_END  (HAIMR_TRANS_START)
 
-/* Host command buffer control register */
-#define STOP_CMD   (0x01 << 28)
-
-/* Host data buffer control register */
-#define SDMA_MODE  0x00
-#define ADMA_MODE  (0x02 << 26)
-#define STOP_DMA   (0x01 << 28)
-#define TRIG_DMA   (0x01 << 31)
-
-/* Host access internal memory register */
-#define HAIMR_TRANS_START  (0x01 << 31)
-#define HAIMR_READ 0x00
-#define HAIMR_WRITE(0x01 << 30)
-#define HAIMR_READ_START   (HAIMR_TRANS_START | HAIMR_READ)
-#define HAIMR_WRITE_START  (HAIMR_TRANS_START | HAIMR_WRITE)
-#define HAIMR_TRANS_END(HAIMR_TRANS_START)
-
-/* Bus interrupt pending register */
-#define CMD_DONE_INT   (1 << 31)
-#define DATA_DONE_INT  (1 << 30)
-#define TRANS_OK_INT   (1 << 29)
-#define TRANS_FAIL_INT (1 << 28)
-#define XD_INT (1 << 27)
-#define MS_INT (1 << 26)
-#define SD_INT (1 << 25)
-#define GPIO0_INT  (1 << 24)
-#define OC_INT (1 << 23)
-#define SD_WRITE_PROTECT   (1 << 19)
-#define XD_EXIST   (1 << 18)
-#define MS_EXIST   (1 << 17)
-#define SD_EXIST   (1 << 16)
-#define DELINK_INT GPIO0_INT
-#define MS_OC_INT  (1 << 23)
-#define SD_OC_INT  (1 << 22)
+#define RTSX_BIPR  0x14
+#define   CMD_DONE_INT (1 << 31)
+#define   DATA_DONE_INT(1 << 30)
+#define   TRANS_OK_INT (1 << 29)
+#define   TRANS_FAIL_INT   (1 << 28)
+#define   XD_INT   (1 << 27)
+#define   MS_INT   (1 << 26)
+#define   SD_INT   (1 << 25)
+#define   GPIO0_INT(1 << 24)
+#define   OC_INT   (1 << 23)
+#define   SD_WRITE_PROTECT (1 << 19)
+#define   XD_EXIST (1 << 18)
+#define   MS_EXIST (1 << 17)
+#define   SD_EXIST (1 << 16)
+#define   DELINK_INT   GPIO0_INT
+#define   MS_OC_INT(1 << 23)
+#define   SD_OC_INT(1 << 22)
 
 #define CARD_INT   (XD_INT | MS_INT | SD_INT)
 #define NEED_COMPLETE_INT  (DATA_DONE_INT | TRANS_OK_INT | TRANS_FAIL_INT)
 #define RTSX_INT   (CMD_DONE_INT | NEED_COMPLETE_INT | \
CARD_INT | GPIO0_INT | OC_INT)
-
 #define CARD_EXIST (XD_EXIST | MS_EXIST | SD_EXIST)
 
-/* Bus interrupt enable register */
-#define CMD_DONE_INT_EN(1 << 31)
-#define DATA_DONE_INT_EN   (1 << 30)
-#define TRANS_OK_INT_EN   

[PATCH v3 0/9] mfd: rtsx: add support for new rts524A and rts525A

2015-02-24 Thread micky_ching
From: Micky Ching 

v3:
- define member pcr->reg_pm_ctrl3 for PM_CTRL3 address
- update phy register without change the indent
- define macro for switch output voltage

resend:
- add lee jones ack for some patch.
v2:
- remove debug info when access failed.
- using macro list for phy register init.
- rename function for multi chip prefix with rtsx_base_
- save pcie_cap offset when init chip, not calling pci_find_capacity()
  every time.
- add pcr->ops: write_phy/read_phy for special chip.

This patchset including re-format some coding-style and add two new chip
rts524A and rts525A.

Micky Ching (9):
  mfd: rtsx: replace TAB by SPC after #define
  mfd: rtsx: place register address and values togather
  mfd: rtsx: update PETXCFG address
  mfd: rtsx: update driving settings
  mfd: rtsx: update phy register
  mfd: rtsx: remove LCTLR defination
  mfd: rtsx: add support for rts524A
  mfd: rtsx: add support for rts525A
  mfd: rtsx: using pcr_dbg replace dev_dbg

 drivers/mfd/Makefile |2 +-
 drivers/mfd/rtl8411.c|   11 +-
 drivers/mfd/rts5209.c|4 +-
 drivers/mfd/rts5227.c|   12 +-
 drivers/mfd/rts5229.c|4 +-
 drivers/mfd/rts5249.c|  343 +++--
 drivers/mfd/rtsx_gops.c  |   37 --
 drivers/mfd/rtsx_pcr.c   |  109 +++--
 drivers/mfd/rtsx_pcr.h   |8 +
 include/linux/mfd/rtsx_pci.h | 1116 ++
 10 files changed, 961 insertions(+), 685 deletions(-)
 delete mode 100644 drivers/mfd/rtsx_gops.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 v3 1/9] mfd: rtsx: replace TAB by SPC after #define

2015-02-24 Thread micky_ching
From: Micky Ching 

Re-format coding-style, using uniform SPC after "#define" keyword
instead of mixing using TAB and SPC.

Signed-off-by: Micky Ching 
Acked-by: Lee Jones 
---
 include/linux/mfd/rtsx_pci.h | 254 +--
 1 file changed, 127 insertions(+), 127 deletions(-)

diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 0c12628..a9c2a14 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -175,9 +175,9 @@
 /* CARD_SHARE_MODE */
 #define CARD_SHARE_MASK0x0F
 #define CARD_SHARE_MULTI_LUN   0x00
-#defineCARD_SHARE_NORMAL   0x00
-#defineCARD_SHARE_48_SD0x04
-#defineCARD_SHARE_48_MS0x08
+#define CARD_SHARE_NORMAL  0x00
+#define CARD_SHARE_48_SD   0x04
+#define CARD_SHARE_48_MS   0x08
 /* CARD_SHARE_MODE for barossa */
 #define CARD_SHARE_BAROSSA_SD  0x01
 #define CARD_SHARE_BAROSSA_MS  0x02
@@ -249,76 +249,76 @@
 #define CD_AUTO_DISABLE0x40
 
 /* SD_STAT1 */
-#defineSD_CRC7_ERR 0x80
-#defineSD_CRC16_ERR0x40
-#defineSD_CRC_WRITE_ERR0x20
-#defineSD_CRC_WRITE_ERR_MASK   0x1C
-#defineGET_CRC_TIME_OUT0x02
-#defineSD_TUNING_COMPARE_ERR   0x01
+#define SD_CRC7_ERR0x80
+#define SD_CRC16_ERR   0x40
+#define SD_CRC_WRITE_ERR   0x20
+#define SD_CRC_WRITE_ERR_MASK  0x1C
+#define GET_CRC_TIME_OUT   0x02
+#define SD_TUNING_COMPARE_ERR  0x01
 
 /* SD_STAT2 */
-#defineSD_RSP_80CLK_TIMEOUT0x01
+#define SD_RSP_80CLK_TIMEOUT   0x01
 
 /* SD_BUS_STAT */
-#defineSD_CLK_TOGGLE_EN0x80
-#defineSD_CLK_FORCE_STOP   0x40
-#defineSD_DAT3_STATUS  0x10
-#defineSD_DAT2_STATUS  0x08
-#defineSD_DAT1_STATUS  0x04
-#defineSD_DAT0_STATUS  0x02
-#defineSD_CMD_STATUS   0x01
+#define SD_CLK_TOGGLE_EN   0x80
+#define SD_CLK_FORCE_STOP  0x40
+#define SD_DAT3_STATUS 0x10
+#define SD_DAT2_STATUS 0x08
+#define SD_DAT1_STATUS 0x04
+#define SD_DAT0_STATUS 0x02
+#define SD_CMD_STATUS  0x01
 
 /* SD_PAD_CTL */
-#defineSD_IO_USING_1V8 0x80
-#defineSD_IO_USING_3V3 0x7F
-#defineTYPE_A_DRIVING  0x00
-#defineTYPE_B_DRIVING  0x01
-#defineTYPE_C_DRIVING  0x02
-#defineTYPE_D_DRIVING  0x03
+#define SD_IO_USING_1V80x80
+#define SD_IO_USING_3V30x7F
+#define TYPE_A_DRIVING 0x00
+#define TYPE_B_DRIVING 0x01
+#define TYPE_C_DRIVING 0x02
+#define TYPE_D_DRIVING 0x03
 
 /* SD_SAMPLE_POINT_CTL */
-#defineDDR_FIX_RX_DAT  0x00
-#defineDDR_VAR_RX_DAT  0x80
-#defineDDR_FIX_RX_DAT_EDGE 0x00
-#defineDDR_FIX_RX_DAT_14_DELAY 0x40
-#defineDDR_FIX_RX_CMD  0x00
-#defineDDR_VAR_RX_CMD  0x20
-#defineDDR_FIX_RX_CMD_POS_EDGE 0x00
-#defineDDR_FIX_RX_CMD_14_DELAY 0x10
-#defineSD20_RX_POS_EDGE0x00
-#defineSD20_RX_14_DELAY0x08
+#define DDR_FIX_RX_DAT 0x00
+#define DDR_VAR_RX_DAT 0x80
+#define DDR_FIX_RX_DAT_EDGE0x00
+#define DDR_FIX_RX_DAT_14_DELAY0x40
+#define DDR_FIX_RX_CMD 0x00
+#define DDR_VAR_RX_CMD 0x20
+#define DDR_FIX_RX_CMD_POS_EDGE0x00
+#define DDR_FIX_RX_CMD_14_DELAY0x10
+#define SD20_RX_POS_EDGE   0x00
+#define SD20_RX_14_DELAY   0x08
 #define SD20_RX_SEL_MASK   0x08
 
 /* SD_PUSH_POINT_CTL */
-#defineDDR_FIX_TX_CMD_DAT  0x00
-#defineDDR_VAR_TX_CMD_DAT  0x80
-#defineDDR_FIX_TX_DAT_14_TSU   0x00
-#defineDDR_FIX_TX_DAT_12_TSU   0x40
-#defineDDR_FIX_TX_CMD_NEG_EDGE 0x00
-#defineDDR_FIX_TX_CMD_14_AHEAD 0x20
-#defineSD20_TX_NEG_EDGE0x00
-#defineSD20_TX_14_AHEAD0x10
+#define DDR_FIX_TX_CMD_DAT 0x00
+#define DDR_VAR_TX_CMD_DAT 0x80
+#define DDR_FIX_TX_DAT_14_TSU  0x00
+#define DDR_FIX_TX_DAT_12_TSU  0x40
+#define DDR_FIX_TX_CMD_NEG_EDGE0x00
+#define DDR_FIX_TX_CMD_14_AHEAD0x20
+#define 

[PATCH v3 6/9] mfd: rtsx: remove LCTLR defination

2015-02-24 Thread micky_ching
From: Micky Ching 

To enable/disable ASPM we should find LINK CONTROL register
in PCI config space. All old chip use 0x80 address, but new
chip may use another address, so we using pci_find_capability()
to get LINK CONTROL address.

rtsx_gops.c was removed, we consider to put some common operations
to this file, but the actual thing is, only a group of chips
are in common ops1, and another group of chips in common ops2,
it is hard to decide put which ops into generic ops file.

Signed-off-by: Micky Ching 
Acked-by: Lee Jones 
---
 drivers/mfd/Makefile |  2 +-
 drivers/mfd/rts5227.c|  2 +-
 drivers/mfd/rts5249.c|  3 +--
 drivers/mfd/rtsx_gops.c  | 37 -
 drivers/mfd/rtsx_pcr.c   | 22 +-
 include/linux/mfd/rtsx_pci.h | 10 +-
 6 files changed, 21 insertions(+), 55 deletions(-)
 delete mode 100644 drivers/mfd/rtsx_gops.c

diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..2cd7e74 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
 obj-$(CONFIG_MFD_CROS_EC_I2C)  += cros_ec_i2c.o
 obj-$(CONFIG_MFD_CROS_EC_SPI)  += cros_ec_spi.o
 
-rtsx_pci-objs  := rtsx_pcr.o rtsx_gops.o rts5209.o rts5229.o 
rtl8411.o rts5227.o rts5249.o
+rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
rts5227.o rts5249.o
 obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
 obj-$(CONFIG_MFD_RTSX_USB) += rtsx_usb.o
 
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 1f387d4..0c02831 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -130,7 +130,7 @@ static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
 {
int err;
 
-   err = rtsx_gops_pm_reset(pcr);
+   err = rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
if (err < 0)
return err;
 
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 8de8220..3c77058 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -119,7 +119,6 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0xB0);
else
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0x80);
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
 
return rtsx_pci_send_cmd(pcr, 100);
 }
@@ -128,7 +127,7 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
 {
int err;
 
-   err = rtsx_gops_pm_reset(pcr);
+   err = rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
if (err < 0)
return err;
 
diff --git a/drivers/mfd/rtsx_gops.c b/drivers/mfd/rtsx_gops.c
deleted file mode 100644
index b1a98c6..000
--- a/drivers/mfd/rtsx_gops.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/* Driver for Realtek PCI-Express card reader
- *
- * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2, or (at your option) any
- * later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, see .
- *
- * Author:
- *   Micky Ching 
- */
-
-#include 
-#include "rtsx_pcr.h"
-
-int rtsx_gops_pm_reset(struct rtsx_pcr *pcr)
-{
-   int err;
-
-   /* init aspm */
-   rtsx_pci_write_register(pcr, ASPM_FORCE_CTL, 0xFF, 0x00);
-   err = rtsx_pci_update_cfg_byte(pcr, LCTLR, ~LCTLR_ASPM_CTL_MASK, 0x00);
-   if (err < 0)
-   return err;
-
-   /* reset PM_CTRL3 before send buffer cmd */
-   return rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
-}
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 30f7ca8..81b9c2c 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -63,6 +63,18 @@ static const struct pci_device_id rtsx_pci_ids[] = {
 
 MODULE_DEVICE_TABLE(pci, rtsx_pci_ids);
 
+static inline void rtsx_pci_enable_aspm(struct rtsx_pcr *pcr)
+{
+   rtsx_pci_update_cfg_byte(pcr, pcr->pcie_cap + PCI_EXP_LNKCTL,
+   0xFC, pcr->aspm_en);
+}
+
+static inline void rtsx_pci_disable_aspm(struct rtsx_pcr *pcr)
+{
+   rtsx_pci_update_cfg_byte(pcr, pcr->pcie_cap + PCI_EXP_LNKCTL,
+   0xFC, 0);
+}
+
 void rtsx_pci_start_run(struct rtsx_pcr *pcr)
 {
/* If pci device removed, don't queue idle work any more */
@@ -75,7 +87,7 @@ void rtsx_pci_start_run(struct rtsx_pcr *pcr)

[PATCH v3 8/9] mfd: rtsx: add support for rts525A

2015-02-24 Thread micky_ching
From: Micky Ching 

add support for new chip rts525A.

Signed-off-by: Micky Ching 
---
 drivers/mfd/rts5249.c| 103 +++
 drivers/mfd/rtsx_pcr.c   |  13 --
 drivers/mfd/rtsx_pcr.h   |   1 +
 include/linux/mfd/rtsx_pci.h |  15 +++
 4 files changed, 129 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 32be803..d1ff32f 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -487,3 +487,106 @@ void rts524a_init_params(struct rtsx_pcr *pcr)
pcr->ops = _pcr_ops;
 }
 
+static int rts525a_card_power_on(struct rtsx_pcr *pcr, int card)
+{
+   rtsx_pci_write_register(pcr, LDO_VCC_CFG1,
+   LDO_VCC_TUNE_MASK, LDO_VCC_3V3);
+   return rtsx_base_card_power_on(pcr, card);
+}
+
+static int rts525a_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+   switch (voltage) {
+   case OUTPUT_3V3:
+   rtsx_pci_write_register(pcr, LDO_CONFIG2,
+   LDO_D3318_MASK, LDO_D3318_33V);
+   rtsx_pci_write_register(pcr, SD_PAD_CTL, SD_IO_USING_1V8, 0);
+   break;
+   case OUTPUT_1V8:
+   rtsx_pci_write_register(pcr, LDO_CONFIG2,
+   LDO_D3318_MASK, LDO_D3318_18V);
+   rtsx_pci_write_register(pcr, SD_PAD_CTL, SD_IO_USING_1V8,
+   SD_IO_USING_1V8);
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   rtsx_pci_init_cmd(pcr);
+   rts5249_fill_driving(pcr, voltage);
+   return rtsx_pci_send_cmd(pcr, 100);
+}
+
+static int rts525a_optimize_phy(struct rtsx_pcr *pcr)
+{
+   int err;
+
+   err = rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3,
+   D3_DELINK_MODE_EN, 0x00);
+   if (err < 0)
+   return err;
+
+   rtsx_pci_write_phy_register(pcr, _PHY_FLD0,
+   _PHY_FLD0_CLK_REQ_20C | _PHY_FLD0_RX_IDLE_EN |
+   _PHY_FLD0_BIT_ERR_RSTN | _PHY_FLD0_BER_COUNT |
+   _PHY_FLD0_BER_TIMER | _PHY_FLD0_CHECK_EN);
+
+   rtsx_pci_write_phy_register(pcr, _PHY_ANA03,
+   _PHY_ANA03_TIMER_MAX | _PHY_ANA03_OOBS_DEB_EN |
+   _PHY_CMU_DEBUG_EN);
+
+   if (is_version(pcr, 0x525A, IC_VER_A))
+   rtsx_pci_write_phy_register(pcr, _PHY_REV0,
+   _PHY_REV0_FILTER_OUT | _PHY_REV0_CDR_BYPASS_PFD |
+   _PHY_REV0_CDR_RX_IDLE_BYPASS);
+
+   return 0;
+}
+
+static int rts525a_extra_init_hw(struct rtsx_pcr *pcr)
+{
+   rts5249_extra_init_hw(pcr);
+
+   rtsx_pci_write_register(pcr, PCLK_CTL, PCLK_MODE_SEL, PCLK_MODE_SEL);
+   if (is_version(pcr, 0x525A, IC_VER_A)) {
+   rtsx_pci_write_register(pcr, L1SUB_CONFIG2,
+   L1SUB_AUTO_CFG, L1SUB_AUTO_CFG);
+   rtsx_pci_write_register(pcr, RREF_CFG,
+   RREF_VBGSEL_MASK, RREF_VBGSEL_1V25);
+   rtsx_pci_write_register(pcr, LDO_VIO_CFG,
+   LDO_VIO_TUNE_MASK, LDO_VIO_1V7);
+   rtsx_pci_write_register(pcr, LDO_DV12S_CFG,
+   LDO_D12_TUNE_MASK, LDO_D12_TUNE_DF);
+   rtsx_pci_write_register(pcr, LDO_AV12S_CFG,
+   LDO_AV12S_TUNE_MASK, LDO_AV12S_TUNE_DF);
+   rtsx_pci_write_register(pcr, LDO_VCC_CFG0,
+   LDO_VCC_LMTVTH_MASK, LDO_VCC_LMTVTH_2A);
+   rtsx_pci_write_register(pcr, OOBS_CONFIG,
+   OOBS_AUTOK_DIS | OOBS_VAL_MASK, 0x89);
+   }
+
+   return 0;
+}
+
+static const struct pcr_ops rts525a_pcr_ops = {
+   .fetch_vendor_settings = rtsx_base_fetch_vendor_settings,
+   .extra_init_hw = rts525a_extra_init_hw,
+   .optimize_phy = rts525a_optimize_phy,
+   .turn_on_led = rtsx_base_turn_on_led,
+   .turn_off_led = rtsx_base_turn_off_led,
+   .enable_auto_blink = rtsx_base_enable_auto_blink,
+   .disable_auto_blink = rtsx_base_disable_auto_blink,
+   .card_power_on = rts525a_card_power_on,
+   .card_power_off = rtsx_base_card_power_off,
+   .switch_output_voltage = rts525a_switch_output_voltage,
+   .force_power_down = rtsx_base_force_power_down,
+};
+
+void rts525a_init_params(struct rtsx_pcr *pcr)
+{
+   rts5249_init_params(pcr);
+
+   pcr->reg_pm_ctrl3 = RTS524A_PM_CTRL3;
+   pcr->ops = _pcr_ops;
+}
+
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index e6d97ad..433cb41 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -59,6 +59,7 @@ static const struct pci_device_id rtsx_pci_ids[] = {
{ PCI_DEVICE(0x10EC, 0x5287), PCI_CLASS_OTHERS << 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5286), PCI_CLASS_OTHERS << 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x524A), PCI_CLASS_OTHERS << 16, 0xFF },
+   { PCI_DEVICE(0x10EC, 0x525A), PCI_CLASS_OTHERS << 16, 0xFF },
{ 0, }
 };
 
@@ -1114,6 +1115,10 @@ static int 

[PATCH v3 9/9] mfd: rtsx: using pcr_dbg replace dev_dbg

2015-02-24 Thread micky_ching
From: Micky Ching 

pcr_dbg is a wrapper of dev_dbg, which can save some code,
and help to enable/disable debug message static.

Signed-off-by: Micky Ching 
Acked-by: Lee Jones 
---
 drivers/mfd/rtl8411.c  | 11 +--
 drivers/mfd/rts5209.c  |  4 ++--
 drivers/mfd/rts5227.c  |  4 ++--
 drivers/mfd/rts5229.c  |  4 ++--
 drivers/mfd/rts5249.c  |  4 ++--
 drivers/mfd/rtsx_pcr.c | 49 ++---
 6 files changed, 35 insertions(+), 41 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index fdd34c8..b3ae659 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -53,7 +53,7 @@ static void rtl8411_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
u8 reg3 = 0;
 
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, );
-   dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg1);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg1);
 
if (!rtsx_vendor_setting_valid(reg1))
return;
@@ -65,7 +65,7 @@ static void rtl8411_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr->card_drive_sel |= rtsx_reg_to_card_drive_sel(reg1);
 
rtsx_pci_read_config_byte(pcr, PCR_SETTING_REG3, );
-   dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG3, reg3);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG3, reg3);
pcr->sd30_drive_sel_3v3 = rtl8411_reg_to_sd30_drive_sel_3v3(reg3);
 }
 
@@ -74,7 +74,7 @@ static void rtl8411b_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
u32 reg = 0;
 
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, );
-   dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
 
if (!rtsx_vendor_setting_valid(reg))
return;
@@ -260,9 +260,8 @@ static unsigned int rtl8411_cd_deglitch(struct rtsx_pcr 
*pcr)
rtsx_pci_write_register(pcr, CARD_PWR_CTL,
BPP_POWER_MASK, BPP_POWER_OFF);
 
-   dev_dbg(&(pcr->pci->dev),
-   "After CD deglitch, card_exist = 0x%x\n",
-   card_exist);
+   pcr_dbg(pcr, "After CD deglitch, card_exist = 0x%x\n",
+   card_exist);
}
 
if (card_exist & MS_EXIST) {
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index cb04174..373e253 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -38,7 +38,7 @@ static void rts5209_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
u32 reg;
 
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, );
-   dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
 
if (rts5209_vendor_setting1_valid(reg)) {
if (rts5209_reg_check_ms_pmos(reg))
@@ -47,7 +47,7 @@ static void rts5209_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
}
 
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG2, );
-   dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG2, reg);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG2, reg);
 
if (rts5209_vendor_setting2_valid(reg)) {
pcr->sd30_drive_sel_1v8 =
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 0c02831..ce012d7 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -63,7 +63,7 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
u32 reg;
 
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, );
-   dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
 
if (!rtsx_vendor_setting_valid(reg))
return;
@@ -74,7 +74,7 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr->card_drive_sel |= rtsx_reg_to_card_drive_sel(reg);
 
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG2, );
-   dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG2, reg);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG2, reg);
pcr->sd30_drive_sel_3v3 = rtsx_reg_to_sd30_drive_sel_3v3(reg);
if (rtsx_reg_check_reverse_socket(reg))
pcr->flags |= PCR_REVERSE_SOCKET;
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index 6353f5d..ace4538 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -38,7 +38,7 @@ static void rts5229_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
u32 reg;
 
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, );
-   dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
 
if (!rtsx_vendor_setting_valid(reg))
return;
@@ -50,7 +50,7 @@ static void rts5229_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr->card_drive_sel |= 

[PATCH v3 7/9] mfd: rtsx: add support for rts524A

2015-02-24 Thread micky_ching
From: Micky Ching 

add support for new chip rts524A.

Signed-off-by: Micky Ching 
---
 drivers/mfd/rts5249.c| 186 ---
 drivers/mfd/rtsx_pcr.c   |  25 +-
 drivers/mfd/rtsx_pcr.h   |   7 ++
 include/linux/mfd/rtsx_pci.h | 132 +-
 4 files changed, 318 insertions(+), 32 deletions(-)

diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 3c77058..32be803 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -65,15 +65,17 @@ static void rts5249_fill_driving(struct rtsx_pcr *pcr, u8 
voltage)
0xFF, driving[drive_sel][2]);
 }
 
-static void rts5249_fetch_vendor_settings(struct rtsx_pcr *pcr)
+static void rtsx_base_fetch_vendor_settings(struct rtsx_pcr *pcr)
 {
u32 reg;
 
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, );
dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
 
-   if (!rtsx_vendor_setting_valid(reg))
+   if (!rtsx_vendor_setting_valid(reg)) {
+   pcr_dbg(pcr, "skip fetch vendor setting\n");
return;
+   }
 
pcr->aspm_en = rtsx_reg_to_aspm(reg);
pcr->sd30_drive_sel_1v8 = rtsx_reg_to_sd30_drive_sel_1v8(reg);
@@ -87,7 +89,7 @@ static void rts5249_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr->flags |= PCR_REVERSE_SOCKET;
 }
 
-static void rts5249_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
+static void rtsx_base_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
 {
/* Set relink_time to 0 */
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, 0xFF, 0);
@@ -95,7 +97,8 @@ static void rts5249_force_power_down(struct rtsx_pcr *pcr, u8 
pm_state)
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
 
if (pm_state == HOST_ENTER_S3)
-   rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
+   rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3,
+   D3_DELINK_MODE_EN, D3_DELINK_MODE_EN);
 
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
 }
@@ -104,6 +107,8 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
 {
rtsx_pci_init_cmd(pcr);
 
+   /* Rest L1SUB Config */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, L1SUB_CONFIG3, 0xFF, 0x00);
/* Configure GPIO as output */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
/* Reset ASPM state to default value */
@@ -189,27 +194,27 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
PHY_TUNE_TUNED12 | PHY_TUNE_TUNEA12);
 }
 
-static int rts5249_turn_on_led(struct rtsx_pcr *pcr)
+static int rtsx_base_turn_on_led(struct rtsx_pcr *pcr)
 {
return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x02);
 }
 
-static int rts5249_turn_off_led(struct rtsx_pcr *pcr)
+static int rtsx_base_turn_off_led(struct rtsx_pcr *pcr)
 {
return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x00);
 }
 
-static int rts5249_enable_auto_blink(struct rtsx_pcr *pcr)
+static int rtsx_base_enable_auto_blink(struct rtsx_pcr *pcr)
 {
return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x08);
 }
 
-static int rts5249_disable_auto_blink(struct rtsx_pcr *pcr)
+static int rtsx_base_disable_auto_blink(struct rtsx_pcr *pcr)
 {
return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x00);
 }
 
-static int rts5249_card_power_on(struct rtsx_pcr *pcr, int card)
+static int rtsx_base_card_power_on(struct rtsx_pcr *pcr, int card)
 {
int err;
 
@@ -236,7 +241,7 @@ static int rts5249_card_power_on(struct rtsx_pcr *pcr, int 
card)
return 0;
 }
 
-static int rts5249_card_power_off(struct rtsx_pcr *pcr, int card)
+static int rtsx_base_card_power_off(struct rtsx_pcr *pcr, int card)
 {
rtsx_pci_init_cmd(pcr);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_PWR_CTL,
@@ -246,22 +251,35 @@ static int rts5249_card_power_off(struct rtsx_pcr *pcr, 
int card)
return rtsx_pci_send_cmd(pcr, 100);
 }
 
-static int rts5249_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+static int rtsx_base_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
 {
int err;
+   u16 append;
 
-   if (voltage == OUTPUT_3V3) {
-   err = rtsx_pci_write_phy_register(pcr, PHY_TUNE, 0x4FC0 | 0x24);
+   switch (voltage) {
+   case OUTPUT_3V3:
+   err = rtsx_pci_update_phy(pcr, PHY_TUNE, PHY_TUNE_VOLTAGE_MASK,
+   PHY_TUNE_VOLTAGE_3V3);
if (err < 0)
return err;
-   } else if (voltage == OUTPUT_1V8) {
-   err = rtsx_pci_write_phy_register(pcr, PHY_BACR, 0x3C02);
+   break;
+   case OUTPUT_1V8:
+   append = PHY_TUNE_D18_1V8;
+   if (CHK_PCI_PID(pcr, 0x5249)) {
+   err = rtsx_pci_update_phy(pcr, PHY_BACR,
+   PHY_BACR_BASIC_MASK, 0);
+  

[PATCH v3 5/9] mfd: rtsx: update phy register

2015-02-24 Thread micky_ching
From: Micky Ching 

Update some phy register name and value for rts5249,
the updated value makes chip more stable on some platform.

Signed-off-by: Micky Ching 
---
 drivers/mfd/rts5249.c|  29 +++-
 include/linux/mfd/rtsx_pci.h | 109 ++-
 2 files changed, 72 insertions(+), 66 deletions(-)

diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 2fe2854..8de8220 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -132,11 +132,12 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
if (err < 0)
return err;
 
-   err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
-   PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
-   PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
-   PHY_REG_REV_RX_PWST | PHY_REG_REV_CLKREQ_DLY_TIMER_1_0 |
-   PHY_REG_REV_STOP_CLKRD | PHY_REG_REV_STOP_CLKWR);
+   err = rtsx_pci_write_phy_register(pcr, PHY_REV,
+   PHY_REV_RESV | PHY_REV_RXIDLE_LATCHED |
+   PHY_REV_P1_EN | PHY_REV_RXIDLE_EN |
+   PHY_REV_CLKREQ_TX_EN | PHY_REV_RX_PWST |
+   PHY_REV_CLKREQ_DT_1_0 | PHY_REV_STOP_CLKRD |
+   PHY_REV_STOP_CLKWR);
if (err < 0)
return err;
 
@@ -147,19 +148,21 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
PHY_BPCR_IB_FILTER | PHY_BPCR_CMIRROR_EN);
if (err < 0)
return err;
+
err = rtsx_pci_write_phy_register(pcr, PHY_PCR,
PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 |
PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 |
-   PHY_PCR_RSSI_EN);
+   PHY_PCR_RSSI_EN | PHY_PCR_RX10K);
if (err < 0)
return err;
+
err = rtsx_pci_write_phy_register(pcr, PHY_RCR2,
PHY_RCR2_EMPHASE_EN | PHY_RCR2_NADJR |
-   PHY_RCR2_CDR_CP_10 | PHY_RCR2_CDR_SR_2 |
-   PHY_RCR2_FREQSEL_12 | PHY_RCR2_CPADJEN |
-   PHY_RCR2_CDR_SC_8 | PHY_RCR2_CALIB_LATE);
+   PHY_RCR2_CDR_SR_2 | PHY_RCR2_FREQSEL_12 |
+   PHY_RCR2_CDR_SC_12P | PHY_RCR2_CALIB_LATE);
if (err < 0)
return err;
+
err = rtsx_pci_write_phy_register(pcr, PHY_FLD4,
PHY_FLD4_FLDEN_SEL | PHY_FLD4_REQ_REF |
PHY_FLD4_RXAMP_OFF | PHY_FLD4_REQ_ADDA |
@@ -167,11 +170,12 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
PHY_FLD4_BER_CHK_EN);
if (err < 0)
return err;
-   err = rtsx_pci_write_phy_register(pcr, PHY_RDR, PHY_RDR_RXDSEL_1_9);
+   err = rtsx_pci_write_phy_register(pcr, PHY_RDR,
+   PHY_RDR_RXDSEL_1_9 | PHY_SSC_AUTO_PWD);
if (err < 0)
return err;
err = rtsx_pci_write_phy_register(pcr, PHY_RCR1,
-   PHY_RCR1_ADP_TIME | PHY_RCR1_VCO_COARSE);
+   PHY_RCR1_ADP_TIME_4 | PHY_RCR1_VCO_COARSE);
if (err < 0)
return err;
err = rtsx_pci_write_phy_register(pcr, PHY_FLD3,
@@ -179,10 +183,11 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
PHY_FLD3_RXDELINK);
if (err < 0)
return err;
+
return rtsx_pci_write_phy_register(pcr, PHY_TUNE,
PHY_TUNE_TUNEREF_1_0 | PHY_TUNE_VBGSEL_1252 |
PHY_TUNE_SDBUS_33 | PHY_TUNE_TUNED18 |
-   PHY_TUNE_TUNED12);
+   PHY_TUNE_TUNED12 | PHY_TUNE_TUNEA12);
 }
 
 static int rts5249_turn_on_led(struct rtsx_pcr *pcr)
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 87cff60..0103210 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -630,16 +630,47 @@
 
 /* Phy register */
 #define PHY_PCR0x00
+#define   PHY_PCR_FORCE_CODE   0xB000
+#define   PHY_PCR_OOBS_CALI_50 0x0800
+#define   PHY_PCR_OOBS_VCM_08  0x0200
+#define   PHY_PCR_OOBS_SEN_90  0x0040
+#define   PHY_PCR_RSSI_EN  0x0002
+#define   PHY_PCR_RX10K0x0001
+
 #define PHY_RCR0   0x01
 #define PHY_RCR1   0x02
+#define   PHY_RCR1_ADP_TIME_4  0x0400
+#define   PHY_RCR1_VCO_COARSE  0x001F
+
 #define PHY_RCR2   0x03
+#define   PHY_RCR2_EMPHASE_EN  0x8000
+#define   PHY_RCR2_NADJR   0x4000
+#define   PHY_RCR2_CDR_SR_20x0100
+#define   PHY_RCR2_FREQSEL_12  0x0040
+#define   PHY_RCR2_CDR_SC_12P  0x0010
+#define   PHY_RCR2_CALIB_LATE  0x0002
+
 #define PHY_RTCR   0x04
 #define PHY_RDR 

Re: [PATCH Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

2015-02-24 Thread Ethan Zhao
Viresh,

Will do that when I get the test box.

Thanks,
Ethan

On Wed, Feb 25, 2015 at 12:35 PM, viresh kumar  wrote:
> On Wednesday 25 February 2015 08:54 AM, Ethan Zhao wrote:
>> Viresh,
>>   With this patch applied, still got the following warning and panic,
>> seems it needs more care.
>>
>>  54.474618] [ cut here ]
>> [   54.545816] WARNING: CPU: 0 PID: 213 at include/linux/kref.h:47
>> kobject_get+0x41/0x50()
>> [   54.642595] Modules linked in: i2c_i801(+) mfd_core shpchp(+)
>> acpi_cpufreq(+) edac_core ioatdma(+) xfs libcrc32c ast syscopyarea ixgbe
>> sysfillrect sysimgblt sr_mod sd_mod drm_kms_helper igb mdio cdrom e1000e ahci
>> dca ttm libahci uas drm i2c_algo_bit ptp megaraid_sas libata usb_storage
>> i2c_core pps_core dm_mirror dm_region_hash dm_log dm_mod
>> [   55.007264] CPU: 0 PID: 213 Comm: kworker/0:2 Not tainted
>> 3.18.5
>> [   55.099970] Hardware name: Oracle Corporation SUN FIRE X4170 M2 SERVER
>>/ASSY,MOTHERBOARD,X4170, BIOS 08120104 05/08/2012
>> [   55.239736] Workqueue: kacpi_notify acpi_os_execute_deferred
>> [   55.308598]   bd730b61 88046742baf8
>> 816b7edb
>> [   55.398305]    88046742bb38
>> 81078ae1
>> [   55.488040]  88046742bbd8 8806706b3000 0292
>> 
>> [   55.56] Call Trace:
>> [   55.608228]  [] dump_stack+0x46/0x58
>> [   55.670895]  [] warn_slowpath_common+0x81/0xa0
>> [   55.743952]  [] warn_slowpath_null+0x1a/0x20
>> [   55.814929]  [] kobject_get+0x41/0x50
>> [   55.878654]  [] cpufreq_cpu_get+0x75/0xc0
>> [   55.946528]  [] cpufreq_update_policy+0x2e/0x1f0
>> [   56.021682]  [] ? up+0x32/0x50
>> [   56.078126]  [] ? acpi_ns_get_node+0xcb/0xf2
>> [   56.148974]  [] ? acpi_evaluate_object+0x22c/0x252
>> [   56.226066]  [] ? acpi_get_handle+0x95/0xc0
>> [   56.295871]  [] ? acpi_has_method+0x25/0x40
>> [   56.365661]  [] acpi_processor_ppc_has_changed+0x77/0x82
>> [   56.448956]  [] ? move_linked_works+0x66/0x90
>> [   56.520842]  [] acpi_processor_notify+0x58/0xe7
>> [   56.594807]  [] acpi_ev_notify_dispatch+0x44/0x5c
>> [   56.670859]  [] acpi_os_execute_deferred+0x15/0x22
>> [   56.747936]  [] process_one_work+0x14e/0x3f0
>> [   56.818766]  [] worker_thread+0x11b/0x4d0
>> [   56.886486]  [] ? rescuer_thread+0x350/0x350
>> [   56.957316]  [] kthread+0xe1/0x100
>> [   57.017742]  [] ? kthread_create_on_node+0x1b0/0x1b0
>> [   57.096903]  [] ret_from_fork+0x7c/0xb0
>> [   57.162534]  [] ? kthread_create_on_node+0x1b0/0x1b0
>> [   57.241680] ---[ end trace dce06bb76f547de5 ]---
>>
>>
>> Any idea ?
>
> No. Santosh reported this to me few days back, I asked him to perform some
> testing but don't know what happened after that..
>
> Can you give me full kernel logs along with the crash after this patch.
> You will be required to do some testing this time as I don't have any clue
> about the problem..
>
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index b4375021238f..230a59d2e0d7 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -214,8 +214,10 @@ struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
> if (cpufreq_driver) {
> /* get the CPU */
> policy = per_cpu(cpufreq_cpu_data, cpu);
> -   if (policy)
> +   if (policy) {
> kobject_get(>kobj);
> +   pr_info("%s: %d", __func__, 
> atomic_read(>kobj.kref.refcount));
> +   }
> }
>
> read_unlock_irqrestore(_driver_lock, flags);
> @@ -233,6 +235,7 @@ void cpufreq_cpu_put(struct cpufreq_policy *policy)
> return;
>
> kobject_put(>kobj);
> +   pr_info("%s: %d", __func__, atomic_read(>kobj.kref.refcount));
> up_read(_rwsem);
>  }
>  EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: regression in 4.0.0-rc1 with r8169 ethernet

2015-02-24 Thread Bjorn Helgaas
[+cc linux-pci]

On Tue, Feb 24, 2015 at 9:47 PM, Dave Airlie  wrote:
> Hey,
>
> just booted an old AMD rs780 box with new kernel and my ethernet
> failed to come up!
>
> Looks like the MAC addr is all ff's because the PCI bridge windows are
> messed up.
>
> I've attached two dmesg one from a 3.19.0-rc6 I had on it, and one
> failing from the 4.0.0-rc1 time.
>
> b24e2bdde4af656bb0679a101265ebb8f8735d3c is latest Linus commit in
> that tree (I have some radeon patches on top).
>
> motherboard is a Gigabyte GA-MA78GM-S2H, lspci also attached.

Hi Dave,

Looking, thanks for the report and sorry for the inconvenience.

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


Re: [PATCH v2] scripts: checkpatch.pl: add 2 new checks on memset calls

2015-02-24 Thread Joe Perches
On Wed, 2015-02-25 at 06:59 +0200, Aya Mahfouz wrote:
> On Tue, Feb 24, 2015 at 08:41:23PM -0800, Joe Perches wrote:
> > On Wed, 2015-02-25 at 06:35 +0200, Aya Mahfouz wrote:
> > > On Tue, Feb 24, 2015 at 07:10:52PM -0800, Joe Perches wrote:
> > > > On Wed, 2015-02-25 at 04:40 +0200, Aya Mahfouz wrote:
> > > > > This patch adds 2 new checks on memset calls in the file
> > > > > checkpatch.pl as follows:
> > []
> > > ok, I didn't see your suggestion, sorry.
> > 
> > No worries.
> > 
> > > Can you look at the following
> > > modification before sending the third patch? I don't use $stat because
> > > I get false positives with it.
> > 
> > Please describe the false positives.
> > 
> > 
> 
> ok, here are the relevant warnings issued by checkpatch.pl when using
> $stat for the file drivers/staging/rtl8188eu/os_dep/ioctl_linux.c.
> The only correct results are lines 95, 830, 1031, 1040, 1908. 
> 
> WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
> #95: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:95:
> + memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN);
> 
> 
> WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
> #775: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:775:
> +}

[]

Try this:
---
 scripts/checkpatch.pl | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d124359..9127c65 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4890,10 +4890,11 @@ sub process {
}
}
 
-# Check for misused memsets
+# Check for misused memsets then check for memset(foo, 0x00|0xff, ETH_ALEN)
+# calls that could be eth_zero_addr(foo)|eth_broadcast_addr(foo)
if ($^V && $^V ge 5.10.0 &&
defined $stat &&
-   $stat =~ 
/^\+(?:.*?)\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*$FuncArg\s*\)/s) {
+   $stat =~ 
/^\+(?:\s*$Ident\s*=)?\s*memset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*$FuncArg\s*\)/s)
 {
 
my $ms_addr = $2;
my $ms_val = $7;
@@ -4901,10 +4902,22 @@ sub process {
 
if ($ms_size =~ /^(0x|)0$/i) {
ERROR("MEMSET",
- "memset to 0's uses 0 as the 2nd 
argument, not the 3rd\n" . "$here\n$stat\n");
+ "memset to 0's uses 0 as the 2nd 
argument, not the 3rd\n" . "$here\n$line\n");
} elsif ($ms_size =~ /^(0x|)1$/i) {
WARN("MEMSET",
-"single byte memset is suspicious. Swapped 
2nd/3rd argument?\n" . "$here\n$stat\n");
+"single byte memset is suspicious. Swapped 
2nd/3rd argument?\n" . "$here\n$line\n");
+   } elsif ($ms_val =~ /^(?:0x)?0+$/i &&
+$ms_size =~ /^ETH_ALEN$/ &&
+WARN("PREFER_ETH_ADDR",
+"Prefer eth_zero_addr() over memset() if 
the second address is 0\n" . $herecurr) &&
+$fix) {
+   $fixed[$fixlinenr] =~ 
s/\bmemset\s*\(\s*\Q$ms_addr\E\s*,\s*\Q$ms_val\E\s*,\s*ETH_ALEN\s*\)/eth_zero_addr($ms_addr)/;
+   } elsif ($ms_val =~ /^(?:0xff|255)$/i &&
+$ms_size =~ /^ETH_ALEN$/ &&
+WARN("PREFER_ETH_ADDR",
+ "Prefer eth_broadcast_addr() over 
memset() if the second address is 0xff\n" . $herecurr) &&
+$fix) {
+   $fixed[$fixlinenr] =~ 
s/\bmemset\s*\(\s*\Q$ms_addr\E\s*,\s*\Q$ms_val\E\s*,\s*ETH_ALEN\s*\)/eth_broadcast_addr($ms_addr)/;
}
}
 


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


Re: [PATCH v2] mmc: dw_mmc: Don't start commands while busy

2015-02-24 Thread Doug Anderson
Javier,

On Tue, Feb 24, 2015 at 3:20 AM, Javier Martinez Canillas
 wrote:
>> Hm.  In the cases I was seeing I didn't need the "reset" since the
>> "SDMMC_CMD_UPD_CLK" was the one from dw_mci_set_ios() and my patch:
>>
>> * mmc: dw_mmc: Give a good reset after we give power
>>   https://patchwork.kernel.org/patch/5858281/
>>
>> ...gave the needed reset after vqmmc power was applied.  Then dw_mmc
>> never got wedged and didn't need the reset to get it unwedged.  In
>> your care you're getting called from dw_mci_init_card().  That should
>> happen _after_ dw_mci_set_ios() as far as I know.  Can you put a
>> printout in the reset in dw_mci_set_ios() and make sure it runs?
>>
>
> Added a printout in dw_mci_set_ios() and I see that the card is reset
> at MMC_POWER_ON. So you are right that it gets wedged somehow between
> dw_mci_set_ios() and dw_mci_init_card().

Actually, if your code needs 3 resets then maybe there's something else wrong...


> This only happens when the slot is attached to a SDIO device though
> since the controller neither gets busy nor a command timeouts for
> the eMMC and uSD.

It sounds like there's something else going on here.


>> How many resets do you need before things work?  If just one then
>> something must be happening between the initial "set_ios" and the
>
> The card is reseted 3 times to make it "work", that is to avoid being
> blocked constantly with "Timeout sending command" errors. But as I said
> before, even when the reset in dw_mci_wait_while_busy(), the firmware
> fails to load into the WiFi module so is not in the best state.

3 times?  ...but that doesn't make a lot of sense to me.  Is it simply
the delay that makes it work, or do you actually need the 3 resets?
Is anything else happening between all the resets?  I guess you keep
trying to send the command and resetting between?  Hrmmm...

Seems like there has got to be something else going on in this case...


>> BTW: IIRC the "WIFI_RSTn" ended up being totally unused.  It was used
>> in earlier revs of the board that had a different rev of the WiFi
>> chip...
>>
>
> You are right, I removed WIFI_RSTn and the SDIO devices are still enumerated.

I just checked.  WIFI_RSTn goes to the 3G connector which (as far as I
know) was never hooked up to anything.  ...so yeah, you can safely
leave that out.



>>> +_1 {
>>> +   status = "okay";
>>> +   num-slots = <1>;
>>> +   broken-cd;
>>> +   cap-sdio-irq;
>>> +   card-detect-delay = <200>;
>>> +   clock-frequency = <4>;
>>> +   samsung,dw-mshc-ciu-div = <1>;
>>> +   samsung,dw-mshc-sdr-timing = <0 1>;
>>
>> Just for kicks, does this help if you do:
>>
>> ciu-div = 3
>> sdr-timing = 2 3
>>
>> ...I know we have ciu-div = 1 downstream, but we also have tuning...
>>
>
> This makes it even worst since with those values the boot hangs after a
> "Timeout sending command" error even with the reset in wait while busy.

I don't have a pit or pi hooked up on my desk right now, but I will
try to give it a shot soon and see what it ends up at.  ...of course
you might still be at 400kHz mode in which case the divs just have to
not be totally wrong, I think...


>>> +   samsung,dw-mshc-ddr-timing = <0 2>;
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <_clk>, <_cmd>, <_int>, <_bus4>,
>>> +   <_bus8>, <_en>, <_rst>;
>>> +   bus-width = <4>;
>>> +   cap-sd-highspeed;
>>> +   mmc-pwrseq = <_pwrseq>;
>>
>> Should you be specifying a "vqmmc-supply" here?  I know that we don't
>> change voltages for WiFi (starts at 1.8V and ends up at 1.8V) but
>> still might be good to specify it...
>>
>
> Sure, I added a "vqmmc-supply = <_reg>" here. It does not have an
> effect though but is true that is better to specify it.

Yeah, makes sense.

---

OK, so looking through things I _think_ I found another difference
that _might_ matter...

Upstream (arch/arm/boot/dts/exynos5420-pinctrl.dtsi):
sd1_bus1: sd1-bus-width1 {
samsung,pins = "gpc1-3";
...
};

sd1_bus4: sd1-bus-width4 {
samsung,pins = "gpc1-4", "gpc1-5", "gpc1-6";
...
   };

sd1_bus8: sd1-bus-width8 {
samsung,pins = "gpd1-4", "gpd1-5", "gpd1-6", "gpd1-7";
...
   };

Upsttream (arch/arm/boot/dts/exynos5420-peach-pit.dts) -- your patch:
   pinctrl-0 = <_clk>, <_cmd>, <_int>, <_bus4>,
   <_bus8>, <_en>, <_rst>;

Downstream (arch/arm/boot/dts/exynos542x-pinctrl.dtsi):
sd1_bus1: sd1-bus-width1 {
samsung,pins = "gpc1-3";
...
   };

sd1_bus4: sd1-bus-width4 {
samsung,pins = "gpc1-3", "gpc1-4", "gpc1-5", "gpc1-6";
...
   };

sd1_bus8: sd1-bus-width8 {
  

Re: [PATCH] fib_trie: Add proc entry for next-hop exceptions

2015-02-24 Thread David Miller
From: Chris Rorvick 
Date: Tue, 24 Feb 2015 23:27:12 -0600

> Exceptions are added to the FIB in response to ICMP redirects and to
> account for PMTU, but there is little visibility into what the current
> exceptions are.  Add a proc entry for listing the current next-hop
> exceptions
> 
> Signed-off-by: Chris Rorvick 

Procfs exportation of networking information is deprecated.

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


Re: [RFC v2 0/5] introduce gcma

2015-02-24 Thread SeongJae Park

Hello Michal,

Thanks for your comment :)

On Tue, 24 Feb 2015, Michal Hocko wrote:


On Tue 24-02-15 04:54:18, SeongJae Park wrote:
[...]

 include/linux/cma.h  |4 +
 include/linux/gcma.h |   64 +++
 mm/Kconfig   |   24 +
 mm/Makefile  |1 +
 mm/cma.c |  113 -
 mm/gcma.c| 1321 ++
 6 files changed, 1508 insertions(+), 19 deletions(-)
 create mode 100644 include/linux/gcma.h
 create mode 100644 mm/gcma.c


Wow this is huge! And I do not see reason for it to be so big. Why
cannot you simply define (per-cma area) 2-class users policy? Either via
kernel command line or export areas to userspace and allow to set policy
there.


For implementation of the idea, we should develop not only policy 
selection, but also backend for discardable memory. Most part of this 
patch were made for the backend.


Current implementation gives selection of policy per cma area to users. 
Only about 120 lines of code were changed for that though it's most ugly 
part of this patch. The part remains as ugly in this RFC because this is 
just prototype. The part will be changed in next version patchset.




For starter something like the following policies should suffice AFAIU
your description.
- NONE - exclusive pool for CMA allocations only
- DROPABLE - only allocations which might be dropped without any
  additional actions - e.g. cleancache and frontswap with
  write-through policy
- RECLAIMABLE - only movable allocations which can be migrated
  or dropped after writeback.

Has such an approach been considered?


Similarly, but not in same way. In summary, GCMA gives DROPABLE and 
RECLAIMABLE policy selection per cma area and NONE policy to entire cma 
area declared using GCMA interface.


In detail, user could set policy of cma area as gcma way(DROPABLE) or cma 
way(RECLAIMABLE). Also, user could set gcma to utilize their cma area with 
Cleancache and/or Frontswap or not(NONE policy).


Your suggestion looks simple and better to understand. Next version of 
gcma will let users to be able to select policy as those per cma area.



Thanks,
SeongJae Park


--
Michal Hocko
SUSE Labs


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


[PATCH] fib_trie: Add proc entry for next-hop exceptions

2015-02-24 Thread Chris Rorvick
Exceptions are added to the FIB in response to ICMP redirects and to
account for PMTU, but there is little visibility into what the current
exceptions are.  Add a proc entry for listing the current next-hop
exceptions

Signed-off-by: Chris Rorvick 
---
I wrote this patch while looking into some issues on a network and found
it useful.  It caused me to realize that I needed to fix the routing on
my home network as the MTU over my PPPoE DSL service was causing the
exception list to grow very large.

Is there another way of getting the list of next-hop exceptions?  Or
even the current count?  Or is something similar to this patch a useful
addition?

Regards,

Chris

 net/ipv4/fib_trie.c | 92 +
 1 file changed, 92 insertions(+)

diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 3daf022..591d854 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2487,6 +2487,93 @@ static const struct file_operations fib_route_fops = {
.release = seq_release_net,
 };
 
+static void fib_nhe_seq_show_fib_info(struct seq_file *seq,
+ const struct fib_info *fi)
+{
+   const struct fnhe_hash_bucket *bucket;
+   const struct fib_nh_exception *fnhe;
+   int i, j;
+
+   for (i = 0; i < fi->fib_nhs; i++) {
+   bucket = fi->fib_nh[i].nh_exceptions;
+   if (!bucket)
+   continue;
+
+   for (j = 0; j < FNHE_HASH_SIZE; j++, bucket++) {
+   if (!bucket->chain)
+   continue;
+
+   for (fnhe = rcu_dereference(bucket->chain); fnhe;
+fnhe = rcu_dereference(fnhe->fnhe_next)) {
+   seq_printf(seq, "%-8s %-16pI4 %-16pI4 %-6d %-6d 
%-11ld %ld\n",
+  fi->fib_dev ? fi->fib_dev->name
+  : "*",
+  >fnhe_daddr,
+  fnhe->fnhe_gw ? >fnhe_gw
+: >fib_nh[i].nh_gw,
+  fnhe->fnhe_pmtu,
+  fnhe->fnhe_genid,
+  fnhe->fnhe_stamp,
+  fnhe->fnhe_expires);
+   }
+   }
+   }
+}
+
+static int fib_nhe_seq_show(struct seq_file *seq, void *v)
+{
+   struct tnode *l = v;
+   struct leaf_info *li;
+
+   if (v == SEQ_START_TOKEN) {
+   seq_printf(seq, "%-8s %-16s %-16s %-6s %-6s %-11s %s\n",
+  "Iface",
+  "Destination",
+  "Next Hop",
+  "PMTU",
+  "GenID",
+  "Time",
+  "Expires");
+   return 0;
+   }
+
+   hlist_for_each_entry_rcu(li, >list, hlist) {
+   struct fib_alias *fa;
+
+   list_for_each_entry_rcu(fa, >falh, fa_list) {
+   const struct fib_info *fi = fa->fa_info;
+
+   if (!fi)
+   continue;
+
+   fib_nhe_seq_show_fib_info(seq, fi);
+   }
+   }
+
+   return 0;
+}
+
+static const struct seq_operations fib_nhe_seq_ops = {
+   .start  = fib_route_seq_start,
+   .next   = fib_route_seq_next,
+   .stop   = fib_route_seq_stop,
+   .show   = fib_nhe_seq_show,
+};
+
+static int fib_nhe_seq_open(struct inode *inode, struct file *file)
+{
+   return seq_open_net(inode, file, _nhe_seq_ops,
+   sizeof(struct fib_route_iter));
+}
+
+static const struct file_operations fib_nhe_fops = {
+   .owner  = THIS_MODULE,
+   .open   = fib_nhe_seq_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release = seq_release_net,
+};
+
 int __net_init fib_proc_init(struct net *net)
 {
if (!proc_create("fib_trie", S_IRUGO, net->proc_net, _trie_fops))
@@ -2499,8 +2586,13 @@ int __net_init fib_proc_init(struct net *net)
if (!proc_create("route", S_IRUGO, net->proc_net, _route_fops))
goto out3;
 
+   if (!proc_create("fib_nh_exceptions", S_IRUGO, net->proc_net, 
_nhe_fops))
+   goto out4;
+
return 0;
 
+out4:
+   remove_proc_entry("route", net->proc_net);
 out3:
remove_proc_entry("fib_triestat", net->proc_net);
 out2:
-- 
2.1.0

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


[ANNOUNCE]: SCST 3.0.1 released

2015-02-24 Thread Vladislav Bolkhovitin
I'm glad to announce that maintenance update for SCST and its drivers 3.0.1 has 
just
been released and ready for download from 
http://scst.sourceforge.net/downloads.html.
All SCST users are encouraged to update.

SCST is alternative SCSI target stack for Linux. SCST allows creation of 
sophisticated
storage devices, which provide advanced functionality, like replication, thin
provisioning, deduplication, high availability, automatic backup, etc. Majority 
of
recently developed SAN appliances, especially higher end ones, are SCST based. 
It might
well be that your favorite storage appliance running SCST in the firmware.

More info about SCST and its modules you can find on: 
http://scst.sourceforge.net

Thanks to all who made it happen, especially Bart Van Assche!

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


Re: [PATCH v2] scripts: checkpatch.pl: add 2 new checks on memset calls

2015-02-24 Thread Aya Mahfouz
On Tue, Feb 24, 2015 at 08:41:23PM -0800, Joe Perches wrote:
> On Wed, 2015-02-25 at 06:35 +0200, Aya Mahfouz wrote:
> > On Tue, Feb 24, 2015 at 07:10:52PM -0800, Joe Perches wrote:
> > > On Wed, 2015-02-25 at 04:40 +0200, Aya Mahfouz wrote:
> > > > This patch adds 2 new checks on memset calls in the file
> > > > checkpatch.pl as follows:
> []
> > ok, I didn't see your suggestion, sorry.
> 
> No worries.
> 
> > Can you look at the following
> > modification before sending the third patch? I don't use $stat because
> > I get false positives with it.
> 
> Please describe the false positives.
> 
> 

ok, here are the relevant warnings issued by checkpatch.pl when using
$stat for the file drivers/staging/rtl8188eu/os_dep/ioctl_linux.c.
The only correct results are lines 95, 830, 1031, 1040, 1908. 

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#95: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:95:
+   memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN);


WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#775: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:775:
+}

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#777: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:777:
+static int rtw_wx_set_pmkid(struct net_device *dev,

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#778: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:778:
+   struct iw_request_info *a,

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#779: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:779:
+   union iwreq_data *wrqu, char *extra)

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#780: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:780:
+{

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#823: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:823:
+   }

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#824: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:824:
+   } else if (pPMK->cmd == IW_PMKSA_REMOVE) {

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#827: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:827:
+   for (j = 0; j < NUM_PMKID_CACHE; j++) {

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#828: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:828:
+   if (!memcmp(psecuritypriv->PMKIDList[j].Bssid, 
strIssueBssid, ETH_ALEN)) {

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#830: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:830:
+   memset(psecuritypriv->PMKIDList[j].Bssid, 0x00, 
ETH_ALEN);

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#1019: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:1019:
+}

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#1021: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:1021:
+static int rtw_wx_get_wap(struct net_device *dev,

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#1022: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:1022:
+   struct iw_request_info *info,

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#1023: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:1023:
+   union iwreq_data *wrqu, char *extra)

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#1024: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:1024:
+{

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#1031: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:1031:
+   memset(wrqu->ap_addr.sa_data, 0, ETH_ALEN);

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#1039: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:1039:
+   else

WARNING: Prefer eth_zero_addr() over memset() if the second address is 0x00
#1040: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:1040:
+   memset(wrqu->ap_addr.sa_data, 0, ETH_ALEN);

WARNING: Prefer eth_broadcast_addr() over memset() if the second address is 0xff
#1908: FILE: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:1908:
+   memset(param->sta_addr, 0xff, ETH_ALEN);



-- 
Kind Regards,
Aya Saif El-yazal Mahfouz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] f2fs: fix recover orphan inodes

2015-02-24 Thread Wanpeng Li
recover_orphan_inodes is used to recover orphan inodes, the meta pages 
which readahead should be orphan_blkaddr - start_blk instead of orphan_blkaddr.
This patch fix it.

Signed-off-by: Wanpeng Li 
---
 fs/f2fs/checkpoint.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index e6c271f..0f42ff3 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -468,9 +468,9 @@ void recover_orphan_inodes(struct f2fs_sb_info *sbi)
le32_to_cpu(F2FS_RAW_SUPER(sbi)->cp_payload);
orphan_blkaddr = __start_sum_addr(sbi) - 1;
 
-   ra_meta_pages(sbi, start_blk, orphan_blkaddr, META_CP);
+   ra_meta_pages(sbi, start_blk, orphan_blkaddr - start_blk, META_CP);
 
-   for (i = 0; i < orphan_blkaddr; i++) {
+   for (i = 0; i < orphan_blkaddr - start_blk; i++) {
struct page *page = get_meta_page(sbi, start_blk + i);
struct f2fs_orphan_block *orphan_blk;
 
-- 
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 v2] scripts: checkpatch.pl: add 2 new checks on memset calls

2015-02-24 Thread Joe Perches
On Wed, 2015-02-25 at 06:35 +0200, Aya Mahfouz wrote:
> On Tue, Feb 24, 2015 at 07:10:52PM -0800, Joe Perches wrote:
> > On Wed, 2015-02-25 at 04:40 +0200, Aya Mahfouz wrote:
> > > This patch adds 2 new checks on memset calls in the file
> > > checkpatch.pl as follows:
[]
> ok, I didn't see your suggestion, sorry.

No worries.

> Can you look at the following
> modification before sending the third patch? I don't use $stat because
> I get false positives with it.

Please describe the false positives.


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


[PATCH RESEND v2] sched/deadline: fix rt runtime corrupt when dl refuse a smaller bandwidth

2015-02-24 Thread Wanpeng Li
Dl class will refuse the bandwidth being set to some value smaller
than the currently allocated bandwidth in any of the root_domains
through sched_rt_runtime_us and sched_rt_period_us. RT runtime will
be set according to sched_rt_runtime_us before dl class verify if
the new bandwidth is suitable in the case of !CONFIG_RT_GROUP_SCHED.

However, rt runtime will be corrupt if dl refuse the new bandwidth
since there is no undo to reset the rt runtime to the old value.

This patch fix it by verifying new bandwidth for deadline in advance.

Cc: Juri Lelli 
Signed-off-by: Wanpeng Li 
---
v1 -> v2:
 * move sched_dl_global_constraints before sched_rt_global_constraints,
   and change the name of the former to sched_dl_global_validate().

 kernel/sched/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 97fe79c..e884909 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7815,7 +7815,7 @@ static int sched_rt_global_constraints(void)
 }
 #endif /* CONFIG_RT_GROUP_SCHED */
 
-static int sched_dl_global_constraints(void)
+static int sched_dl_global_validate(void)
 {
u64 runtime = global_rt_runtime();
u64 period = global_rt_period();
@@ -7916,11 +7916,11 @@ int sched_rt_handler(struct ctl_table *table, int write,
if (ret)
goto undo;
 
-   ret = sched_rt_global_constraints();
+   ret = sched_dl_global_validate();
if (ret)
goto undo;
 
-   ret = sched_dl_global_constraints();
+   ret = sched_rt_global_constraints();
if (ret)
goto undo;
 
-- 
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 Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

2015-02-24 Thread viresh kumar
On Wednesday 25 February 2015 08:54 AM, Ethan Zhao wrote:
> Viresh,
>   With this patch applied, still got the following warning and panic,
> seems it needs more care.
> 
>  54.474618] [ cut here ]
> [   54.545816] WARNING: CPU: 0 PID: 213 at include/linux/kref.h:47
> kobject_get+0x41/0x50()
> [   54.642595] Modules linked in: i2c_i801(+) mfd_core shpchp(+)
> acpi_cpufreq(+) edac_core ioatdma(+) xfs libcrc32c ast syscopyarea ixgbe
> sysfillrect sysimgblt sr_mod sd_mod drm_kms_helper igb mdio cdrom e1000e ahci
> dca ttm libahci uas drm i2c_algo_bit ptp megaraid_sas libata usb_storage
> i2c_core pps_core dm_mirror dm_region_hash dm_log dm_mod
> [   55.007264] CPU: 0 PID: 213 Comm: kworker/0:2 Not tainted
> 3.18.5
> [   55.099970] Hardware name: Oracle Corporation SUN FIRE X4170 M2 SERVER
>/ASSY,MOTHERBOARD,X4170, BIOS 08120104 05/08/2012
> [   55.239736] Workqueue: kacpi_notify acpi_os_execute_deferred
> [   55.308598]   bd730b61 88046742baf8
> 816b7edb
> [   55.398305]    88046742bb38
> 81078ae1
> [   55.488040]  88046742bbd8 8806706b3000 0292
> 
> [   55.56] Call Trace:
> [   55.608228]  [] dump_stack+0x46/0x58
> [   55.670895]  [] warn_slowpath_common+0x81/0xa0
> [   55.743952]  [] warn_slowpath_null+0x1a/0x20
> [   55.814929]  [] kobject_get+0x41/0x50
> [   55.878654]  [] cpufreq_cpu_get+0x75/0xc0
> [   55.946528]  [] cpufreq_update_policy+0x2e/0x1f0
> [   56.021682]  [] ? up+0x32/0x50
> [   56.078126]  [] ? acpi_ns_get_node+0xcb/0xf2
> [   56.148974]  [] ? acpi_evaluate_object+0x22c/0x252
> [   56.226066]  [] ? acpi_get_handle+0x95/0xc0
> [   56.295871]  [] ? acpi_has_method+0x25/0x40
> [   56.365661]  [] acpi_processor_ppc_has_changed+0x77/0x82
> [   56.448956]  [] ? move_linked_works+0x66/0x90
> [   56.520842]  [] acpi_processor_notify+0x58/0xe7
> [   56.594807]  [] acpi_ev_notify_dispatch+0x44/0x5c
> [   56.670859]  [] acpi_os_execute_deferred+0x15/0x22
> [   56.747936]  [] process_one_work+0x14e/0x3f0
> [   56.818766]  [] worker_thread+0x11b/0x4d0
> [   56.886486]  [] ? rescuer_thread+0x350/0x350
> [   56.957316]  [] kthread+0xe1/0x100
> [   57.017742]  [] ? kthread_create_on_node+0x1b0/0x1b0
> [   57.096903]  [] ret_from_fork+0x7c/0xb0
> [   57.162534]  [] ? kthread_create_on_node+0x1b0/0x1b0
> [   57.241680] ---[ end trace dce06bb76f547de5 ]---
> 
> 
> Any idea ?

No. Santosh reported this to me few days back, I asked him to perform some
testing but don't know what happened after that..

Can you give me full kernel logs along with the crash after this patch.
You will be required to do some testing this time as I don't have any clue
about the problem..


diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b4375021238f..230a59d2e0d7 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -214,8 +214,10 @@ struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
if (cpufreq_driver) {
/* get the CPU */
policy = per_cpu(cpufreq_cpu_data, cpu);
-   if (policy)
+   if (policy) {
kobject_get(>kobj);
+   pr_info("%s: %d", __func__, 
atomic_read(>kobj.kref.refcount));
+   }
}

read_unlock_irqrestore(_driver_lock, flags);
@@ -233,6 +235,7 @@ void cpufreq_cpu_put(struct cpufreq_policy *policy)
return;

kobject_put(>kobj);
+   pr_info("%s: %d", __func__, atomic_read(>kobj.kref.refcount));
up_read(_rwsem);
 }
 EXPORT_SYMBOL_GPL(cpufreq_cpu_put);

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


Re: [PATCH v2] scripts: checkpatch.pl: add 2 new checks on memset calls

2015-02-24 Thread Aya Mahfouz
On Tue, Feb 24, 2015 at 07:10:52PM -0800, Joe Perches wrote:
> On Wed, 2015-02-25 at 04:40 +0200, Aya Mahfouz wrote:
> > This patch adds 2 new checks on memset calls in the file
> > checkpatch.pl as follows:
> > 
> > replace memset by eth_zero_addr if the second argument is
> > an address of zeros (0x00). eth_zero_addr is a wrapper function
> > for memset that takes an address array to set as zero. The size
> > address has to be ETH_ALEN.
> 
> []
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
> > @@ -4901,10 +4901,22 @@ sub process {
> >  
> > if ($ms_size =~ /^(0x|)0$/i) {
> > ERROR("MEMSET",
> > - "memset to 0's uses 0 as the 2nd 
> > argument, not the 3rd\n" . "$here\n$stat\n");
> > + "memset to 0's uses 0 as the 2nd 
> > argument, not the 3rd\n" . "$here\n$line\n");
> > } elsif ($ms_size =~ /^(0x|)1$/i) {
> > WARN("MEMSET",
> > -"single byte memset is suspicious. Swapped 
> > 2nd/3rd argument?\n" . "$here\n$stat\n");
> > +"single byte memset is suspicious. Swapped 
> > 2nd/3rd argument?\n" . "$here\n$line\n");
> > +   } elsif ($ms_size =~ /^ETH_ALEN/i) {
> > +   if ($ms_val =~ /^0x00/i && 
> > WARN("PREFER_ETH_ZERO_ADDR",
> 
> This isn't right.  Look again at what I suggested.
> 
> This would match 0x00ff and wouldn't match 0
> 
> > +"Prefer eth_zero_addr() over memset() 
> > if the second address is 0x00\n" . $herecurr) &&
> > +   $fix) {
> > +
> > +   $fixed[$fixlinenr] =~ 
> > s/\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*ETH_ALEN\s*\)/eth_zero_addr($ms_addr)/;
> > +   } elsif ($ms_val =~ /^0xff/i && 
> > WARN("PREFER_ETH_BROADCAST_ADDR",
> > +"Prefer eth_broadcast_addr() over 
> > memset() if the second address is 0xff\n" . $herecurr) &&
> > +   $fix) {
> > +
> > +   $fixed[$fixlinenr] =~ 
> > s/\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*ETH_ALEN\s*\)/eth_broadcast_addr($ms_addr)/;
> > +   }
> > }
> > }
> >  
> 
> 
>

ok, I didn't see your suggestion, sorry. Can you look at the following
modification before sending the third patch? I don't use $stat because
I get false positives with it.

#check for misused memsets
if ($^V && $^V ge 5.10.0 &&
$line =~ 
/^\+(?:.*?)\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*$FuncArg\s*\)/s) {

my $ms_addr = $2;
my $ms_val = $7;
my $ms_size = $12;

if ($ms_val =~ /^(?:0|0x0+)$/i &&
$ms_size =~ /^ETH_ALEN$/ &&
WARN("PREFER_ETH_ADDR_FUNC",
 "Prefer eth_zero_addr() over memset() if the 
second address is 0x00\n" . $herecurr) &&
$fix) {
$fixed[$fixlinenr] =~ 
s/\bmemcpy\s*\(\s*\Q$ms_addr\E\s*,\s*\Q$ms_val\E\s*\,\s*ETH_ALEN\s*\)/eth_zero_addr($ms_addr)/;
} elsif ($ms_val =~ /^(?:0xff|255)$/i &&
 $ms_size =~ /^ETH_ALEN$/ &&
 WARN("PREFER_ETH_ADDR_FUNC",
  "Prefer eth_broadcast_addr() over 
memset() if the second address is 0xff\n" . $herecurr) &&
 $fix) {
$fixed[$fixlinenr] =~ 
s/\bmemcpy\s*\(\s*\Q$ms_addr\E\s*,\s*\Q$ms_val\E\s*\,\s*ETH_ALEN\s*\)/eth_broadcast_addr($ms_addr)/;
} elsif ($ms_size =~ /^(0x|)0$/i) {
ERROR("MEMSET",
  "memset to 0's uses 0 as the 2nd 
argument, not the 3rd\n" . "$here\n$line\n");
} elsif ($ms_size =~ /^(0x|)1$/i) {
WARN("MEMSET",
 "single byte memset is suspicious. Swapped 
2nd/3rd argument?\n" . "$here\n$line\n");
}
}

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


[PATCH] README: Update version number reference

2015-02-24 Thread Jeff Kirsher
When 4.0 is released, the README should reflect the new numbering.

Signed-off-by: Jeff Kirsher 
---
 README | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

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

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


Re: [PATCH] kernel/module.c: fix typos in message about unused symbols

2015-02-24 Thread Rusty Russell
Yannick Guerrini  writes:
> Fix typos in pr_warn message about unused symbols
>
> Signed-off-by: Yannick Guerrini 

Thanks.  AFAICT you changed "evalute" to "evaluate", "mainlinglist" to
"mailing list" and added a "to".

Applied,
Rusty.

> ---
>  kernel/module.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index b34813f..7441733 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -388,9 +388,9 @@ static bool check_symbol(const struct symsearch *syms,
>   pr_warn("Symbol %s is marked as UNUSED, however this module is "
>   "using it.\n", fsa->name);
>   pr_warn("This symbol will go away in the future.\n");
> - pr_warn("Please evalute if this is the right api to use and if "
> - "it really is, submit a report the linux kernel "
> - "mailinglist together with submitting your code for "
> + pr_warn("Please evaluate if this is the right api to use and "
> + "if it really is, submit a report to the linux kernel "
> + "mailing list together with submitting your code for "
>   "inclusion.\n");
>   }
>  #endif
> -- 
> 1.9.5.msysgit.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [PATCH v10 10/12] xfstests: fsstress: Add fallocate insert range operation

2015-02-24 Thread Namjae Jeon

> On Sun, Feb 22, 2015 at 12:45:52AM +0900, Namjae Jeon wrote:
> > From: Namjae Jeon 
> >
> > This commit adds insert operation support for fsstress, which is
> > meant to exercise fallocate FALLOC_FL_INSERT_RANGE support.
> 
> This causes xfs/068 to fail because it changes the file creation
> pattern that results from a specific fsstress random seed. As such,
> I added this to xfs/068:
> 
> FSSTRESS_AVOID="-f insert=0 $FSSTRESS_AVOID"
> 
> To turn off the insert operation for that test and hence produce the
> expected tree of files.
Thanks for your notice :) I will check other TCs as well as insert range
TC next time.
> 
> Cheers,
> 
> Dave.
> --
> Dave Chinner
> da...@fromorbit.com

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


Re: [PATCH v6 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save

2015-02-24 Thread Vignesh R
Hi,

On Thursday 05 February 2015 11:51 AM, Vignesh R wrote:
> 
> 
> On Wednesday 21 January 2015 03:44 PM, Vignesh R wrote:
>> On Tuesday 20 January 2015 09:34 PM, Lee Jones wrote:
>>> On Tue, 20 Jan 2015, R, Vignesh wrote:
 On 1/20/2015 5:23 PM, Lee Jones wrote:
> On Wed, 07 Jan 2015, Vignesh R wrote:
>
>> In one shot mode, sequencer automatically disables all enabled steps at
>> the end of each cycle. (both ADC steps and TSC steps) Hence these steps
>> need not be saved in reg_se_cache for clearing these steps at a later
>> stage.
>> Also, when ADC wakes up Sequencer should not be busy executing any of the
>> config steps except for the charge step. Previously charge step was 1 ADC
>> clock cycle and hence it was ignored.
>> TSC steps are always disabled at the end of each conversion cycle, hence
>> there is no need to explicitly disable TSC steps by writing 0 to REG_SE.
>>
>> Signed-off-by: Vignesh R 
>> ---
>>
>> v5:
>>  - Remove unnecessary clearing of REG_SE
>>
>>  drivers/mfd/ti_am335x_tscadc.c   | 13 +
>>  include/linux/mfd/ti_am335x_tscadc.h |  1 +
>>  2 files changed, 6 insertions(+), 8 deletions(-)
>
> Looks fine.
>
> For my own reference:
>   Acked-by: Lee Jones 
>
> Can this patch be applied on its own?
>

 I prefer to wait until input patches are picked up.
>>>
>>> I have no problem with that, but is there a technical reason why?
>>>
>>
>> Nothing, in particular. This patch alone has no impact on the
>> performance of TSC/ADC unit. Patch 2/6 is necessary to observe the
>> changes caused by this series. Hence, please wait until those patches
>> are picked up.
> 
> Input maintainer has applied other patches. You can pick this one.

Gentle ping... Can you pull this patch into 4.0-rc? Other patches of
this series are already in mainline.

Regards
Vignesh

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


[PATCH 3/7] clk: pistachio: Add PLL driver

2015-02-24 Thread Andrew Bresticker
Add a driver for the integer (GF40LP_LAINT) and fractional (GF40LP_FRAC)
PLLs present on Pistachio.

Signed-off-by: Andrew Bresticker 
---
 drivers/clk/pistachio/Makefile  |   1 +
 drivers/clk/pistachio/clk-pll.c | 401 
 drivers/clk/pistachio/clk.h |  50 +
 3 files changed, 452 insertions(+)
 create mode 100644 drivers/clk/pistachio/clk-pll.c

diff --git a/drivers/clk/pistachio/Makefile b/drivers/clk/pistachio/Makefile
index fc216ad..a93490d 100644
--- a/drivers/clk/pistachio/Makefile
+++ b/drivers/clk/pistachio/Makefile
@@ -1 +1,2 @@
 obj-y  += clk.o
+obj-y  += clk-pll.o
diff --git a/drivers/clk/pistachio/clk-pll.c b/drivers/clk/pistachio/clk-pll.c
new file mode 100644
index 000..de53756
--- /dev/null
+++ b/drivers/clk/pistachio/clk-pll.c
@@ -0,0 +1,401 @@
+/*
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+#define PLL_STATUS 0x0
+#define PLL_STATUS_LOCKBIT(0)
+
+#define PLL_CTRL1  0x4
+#define PLL_CTRL1_REFDIV_SHIFT 0
+#define PLL_CTRL1_REFDIV_MASK  0x3f
+#define PLL_CTRL1_FBDIV_SHIFT  6
+#define PLL_CTRL1_FBDIV_MASK   0xfff
+#define PLL_INT_CTRL1_POSTDIV1_SHIFT   18
+#define PLL_INT_CTRL1_POSTDIV1_MASK0x7
+#define PLL_INT_CTRL1_POSTDIV2_SHIFT   21
+#define PLL_INT_CTRL1_POSTDIV2_MASK0x7
+#define PLL_INT_CTRL1_PD   BIT(24)
+#define PLL_INT_CTRL1_DSMPDBIT(25)
+#define PLL_INT_CTRL1_FOUTPOSTDIVPDBIT(26)
+#define PLL_INT_CTRL1_FOUTVCOPDBIT(27)
+
+#define PLL_CTRL2  0x8
+#define PLL_FRAC_CTRL2_FRAC_SHIFT  0
+#define PLL_FRAC_CTRL2_FRAC_MASK   0xff
+#define PLL_FRAC_CTRL2_POSTDIV1_SHIFT  24
+#define PLL_FRAC_CTRL2_POSTDIV1_MASK   0x7
+#define PLL_FRAC_CTRL2_POSTDIV2_SHIFT  27
+#define PLL_FRAC_CTRL2_POSTDIV2_MASK   0x7
+#define PLL_INT_CTRL2_BYPASS   BIT(28)
+
+#define PLL_CTRL3  0xc
+#define PLL_FRAC_CTRL3_PD  BIT(0)
+#define PLL_FRAC_CTRL3_DACPD   BIT(1)
+#define PLL_FRAC_CTRL3_DSMPD   BIT(2)
+#define PLL_FRAC_CTRL3_FOUTPOSTDIVPD   BIT(3)
+#define PLL_FRAC_CTRL3_FOUT4PHASEPDBIT(4)
+#define PLL_FRAC_CTRL3_FOUTVCOPD   BIT(5)
+
+#define PLL_CTRL4  0x10
+#define PLL_FRAC_CTRL4_BYPASS  BIT(28)
+
+struct pistachio_clk_pll {
+   struct clk_hw hw;
+   void __iomem *base;
+   struct pistachio_pll_rate_table *rates;
+   unsigned int nr_rates;
+};
+
+static inline u32 pll_readl(struct pistachio_clk_pll *pll, u32 reg)
+{
+   return readl(pll->base + reg);
+}
+
+static inline void pll_writel(struct pistachio_clk_pll *pll, u32 val, u32 reg)
+{
+   writel(val, pll->base + reg);
+}
+
+static inline u32 do_div_round_closest(u64 dividend, u32 divisor)
+{
+   dividend += divisor / 2;
+   do_div(dividend, divisor);
+
+   return dividend;
+}
+
+static inline struct pistachio_clk_pll *to_pistachio_pll(struct clk_hw *hw)
+{
+   return container_of(hw, struct pistachio_clk_pll, hw);
+}
+
+static struct pistachio_pll_rate_table *
+pll_get_params(struct pistachio_clk_pll *pll, unsigned long fref,
+  unsigned long fout)
+{
+   unsigned int i;
+
+   for (i = 0; i < pll->nr_rates; i++) {
+   if (pll->rates[i].fref == fref && pll->rates[i].fout == fout)
+   return >rates[i];
+   }
+
+   return NULL;
+}
+
+static long pll_round_rate(struct clk_hw *hw, unsigned long rate,
+  unsigned long *parent_rate)
+{
+   struct pistachio_clk_pll *pll = to_pistachio_pll(hw);
+   unsigned int i;
+
+   for (i = 0; i < pll->nr_rates; i++) {
+   if (i > 0 && pll->rates[i].fref == *parent_rate &&
+   pll->rates[i].fout <= rate)
+   return pll->rates[i - 1].fout;
+   }
+
+   return pll->rates[0].fout;
+}
+
+static int pll_gf40lp_frac_enable(struct clk_hw *hw)
+{
+   struct pistachio_clk_pll *pll = to_pistachio_pll(hw);
+   u32 val;
+
+   val = pll_readl(pll, PLL_CTRL3);
+   val &= ~(PLL_FRAC_CTRL3_PD | PLL_FRAC_CTRL3_DACPD |
+PLL_FRAC_CTRL3_DSMPD | PLL_FRAC_CTRL3_FOUTPOSTDIVPD |
+PLL_FRAC_CTRL3_FOUT4PHASEPD | PLL_FRAC_CTRL3_FOUTVCOPD);
+   pll_writel(pll, val, PLL_CTRL3);
+
+   val = pll_readl(pll, PLL_CTRL4);
+   val &= ~PLL_FRAC_CTRL4_BYPASS;
+   pll_writel(pll, val, PLL_CTRL4);
+
+   return 0;
+}
+
+static void pll_gf40lp_frac_disable(struct clk_hw *hw)
+{
+   struct pistachio_clk_pll *pll = to_pistachio_pll(hw);
+   u32 val;
+
+   val = pll_readl(pll, PLL_CTRL3);
+   val |= PLL_FRAC_CTRL3_PD;
+   

[PATCH 2/7] clk: Add basic infrastructure for Pistachio clocks

2015-02-24 Thread Andrew Bresticker
Add helpers for registering clocks and clock providers on Pistachio.

Signed-off-by: Andrew Bresticker 
---
 drivers/clk/Makefile   |   1 +
 drivers/clk/pistachio/Makefile |   1 +
 drivers/clk/pistachio/clk.c| 140 +
 drivers/clk/pistachio/clk.h| 124 
 4 files changed, 266 insertions(+)
 create mode 100644 drivers/clk/pistachio/Makefile
 create mode 100644 drivers/clk/pistachio/clk.c
 create mode 100644 drivers/clk/pistachio/clk.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d478ceb..e43ff53 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_ARCH_MMP)+= mmp/
 endif
 obj-$(CONFIG_PLAT_ORION)   += mvebu/
 obj-$(CONFIG_ARCH_MXS) += mxs/
+obj-$(CONFIG_MACH_PISTACHIO)   += pistachio/
 obj-$(CONFIG_COMMON_CLK_PXA)   += pxa/
 obj-$(CONFIG_COMMON_CLK_QCOM)  += qcom/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
diff --git a/drivers/clk/pistachio/Makefile b/drivers/clk/pistachio/Makefile
new file mode 100644
index 000..fc216ad
--- /dev/null
+++ b/drivers/clk/pistachio/Makefile
@@ -0,0 +1 @@
+obj-y  += clk.o
diff --git a/drivers/clk/pistachio/clk.c b/drivers/clk/pistachio/clk.c
new file mode 100644
index 000..85faa83
--- /dev/null
+++ b/drivers/clk/pistachio/clk.c
@@ -0,0 +1,140 @@
+/*
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+struct pistachio_clk_provider *
+pistachio_clk_alloc_provider(struct device_node *node, unsigned int num_clks)
+{
+   struct pistachio_clk_provider *p;
+
+   p = kzalloc(sizeof(*p), GFP_KERNEL);
+   if (!p)
+   return p;
+
+   p->clk_data.clks = kcalloc(num_clks, sizeof(struct clk *), GFP_KERNEL);
+   if (!p->clk_data.clks)
+   goto free_provider;
+   p->clk_data.clk_num = num_clks;
+   p->node = node;
+   p->base = of_iomap(node, 0);
+   if (!p->base) {
+   pr_err("Failed to map clock provider registers\n");
+   goto free_clks;
+   }
+
+   return p;
+
+free_clks:
+   kfree(p->clk_data.clks);
+free_provider:
+   kfree(p);
+   return NULL;
+}
+
+void pistachio_clk_register_provider(struct pistachio_clk_provider *p)
+{
+   unsigned int i;
+
+   for (i = 0; i < p->clk_data.clk_num; i++) {
+   if (IS_ERR(p->clk_data.clks[i]))
+   pr_warn("Failed to register clock %d: %ld\n", i,
+   PTR_ERR(p->clk_data.clks[i]));
+   }
+
+   of_clk_add_provider(p->node, of_clk_src_onecell_get, >clk_data);
+}
+
+void pistachio_clk_register_gate(struct pistachio_clk_provider *p,
+struct pistachio_gate *gate,
+unsigned int num)
+{
+   struct clk *clk;
+   unsigned int i;
+
+   for (i = 0; i < num; i++) {
+   clk = clk_register_gate(NULL, gate[i].name, gate[i].parent,
+   CLK_SET_RATE_PARENT,
+   p->base + gate[i].reg, gate[i].shift,
+   0, NULL);
+   p->clk_data.clks[gate[i].id] = clk;
+   }
+}
+
+void pistachio_clk_register_mux(struct pistachio_clk_provider *p,
+   struct pistachio_mux *mux,
+   unsigned int num)
+{
+   struct clk *clk;
+   unsigned int i;
+
+   for (i = 0; i < num; i++) {
+   clk = clk_register_mux(NULL, mux[i].name, mux[i].parents,
+  mux[i].num_parents,
+  CLK_SET_RATE_NO_REPARENT,
+  p->base + mux[i].reg, mux[i].shift,
+  get_count_order(mux[i].num_parents),
+  0, NULL);
+   p->clk_data.clks[mux[i].id] = clk;
+   }
+}
+
+void pistachio_clk_register_div(struct pistachio_clk_provider *p,
+   struct pistachio_div *div,
+   unsigned int num)
+{
+   struct clk *clk;
+   unsigned int i;
+
+   for (i = 0; i < num; i++) {
+   clk = clk_register_divider(NULL, div[i].name, div[i].parent,
+  0, p->base + div[i].reg, 0,
+  div[i].width, div[i].div_flags,
+  NULL);
+   p->clk_data.clks[div[i].id] = clk;
+   }
+}
+
+void pistachio_clk_register_fixed_factor(struct pistachio_clk_provider *p,
+   

[PATCH 1/7] clk: Add binding document for Pistachio clock controllers

2015-02-24 Thread Andrew Bresticker
Add a device-tree binding document describing the four clock
controllers present on the IMG Pistachio SoC.

Signed-off-by: Damien Horsley 
Signed-off-by: Andrew Bresticker 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
---
 .../devicetree/bindings/clock/pistachio-clock.txt  | 123 ++
 include/dt-bindings/clock/pistachio-clk.h  | 183 +
 2 files changed, 306 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/pistachio-clock.txt
 create mode 100644 include/dt-bindings/clock/pistachio-clk.h

diff --git a/Documentation/devicetree/bindings/clock/pistachio-clock.txt 
b/Documentation/devicetree/bindings/clock/pistachio-clock.txt
new file mode 100644
index 000..868db49
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/pistachio-clock.txt
@@ -0,0 +1,123 @@
+Imagination Technologies Pistachio SoC clock controllers
+
+
+Pistachio has four clock controllers (core clock, peripheral clock, peripheral
+general control, and top general control) which are instantiated individually
+from the device-tree.
+
+External clocks:
+
+
+There are three external inputs to the clock controllers which should be
+defined with the following clock-output-names:
+- "xtal": External 52Mhz oscillator (required)
+- "audio_clk_in": Alternate audio reference clock (optional)
+- "enet_clk_in": Alternate ethernet PHY clock (optional)
+
+Core clock controller:
+--
+
+The core clock controller generates clocks for the CPU, RPU (WiFi + BT
+co-processor), audio, and several peripherals.
+
+Required properties:
+- compatible: Must be "img,pistachio-clk".
+- reg: Must contain the base address and length of the core clock controller.
+- #clock-cells: Must be 1.  The single cell is the clock identifier.
+  See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
+- clocks: Must contain an entry for each clock in clock-names.
+- clock-names: Must include "xtal" (see "External clocks") and
+  "audio_clk_in_gate", "enet_clk_in_gate" which are generated by the
+  top-level general control.
+
+Example:
+   clk_core: clock-controller@18144000 {
+   compatible = "img,pistachio-clk";
+   reg = <0x18144000 0x800>;
+   clocks = <>, <_top EXT_CLK_AUDIO_IN>,
+<_top EXT_CLK_ENET_IN>;
+   clock-names = "xtal", "audio_clk_in_gate", "enet_clk_in_gate";
+
+   #clock-cells = <1>;
+   };
+
+Peripheral clock controller:
+
+
+The peripheral clock controller generates clocks for the DDR, ROM, and other
+peripherals.  The peripheral system clock ("periph_sys") generated by the core
+clock controller is the input clock to the peripheral clock controller.
+
+Required properties:
+- compatible: Must be "img,pistachio-periph-clk".
+- reg: Must contain the base address and length of the peripheral clock
+  controller.
+- #clock-cells: Must be 1.  The single cell is the clock identifier.
+  See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
+- clocks: Must contain an entry for each clock in clock-names.
+- clock-names: Must include "periph_sys", the peripheral system clock generated
+  by the core clock controller.
+
+Example:
+   clk_periph: clock-controller@18144800 {
+   compatible = "img,pistachio-clk-periph";
+   reg = <0x18144800 0x800>;
+   clocks = <_core CLK_PERIPH_SYS>;
+   clock-names = "periph_sys";
+
+   #clock-cells = <1>;
+   };
+
+Peripheral general control:
+---
+
+The peripheral general control block generates system interface clocks and
+resets for various peripherals.  It also contains miscellaneous peripheral
+control registers.  The system clock ("sys") generated by the peripheral clock
+controller is the input clock to the system clock controller.
+
+Required properties:
+- compatible: Must include "img,pistachio-periph-cr" and "syscon".
+- reg: Must contain the base address and length of the peripheral general
+  control registers.
+- #clock-cells: Must be 1.  The single cell is the clock identifier.
+  See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
+- clocks: Must contain an entry for each clock in clock-names.
+- clock-names: Must include "sys", the system clock generated by the peripheral
+  clock controller.
+
+Example:
+   cr_periph: syscon@18144800 {
+   compatible = "img,pistachio-cr-periph", "syscon";
+   reg = <0x18148000 0x1000>;
+   clocks = <_periph PERIPH_CLK_PERIPH_SYS>;
+   clock-names = "sys";
+
+   #clock-cells = <1>;
+   };
+
+Top-level general control:
+--
+
+The top-level general control block contains miscellaneous control registers 
and
+gates for the external clocks 

[PATCH 4/7] clk: pistachio: Register core clocks

2015-02-24 Thread Andrew Bresticker
Register the clocks generated by the core clock controller.
This includes the 7 PLLs and clocks for the CPU, RPU co-processor,
audio, WiFi, bluetooth, and several other peripherals.

The MIPS and PERIPH_SYS clocks must remain enabled at all times.

Signed-off-by: Damien Horsley 
Signed-off-by: Andrew Bresticker 
---
 drivers/clk/pistachio/Makefile|   1 +
 drivers/clk/pistachio/clk-pistachio.c | 199 ++
 2 files changed, 200 insertions(+)
 create mode 100644 drivers/clk/pistachio/clk-pistachio.c

diff --git a/drivers/clk/pistachio/Makefile b/drivers/clk/pistachio/Makefile
index a93490d..f1e151f 100644
--- a/drivers/clk/pistachio/Makefile
+++ b/drivers/clk/pistachio/Makefile
@@ -1,2 +1,3 @@
 obj-y  += clk.o
 obj-y  += clk-pll.o
+obj-y  += clk-pistachio.o
diff --git a/drivers/clk/pistachio/clk-pistachio.c 
b/drivers/clk/pistachio/clk-pistachio.c
new file mode 100644
index 000..12a45e2
--- /dev/null
+++ b/drivers/clk/pistachio/clk-pistachio.c
@@ -0,0 +1,199 @@
+/*
+ * Pistachio SoC clock controllers
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk.h"
+
+static struct pistachio_gate pistachio_gates[] __initdata = {
+   GATE(CLK_MIPS, "mips", "mips_div", 0x104, 0),
+   GATE(CLK_AUDIO_IN, "audio_in", "audio_clk_in_gate", 0x104, 1),
+   GATE(CLK_AUDIO, "audio", "audio_div", 0x104, 2),
+   GATE(CLK_I2S, "i2s", "i2s_div", 0x104, 3),
+   GATE(CLK_SPDIF, "spdif", "spdif_div", 0x104, 4),
+   GATE(CLK_AUDIO_DAC, "audio_dac", "audio_dac_div", 0x104, 5),
+   GATE(CLK_RPU_V, "rpu_v", "rpu_v_div", 0x104, 6),
+   GATE(CLK_RPU_L, "rpu_l", "rpu_l_div", 0x104, 7),
+   GATE(CLK_RPU_SLEEP, "rpu_sleep", "rpu_sleep_div", 0x104, 8),
+   GATE(CLK_WIFI_PLL_GATE, "wifi_pll_gate", "wifi_pll_mux", 0x104, 9),
+   GATE(CLK_RPU_CORE, "rpu_core", "rpu_core_div", 0x104, 10),
+   GATE(CLK_WIFI_ADC, "wifi_adc", "wifi_div8_mux", 0x104, 11),
+   GATE(CLK_WIFI_DAC, "wifi_dac", "wifi_div4_mux", 0x104, 12),
+   GATE(CLK_USB_PHY, "usb_phy", "usb_phy_div", 0x104, 13),
+   GATE(CLK_ENET_IN, "enet_in", "enet_clk_in_gate", 0x104, 14),
+   GATE(CLK_ENET, "enet", "enet_div", 0x104, 15),
+   GATE(CLK_UART0, "uart0", "uart0_div", 0x104, 16),
+   GATE(CLK_UART1, "uart1", "uart1_div", 0x104, 17),
+   GATE(CLK_PERIPH_SYS, "periph_sys", "sys_internal_div", 0x104, 18),
+   GATE(CLK_SPI0, "spi0", "spi0_div", 0x104, 19),
+   GATE(CLK_SPI1, "spi1", "spi1_div", 0x104, 20),
+   GATE(CLK_EVENT_TIMER, "event_timer", "event_timer_div", 0x104, 21),
+   GATE(CLK_AUX_ADC_INTERNAL, "aux_adc_internal", "sys_internal_div",
+0x104, 22),
+   GATE(CLK_AUX_ADC, "aux_adc", "aux_adc_div", 0x104, 23),
+   GATE(CLK_SD_HOST, "sd_host", "sd_host_div", 0x104, 24),
+   GATE(CLK_BT, "bt", "bt_div", 0x104, 25),
+   GATE(CLK_BT_DIV4, "bt_div4", "bt_div4_div", 0x104, 26),
+   GATE(CLK_BT_DIV8, "bt_div8", "bt_div8_div", 0x104, 27),
+   GATE(CLK_BT_1MHZ, "bt_1mhz", "bt_1mhz_div", 0x104, 28),
+};
+
+static struct pistachio_fixed_factor pistachio_ffs[] __initdata = {
+   FIXED_FACTOR(CLK_WIFI_DIV4, "wifi_div4", "wifi_pll", 4),
+   FIXED_FACTOR(CLK_WIFI_DIV8, "wifi_div8", "wifi_pll", 8),
+};
+
+static struct pistachio_div pistachio_divs[] __initdata = {
+   DIV(CLK_MIPS_INTERNAL_DIV, "mips_internal_div", "mips_pll_mux",
+   0x204, 2),
+   DIV(CLK_MIPS_DIV, "mips_div", "mips_internal_div", 0x208, 8),
+   DIV_F(CLK_AUDIO_DIV, "audio_div", "audio_mux",
+   0x20c, 8, CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(CLK_I2S_DIV, "i2s_div", "audio_pll_mux",
+   0x210, 8, CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(CLK_SPDIF_DIV, "spdif_div", "audio_pll_mux",
+   0x214, 8, CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(CLK_AUDIO_DAC_DIV, "audio_dac_div", "audio_pll_mux",
+   0x218, 8, CLK_DIVIDER_ROUND_CLOSEST),
+   DIV(CLK_RPU_V_DIV, "rpu_v_div", "rpu_v_pll_mux", 0x21c, 2),
+   DIV(CLK_RPU_L_DIV, "rpu_l_div", "rpu_l_mux", 0x220, 2),
+   DIV(CLK_RPU_SLEEP_DIV, "rpu_sleep_div", "xtal", 0x224, 10),
+   DIV(CLK_RPU_CORE_DIV, "rpu_core_div", "rpu_core_mux", 0x228, 3),
+   DIV(CLK_USB_PHY_DIV, "usb_phy_div", "sys_internal_div", 0x22c, 6),
+   DIV(CLK_ENET_DIV, "enet_div", "enet_mux", 0x230, 6),
+   DIV_F(CLK_UART0_INTERNAL_DIV, "uart0_internal_div", "sys_pll_mux",
+ 0x234, 3, CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(CLK_UART0_DIV, "uart0_div", "uart0_internal_div", 0x238, 10,
+ CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(CLK_UART1_INTERNAL_DIV, "uart1_internal_div", "sys_pll_mux",
+ 0x23c, 3, CLK_DIVIDER_ROUND_CLOSEST),
+   

[PATCH 5/7] clk: pistachio: Register peripheral clocks

2015-02-24 Thread Andrew Bresticker
Register the clocks generated by the peripheral clock controller.
This includes the clocks for several peripherals, including I2C,
PWM, watchdog, and timer.

Signed-off-by: Damien Horsley 
Signed-off-by: Andrew Bresticker 
---
 drivers/clk/pistachio/clk-pistachio.c | 67 +++
 1 file changed, 67 insertions(+)

diff --git a/drivers/clk/pistachio/clk-pistachio.c 
b/drivers/clk/pistachio/clk-pistachio.c
index 12a45e2..0eabb54 100644
--- a/drivers/clk/pistachio/clk-pistachio.c
+++ b/drivers/clk/pistachio/clk-pistachio.c
@@ -197,3 +197,70 @@ static void __init pistachio_clk_init(struct device_node 
*np)
   ARRAY_SIZE(pistachio_critical_clks));
 }
 CLK_OF_DECLARE(pistachio_clk, "img,pistachio-clk", pistachio_clk_init);
+
+static struct pistachio_gate pistachio_periph_gates[] __initdata = {
+   GATE(PERIPH_CLK_SYS, "sys", "periph_sys", 0x100, 0),
+   GATE(PERIPH_CLK_SYS_BUS, "bus_sys", "periph_sys", 0x100, 1),
+   GATE(PERIPH_CLK_DDR, "ddr", "periph_sys", 0x100, 2),
+   GATE(PERIPH_CLK_ROM, "rom", "rom_div", 0x100, 3),
+   GATE(PERIPH_CLK_COUNTER_FAST, "counter_fast", "counter_fast_div",
+0x100, 4),
+   GATE(PERIPH_CLK_COUNTER_SLOW, "counter_slow", "counter_slow_div",
+0x100, 5),
+   GATE(PERIPH_CLK_IR, "ir", "ir_div", 0x100, 6),
+   GATE(PERIPH_CLK_WD, "wd", "wd_div", 0x100, 7),
+   GATE(PERIPH_CLK_PDM, "pdm", "pdm_div", 0x100, 8),
+   GATE(PERIPH_CLK_PWM, "pwm", "pwm_div", 0x100, 9),
+   GATE(PERIPH_CLK_I2C0, "i2c0", "i2c0_div", 0x100, 10),
+   GATE(PERIPH_CLK_I2C1, "i2c1", "i2c1_div", 0x100, 11),
+   GATE(PERIPH_CLK_I2C2, "i2c2", "i2c2_div", 0x100, 12),
+   GATE(PERIPH_CLK_I2C3, "i2c3", "i2c3_div", 0x100, 13),
+};
+
+static struct pistachio_div pistachio_periph_divs[] __initdata = {
+   DIV(PERIPH_CLK_ROM_DIV, "rom_div", "periph_sys", 0x10c, 7),
+   DIV(PERIPH_CLK_COUNTER_FAST_DIV, "counter_fast_div", "periph_sys",
+   0x110, 7),
+   DIV(PERIPH_CLK_COUNTER_SLOW_PRE_DIV, "counter_slow_pre_div",
+   "periph_sys", 0x114, 7),
+   DIV(PERIPH_CLK_COUNTER_SLOW_DIV, "counter_slow_div",
+   "counter_slow_pre_div", 0x118, 7),
+   DIV_F(PERIPH_CLK_IR_PRE_DIV, "ir_pre_div", "periph_sys", 0x11c, 7,
+ CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(PERIPH_CLK_IR_DIV, "ir_div", "ir_pre_div", 0x120, 7,
+ CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(PERIPH_CLK_WD_PRE_DIV, "wd_pre_div", "periph_sys", 0x124, 7,
+ CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(PERIPH_CLK_WD_DIV, "wd_div", "wd_pre_div", 0x128, 7,
+ CLK_DIVIDER_ROUND_CLOSEST),
+   DIV(PERIPH_CLK_PDM_PRE_DIV, "pdm_pre_div", "periph_sys", 0x12c, 7),
+   DIV(PERIPH_CLK_PDM_DIV, "pdm_div", "pdm_pre_div", 0x130, 7),
+   DIV(PERIPH_CLK_PWM_PRE_DIV, "pwm_pre_div", "periph_sys", 0x134, 7),
+   DIV(PERIPH_CLK_PWM_DIV, "pwm_div", "pwm_pre_div", 0x138, 7),
+   DIV(PERIPH_CLK_I2C0_PRE_DIV, "i2c0_pre_div", "periph_sys", 0x13c, 7),
+   DIV(PERIPH_CLK_I2C0_DIV, "i2c0_div", "i2c0_pre_div", 0x140, 7),
+   DIV(PERIPH_CLK_I2C1_PRE_DIV, "i2c1_pre_div", "periph_sys", 0x144, 7),
+   DIV(PERIPH_CLK_I2C1_DIV, "i2c1_div", "i2c1_pre_div", 0x148, 7),
+   DIV(PERIPH_CLK_I2C2_PRE_DIV, "i2c2_pre_div", "periph_sys", 0x14c, 7),
+   DIV(PERIPH_CLK_I2C2_DIV, "i2c2_div", "i2c2_pre_div", 0x150, 7),
+   DIV(PERIPH_CLK_I2C3_PRE_DIV, "i2c3_pre_div", "periph_sys", 0x154, 7),
+   DIV(PERIPH_CLK_I2C3_DIV, "i2c3_div", "i2c3_pre_div", 0x158, 7),
+};
+
+static void __init pistachio_clk_periph_init(struct device_node *np)
+{
+   struct pistachio_clk_provider *p;
+
+   p = pistachio_clk_alloc_provider(np, PERIPH_CLK_NR_CLKS);
+   if (!p)
+   return;
+
+   pistachio_clk_register_div(p, pistachio_periph_divs,
+  ARRAY_SIZE(pistachio_periph_divs));
+   pistachio_clk_register_gate(p, pistachio_periph_gates,
+   ARRAY_SIZE(pistachio_periph_gates));
+
+   pistachio_clk_register_provider(p);
+}
+CLK_OF_DECLARE(pistachio_clk_periph, "img,pistachio-clk-periph",
+  pistachio_clk_periph_init);
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/7] clk: pistachio: Register system interface gate clocks

2015-02-24 Thread Andrew Bresticker
Register the system interface gate clocks provided by the peripheral
general control block.  These clocks gate register access for various
peripherals.

Signed-off-by: Damien Horsley 
Signed-off-by: Andrew Bresticker 
---
 drivers/clk/pistachio/clk-pistachio.c | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/drivers/clk/pistachio/clk-pistachio.c 
b/drivers/clk/pistachio/clk-pistachio.c
index 0eabb54..3351808 100644
--- a/drivers/clk/pistachio/clk-pistachio.c
+++ b/drivers/clk/pistachio/clk-pistachio.c
@@ -264,3 +264,45 @@ static void __init pistachio_clk_periph_init(struct 
device_node *np)
 }
 CLK_OF_DECLARE(pistachio_clk_periph, "img,pistachio-clk-periph",
   pistachio_clk_periph_init);
+
+static struct pistachio_gate pistachio_sys_gates[] __initdata = {
+   GATE(SYS_CLK_I2C0, "i2c0_sys", "sys", 0x8, 0),
+   GATE(SYS_CLK_I2C1, "i2c1_sys", "sys", 0x8, 1),
+   GATE(SYS_CLK_I2C2, "i2c2_sys", "sys", 0x8, 2),
+   GATE(SYS_CLK_I2C3, "i2c3_sys", "sys", 0x8, 3),
+   GATE(SYS_CLK_I2S_IN, "i2s_in_sys", "sys", 0x8, 4),
+   GATE(SYS_CLK_PAUD_OUT, "paud_out_sys", "sys", 0x8, 5),
+   GATE(SYS_CLK_SPDIF_OUT, "spdif_out_sys", "sys", 0x8, 6),
+   GATE(SYS_CLK_SPI0_MASTER, "spi0_master_sys", "sys", 0x8, 7),
+   GATE(SYS_CLK_SPI0_SLAVE, "spi0_slave_sys", "sys", 0x8, 8),
+   GATE(SYS_CLK_PWM, "pwm_sys", "sys", 0x8, 9),
+   GATE(SYS_CLK_UART0, "uart0_sys", "sys", 0x8, 10),
+   GATE(SYS_CLK_UART1, "uart1_sys", "sys", 0x8, 11),
+   GATE(SYS_CLK_SPI1, "spi1_sys", "sys", 0x8, 12),
+   GATE(SYS_CLK_MDC, "mdc_sys", "sys", 0x8, 13),
+   GATE(SYS_CLK_SD_HOST, "sd_host_sys", "sys", 0x8, 14),
+   GATE(SYS_CLK_ENET, "enet_sys", "sys", 0x8, 15),
+   GATE(SYS_CLK_IR, "ir_sys", "sys", 0x8, 16),
+   GATE(SYS_CLK_WD, "wd_sys", "sys", 0x8, 17),
+   GATE(SYS_CLK_TIMER, "timer_sys", "sys", 0x8, 18),
+   GATE(SYS_CLK_I2S_OUT, "i2s_out_sys", "sys", 0x8, 24),
+   GATE(SYS_CLK_SPDIF_IN, "spdif_in_sys", "sys", 0x8, 25),
+   GATE(SYS_CLK_EVENT_TIMER, "event_timer_sys", "sys", 0x8, 26),
+   GATE(SYS_CLK_HASH, "hash_sys", "sys", 0x8, 27),
+};
+
+static void __init pistachio_cr_periph_init(struct device_node *np)
+{
+   struct pistachio_clk_provider *p;
+
+   p = pistachio_clk_alloc_provider(np, SYS_CLK_NR_CLKS);
+   if (!p)
+   return;
+
+   pistachio_clk_register_gate(p, pistachio_sys_gates,
+   ARRAY_SIZE(pistachio_sys_gates));
+
+   pistachio_clk_register_provider(p);
+}
+CLK_OF_DECLARE(pistachio_cr_periph, "img,pistachio-cr-periph",
+  pistachio_cr_periph_init);
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/7] clk: pistachio: Register external clock gates

2015-02-24 Thread Andrew Bresticker
Register the clock gates for the external audio and ethernet
reference clocks provided by the top-level general control block.

Signed-off-by: Damien Horsley 
Signed-off-by: Andrew Bresticker 
---
 drivers/clk/pistachio/clk-pistachio.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/clk/pistachio/clk-pistachio.c 
b/drivers/clk/pistachio/clk-pistachio.c
index 3351808..8c0fe88 100644
--- a/drivers/clk/pistachio/clk-pistachio.c
+++ b/drivers/clk/pistachio/clk-pistachio.c
@@ -306,3 +306,24 @@ static void __init pistachio_cr_periph_init(struct 
device_node *np)
 }
 CLK_OF_DECLARE(pistachio_cr_periph, "img,pistachio-cr-periph",
   pistachio_cr_periph_init);
+
+static struct pistachio_gate pistachio_ext_gates[] __initdata = {
+   GATE(EXT_CLK_ENET_IN, "enet_clk_in_gate", "enet_clk_in", 0x58, 5),
+   GATE(EXT_CLK_AUDIO_IN, "audio_clk_in_gate", "audio_clk_in", 0x58, 8)
+};
+
+static void __init pistachio_cr_top_init(struct device_node *np)
+{
+   struct pistachio_clk_provider *p;
+
+   p = pistachio_clk_alloc_provider(np, EXT_CLK_NR_CLKS);
+   if (!p)
+   return;
+
+   pistachio_clk_register_gate(p, pistachio_ext_gates,
+   ARRAY_SIZE(pistachio_ext_gates));
+
+   pistachio_clk_register_provider(p);
+}
+CLK_OF_DECLARE(pistachio_cr_top, "img,pistachio-cr-top",
+  pistachio_cr_top_init);
-- 
2.2.0.rc0.207.ga3a616c

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


[PATCH 0/7] clk: Common clock support for IMG Pistachio

2015-02-24 Thread Andrew Bresticker
This series adds common clock support for the IMG Pistachio SoC.
Pistachio has two clock controllers (core and peripheral) and two
general control blocks (peripheral and top) which also contain
several clock gates.  Like the recently submitted pinctrl driver [1],
this driver is written so that it's hopefully easy to add support
for future IMG SoCs.

Tested on an IMG Pistachio BuB.  Based on 4.0-rc1 + my series adding
Pistachio platform support [2], which introduces the MACH_PISTACHIO
Kconfig symbol.  A branch with this series and the dependent patches
is available at [3].  I'd like this to go through the MIPS tree with
Mike's or Stephen's ACK if possible.

Cc: Ezequiel Garcia 
Cc: James Hartley 
Cc: James Hogan 

[1] https://lkml.org/lkml/2015/2/23/705
[2] https://lkml.org/lkml/2015/2/23/694
[3] https://github.com/abrestic/linux/tree/pistachio-clk-v1

Andrew Bresticker (7):
  clk: Add binding document for Pistachio clock controllers
  clk: Add basic infrastructure for Pistachio clocks
  clk: pistachio: Add PLL driver
  clk: pistachio: Register core clocks
  clk: pistachio: Register peripheral clocks
  clk: pistachio: Register system interface gate clocks
  clk: pistachio: Register external clock gates

 .../devicetree/bindings/clock/pistachio-clock.txt  | 123 +++
 drivers/clk/Makefile   |   1 +
 drivers/clk/pistachio/Makefile |   3 +
 drivers/clk/pistachio/clk-pistachio.c  | 329 +
 drivers/clk/pistachio/clk-pll.c| 401 +
 drivers/clk/pistachio/clk.c| 140 +++
 drivers/clk/pistachio/clk.h| 174 +
 include/dt-bindings/clock/pistachio-clk.h  | 183 ++
 8 files changed, 1354 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/pistachio-clock.txt
 create mode 100644 drivers/clk/pistachio/Makefile
 create mode 100644 drivers/clk/pistachio/clk-pistachio.c
 create mode 100644 drivers/clk/pistachio/clk-pll.c
 create mode 100644 drivers/clk/pistachio/clk.c
 create mode 100644 drivers/clk/pistachio/clk.h
 create mode 100644 include/dt-bindings/clock/pistachio-clk.h

-- 
2.2.0.rc0.207.ga3a616c

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


Re: [patch v2] sunrpc: integer underflow in rsc_parse()

2015-02-24 Thread Simo Sorce
On Tue, 2015-02-24 at 18:34 +0300, Dan Carpenter wrote:
> If we call groups_alloc() with invalid values then it's might lead to
> memory corruption.  For example, with a negative value then we might not
> allocate enough for sizeof(struct group_info).
> 
> Signed-off-by: Dan Carpenter 
> ---
> v2:  In v1, I changed groups_alloc().  The other places which call
> groups_alloc() check the value before calling.  Eric wanted that, either
> have all the callers check, or all the callers rely on groups_alloc().
> In the end, Bruce Fields said adding the check here was probably
> reasonable.
> 
> diff --git a/net/sunrpc/auth_gss/svcauth_gss.c 
> b/net/sunrpc/auth_gss/svcauth_gss.c
> index 224a82f..1095be9 100644
> --- a/net/sunrpc/auth_gss/svcauth_gss.c
> +++ b/net/sunrpc/auth_gss/svcauth_gss.c
> @@ -463,6 +463,8 @@ static int rsc_parse(struct cache_detail *cd,
>   /* number of additional gid's */
>   if (get_int(, ))
>   goto out;
> + if (N < 0 || N > NGROUPS_MAX)
> + goto out;
>   status = -ENOMEM;
>   rsci.cred.cr_group_info = groups_alloc(N);
>   if (rsci.cred.cr_group_info == NULL)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I touched this code relatively recently, and this check looks correct.
Feel free to add Reviewed-by: Simo Sorce 

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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


linux-next: Tree for Feb 25

2015-02-24 Thread Stephen Rothwell
Hi all,

Changes since 20150224:

The drm-intel tree gained a conflict against the drm-intel-fixes tree.

The drm-misc tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1506
 1173 files changed, 30443 insertions(+), 30102 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (b24e2bdde4af Merge tag 'stable/for-linus-4.0-rc1-tag' of 
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the 
debian/ directory)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (23be7fdafa50 ARM: 8305/1: DMA: Fix kzalloc flags in 
__iommu_alloc_buffer())
Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet 
bridging)
Merging metag-fixes/fixes (c2996cb29bfb metag: Fix KSTK_EIP() and KSTK_ESP() 
macros)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused 
force_32bit_msi quirk)
Merging powerpc-merge-mpe/fixes (c59c961ca511 Merge branch 'drm-fixes' of 
git://people.freedesktop.org/~airlied/linux)
Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() 
needs to disable interrupts.)
Merging net/master (5c2d2b148b35 r8169: Fix trivial typo in rtl_check_firmware)
Merging ipsec/master (ac37e2515c1a xfrm: release dst_orig in case of error in 
xfrm_lookup())
Merging sound-current/for-linus (37ed398839fa ALSA: hda: controller code - do 
not export static functions)
Merging pci-current/for-linus (c517d838eb7d Linux 4.0-rc1)
Merging wireless-drivers/master (aeb2d2a4c0ae rtlwifi: Remove logging statement 
that is no longer needed)
Merging driver-core.current/driver-core-linus (c517d838eb7d Linux 4.0-rc1)
Merging tty.current/tty-linus (c517d838eb7d Linux 4.0-rc1)
Merging usb.current/usb-linus (b20b1618b8fc cdc-acm: Add support for Denso 
cradle CU-321)
Merging usb-gadget-fixes/fixes (a0456399fb07 usb: gadget: configfs: don't 
NUL-terminate (sub)compatible ids)
Merging usb-serial-fixes/usb-linus (a6f0331236fa USB: cp210x: add ID for 
RUGGEDCOM USB Serial Console)
Merging staging.current/staging-linus (c517d838eb7d Linux 4.0-rc1)
Merging char-misc.current/char-misc-linus (c517d838eb7d Linux 4.0-rc1)
Merging input-current/for-linus (4c971aa78314 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (96692a7305c4 crypto: tcrypt - do not allocate iv 
on stack for aead speed tests)
Merging ide/master (f96fe225677b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays 
with sub-devices tests)
Merging rr-fixes/fixes (f47689345931 lguest: update help text.)
Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci 
device type in vfio_pci_probe())
Merging kselftest-fixes/fixes (f5db310d77ef selftests/vm: fix link error for 
transhuge-stress test)
Merging drm-intel-fixes/for-linux-next-fixes (f37b5c2be897 drm/i915: Align 
initial plane backing objects correctly)
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic)
Merging arc/for-next (c517d838eb7d Linux 

[PATCH v3 2/2] leds: add Qualcomm PM8941 WLED driver

2015-02-24 Thread Bjorn Andersson
From: Courtney Cavin 

This adds support for the WLED ('White' LED) block on Qualcomm's
PM8941 PMICs.

Signed-off-by: Courtney Cavin 
Signed-off-by: Bjorn Andersson 
---

The details surrounding the OVP spike issue that Stephen brought up during v2
review is still unkown, the patches provided on codeaurora msm-3.10 can with
ease be implemented as an incremental patch on top of this.
As the severity doesn't seem to high (the fixes are not done on all active msm
branches), I'm sending out v3 instead of waiting for a conclusion.

Changes since v2:
- Fix of parser return value on error
- Dropped THIS_MODULE

Changes since v1:
- Replace enum blob with defines
- Merged wled_context and wled structs
- Some style updates

 drivers/leds/Kconfig|   8 +
 drivers/leds/Makefile   |   1 +
 drivers/leds/leds-pm8941-wled.c | 446 
 3 files changed, 455 insertions(+)
 create mode 100644 drivers/leds/leds-pm8941-wled.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index a6c3d2f..901b21a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -516,6 +516,14 @@ config LEDS_VERSATILE
  This option enabled support for the LEDs on the ARM Versatile
  and RealView boards. Say Y to enabled these.
 
+config LEDS_PM8941_WLED
+   tristate "LED support for the Qualcomm PM8941 WLED block"
+   depends on LEDS_CLASS
+   select REGMAP
+   help
+ This option enables support for the 'White' LED block
+ on Qualcomm PM8941 PMICs.
+
 comment "LED Triggers"
 source "drivers/leds/trigger/Kconfig"
 
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1c65a19..4325e49 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
 obj-$(CONFIG_LEDS_SYSCON)  += leds-syscon.o
 obj-$(CONFIG_LEDS_VERSATILE)   += leds-versatile.o
 obj-$(CONFIG_LEDS_MENF21BMC)   += leds-menf21bmc.o
+obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
 
 # LED SPI Drivers
 obj-$(CONFIG_LEDS_DAC124S085)  += leds-dac124s085.o
diff --git a/drivers/leds/leds-pm8941-wled.c b/drivers/leds/leds-pm8941-wled.c
new file mode 100644
index 000..9bf7358
--- /dev/null
+++ b/drivers/leds/leds-pm8941-wled.c
@@ -0,0 +1,446 @@
+/* Copyright (c) 2015, Sony Mobile Communications, AB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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 
+
+#define PM8941_WLED_REG_VAL_BASE   0x40
+#define  PM8941_WLED_REG_VAL_MAX   0xFFF
+
+#define PM8941_WLED_REG_MOD_EN 0x46
+#define  PM8941_WLED_REG_MOD_EN_BITBIT(7)
+#define  PM8941_WLED_REG_MOD_EN_MASK   BIT(7)
+
+#define PM8941_WLED_REG_SYNC   0x47
+#define  PM8941_WLED_REG_SYNC_MASK 0x07
+#define  PM8941_WLED_REG_SYNC_LED1 BIT(0)
+#define  PM8941_WLED_REG_SYNC_LED2 BIT(1)
+#define  PM8941_WLED_REG_SYNC_LED3 BIT(2)
+#define  PM8941_WLED_REG_SYNC_ALL  0x07
+#define  PM8941_WLED_REG_SYNC_CLEAR0x00
+
+#define PM8941_WLED_REG_FREQ   0x4c
+#define  PM8941_WLED_REG_FREQ_MASK 0x0f
+
+#define PM8941_WLED_REG_OVP0x4d
+#define  PM8941_WLED_REG_OVP_MASK  0x03
+
+#define PM8941_WLED_REG_BOOST  0x4e
+#define  PM8941_WLED_REG_BOOST_MASK0x07
+
+#define PM8941_WLED_REG_SINK   0x4f
+#define  PM8941_WLED_REG_SINK_MASK 0xe0
+#define  PM8941_WLED_REG_SINK_SHFT 0x05
+
+/* Per-'string' registers below */
+#define PM8941_WLED_REG_STR_OFFSET 0x10
+
+#define PM8941_WLED_REG_STR_MOD_EN_BASE0x60
+#define  PM8941_WLED_REG_STR_MOD_MASK  BIT(7)
+#define  PM8941_WLED_REG_STR_MOD_ENBIT(7)
+
+#define PM8941_WLED_REG_STR_SCALE_BASE 0x62
+#define  PM8941_WLED_REG_STR_SCALE_MASK0x1f
+
+#define PM8941_WLED_REG_STR_MOD_SRC_BASE   0x63
+#define  PM8941_WLED_REG_STR_MOD_SRC_MASK  0x01
+#define  PM8941_WLED_REG_STR_MOD_SRC_INT   0x00
+#define  PM8941_WLED_REG_STR_MOD_SRC_EXT   0x01
+
+#define PM8941_WLED_REG_STR_CABC_BASE  0x66
+#define  PM8941_WLED_REG_STR_CABC_MASK BIT(7)
+#define  PM8941_WLED_REG_STR_CABC_EN   BIT(7)
+
+struct pm8941_wled_config {
+   u32 i_boost_limit;
+   u32 ovp;
+   u32 switch_freq;
+   u32 num_strings;
+   u32 i_limit;
+   bool 

[PATCH v3 1/2] leds: add DT binding for Qualcomm PM8941 WLED block

2015-02-24 Thread Bjorn Andersson
From: Courtney Cavin 

This adds device tree binding documentation for the WLED ('White' LED)
block on Qualcomm's PM8941 PMICs.

Signed-off-by: Courtney Cavin 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- None

Changes since v1:
- None

 .../devicetree/bindings/leds/leds-pm8941-wled.txt  | 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt 
b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
new file mode 100644
index 000..a85a964
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
@@ -0,0 +1,43 @@
+Binding for Qualcomm PM8941 WLED driver
+
+Required properties:
+- compatible: should be "qcom,pm8941-wled"
+- reg: slave address
+
+Optional properties:
+- label: The label for this led
+  See Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger: Default trigger assigned to the LED
+  See Documentation/devicetree/bindings/leds/common.txt
+- qcom,cs-out: bool; enable current sink output
+- qcom,cabc: bool; enable content adaptive backlight control
+- qcom,ext-gen: bool; use externally generated modulator signal to dim
+- qcom,current-limit: mA; per-string current limit; value from 0 to 25
+   default: 20mA
+- qcom,current-boost-limit: mA; boost current limit; one of:
+   105, 385, 525, 805, 980, 1260, 1400, 1680
+   default: 805mA
+- qcom,switching-freq: kHz; switching frequency; one of:
+   600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
+   1600, 1920, 2400, 3200, 4800, 9600,
+   default: 1600kHz
+- qcom,ovp: V; Over-voltage protection limit; one of:
+   27, 29, 32, 35
+   default: 29V
+- qcom,num-strings: #; number of led strings attached; value from 1 to 3
+   default: 2
+
+Example:
+
+pm8941-wled@d800 {
+   compatible = "qcom,pm8941-wled";
+   reg = <0xd800>;
+   label = "backlight";
+
+   qcom,cs-out;
+   qcom,current-limit = <20>;
+   qcom,current-boost-limit = <805>;
+   qcom,switching-freq = <1600>;
+   qcom,ovp = <29>;
+   qcom,num-strings = <2>;
+};
-- 
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] media: em28xx replace printk in dprintk macros

2015-02-24 Thread Joe Perches
On Tue, 2015-02-24 at 16:41 -0700, Shuah Khan wrote:
> On 02/24/2015 03:03 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 24 Feb 2015 11:53:47 -0700 Shuah Khan  
> > escreveu:
> >> Replace printk macro in dprintk macros in em28xx audio, dvb,
> >> and input files with pr_* equivalent routines.
[]
> >> diff --git a/drivers/media/usb/em28xx/em28xx-input.c 
> >> b/drivers/media/usb/em28xx/em28xx-input.c
[]
> >>  #define dprintk(fmt, arg...) \
> >>if (ir_debug) { \
> >> -  printk(KERN_DEBUG "%s/ir: " fmt, ir->name , ## arg); \
> >> +  pr_debug("%s/ir: " fmt, ir->name, ## arg); \
> > 
> > NACK.
> > 
> > This is the worse of two words, as it would require both to enable
> > each debug line via dynamic printk setting and to enable ir_debug.
> Ah. I missed that. Sorry for the noise.

It's
At some point, I'm going to propose a standard mechanism
similar to netif_ that does bitmap matching for
dynamic_debug and generic debugging.



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


Re: [PATCH] capabilities: Ambient capability set V1

2015-02-24 Thread Serge Hallyn
Quoting Christoph Lameter (c...@linux.com):
> On Tue, 24 Feb 2015, Serge Hallyn wrote:
> 
> > Unless I'm misunderstanding what you are saying, apps do have surprises.
> > They drop capabilities, execute a file, and the result has capabilities
> > which the app couldn't have expected.  At least if the bits have to be
> > in fI to become part of pP', the app has a clue.
> 
> Well yes but the surprises do not occur in the cap bits they are
> manipulating or inspecting via prctl.
> 
> > To be clear, I'm suggesting that the rules at exec become:
> >
> > pI' = pI
> 
> Ok that is new and on its own may solve the issue?

No that's not new.

> > pA' = pA  (pA is ambient)
> 
> Thats what this patch does
> 
> > pP' = (X & fP) | (pI & (fI | pA))
> 
> Hmmm... fP is empty for the file not having caps. so
> 
> pP' = pI & pA

Right.

> > pE' = pP' & fE
> 
> fE? So the inherited caps are not effective? fE would be empty for a file
> not having caps thus the ambient caps would not be available in the child.

Yeah we could make this

pE' = pP' & (fE | pA)

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


Re: [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1

2015-02-24 Thread Fam Zheng
On Wed, 02/18 19:49, Ingo Molnar wrote:
> 
> * Fam Zheng  wrote:
> 
> > On Sun, 02/15 15:00, Jonathan Corbet wrote:
> > > On Fri, 13 Feb 2015 17:03:56 +0800
> > > Fam Zheng  wrote:
> > > 
> > > > SYNOPSIS
> > > > 
> > > >#include 
> > > > 
> > > >int epoll_pwait1(int epfd, int flags,
> > > > struct epoll_event *events,
> > > > int maxevents,
> > > > struct epoll_wait_params *params);
> > > 
> > > Quick, possibly dumb question: might it make sense to also pass in 
> > > sizeof(struct epoll_wait_params)?  That way, when somebody wants to add
> > > another parameter in the future, the kernel can tell which version is in
> > > use and they won't have to do an epoll_pwait2()?
> > > 
> > 
> > Flags can be used for that, if the change is not 
> > radically different.
> 
> Passing in size is generally better than flags, because 
> that way an extension of the ABI (new field[s]) 
> automatically signals towards the kernel what to do with 
> old binaries - while extending the functionality of new 
> binaries, without sacrificing functionality.
> 
> With flags you are either limited to the same structure 
> size - or have to decode a 'size' value from the flags 
> value - which is fragile (and in which case a real 'size' 
> parameter is better).
> 
> in the perf ABI we use something like that: there's a 
> perf_attr.size parameter that iterates the ABI forward, 
> while still being binary compatible with older software.
> 
> If old binaries pass in a smaller structure to a newer 
> kernel then the kernel pads the new fields with zero by 
> default - that way the kernel internals are never burdened 
> with compatibility details and data format versions.
> 
> If new user-space passes in a large structure than the 
> kernel can handle then the kernel returns an error - this 
> way user-space can transparently support conditional 
> features and fallback logic.
> 
> It works really well, we've done literally a hundred perf 
> ABI extensions this way in the last 4+ years, in a pretty 
> natural fashion, without littering the kernel (or 
> user-space) with version legacies and without breaking 
> existing perf tooling.
> 
> Other syscall ABIs already get painful when trying to 
> handle 2-3 data structure versions, so people either give 
> up, or add flags kludges or go to new syscall entries: 
> which is painful in its own fashion and adds unnecessary 
> latency to feature introduction as well.
> 

Excellent. This now makes a lot of sense to me, thanks to your explanations,
Ingo.

I'll add the "size" field in the next revision.

Thanks,
Fam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpusets,isolcpus: add file to show isolated cpus in cpuset

2015-02-24 Thread Rik van Riel
On 02/24/2015 09:15 PM, David Rientjes wrote:
> On Mon, 23 Feb 2015, r...@redhat.com wrote:
> 
>> From: Rik van Riel 
>>
>> The previous patch makes it so the code skips over isolcpus when
>> building scheduler load balancing domains. This makes it hard to
>> see for a user which of the CPUs in a cpuset are participating in
>> load balancing, and which ones are isolated cpus.
>>
>> Add a cpuset.isolcpus file with info on which cpus in a cpuset are
>> isolated CPUs.
>>
>> This file is read-only for now. In the future we could extend things
>> so isolcpus can be changed at run time, for the root (system wide)
>> cpuset only.
>>
>> Cc: Peter Zijlstra 
>> Cc: Clark Williams 
>> Cc: Li Zefan 
>> Cc: Ingo Molnar 
>> Cc: Luiz Capitulino 
>> Cc: cgro...@vger.kernel.org
>> Signed-off-by: Rik van Riel 
>> ---
>>  kernel/cpuset.c | 27 +++
>>  1 file changed, 27 insertions(+)
>>
>> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
>> index 1ad63fa37cb4..19ad5d3377f8 100644
>> --- a/kernel/cpuset.c
>> +++ b/kernel/cpuset.c
>> @@ -1563,6 +1563,7 @@ typedef enum {
>>  FILE_MEMORY_PRESSURE,
>>  FILE_SPREAD_PAGE,
>>  FILE_SPREAD_SLAB,
>> +FILE_ISOLCPUS,
>>  } cpuset_filetype_t;
>>  
>>  static int cpuset_write_u64(struct cgroup_subsys_state *css, struct cftype 
>> *cft,
>> @@ -1704,6 +1705,23 @@ static ssize_t cpuset_write_resmask(struct 
>> kernfs_open_file *of,
>>  return retval ?: nbytes;
>>  }
>>  
>> +static size_t cpuset_sprintf_isolcpus(char *s, ssize_t pos, struct cpuset 
>> *cs)
>> +{
>> +cpumask_var_t my_isolated_cpus;
>> +ssize_t count;
>> +
> 
> Whitespace.
> 
>> +if (!alloc_cpumask_var(_isolated_cpus, GFP_KERNEL))
>> +return 0;
>> +
>> +cpumask_and(my_isolated_cpus, cs->cpus_allowed, cpu_isolated_map);
>> +
>> +count = cpulist_scnprintf(s, pos, my_isolated_cpus);
>> +
>> +free_cpumask_var(my_isolated_cpus);
>> +
>> +return count;
>> +}
>> +
>>  /*
>>   * These ascii lists should be read in a single call, by using a user
>>   * buffer large enough to hold the entire map.  If read in smaller
>> @@ -1738,6 +1756,9 @@ static int cpuset_common_seq_show(struct seq_file *sf, 
>> void *v)
>>  case FILE_EFFECTIVE_MEMLIST:
>>  s += nodelist_scnprintf(s, count, cs->effective_mems);
>>  break;
>> +case FILE_ISOLCPUS:
>> +s += cpuset_sprintf_isolcpus(s, count, cs);
>> +break;
> 
> This patch looks fine, and I think cpuset.effective_cpus and 
> cpuset.isolcpus can be used well together, but will need updating now that 
> commit e8e6d97c9b ("cpuset: use %*pb[l] to print bitmaps including 
> cpumasks and nodemasks") has been merged which reworks this function.

I will take a look at that changeset. It was not in the
tip tree I worked against.

Expect a v2 :)

> It's a little unfortunate, though, that the user sees Cpus_allowed, 
> cpuset.cpus, and cpuset.effective_cpus that include isolcpus and then have 
> to check another cpulist for the isolcpus to see their sched domain, 
> though.

Agreed, but all the alternatives I could think of would break the
userspace API, leaving this as the best way to go.

-- 
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: [RESEND PATCH v2 7/9] mfd: rtsx: add support for rts524A

2015-02-24 Thread 敬锐

On 02/16/2015 10:28 PM, Lee Jones wrote:
>
> +static int rts524a_optimize_phy(struct rtsx_pcr *pcr)
> +{
> + int err;
> +
> + err = rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3,
> + D3_DELINK_MODE_EN, 0x00);
> + if (err < 0)
> + return err;
> +
> + rtsx_pci_write_phy_register(pcr, PHY_PCR,
> + PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 |
> + PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 | PHY_PCR_RSSI_EN);
> + rtsx_pci_write_phy_register(pcr, PHY_SSCCR3,
> + PHY_SSCCR3_STEP_IN | PHY_SSCCR3_CHECK_DELAY);
> +
> + if (is_version(pcr, 0x524A, IC_VER_A)) {
> + rtsx_pci_write_phy_register(pcr, PHY_SSCCR3,
> + PHY_SSCCR3_STEP_IN | PHY_SSCCR3_CHECK_DELAY);
> + rtsx_pci_write_phy_register(pcr, PHY_SSCCR2,
> + PHY_SSCCR2_PLL_NCODE | PHY_SSCCR2_TIME0 |
> + PHY_SSCCR2_TIME2_WIDTH);
> + rtsx_pci_write_phy_register(pcr, PHY_ANA1A,
> + PHY_ANA1A_TXR_LOOPBACK | PHY_ANA1A_RXT_BIST |
> + PHY_ANA1A_TXR_BIST | PHY_ANA1A_REV);
> + rtsx_pci_write_phy_register(pcr, PHY_ANA1D,
> + PHY_ANA1D_DEBUG_ADDR);
> + rtsx_pci_write_phy_register(pcr, PHY_DIG1E,
> + PHY_DIG1E_REV | PHY_DIG1E_D0_X_D1 |
> + PHY_DIG1E_RX_ON_HOST | PHY_DIG1E_RCLK_REF_HOST |
> + PHY_DIG1E_RCLK_TX_EN_KEEP |
> + PHY_DIG1E_RCLK_TX_TERM_KEEP |
> + PHY_DIG1E_RCLK_RX_EIDLE_ON | PHY_DIG1E_TX_TERM_KEEP |
> + PHY_DIG1E_RX_TERM_KEEP | PHY_DIG1E_TX_EN_KEEP |
> + PHY_DIG1E_RX_EN_KEEP);
> + }
> +
> + rtsx_pci_write_phy_register(pcr, PHY_ANA08,
> + PHY_ANA08_RX_EQ_DCGAIN | PHY_ANA08_SEL_RX_EN |
> + PHY_ANA08_RX_EQ_VAL | PHY_ANA08_SCP | PHY_ANA08_SEL_IPI);
> To the uninitiated this function is mostly randomness.  How about some
> nice comments to illuminate?
I'm not clear with these setting either, it is used to fix some phy 
setting, the default phy setting
it not stable on some special platform, so we have to modify them by driver,
newer version of chip will change its default value to more stable 
configure, so some value is
no need to setting for Version B/C...

>
>> diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
>> index fe2bbb6..e7daf6f 100644
>> --- a/drivers/mfd/rtsx_pcr.h
>> +++ b/drivers/mfd/rtsx_pcr.h
>> @@ -27,12 +27,19 @@
>>   #define MIN_DIV_N_PCR  80
>>   #define MAX_DIV_N_PCR  208
>>   
>> +#define RTS524A_PME_FORCE_CTL   0xFF78
>> +#define RTS524A_PM_CTRL30xFF7E
>> +
>> +int __rtsx_pci_write_phy_register(struct rtsx_pcr *pcr, u8 addr, u16 val);
>> +int __rtsx_pci_read_phy_register(struct rtsx_pcr *pcr, u8 addr, u16 *val);
>> +
>>   void rts5209_init_params(struct rtsx_pcr *pcr);
>>   void rts5229_init_params(struct rtsx_pcr *pcr);
>>   void rtl8411_init_params(struct rtsx_pcr *pcr);
>>   void rtl8402_init_params(struct rtsx_pcr *pcr);
>>   void rts5227_init_params(struct rtsx_pcr *pcr);
>>   void rts5249_init_params(struct rtsx_pcr *pcr);
>> +void rts524a_init_params(struct rtsx_pcr *pcr);
>>   void rtl8411b_init_params(struct rtsx_pcr *pcr);
>>   
>>   static inline u8 map_sd_drive(int idx)
>> diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
>> index 33cc63c..a392546 100644
>> --- a/include/linux/mfd/rtsx_pci.h
>> +++ b/include/linux/mfd/rtsx_pci.h
>> @@ -577,8 +577,16 @@
>>
>>   
>>   #define PCR_SETTING_REG1   0x724
>> @@ -729,6 +831,8 @@ struct pcr_handle {
>>   };
>>   
>>   struct pcr_ops {
>> +int (*write_phy)(struct rtsx_pcr *pcr, u8 addr, u16 val);
>> +int (*read_phy)(struct rtsx_pcr *pcr, u8 addr, u16 *val);
>>  int (*extra_init_hw)(struct rtsx_pcr *pcr);
>>  int (*optimize_phy)(struct rtsx_pcr *pcr);
>>  int (*turn_on_led)(struct rtsx_pcr *pcr);
>> @@ -830,6 +934,10 @@ struct rtsx_pcr {
>>   #define CHK_PCI_PID(pcr, pid)  ((pcr)->pci->device == (pid))
>>   #define PCI_VID(pcr)   ((pcr)->pci->vendor)
>>   #define PCI_PID(pcr)   ((pcr)->pci->device)
>> +#define is_version(pcr, pid, ver)   \
>> +(CHK_PCI_PID(pcr, pid) && (pcr)->ic_version == (ver))
>> +#define pcr_dbg(pcr, fmt, arg...)   \
>> +dev_dbg(&(pcr)->pci->dev, fmt, ##arg)
>>   
>>   #define SDR104_PHASE(val)  ((val) & 0xFF)
>>   #define SDR50_PHASE(val)   (((val) >> 8) & 0xFF)
>> @@ -899,4 +1007,17 @@ static inline void rtsx_pci_write_be32(struct rtsx_pcr 
>> *pcr, u16 reg, u32 val)
>>  rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
>>   }
>>   
>> +static inline int rtsx_pci_update_phy(struct rtsx_pcr *pcr, u8 addr,
>> +u16 mask, u16 append)
>> +{
>> +int err;
>> +u16 val;

Re: [PATCH Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

2015-02-24 Thread Ethan Zhao
Viresh,
  With this patch applied, still got the following warning and panic,
seems it needs more care.

 54.474618] [ cut here ]
[   54.545816] WARNING: CPU: 0 PID: 213 at include/linux/kref.h:47
kobject_get+0x41/0x50()
[   54.642595] Modules linked in: i2c_i801(+) mfd_core shpchp(+)
acpi_cpufreq(+) edac_core ioatdma(+) xfs libcrc32c ast syscopyarea ixgbe
sysfillrect sysimgblt sr_mod sd_mod drm_kms_helper igb mdio cdrom e1000e ahci
dca ttm libahci uas drm i2c_algo_bit ptp megaraid_sas libata usb_storage
i2c_core pps_core dm_mirror dm_region_hash dm_log dm_mod
[   55.007264] CPU: 0 PID: 213 Comm: kworker/0:2 Not tainted
3.18.5
[   55.099970] Hardware name: Oracle Corporation SUN FIRE X4170 M2 SERVER
   /ASSY,MOTHERBOARD,X4170, BIOS 08120104 05/08/2012
[   55.239736] Workqueue: kacpi_notify acpi_os_execute_deferred
[   55.308598]   bd730b61 88046742baf8
816b7edb
[   55.398305]    88046742bb38
81078ae1
[   55.488040]  88046742bbd8 8806706b3000 0292

[   55.56] Call Trace:
[   55.608228]  [] dump_stack+0x46/0x58
[   55.670895]  [] warn_slowpath_common+0x81/0xa0
[   55.743952]  [] warn_slowpath_null+0x1a/0x20
[   55.814929]  [] kobject_get+0x41/0x50
[   55.878654]  [] cpufreq_cpu_get+0x75/0xc0
[   55.946528]  [] cpufreq_update_policy+0x2e/0x1f0
[   56.021682]  [] ? up+0x32/0x50
[   56.078126]  [] ? acpi_ns_get_node+0xcb/0xf2
[   56.148974]  [] ? acpi_evaluate_object+0x22c/0x252
[   56.226066]  [] ? acpi_get_handle+0x95/0xc0
[   56.295871]  [] ? acpi_has_method+0x25/0x40
[   56.365661]  [] acpi_processor_ppc_has_changed+0x77/0x82
[   56.448956]  [] ? move_linked_works+0x66/0x90
[   56.520842]  [] acpi_processor_notify+0x58/0xe7
[   56.594807]  [] acpi_ev_notify_dispatch+0x44/0x5c
[   56.670859]  [] acpi_os_execute_deferred+0x15/0x22
[   56.747936]  [] process_one_work+0x14e/0x3f0
[   56.818766]  [] worker_thread+0x11b/0x4d0
[   56.886486]  [] ? rescuer_thread+0x350/0x350
[   56.957316]  [] kthread+0xe1/0x100
[   57.017742]  [] ? kthread_create_on_node+0x1b0/0x1b0
[   57.096903]  [] ret_from_fork+0x7c/0xb0
[   57.162534]  [] ? kthread_create_on_node+0x1b0/0x1b0
[   57.241680] ---[ end trace dce06bb76f547de5 ]---


Any idea ?

Thanks,
Ethan

On Mon, Feb 2, 2015 at 11:04 PM, ethan zhao  wrote:
>
> On 2015/2/2 12:54, Viresh Kumar wrote:
>>
>> On 2 February 2015 at 10:15, ethan zhao  wrote:
>>>
>>> On 2015/2/2 12:26, Viresh Kumar wrote:
>>>   But there is no checking against refcount in or before
>>>
>>>   cpufreq_policy_free(), that is one issue I mentioned.
>>
>> As I said earlier, the completion will only fire once the refcount
>> is zero. And so there is no need of any check here.
>>
 That routines doesn't have any tricks and simply frees the policy.
 Because, before calling cpufreq_policy_put_kobj(), we have set
 the per-cpu variable to NULL, nobody else will get the policy
>>>
>>>   It is possible cpufreq_cpu_get() within the PPC thread was called just
>>>   before __cpufreq_remove_dev_finish() is to be called in another thread,
>>>   so you set the per_cpu(cpufreq_cpu_data, cpu) to NULL will not prevent
>>>   the actions between cpufreq_cpu_get and cpufreq_cpu_put().
>>>
>>>   And then the freeing happens in __cpufreq_remove_dev_finish().
>>
>> It will.. You aren't looking closely enough. If cpufreq_cpu_get() is
>> called just
>> before remove-dev, then cpufreq_cpu_get() will take:
>>
>> read_lock_irqsave(_driver_lock, flags);
>>
>> And it will do:
>>
>> read_unlock_irqrestore(_driver_lock, flags);
>>
>> only after increasing the refcount with kobject_get().
>>
>> While on the other side __cpufreq_remove_dev_finish() will do this:
>>
>> write_lock_irqsave(_driver_lock, flags);
>> policy = per_cpu(cpufreq_cpu_data, cpu);
>> per_cpu(cpufreq_cpu_data, cpu) = NULL;
>> write_unlock_irqrestore(_driver_lock, flags);
>>
>> So, it will wait for the read_lock in cpufreq_cpu_get() to finish before
>> setting per-cpu variable to NULL. And so, after kobject_put() in
>> cpufreq_policy_put_kobj(), we will wait for the completion to fire
>
>  Closely enough this time, understood, thanks for your explanation.
>
>
>  Ethan
>
>> and that will only happen once a corresponding cpufreq_cpu_put()
>> is issued.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.2 055/152] x86_64, switch_to(): Load TLS descriptors before switching DS and ES

2015-02-24 Thread Brian Gerst
On Tue, Feb 24, 2015 at 3:08 PM, Denys Vlasenko
 wrote:
> On Tue, Feb 24, 2015 at 9:02 PM, Andy Lutomirski  wrote:
>>> This currently fails in 32-bit kernels (at least in qemu):
>>>
>>> / # ./es_test
>>> Allocated GDT index 7
>>> [FAIL]ES changed from 0x3b to 0x7b
>>> [FAIL]ES was corrupted 1000/1000 times
>>> / # uname -a
>>> Linux (none) 4.0.0-rc1 #1 SMP Tue Feb 24 16:41:58 CET 2015 i686 GNU/Linux
>>
>> Want to send a patch?  I'll get it in a few days if no one beats me.
>
> I have no patch, sorry (in fact, I failed to find where is the relevant
> 32-bit counterpart).
>
> It's just security people asked me to backport this and I wondered
> maybe I should wait a bit on this one, since fix for 32-bit ought
> to appear as well.

For 32-bit kernel, userspace DS and ES are saved at syscall/interrupt
entry time and reloaded on exit, unlike in 64-bit where they are saved
and loaded at context switch time.  Therefore 32-bit is not affected
by the issue this patch addresses.

It looks to me though, that the ES test program doesn't actually test
what the patch fixes - the segment attributes, like the base address.
It tests just the selector, which shouldn't change across a kernel
entry (with a few exceptions, like signals).  If the test is failing,
then it is a different issue from what this patch addresses.

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


Re: [PATCH v2] scripts: checkpatch.pl: add 2 new checks on memset calls

2015-02-24 Thread Joe Perches
On Wed, 2015-02-25 at 04:40 +0200, Aya Mahfouz wrote:
> This patch adds 2 new checks on memset calls in the file
> checkpatch.pl as follows:
> 
> replace memset by eth_zero_addr if the second argument is
> an address of zeros (0x00). eth_zero_addr is a wrapper function
> for memset that takes an address array to set as zero. The size
> address has to be ETH_ALEN.

[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -4901,10 +4901,22 @@ sub process {
>  
>   if ($ms_size =~ /^(0x|)0$/i) {
>   ERROR("MEMSET",
> -   "memset to 0's uses 0 as the 2nd 
> argument, not the 3rd\n" . "$here\n$stat\n");
> +   "memset to 0's uses 0 as the 2nd 
> argument, not the 3rd\n" . "$here\n$line\n");
>   } elsif ($ms_size =~ /^(0x|)1$/i) {
>   WARN("MEMSET",
> -  "single byte memset is suspicious. Swapped 
> 2nd/3rd argument?\n" . "$here\n$stat\n");
> +  "single byte memset is suspicious. Swapped 
> 2nd/3rd argument?\n" . "$here\n$line\n");
> + } elsif ($ms_size =~ /^ETH_ALEN/i) {
> + if ($ms_val =~ /^0x00/i && 
> WARN("PREFER_ETH_ZERO_ADDR",

This isn't right.  Look again at what I suggested.

This would match 0x00ff and wouldn't match 0

> +  "Prefer eth_zero_addr() over memset() 
> if the second address is 0x00\n" . $herecurr) &&
> + $fix) {
> +
> + $fixed[$fixlinenr] =~ 
> s/\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*ETH_ALEN\s*\)/eth_zero_addr($ms_addr)/;
> + } elsif ($ms_val =~ /^0xff/i && 
> WARN("PREFER_ETH_BROADCAST_ADDR",
> +  "Prefer eth_broadcast_addr() over 
> memset() if the second address is 0xff\n" . $herecurr) &&
> + $fix) {
> +
> + $fixed[$fixlinenr] =~ 
> s/\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*ETH_ALEN\s*\)/eth_broadcast_addr($ms_addr)/;
> + }
>   }
>   }
>  



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v10 10/12] xfstests: fsstress: Add fallocate insert range operation

2015-02-24 Thread Dave Chinner
On Sun, Feb 22, 2015 at 12:45:52AM +0900, Namjae Jeon wrote:
> From: Namjae Jeon 
> 
> This commit adds insert operation support for fsstress, which is
> meant to exercise fallocate FALLOC_FL_INSERT_RANGE support.

This causes xfs/068 to fail because it changes the file creation
pattern that results from a specific fsstress random seed. As such,
I added this to xfs/068:

FSSTRESS_AVOID="-f insert=0 $FSSTRESS_AVOID"

To turn off the insert operation for that test and hence produce the
expected tree of files.

Cheers,

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


[PATCH] eCryptfs: don't pass fs-specific ioctl commands through

2015-02-24 Thread Tyler Hicks
eCryptfs can't be aware of what to expect when after passing an
arbitrary ioctl command through to the lower filesystem. The ioctl
command may trigger an action in the lower filesystem that is
incompatible with eCryptfs.

One specific example is when one attempts to use the Btrfs clone
ioctl command when the source file is in the Btrfs filesystem that
eCryptfs is mounted on top of and the destination fd is from a new file
created in the eCryptfs mount. The ioctl syscall incorrectly returns
success because the command is passed down to Btrfs which thinks that it
was able to do the clone operation. However, the result is an empty
eCryptfs file.

This patch allows the trim, {g,s}etflags, and {g,s}etversion ioctl
commands through and then copies up the inode metadata from the lower
inode to the eCryptfs inode to catch any changes made to the lower
inode's metadata. Those five ioctl commands are mostly common across all
filesystems but the whitelist may need to be further pruned in the
future.

https://bugzilla.kernel.org/show_bug.cgi?id=93691
https://launchpad.net/bugs/1305335

Signed-off-by: Tyler Hicks 
Cc: Rocko 
Cc: Colin Ian King 
---
 fs/ecryptfs/file.c | 34 ++
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/fs/ecryptfs/file.c b/fs/ecryptfs/file.c
index b07731e..fd39bad 100644
--- a/fs/ecryptfs/file.c
+++ b/fs/ecryptfs/file.c
@@ -303,9 +303,22 @@ ecryptfs_unlocked_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
struct file *lower_file = ecryptfs_file_to_lower(file);
long rc = -ENOTTY;
 
-   if (lower_file->f_op->unlocked_ioctl)
+   if (!lower_file->f_op->unlocked_ioctl)
+   return rc;
+
+   switch (cmd) {
+   case FITRIM:
+   case FS_IOC_GETFLAGS:
+   case FS_IOC_SETFLAGS:
+   case FS_IOC_GETVERSION:
+   case FS_IOC_SETVERSION:
rc = lower_file->f_op->unlocked_ioctl(lower_file, cmd, arg);
-   return rc;
+   fsstack_copy_attr_all(file_inode(file), file_inode(lower_file));
+
+   return rc;
+   default:
+   return rc;
+   }
 }
 
 #ifdef CONFIG_COMPAT
@@ -315,9 +328,22 @@ ecryptfs_compat_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
struct file *lower_file = ecryptfs_file_to_lower(file);
long rc = -ENOIOCTLCMD;
 
-   if (lower_file->f_op->compat_ioctl)
+   if (!lower_file->f_op->compat_ioctl)
+   return rc;
+
+   switch (cmd) {
+   case FITRIM:
+   case FS_IOC32_GETFLAGS:
+   case FS_IOC32_SETFLAGS:
+   case FS_IOC32_GETVERSION:
+   case FS_IOC32_SETVERSION:
rc = lower_file->f_op->compat_ioctl(lower_file, cmd, arg);
-   return rc;
+   fsstack_copy_attr_all(file_inode(file), file_inode(lower_file));
+
+   return rc;
+   default:
+   return rc;
+   }
 }
 #endif
 
-- 
2.1.0

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


Re: [PATCH] scripts: checkpatch.pl: add 2 new checks on memset calls

2015-02-24 Thread Aya Mahfouz
On Mon, Feb 23, 2015 at 07:06:27PM -0800, Joe Perches wrote:
> On Mon, 2015-02-23 at 21:18 +0200, Aya Mahfouz wrote:
> > This patch adds 2 new checks on memset calls in the file
> > checkpatch.pl as follows:
> > 
> > replace memset by eth_zero_addr if the second argument is
> > an address of zeros (0x00). eth_zero_addr is a wrapper function
> > for memset that takes an address array to set as zero. The size
> > address has to be ETH_ALEN.
> > 
> > replace memset by eth_broadcast_addr if the second argument is
> > the broadcast address (0xff). eth_broadcast_addr is a wrapper
> > function for memset that sets the passed array the broadcast
> > address. The size of the address has to be ETH_ALEN.
> 
> Hello Aya.
> 
> Good idea but:
> 
> there already is a test for memset at (-next) line 4893.
> 
> Please extend that as below instead of adding another test.
> 

Hello Joe,

I've adjusted the checks as you requested. Kindly let me know if there
is something else that should be done.

Kind Regards,
Aya Saif El-yazal Mahfouz

> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
> > @@ -4918,6 +4918,25 @@ sub process {
> > }
> > }
> >  
> > +# Check for memset(foo, 0x00|0xff, ETH_ALEN) that could be 
> > eth_zero_addr(foo)|eth_broadcast_addr(foo)
> > +   if ($^V && $^V ge 5.10.0 &&
> > +   $line =~ 
> > /^\+(?:.*?)\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*ETH_ALEN\s*\)/s) {
> > +   my $num = $7;
> > +   if ($num =~ "0x00" && WARN("PREFER_ETH_ZERO_ADDR",
> 
> # Check for misused memsets
>   if ($^V && $^V ge 5.10.0 &&
>   defined $stat &&
>   $stat =~ 
> /^\+(?:.*?)\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*$FuncArg\s*\)/s) {
> 
>   my $ms_addr = $2;
>   my $ms_val = $7;
>   my $ms_size = $12;
> 
>   if ($ms_val =~ /^(?:0|0x0+)$/i &&
>   $ms_size =~ /^ETH_ALEN$/ &&
>   WARN("PREFER_ETH_ADDR_FUNC",
>"..." . herecurr) &&
>   $fix) {
>   $fixed[$fixlinenr] =~ 
> s/\bmemcpy\s*\(\s*\Q$ms_addr\E\s*,\s*\Q$ms_val\E\s*\,\s*ETH_ALEN\s*\)/eth_zero_addr($ms_addr)/;
>   } elsif ($ms_val =~ /^(?:0xff|255)$/i &&
>$ms_size =~ /^ETH_ALEN$/ &&
>WARN("PREFER_ETH_ADDR_FUNC",
> "..." . herecurr) &&
>$fix) {
>   $fixed[$fixlinenr] =~ 
> s/\bmemcpy\s*\(\s*\Q$ms_addr\E\s*,\s*\Q$ms_val\E\s*\,\s*ETH_ALEN\s*\)/eth_broadcast_addr($ms_addr)/;
>   } elsif (...)
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Trying to use 'perf probe' to debug perf itself

2015-02-24 Thread Masami Hiramatsu
Hi Arnaldo,

(2015/02/25 3:49), Arnaldo Carvalho de Melo wrote:
> Hi Masami,
> 
>   I'm adding thread refcounting in perf, and in this process I am
> investigating a problem, so thought about using perf itself to match
> thread__get with thread__put:
> 
> [root@ssdandy ~]# perf probe -x ~/bin/perf -V thread__put 
> Available variables at thread__put
> @
> struct thread*  thread
> [root@ssdandy ~]# perf probe -x ~/bin/perf -V thread__get
> Available variables at thread__get
> @
> struct thread*  thread
> [root@ssdandy ~]#
> 
> cool, so I thought it would be just a matter of asking to put the probes
> and get the value of 'thread', then match things, but:
> 
> 
> [root@ssdandy ~]# perf probe -v ~/bin/perf thread__put thread
> probe-definition(0): thread__put thread 
> symbol:thread__put file:(null) line:0 offset:0 return:0 lazy:(null)
> parsing arg: thread into thread
> 1 arguments
> Open Debuginfo file: /root/bin/perf
> Try to find probe point from debuginfo.
> Probe point found: thread__put+0
> Searching 'thread' variable in context.
> Converting variable thread into trace event.
> thread type is (null).
> Found 1 probe_trace_events.
> Opening /sys/kernel/debug/tracing/uprobe_events write=1
> Added new event:
> Writing event: p:probe_perf/thread__put /root/bin/perf:0xd03d2 
> thread=-32(%sp):u64
> Failed to write event: Invalid argument
>   Error: Failed to add events. Reason: Invalid argument (Code: -22)
> [root@ssdandy ~]#
> 
> Not possible :-\ 

Hmm, strange. Could you tell me the version of your kernel?
It seems that the kernel newer than 3.14 supports uprobes with
memory dereference (e.g. -32(%sp) )feature.
(it was actually introduced by 5baaa59e, and git-describe told
 it was v3.13-rc4-22-g5baaa59)

And also, could you try to write the result command to uprobe_event as
below?

# echo "p:probe_perf/thread__put /root/bin/perf:0xd03d2 thread=-32(%sp):u64" >> 
\
 /sys/kernel/debug/tracing/uprobe_events


> 
> please let me know if you need some file, here is the readelf -wi for
> those two routines:

This should not be the problem of dwarf-analysis. It seems kernel-side
(uprobe) problem.

Thank you,

> 
> # readelf -wi ~/bin/perf
> 
>  <1>: Abbrev Number: 35 (DW_TAG_subprogram)
>DW_AT_external: 1 
>DW_AT_name: (indirect string, offset: 0x4c5c3): 
> thread__get   
>DW_AT_decl_file   : 6 
>DW_AT_decl_line   : 84
>DW_AT_prototyped  : 1 
>DW_AT_type: <0xe15cc> 
>DW_AT_low_pc  : 0x4d038c  
>DW_AT_high_pc : 0x46  
>DW_AT_frame_base  : 1 byte block: 9c  (DW_OP_call_frame_cfa)
>DW_AT_GNU_all_tail_call_sites: 1  
>DW_AT_sibling : <0xe2621> 
>  <2>: Abbrev Number: 32 (DW_TAG_formal_parameter)
>DW_AT_name: (indirect string, offset: 0x43dc7): thread  
>   
>DW_AT_decl_file   : 6 
>DW_AT_decl_line   : 84
>DW_AT_type: <0xe15cc> 
>DW_AT_location: 2 byte block: 91 58   (DW_OP_fbreg: -40)
>  <2>: Abbrev Number: 0
>  <1>: Abbrev Number: 39 (DW_TAG_subprogram)
>DW_AT_external: 1 
>DW_AT_name: (indirect string, offset: 0x4c699): 
> thread__put   
>DW_AT_decl_file   : 6 
>DW_AT_decl_line   : 90
>DW_AT_prototyped  : 1 
>DW_AT_low_pc  : 0x4d03d2  
>DW_AT_high_pc : 0x6c  
>DW_AT_frame_base  : 1 byte block: 9c  (DW_OP_call_frame_cfa)
>DW_AT_GNU_all_tail_call_sites: 1  
>DW_AT_sibling : <0xe264d> 
>  <2>: Abbrev Number: 32 (DW_TAG_formal_parameter)
>DW_AT_name: (indirect string, offset: 0x43dc7): thread  
>   
>DW_AT_decl_file   : 6 
>DW_AT_decl_line   : 90
>DW_AT_type: <0xe15cc> 
> 
> 
> Will see what I can do with just:
> 
> [root@ssdandy ~]# perf probe ~/bin/perf thread__get
> Added new event:
>   probe_perf:thread__get (on thread__get in /root/bin/perf)
> 
> You can now use it in all perf tools, such as:
> 
>   perf record -e probe_perf:thread__get -aR sleep 1
> 
> [root@ssdandy ~]# perf probe ~/bin/perf thread__put
> Added new event:
>   probe_perf:thread__put (on thread__put in /root/bin/perf)
> 
> You can now use it in all perf tools, such as:
> 
>   perf record -e probe_perf:thread__put -aR sleep 1
> 
> [root@ssdandy ~]# perf list probe*:*
> 
> List of pre-defined events (to be used in -e):
> 
>   probe_perf:thread__put [Tracepoint event]
>   probe_perf:thread__get [Tracepoint event]
> [root@ssdandy ~]# perf probe -l
>   probe_perf:thread__get (on thread__get@util/thread.c in /root/bin/perf)
>   probe_perf:thread__put (on thread__put@util/thread.c in /root/bin/perf)
> [root@ssdandy ~]# 
> 
> - Arnaldo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the 

[PATCH] arm64: mm: remove unused functions and variable protoypes

2015-02-24 Thread Yingjoe Chen
The functions __cpu_flush_user_tlb_range and __cpu_flush_kern_tlb_range
were removed in commit fa48e6f780 'arm64: mm: Optimise tlb flush logic
where we have >4K granule'. Global variable cpu_tlb was never used in
arm64.

Remove them.

Signed-off-by: Yingjoe Chen 
---
 arch/arm64/include/asm/tlbflush.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm64/include/asm/tlbflush.h 
b/arch/arm64/include/asm/tlbflush.h
index 73f0ce5..4abe9b9 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -24,11 +24,6 @@
 #include 
 #include 
 
-extern void __cpu_flush_user_tlb_range(unsigned long, unsigned long, struct 
vm_area_struct *);
-extern void __cpu_flush_kern_tlb_range(unsigned long, unsigned long);
-
-extern struct cpu_tlb_fns cpu_tlb;
-
 /*
  * TLB Management
  * ==
-- 
1.8.1.1.dirty

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


Re: Build regressions/improvements in v4.0-rc1

2015-02-24 Thread Michael Ellerman
On Tue, 2015-02-24 at 10:38 +0100, Geert Uytterhoeven wrote:
> Hi Michael,
> 
> On Tue, Feb 24, 2015 at 5:52 AM, Michael Ellerman  wrote:
> >> >   + error: book3s_64_vio_hv.c: undefined reference to 
> >> > `power7_wakeup_loss':  => .text+0x408)
> >>
> >> pseries_defconfig
> >
> > This one is actually from pseries_defconfig+POWERNV=n, so I think I
> 
> Thanks!
> 
> > broke your script with the + notation in the config name :)
> 
> Nope, my brain used the wrong separator.

I can't help with that :)

> However, my scripts do have a problem with the subdirectories
> in arch/powerpc/configs/ (4xx/currituck_defconfig)...

Yeah sorry, they are a bit of a pain. I'm sure some horrible regexp can deal
with it ;)

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scripts: checkpatch.pl: add 2 new checks on memset calls

2015-02-24 Thread Aya Mahfouz
This patch adds 2 new checks on memset calls in the file
checkpatch.pl as follows:

replace memset by eth_zero_addr if the second argument is
an address of zeros (0x00). eth_zero_addr is a wrapper function
for memset that takes an address array to set as zero. The size
address has to be ETH_ALEN.

replace memset by eth_broadcast_addr if the second argument is
the broadcast address (0xff). eth_broadcast_addr is a wrapper
function for memset that sets the passed array the broadcast
address. The size of the address has to be ETH_ALEN.

Cc: Julia Lawall 
Signed-off-by: Aya Mahfouz 
---
v2: adjusted all checks on memset calls to be in one body

 scripts/checkpatch.pl | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d124359..ab43d1b 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4890,10 +4890,10 @@ sub process {
}
}
 
-# Check for misused memsets
+# Check for misused memsets then check for memset(foo, 0x00|0xff, ETH_ALEN)
+# calls that could be eth_zero_addr(foo)|eth_broadcast_addr(foo)
if ($^V && $^V ge 5.10.0 &&
-   defined $stat &&
-   $stat =~ 
/^\+(?:.*?)\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*$FuncArg\s*\)/s) {
+   $line =~ 
/^\+(?:.*?)\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*$FuncArg\s*\)/s) {
 
my $ms_addr = $2;
my $ms_val = $7;
@@ -4901,10 +4901,22 @@ sub process {
 
if ($ms_size =~ /^(0x|)0$/i) {
ERROR("MEMSET",
- "memset to 0's uses 0 as the 2nd 
argument, not the 3rd\n" . "$here\n$stat\n");
+ "memset to 0's uses 0 as the 2nd 
argument, not the 3rd\n" . "$here\n$line\n");
} elsif ($ms_size =~ /^(0x|)1$/i) {
WARN("MEMSET",
-"single byte memset is suspicious. Swapped 
2nd/3rd argument?\n" . "$here\n$stat\n");
+"single byte memset is suspicious. Swapped 
2nd/3rd argument?\n" . "$here\n$line\n");
+   } elsif ($ms_size =~ /^ETH_ALEN/i) {
+   if ($ms_val =~ /^0x00/i && 
WARN("PREFER_ETH_ZERO_ADDR",
+"Prefer eth_zero_addr() over memset() 
if the second address is 0x00\n" . $herecurr) &&
+   $fix) {
+
+   $fixed[$fixlinenr] =~ 
s/\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*ETH_ALEN\s*\)/eth_zero_addr($ms_addr)/;
+   } elsif ($ms_val =~ /^0xff/i && 
WARN("PREFER_ETH_BROADCAST_ADDR",
+"Prefer eth_broadcast_addr() over 
memset() if the second address is 0xff\n" . $herecurr) &&
+   $fix) {
+
+   $fixed[$fixlinenr] =~ 
s/\bmemset\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*ETH_ALEN\s*\)/eth_broadcast_addr($ms_addr)/;
+   }
}
}
 
-- 
1.9.3

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


Re: [patch] mm, hugetlb: close race when setting PageTail for gigantic pages

2015-02-24 Thread Hillf Danton
> Now that gigantic pages are dynamically allocatable, care must be taken
> to ensure that p->first_page is valid before setting PageTail.
> 
> If this isn't done, then it is possible to race and have compound_head()
> return NULL.
> 
> Signed-off-by: David Rientjes 
> ---
Acked-by: Hillf Danton 

>  mm/hugetlb.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -917,7 +917,6 @@ static void prep_compound_gigantic_page(struct page 
> *page, unsigned long order)
>   __SetPageHead(page);
>   __ClearPageReserved(page);
>   for (i = 1; i < nr_pages; i++, p = mem_map_next(p, page, i)) {
> - __SetPageTail(p);
>   /*
>* For gigantic hugepages allocated through bootmem at
>* boot, it's safer to be consistent with the not-gigantic
> @@ -933,6 +932,9 @@ static void prep_compound_gigantic_page(struct page 
> *page, unsigned long order)
>   __ClearPageReserved(p);
>   set_page_count(p, 0);
>   p->first_page = page;
> + /* Make sure p->first_page is always valid for PageTail() */
> + smp_wmb();
> + __SetPageTail(p);
>   }
>  }
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


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


[PATCH 3.10 01/16] ip: zero sockaddr returned on error queue

2015-02-24 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Willem de Bruijn 

[ Upstream commit f812116b174e59a350acc8e4856213a166a91222 ]

The sockaddr is returned in IP(V6)_RECVERR as part of errhdr. That
structure is defined and allocated on the stack as

struct {
struct sock_extended_err ee;
struct sockaddr_in(6)offender;
} errhdr;

The second part is only initialized for certain SO_EE_ORIGIN values.
Always initialize it completely.

An MTU exceeded error on a SOCK_RAW/IPPROTO_RAW is one example that
would return uninitialized bytes.

Signed-off-by: Willem de Bruijn 



Also verified that there is no padding between errhdr.ee and
errhdr.offender that could leak additional kernel data.
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv4/ip_sockglue.c |8 ++--
 net/ipv6/datagram.c|   10 +++---
 2 files changed, 5 insertions(+), 13 deletions(-)

--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -410,15 +410,11 @@ int ip_recv_error(struct sock *sk, struc
 
memcpy(, >ee, sizeof(struct sock_extended_err));
sin = 
-   sin->sin_family = AF_UNSPEC;
+   memset(sin, 0, sizeof(*sin));
if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP) {
-   struct inet_sock *inet = inet_sk(sk);
-
sin->sin_family = AF_INET;
sin->sin_addr.s_addr = ip_hdr(skb)->saddr;
-   sin->sin_port = 0;
-   memset(>sin_zero, 0, sizeof(sin->sin_zero));
-   if (inet->cmsg_flags)
+   if (inet_sk(sk)->cmsg_flags)
ip_cmsg_recv(msg, skb);
}
 
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -374,11 +374,10 @@ int ipv6_recv_error(struct sock *sk, str
 
memcpy(, >ee, sizeof(struct sock_extended_err));
sin = 
-   sin->sin6_family = AF_UNSPEC;
+   memset(sin, 0, sizeof(*sin));
+
if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL) {
sin->sin6_family = AF_INET6;
-   sin->sin6_flowinfo = 0;
-   sin->sin6_port = 0;
if (skb->protocol == htons(ETH_P_IPV6)) {
sin->sin6_addr = ipv6_hdr(skb)->saddr;
if (np->rxopt.all)
@@ -387,12 +386,9 @@ int ipv6_recv_error(struct sock *sk, str
ipv6_iface_scope_id(>sin6_addr,
IP6CB(skb)->iif);
} else {
-   struct inet_sock *inet = inet_sk(sk);
-
ipv6_addr_set_v4mapped(ip_hdr(skb)->saddr,
   >sin6_addr);
-   sin->sin6_scope_id = 0;
-   if (inet->cmsg_flags)
+   if (inet_sk(sk)->cmsg_flags)
ip_cmsg_recv(msg, skb);
}
}


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


[PATCH 3.10 05/16] net: sctp: fix slab corruption from use after free on INIT collisions

2015-02-24 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Daniel Borkmann 

[ Upstream commit 600ddd6825543962fb807884169e57b580dba208 ]

When hitting an INIT collision case during the 4WHS with AUTH enabled, as
already described in detail in commit 1be9a950c646 ("net: sctp: inherit
auth_capable on INIT collisions"), it can happen that we occasionally
still remotely trigger the following panic on server side which seems to
have been uncovered after the fix from commit 1be9a950c646 ...

[  533.876389] BUG: unable to handle kernel paging request at 
[  533.913657] IP: [] __kmalloc+0x95/0x230
[  533.940559] PGD 5030f2067 PUD 0
[  533.957104] Oops:  [#1] SMP
[  533.974283] Modules linked in: sctp mlx4_en [...]
[  534.939704] Call Trace:
[  534.951833]  [] ? crypto_init_shash_ops+0x60/0xf0
[  534.984213]  [] crypto_init_shash_ops+0x60/0xf0
[  535.015025]  [] __crypto_alloc_tfm+0x6d/0x170
[  535.045661]  [] crypto_alloc_base+0x4c/0xb0
[  535.074593]  [] ? _raw_spin_lock_bh+0x12/0x50
[  535.105239]  [] sctp_inet_listen+0x161/0x1e0 [sctp]
[  535.138606]  [] SyS_listen+0x9d/0xb0
[  535.166848]  [] system_call_fastpath+0x16/0x1b

... or depending on the the application, for example this one:

[ 1370.026490] BUG: unable to handle kernel paging request at 
[ 1370.026506] IP: [] kmem_cache_alloc+0x75/0x1d0
[ 1370.054568] PGD 633c94067 PUD 0
[ 1370.070446] Oops:  [#1] SMP
[ 1370.085010] Modules linked in: sctp kvm_amd kvm [...]
[ 1370.963431] Call Trace:
[ 1370.974632]  [] ? SyS_epoll_ctl+0x53f/0x960
[ 1371.000863]  [] SyS_epoll_ctl+0x53f/0x960
[ 1371.027154]  [] ? anon_inode_getfile+0xd3/0x170
[ 1371.054679]  [] ? __alloc_fd+0xa7/0x130
[ 1371.080183]  [] system_call_fastpath+0x16/0x1b

With slab debugging enabled, we can see that the poison has been overwritten:

[  669.826368] BUG kmalloc-128 (Tainted: GW ): Poison overwritten
[  669.826385] INFO: 0x880228b32e50-0x880228b32e50. First byte 0x6a 
instead of 0x6b
[  669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 
cpu=0 pid=18494
[  669.826424]  __slab_alloc+0x4bf/0x566
[  669.826433]  __kmalloc+0x280/0x310
[  669.826453]  sctp_auth_create_key+0x23/0x50 [sctp]
[  669.826471]  sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp]
[  669.826488]  sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp]
[  669.826505]  sctp_do_sm+0x29d/0x17c0 [sctp] [...]
[  669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494
[  669.826635]  __slab_free+0x39/0x2a8
[  669.826643]  kfree+0x1d6/0x230
[  669.826650]  kzfree+0x31/0x40
[  669.82]  sctp_auth_key_put+0x19/0x20 [sctp]
[  669.826681]  sctp_assoc_update+0x1ee/0x2d0 [sctp]
[  669.826695]  sctp_do_sm+0x674/0x17c0 [sctp]

Since this only triggers in some collision-cases with AUTH, the problem at
heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice
when having refcnt 1, once directly in sctp_assoc_update() and yet again
from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on
the already kzfree'd memory, which is also consistent with the observation
of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected
at a later point in time when poison is checked on new allocation).

Reference counting of auth keys revisited:

Shared keys for AUTH chunks are being stored in endpoints and associations
in endpoint_shared_keys list. On endpoint creation, a null key is being
added; on association creation, all endpoint shared keys are being cached
and thus cloned over to the association. struct sctp_shared_key only holds
a pointer to the actual key bytes, that is, struct sctp_auth_bytes which
keeps track of users internally through refcounting. Naturally, on assoc
or enpoint destruction, sctp_shared_key are being destroyed directly and
the reference on sctp_auth_bytes dropped.

User space can add keys to either list via setsockopt(2) through struct
sctp_authkey and by passing that to sctp_auth_set_key() which replaces or
adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes
with refcount 1 and in case of replacement drops the reference on the old
sctp_auth_bytes. A key can be set active from user space through setsockopt()
on the id via sctp_auth_set_active_key(), which iterates through either
endpoint_shared_keys and in case of an assoc, invokes (one of various places)
sctp_auth_asoc_init_active_key().

sctp_auth_asoc_init_active_key() computes the actual secret from local's
and peer's random, hmac and shared key parameters and returns a new key
directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops
the reference if there was a previous one. The secret, which where we
eventually double drop the ref comes from sctp_auth_asoc_set_secret() with
intitial refcount of 1, which also stays unchanged eventually in
sctp_assoc_update(). This key is later being used for crypto layer to
set the key for the hash in crypto_hash_setkey() 

[PATCH 3.10 03/16] ipv6: stop sending PTB packets for MTU < 1280

2015-02-24 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Hagen Paul Pfeifer 

[ Upstream commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2 ]

Reduce the attack vector and stop generating IPv6 Fragment Header for
paths with an MTU smaller than the minimum required IPv6 MTU
size (1280 byte) - called atomic fragments.

See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1]
for more information and how this "feature" can be misused.

[1] https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00

Signed-off-by: Fernando Gont 
Signed-off-by: Hagen Paul Pfeifer 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/route.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1141,12 +1141,9 @@ static void ip6_rt_update_pmtu(struct ds
struct net *net = dev_net(dst->dev);
 
rt6->rt6i_flags |= RTF_MODIFIED;
-   if (mtu < IPV6_MIN_MTU) {
-   u32 features = dst_metric(dst, RTAX_FEATURES);
+   if (mtu < IPV6_MIN_MTU)
mtu = IPV6_MIN_MTU;
-   features |= RTAX_FEATURE_ALLFRAG;
-   dst_metric_set(dst, RTAX_FEATURES, features);
-   }
+
dst_metric_set(dst, RTAX_MTU, mtu);
rt6_update_expires(rt6, net->ipv6.sysctl.ip6_rt_mtu_expires);
}


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


  1   2   3   4   5   6   7   8   9   10   >