Re: [PATCH] crypto: aesni_intel - fix accessing of unaligned memory

[Herbert Xu]

On Tue, Jun 11, 2013 at 10:25:22PM +0300, Jussi Kivilinna wrote:
> The new XTS code for aesni_intel uses input buffers directly as memory 
> operands
> for pxor instructions, which causes crash if those buffers are not aligned to
> 16 bytes.
> 
> Patch changes XTS code to handle unaligned memory correctly, by loading memory
> with movdqu instead.
> 
> Reported-by: Dave Jones 
> Tested-by: Dave Jones 
> Signed-off-by: Jussi Kivilinna 

Applied to crypto.  Thanks!
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/14] ARM: OMAP2+: AM43x: Kconfig

[Mohammed, Afzal]

Hi Tony,

On Wed, Jun 12, 2013 at 22:42:00, Tony Lindgren wrote:

> I've updated this patch to remove the "default y" and
> "depends on ARCH_OMAP2PLUS" entries for the usual reasons
> and applied the first ten patches into omap-for-v3.11/soc.

Thanks.

Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in
omap-for-v3.11/soc branch and omap soc pull request, can you
please help patch 10 also to go upstream.

Regards
Afzal

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] slab: prevent warnings when allocating with __GFP_NOWARN

[Pekka Enberg]

On Wed, Jun 12, 2013 at 1:34 AM, Andrew Morton
 wrote:
> __GFP_NOWARN is frequently used by kernel code to probe for "how big an
> allocation can I get".  That's a bit lame, but it's used on slow paths
> and is pretty simple.

Applied to slab/urgent, thanks guys!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] cpuset: implement sane hierarchy behaviors

[Li Zefan]

On 2013/6/10 0:03, Tejun Heo wrote:
> Hello, Li.
> 
> On Sun, Jun 09, 2013 at 05:14:02PM +0800, Li Zefan wrote:
>> v2 -> v3:
>> Currently some cpuset behaviors are not friendly when cpuset is co-mounted
>> with other cgroup controllers.
>>
>> Now with this patchset if cpuset is mounted with sane_behavior option, it
>> behaves differently:
>>
>> - Tasks will be kept in empty cpusets when hotplug happens and take masks
>> of ancestors with non-empty cpus/mems, instead of being moved to an ancestor.
>>
>> - A task can be moved into an empty cpuset, and again it takes masks of
>> ancestors, so the user can drop a task into a newly created cgroup without
>> having to do anything for it.
> 
> I applied 1-2 and the rest of the series also look correct to me and
> seem like a step in the right direction; however, I'm not quite sure
> this is the final interface we want.
> 
> * cpus/mems_allowed changing as CPUs go up and down is nasty.  There
>   should be separation between the configured CPUs and currently
>   available CPUs.  The current behavior makes sense when coupled with
>   the irreversible task migration and all.  If we're allowing tasks to
>   remain in empty cpusets, it only makes sense to retain and re-apply
>   configuration as CPUs come back online.
> 
>   I find the original behavior of changing configurations as system
>   state changes pretty weird especially because it's happening without
>   any notification making it pretty difficult to use in any sort of
>   automated way - anything which wants to wrap cpuset would have to
>   track the configuration and CPU/nodes up/down states separately on
>   its own, which is a very easy way to introduce incoherencies.
> 
> * validate_change() rejecting updates to config if any of its
>   descendants are using some is weird.  The config change should be
>   enforced in hierarchical manner too.  If the parent drops some CPUs,
>   it should simply drop those CPUs from the children.  The same in the
>   other direction, children having configs which aren't fully
>   contained inside their parents is fine as long as the effective
>   masks are correct.
> 

I've just checked other cgroup controllers, and they do behavior the
way you described. So yeah, it makes sense that cpuset behaviors
coherently.

>   IOW, validate_change() doesn't really make sense if we're keeping
>   tasks in empty cgroups.  As CPUs go down and up, we'd keep the
>   organization but lose the configuration, which is just weird.
> 
> I think what we want is expanding on this patchset so that we have
> separate "configured" and "effective" masks, which are preferably
> exposed to userland and just let the config propagation deal with
> computing the effective masks as CPUs/nodes go down/up and config
> changes.  The code actually could be simpler that way although
> there'll be complications due to the old behaviors.
> 
> What do you think?  If you agree, how should we proceed?  We can apply
> these patches and build on top if you prefer.
> 

I would prefer those patches are applied first, as the new changes can
be based on this patchset, and the changes should be quite straightforward,
and also I don't have to rebase those patches again.

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

[PATCH v2] macvlan: don't touch promisc without passthrough

[Michael S. Tsirkin]

commit df8ef8f3aaa6692970a436204c4429210addb23a
"macvlan: add FDB bridge ops and macvlan flags"
added a way to control NOPROMISC macvlan flag through netlink.

However, with a non passthrough device we never set promisc on open,
even if NOPROMISC is off.  As a result:

If userspace clears NOPROMISC on open, then does not clear it on a
netlink command, promisc counter is not decremented on stop and there
will be no way to clear it once macvlan is detached.

If userspace does not clear NOPROMISC on open, then sets NOPROMISC on a
netlink command, promisc counter will be decremented from 0 and overflow
to f with no way to clear promisc.

To fix, simply ignore NOPROMISC flag in a netlink command for
non-passthrough devices, same as we do at open/close.

Since we touch this code anyway - check dev_set_promiscuity return code
and pass it to users (though an error here is unlikely).

Cc: "David S. Miller" 
Reviewed-by: John Fastabend 
Signed-off-by: Michael S. Tsirkin 
---

Changes from v1:
minor style changes suggested by Sergei Shtylyov

 drivers/net/macvlan.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 1c502bb..6e91931 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -853,18 +853,24 @@ static int macvlan_changelink(struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
 {
struct macvlan_dev *vlan = netdev_priv(dev);
-   if (data && data[IFLA_MACVLAN_MODE])
-   vlan->mode = nla_get_u32(data[IFLA_MACVLAN_MODE]);
+
if (data && data[IFLA_MACVLAN_FLAGS]) {
__u16 flags = nla_get_u16(data[IFLA_MACVLAN_FLAGS]);
bool promisc = (flags ^ vlan->flags) & MACVLAN_FLAG_NOPROMISC;
-
-   if (promisc && (flags & MACVLAN_FLAG_NOPROMISC))
-   dev_set_promiscuity(vlan->lowerdev, -1);
-   else if (promisc && !(flags & MACVLAN_FLAG_NOPROMISC))
-   dev_set_promiscuity(vlan->lowerdev, 1);
+   if (vlan->port->passthru && promisc) {
+   int err;
+
+   if (flags & MACVLAN_FLAG_NOPROMISC)
+   err = dev_set_promiscuity(vlan->lowerdev, -1);
+   else
+   err = dev_set_promiscuity(vlan->lowerdev, 1);
+   if (err < 0)
+   return err;
+   }
vlan->flags = flags;
}
+   if (data && data[IFLA_MACVLAN_MODE])
+   vlan->mode = nla_get_u32(data[IFLA_MACVLAN_MODE]);
return 0;
 }
 
-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch 3/3] clk: Avoid re-parenting orphan clk's having invalid parent index.

[Ambresh K]

>> Sorry for not being descriptive in commit message.  
>>
>> a) Avoids unnecessary re-parenting cycle for orphan clock's with invalid 
>> parent for every clock
>>
> 
> True, but this is a minor optimisation.  If this is a big optimization
> for you then you really need to fix your bootloader.  We shouldn't be
> optimizing slow error paths just because we refuse to fix the errors.

Got it! Should be fixed in boot-loader. 

> 
>> b) With patch [1/3], after a clk with invalid parent was encountered, for 
>> every clk registered thereafter seeing following logs. 
>> 
>> [0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
>> [0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
>> [0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
>> [0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
>> [0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
>> [0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
>> [0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
>> [0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent  
>>
>> Please advice, if can be handled better. 
>>
> 
> First off, I don't think we should create new structures to work around
> bugs that should be fixed.  pr_err_once() will let us know something is
> wrong and won't flood the log.  Even then I'm inclined to say that
> flooding the log is OK and will motivate you to fix up your bootloader.
> Error prints are there for a reason.
> 
> Secondly, I spent like 10 minutes looking at this code and I'm still
> confused.  For a clock with invalid parent programming, are you adding
> it to BOTH the orphan list and the has_invalid_parent list?  Why?  Is
> this just avoid the spurious prints?  For everyone clock registered we
> walk the list of orphans to see if that orphan can be reparented.  This
> patch adds another nested list walk (likely a short list) for each of
> those orphans in the first list walk, so it starts to look like O(n^2).
> I don't like it.
> 
> I think the first two patches in the series look good, but unless I am
> misunderstanding this patch I feel that it can be dropped entirely.
> 

Thanks for your time! 
Will drop this patch and send V2 for first 2 patches. 


Regards,
Ambresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 7/7] cpuset: fix to migrate mm correctly in a corner case

[Li Zefan]

Before moving tasks out of empty cpusets, update_tasks_nodemask()
is called, which calls do_migrate_pages(xx, from, to). Then those
tasks are moved to an ancestor, and do_migrate_pages() is called
again.

The first time: from = node_to_be_offlined, to = empty.
The second time: from = empty, to = ancestor's nodemask.

so looks like no pages will be migrated.

Fix this by:

- Don't call update_tasks_nodemask() on empty cpusets.
- Pass cs->old_mems_allowed to do_migrate_pages().

v4: added comment in cpuset_hotplug_update_tasks() and rephased comment
in cpuset_attach().

Signed-off-by: Li Zefan 
---
 kernel/cpuset.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index d1d6782..3be9597 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -1563,9 +1563,18 @@ static void cpuset_attach(struct cgroup *cgrp, struct 
cgroup_taskset *tset)
struct cpuset *mems_oldcs = effective_nodemask_cpuset(oldcs);
 
mpol_rebind_mm(mm, &cpuset_attach_nodemask_to);
-   if (is_memory_migrate(cs))
-   cpuset_migrate_mm(mm, &mems_oldcs->mems_allowed,
+
+   /*
+* old_mems_allowed is the same with mems_allowed here, except
+* if this task is being moved automatically due to hotplug.
+* In that case @mems_allowed has been updated and is empty,
+* so @old_mems_allowed is the right nodesets that we migrate
+* mm from.
+*/
+   if (is_memory_migrate(cs)) {
+   cpuset_migrate_mm(mm, &mems_oldcs->old_mems_allowed,
  &cpuset_attach_nodemask_to);
+   }
mmput(mm);
}
 
@@ -2152,10 +2161,12 @@ retry:
 
/*
 * If sane_behavior flag is set, we need to update tasks' cpumask
-* for empty cpuset to take on ancestor's cpumask.
+* for empty cpuset to take on ancestor's cpumask. Otherwise, don't
+* call update_tasks_cpumask() if the cpuset becomes empty, as
+* the tasks in it will be migrated to an ancestor.
 */
if ((sane && cpumask_empty(cs->cpus_allowed)) ||
-   !cpumask_empty(&off_cpus))
+   (!cpumask_empty(&off_cpus) && !cpumask_empty(cs->cpus_allowed)))
update_tasks_cpumask(cs, NULL);
 
mutex_lock(&callback_mutex);
@@ -2164,10 +2175,12 @@ retry:
 
/*
 * If sane_behavior flag is set, we need to update tasks' nodemask
-* for empty cpuset to take on ancestor's nodemask.
+* for empty cpuset to take on ancestor's nodemask. Otherwise, don't
+* call update_tasks_nodemask() if the cpuset becomes empty, as
+* the tasks in it will be migratd to an ancestor.
 */
if ((sane && nodes_empty(cs->mems_allowed)) ||
-   !nodes_empty(off_mems))
+   (!nodes_empty(off_mems) && !nodes_empty(cs->mems_allowed)))
update_tasks_nodemask(cs, NULL);
 
is_empty = cpumask_empty(cs->cpus_allowed) ||
-- 
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fuse: hold i_mutex in fuse_file_fallocate()

[Maxim Patlasov]

Anand, Brian,

06/12/2013 11:04 PM, Anand Avati пишет:

On 6/11/13 3:59 AM, Maxim Patlasov wrote:


-if (mode & FALLOC_FL_PUNCH_HOLE) {
+if (lock_inode)
  mutex_lock(&inode->i_mutex);



+if (mode & FALLOC_FL_PUNCH_HOLE)
  fuse_set_nowrite(inode);
-}


Just for clarity, can you make the condition to check 
FALLOC_FL_PUNCH_HOLE and call to fuse_set_nowrite() nested within the 
larger if (lock_inode) { .. } block? fuse_set_nowrite() should not be 
called without i_mutex acquired. The current style of calling 
mutex_lock() and fuse_set_nowrite() in separate conditions can 
potentially cause bugs in the future if they were to get re-ordered 
due to some unrelated patch. Nesting them makes the relation more 
explicit and clear.


Thanks a lot for review. I'll post updated patch soon.

Thanks,
Maxim

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

Re: [PATCH v4] cpufreq: fix governor start/stop race condition

[Xiaoguang Chen]

2013/6/13 Viresh Kumar :
> On 13 June 2013 11:10, Xiaoguang Chen  wrote:
>> 2013/6/12 Viresh Kumar :
>>> On 12 June 2013 14:39, Xiaoguang Chen  wrote:
>>>
 ret = policy->governor->governor(policy, event);
>>>
>>> We again reached to the same problem. We shouldn't call
>>> this between taking locks, otherwise recursive locks problems
>>> would be seen again.
>>
>> But this is not the same lock as the deadlock case, it is a new lock,
>> and only used in this function. no other functions use this lock.
>> I don't know how can we get dead lock again?
>
> I believe I have seen the recursive lock issue with different locks but
> I am not sure. Anyway, I believe the implementation can be simpler than
> that.
>
> Check below patch (attached too):
>
> x--x
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2d53f47..80b9798 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -46,6 +46,7 @@ static DEFINE_PER_CPU(struct cpufreq_policy *,
> cpufreq_cpu_data);
>  static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor);
>  #endif
>  static DEFINE_RWLOCK(cpufreq_driver_lock);
> +static DEFINE_MUTEX(cpufreq_governor_lock);
>
>  /*
>   * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
> @@ -1541,7 +1542,6 @@ static int __cpufreq_governor(struct
> cpufreq_policy *policy,
>  #else
> struct cpufreq_governor *gov = NULL;
>  #endif
> -
> if (policy->governor->max_transition_latency &&
> policy->cpuinfo.transition_latency >
> policy->governor->max_transition_latency) {
> @@ -1562,6 +1562,21 @@ static int __cpufreq_governor(struct
> cpufreq_policy *policy,
>
> pr_debug("__cpufreq_governor for CPU %u, event %u\n",
> policy->cpu, event);
> +
> +   mutex_lock(&cpufreq_governor_lock);
> +   if ((!policy->governor_enabled && (event == CPUFREQ_GOV_STOP)) ||
> +   (policy->governor_enabled && (event == CPUFREQ_GOV_START))) {
> +   mutex_unlock(&cpufreq_governor_lock);
> +   return -EBUSY;
> +   }
> +
> +   if (event == CPUFREQ_GOV_STOP)
> +   policy->governor_enabled = 0;
> +   else if (event == CPUFREQ_GOV_START)
> +   policy->governor_enabled = 1;
> +
> +   mutex_unlock(&cpufreq_governor_lock);
> +
> ret = policy->governor->governor(policy, event);
>
> if (!ret) {
> @@ -1569,6 +1584,14 @@ static int __cpufreq_governor(struct
> cpufreq_policy *policy,
> policy->governor->initialized++;
> else if (event == CPUFREQ_GOV_POLICY_EXIT)
> policy->governor->initialized--;
> +   } else {
> +   /* Restore original values */
> +   mutex_lock(&cpufreq_governor_lock);
> +   if (event == CPUFREQ_GOV_STOP)
> +   policy->governor_enabled = 1;
> +   else if (event == CPUFREQ_GOV_START)
> +   policy->governor_enabled = 0;
> +   mutex_unlock(&cpufreq_governor_lock);
> }
>
> /* we keep one module reference alive for
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 037d36a..c12db73 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -107,6 +107,7 @@ struct cpufreq_policy {
> unsigned intpolicy; /* see above */
> struct cpufreq_governor *governor; /* see below */
> void*governor_data;
> +   int governor_enabled; /* governor start/stop flag 
> */
>
> struct work_struct  update; /* if update_policy() needs to be
>  * called, but you're in IRQ context 
> */

Thanks
So you add the return value checking, I was about to do it in another patch :)
this patch is simpler than my previous patch,  it is ok for me.
Do I need to submit it again or it can be merged?

Thanks
Xiaoguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG] PCI related panic on powerpc based board with 3.10-rcX

[Rojhalat Ibrahim]

On Wednesday 12 June 2013 16:50:26 Scott Wood wrote:
> On 06/12/2013 03:19:30 AM, Rojhalat Ibrahim wrote:
> > On Tuesday 11 June 2013 12:28:59 Scott Wood wrote:
> > > Yes, I figured it was non-PCIe because the code change that you said
> > > helped was on the non-PCIe branch of the if/else.  Generally it's
> > 
> > good
> > 
> > > to explicitly mention the chip you're using, though.
> > > 
> > > fsl_setup_indirect_pci should be renamed to fsl_setup_indirect_pcie.
> > > Your patch above should be applied, and fsl_setup_indirect_pcie
> > 
> > should
> > 
> > > be moved into the booke/86xx ifdef to avoid an unused function
> > 
> > warning.
> > 
> > > -Scott
> > 
> > How about this patch? It uses setup_indirect_pci for the PCI case in
> > mpc83xx_add_bridge. Additionally it adds a check in
> > fsl_setup_indirect_pci
> > to only use the modified read function in case of PCIe.
> 
> If we're adding the check to fsl_setup_indirect_pci, there's no need to
> change the 83xx call back to setup_indirect_pci.  I see that 85xx is
> also callirng fsl_setup_indirect_pci for both; it'd be good to be
> consistent.
> 
> In any case, can you send a proper patch with a signoff and commit
> message?
> 
> -Scott

Where is it called for 85xx? As far as I can tell fsl_setup_indirect_pci is 
called exactly once in fsl_add_bridge and nowhere else (after applying the
proposed patch).
For 83xx the decision between PCI and PCIe has already been made at
the point where the setup function is called. So IMO it doesn't make sense
to call fsl_setup_indirect_pci and do the check again. Moreover PCIe on 83xx
uses a completely different set of functions.

I'll send the proper patch in a separate mail.

   Rojhalat



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

Re: 3.10-rc: bluetooth disappeared on thinkpad x60 (regression)

[Johan Hedberg]

Hi Pavel,

On Wed, Jun 12, 2013, Pavel Machek wrote:
> < HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
> > HCI Event: Command Complete (0x0e) plen 68
> Read Local Supported Commands (0x04|0x0002) ncmd 1
> status 0x00
> Commands: 130f3f

As I suspected, even though the Delete Stored Link Key command is
mandatory from Bluetooth version 1.1 onwards (this controller supports
2.0) this controller doesn't have it mentioned in its supported commands
response (counting from 0 it should be bit 7 of octet 6). Therefore, it
might be possible to just move sending of this problematic command to
after receiving the supported commands response and making it
conditional to having its respective bit set in the mask. I'll be
sending another patch proposal soon.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/11] gpio: davinci: Modify to platform driver

[Philip, Avinash]

On Thu, Jun 13, 2013 at 11:47:52, Nori, Sekhar wrote:
> On 6/12/2013 5:40 PM, Philip, Avinash wrote:
> > On Wed, Jun 12, 2013 at 13:13:59, Nori, Sekhar wrote:
> >> On 6/11/2013 6:25 PM, Philip, Avinash wrote:
> >>
> >>> On Tue, Jun 11, 2013 at 17:26:06, Nori, Sekhar wrote:
> >>
>  On 5/22/2013 12:40 PM, Philip Avinash wrote:
> >>
> > @@ -179,13 +204,10 @@ static int __init davinci_gpio_setup(void)
> > gpiochip_add(&ctlrs[i].chip);
> > }
> >  
> > -   soc_info->gpio_ctlrs = ctlrs;
> 
> > -   soc_info->gpio_ctlrs_num = DIV_ROUND_UP(ngpio, 32);
> 
>  You drop setting gpio_ctlrs_num here and don't introduce it anywhere
>  else in the patchset so in effect you render the inline gpio get/set API
>  useless. Looks like this initialization should be moved to platform code?
> >>>
> >>> With [PATCH 08/11] ARM: davinci: start using gpiolib support gpio get/set 
> >>> API
> >>> Has no more dependency on soc_info->gpio_ctlrs_num.
> >>
> >> With this series, you have removed support for inline gpio get/set API.
> >> I see that the inline functions are still available for use on
> >> tnetv107x. I wonder why it is important to keep these for tnetv107x when
> >> not necessary for other DaVinci devices?
> > 
> > To support DT boot in da850, gpio davinci has to be converted to a driver 
> > and
> > remove references to davinci_soc_info from driver. But tnetv107x has 
> > separate GPIO driver and reference to davinci_soc_info can also be removed.
> > But I didn't found defconfig support for tnetv107x platforms and left 
> > untouched.
> > As I will not be able to build and test on tnetv107x, I prefer to not touch 
> > it.
> 
> You can always build it by enabling it in menuconfig. Its an ARMv6
> platform so you will have to disable other ARMv5 based platforms from
> while enabling it. ARMv5 and ARMv6 cannot co-exist in the same image.

I will try and update.

> 
> > 
> >>
> >> When you are removing this feature, please note it prominently in your
> >> cover letter and patch description.
> > 
> > Ok
> > 
> >> Also, please provide some data on 
> >> how the latency now compares to that of inline access earlier. This is
> >> important especially for the read.
> > 
> > I am not sure whether I understood correctly or not? Meanwhile I had done
> > an experiment by reading printk timing before and after gpio_get_value from
> > a test module. I think this will help in software latency for inline access 
> > over
> > gpiolib specific access.
> > 
> > gpio_get_value latency testing code
> > 
> > +
> > +   local_irq_disable();
> > +   pr_emerg("%d %x\n", __LINE__, jiffies);
> > +   gpio_get_value(gpio_num);
> > +   pr_emerg("%d %x\n", __LINE__, jiffies);
> > +   local_irq_enable();
> > 
> > inline gpio functions with interrupt disabled
> > [   29.734337] 81 966c
> > [   29.736847] 83 966c
> > 
> > Time diff = 0.00251
> > 
> > gpio library with interrupt disabled
> > 
> > [  272.876763] 81 f567
> > [  272.879291] 83 f567
> > 
> > Time diff = 0.002528
> > 
> > Inline function takes less time as expected.
> 
> Okay, please note these experiments in your cover letter. Its an 18usec
> difference. I have no reference to say if that will affect any
> application, but it will at least serve as information for someone who
> may get affected by it.

Ok I will give above details in commit message.

> 
> > 
> >> For the writes, gpio clock will
> >> mostly determine how soon the value changes on the pin.
> >>
> >> I am okay with removing the inline access feature. It helps simplify
> >> code and most arm machines don't use them. I would just like to see some
> >> data for justification as this can be seen as feature regression. Also,
> >> if we are removing it, its better to also remove it completely and get
> >> the LOC savings instead of just stopping its usage.
> > 
> > I see build failure with below patch for tnetv107x
> > [v6,6/6] Davinci: tnetv107x default configuration 
> 
> Where is this patch?

This patch is not in mainline and got it from patchwork
https://patchwork.kernel.org/patch/97853/

> What is the commit-id if it is in mainline? Where
> is the failure log?

With tnetv107x_defconfig build is failing

arch/arm/mach-davinci/board-tnetv107x-evm.c:282:15: error:
 'davinci_timer_init' undeclared here (not in a function)
arch/arm/mach-davinci/board-tnetv107x-evm.c:284:15: error:
 'davinci_init_late' undeclared here (not in a function)
make[1]: *** [arch/arm/mach-davinci/board-tnetv107x-evm.o] Error 1

Following patch fixes the build above breakage

diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c 
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index ba79837..4a9c320 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -30,6 +30,7 @@
 #include 
 #include 

+#include 
 #include 
 #include 
 #include 
@@ -147,7 +148,7 @@ static struct davinci_nand_pdata nand_

Привет

[sales]

Вы Верно воротите зрение - методика причитается абсолютно всем! 
http://goo.gl/P1lMr?/XhNsbzz Тип

Что поможет Вам всегда.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: pinctrl:when two device use the same pin

[Linus Walleij]

On Thu, Jun 13, 2013 at 4:43 AM, xulinuxkernel  wrote:

> I am using the kernel pinctrl subsystem, and I have a problem,when two
> devices use the same pin,how about the consumer devices handle the conflict
> pins? some thing like this:
> assumer the device A and B use the same pin pin0,
> device A:device
> B calling the API
> devm_pinctrl_get_select(&dev_a,"dev_a");
> devm_pinctrl_get_select(&dev_b,"dev_b");
> then the deviceB should be return error,or wait for device A  release pin0?
> like schedule()? or something else?

So you have one of two problems:

- You are trying to probe two drivers on the system, both making
  use of the same pins *at the same time*, this would obviously
  be plain wrong. In this case the solution would be not to add
  the unused device in the first place.

- You are using the same pins with two different devices at
  runtime, i.e. dev A and B actually use the same pins on the
  same one running system.

I assume it's the latter situation, which appear in a few practical
situations, such as a SD card slot being reconfigured into a debug
port becuase we want to get some non-SD-type data out on the
SD card connector. (We have this on the ux500.)

The solution to this situation is described in Documentation/pinctrl.txt
under the heading "Runtime pinmuxing", below is a copy but I think
the basic problem is that you rely on devm_pinctrl_get_select()
to be done at probe instead of retrieveing the pinctrl state handlers
and activeley switching between them at runtime using
pinctrl_select_state() which is what you should do.

Device A should have two states: one which is not using any
pins, and one where it's actively using it's pins, and the same
for device B. At runtime, the drivers shall just activate the state
using the pins when they actually do that.


Copy from Documentation/pinctrl.txt:

Runtime pinmuxing
=

It is possible to mux a certain function in and out at runtime, say to move
an SPI port from one set of pins to another set of pins. Say for example for
spi0 in the example above, we expose two different groups of pins for the same
function, but with different named in the mapping as described under
"Advanced mapping" above. So that for an SPI device, we have two states named
"pos-A" and "pos-B".

This snippet first muxes the function in the pins defined by group A, enables
it, disables and releases it, and muxes it in on the pins defined by group B:

#include 

struct pinctrl *p;
struct pinctrl_state *s1, *s2;

foo_probe()
{
/* Setup */
p = devm_pinctrl_get(&device);
if (IS_ERR(p))
...

s1 = pinctrl_lookup_state(foo->p, "pos-A");
if (IS_ERR(s1))
...

s2 = pinctrl_lookup_state(foo->p, "pos-B");
if (IS_ERR(s2))
...
}

foo_switch()
{
/* Enable on position A */
ret = pinctrl_select_state(s1);
if (ret < 0)
...

...

/* Enable on position B */
ret = pinctrl_select_state(s2);
if (ret < 0)
...

...
}

The above has to be done from process context. The reservation of the pins
will be done when the state is activated, so in effect one specific pin
can be used by different functions at different times on a running system.


Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] netlink: make compare exist all the time

[David Miller]

From: Gao feng 
Date: Thu, 13 Jun 2013 10:05:38 +0800

> Commit da12c90e099789a63073fc82a19542ce54d4efb9
> "netlink: Add compare function for netlink_table"
> only set compare at the time we create kernel netlink,
> and reset compare to NULL at the time we finially
> release netlink socket, but netlink_lookup wants
> the compare exist always.
> 
> So we should set compare after we allocate nl_table,
> and never reset it. make comapre exist all the time.
> 
> Reported-by: Fengguang Wu 
> Signed-off-by: Gao feng 

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

Re: [RFC] PTR_ERR: return 0 if ptr isn't an error value.

[Michael S. Tsirkin]

On Thu, Jun 13, 2013 at 02:07:40PM +0930, Rusty Russell wrote:
> Julia Lawall  writes:
> > On Mon, 3 Jun 2013, Uwe Kleine-König wrote:
> > For a random example, here is a function that currently uses PTR_RET:
> 
> Heheh, nice choice: I think I wrote that code originally :)
> 
> > static int __net_init iptable_raw_net_init(struct net *net)
> > {
> > struct ipt_replace *repl;
> >
> > repl = ipt_alloc_initial_table(&packet_raw);
> > if (repl == NULL)
> > return -ENOMEM;
> > net->ipv4.iptable_raw =
> > ipt_register_table(net, &packet_raw, repl);
> > kfree(repl);
> > return PTR_RET(net->ipv4.iptable_raw);
> > }
> >
> > If it becomes return PTR_ERR(...); at the end, won't it look like the 
> > function always fails?
> 
> That is a valid point, though in this case the reader will know that
> can't be the case.
> 
> On the other hand, there's an incremental learning curve cost to every
> convenience function we add.  There are only 50 places where we use
> PTR_RET(), so it's not saving us very much typing over the clearest
> solution: open-coding the test.
> 
> I think using PTR_ERR() is a less bad solution than promoting PTR_RET,
> which has a non-obvious name.
> 
> Cheers,
> Rusty.

Will a longer name make the function more obvious?
PTR_ERR_OR_ZERO() ?
PTR_ERR0() ?
PTR_ERR() can then stay simple for cases where we know we
are on the error path.

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

Re: [PATCH -next v2] dmaengine: ste_dma40: fix error return code in d40_probe()

[Linus Walleij]

On Wed, Jun 12, 2013 at 11:54 AM, Vinod Koul  wrote:

>> Let me know how you want it, I've removed it from my
>> dma40 branch for the time being.
>
> Have you removed, Also I see a v3 of this, do you want to ack that before I
> apply

Acked-by: Linus Walleij 

I haven't sent this patch to ARM SoC so it will not appear from any other source
in the merge window or cause any conflicts.

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

[PATCH] HID: i2c-hid: add DT bindings

[Benjamin Tissoires]

Add device tree based support for HID over I2C devices.

Tested on an Odroid-X board with a Synaptics touchpad.

Signed-off-by: Benjamin Tissoires 
---

Hi guys,

well, as the commit message says, this is the DT binding for HID over I2C.
I honestly don't know if it will be used besides me, but it may help others
with a DT based board.
As the spec is for ACPI only, I had no specifications regarding the DT names. So
these names can be changed if you think they are bad.

I also created a new bindings directory in the devicetree doc to reflect the
split we have between input and hid. However, if the DT experts prefer having
it under input, I'm fine with that.

Cheers,
Benjamin

 .../devicetree/bindings/hid/hid-over-i2c.txt   | 28 ++
 drivers/hid/i2c-hid/i2c-hid.c  | 44 +-
 include/linux/i2c/i2c-hid.h|  3 +-
 3 files changed, 73 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hid/hid-over-i2c.txt

diff --git a/Documentation/devicetree/bindings/hid/hid-over-i2c.txt 
b/Documentation/devicetree/bindings/hid/hid-over-i2c.txt
new file mode 100644
index 000..488edcb
--- /dev/null
+++ b/Documentation/devicetree/bindings/hid/hid-over-i2c.txt
@@ -0,0 +1,28 @@
+* HID over I2C Device-Tree bindings
+
+HID over I2C provides support for various Human Interface Devices over the
+I2C bus. These devices can be for example touchpads, keyboards, touch screens
+or sensors.
+
+The specification has been written by Microsoft and is currently available 
here:
+http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx
+
+If this binding is used, the kernel module i2c-hid will handle the 
communication
+with the device and the generic hid core layer will handle the protocol.
+
+Required properties:
+- compatible: must be "hid-over-i2c"
+- reg: i2c slave address
+- hid-descr-addr: HID descriptor address
+- interrupt-parent: the phandle for the interrupt controller
+- interrupts: interrupt line
+
+Example:
+
+   i2c-hid-dev@2c {
+   compatible = "hid-over-i2c";
+   reg = <0x2c>;
+   hid-descr-addr = <0x0020>;
+   interrupt-parent = <&gpx3>;
+   interrupts = <3 2>;
+   };
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 2b1799a..85b15a8 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -919,6 +920,42 @@ static inline int i2c_hid_acpi_pdata(struct i2c_client 
*client,
 }
 #endif
 
+#ifdef CONFIG_OF
+static int i2c_hid_of_probe(struct i2c_client *client,
+   struct i2c_hid_platform_data *pdata)
+{
+   struct device *dev = &client->dev;
+   u32 val;
+   int ret;
+
+   ret = of_property_read_u32(dev->of_node, "hid-descr-addr", &val);
+   if (ret) {
+   dev_err(&client->dev, "HID register address not provided\n");
+   return -ENODEV;
+   }
+   if (val >> 16) {
+   dev_err(&client->dev, "Bad HID register address: 0x%08x\n",
+   val);
+   return -EINVAL;
+   }
+   pdata->hid_descriptor_address = val;
+
+   return 0;
+}
+
+static const struct of_device_id i2c_hid_of_match[] = {
+   { .compatible = "hid-over-i2c" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, i2c_hid_of_match);
+#else
+static inline int i2c_hid_of_probe(struct i2c_client *client,
+   struct i2c_hid_platform_data *pdata)
+{
+   return -ENODEV;
+}
+#endif
+
 static int i2c_hid_probe(struct i2c_client *client,
 const struct i2c_device_id *dev_id)
 {
@@ -940,7 +977,11 @@ static int i2c_hid_probe(struct i2c_client *client,
if (!ihid)
return -ENOMEM;
 
-   if (!platform_data) {
+   if (client->dev.of_node) {
+   ret = i2c_hid_of_probe(client, &ihid->pdata);
+   if (ret)
+   goto err;
+   } else if (!platform_data) {
ret = i2c_hid_acpi_pdata(client, &ihid->pdata);
if (ret) {
dev_err(&client->dev,
@@ -1081,6 +1122,7 @@ static struct i2c_driver i2c_hid_driver = {
.owner  = THIS_MODULE,
.pm = &i2c_hid_pm,
.acpi_match_table = ACPI_PTR(i2c_hid_acpi_match),
+   .of_match_table = of_match_ptr(i2c_hid_of_match),
},
 
.probe  = i2c_hid_probe,
diff --git a/include/linux/i2c/i2c-hid.h b/include/linux/i2c/i2c-hid.h
index 60e411d..7aa901d 100644
--- a/include/linux/i2c/i2c-hid.h
+++ b/include/linux/i2c/i2c-hid.h
@@ -19,7 +19,8 @@
  * @hid_descriptor_address: i2c register where the HID descriptor is stored.
  *
  * Note that it is the responsibility of the platform driver (or the acpi 5.0
- * driver) to setup the irq related to the gpio in the struct i2c_board_info.
+ * driver, or the fla

[PATCH] powerpc/pci: Fix setup of Freescale PCI / PCIe controllers

[Rojhalat Ibrahim]

Commit 50d8f87d2b3 (powerpc/fsl-pci Make PCIe hotplug work with Freescale
PCIe controllers) does not handle non-PCIe controllers properly, which causes
a panic during boot for certain configurations.
This patch fixes the issue for 83xx devices by calling the proper setup 
function.
For booke/86xx devices a check is added to differentiate between PCI and PCIe
controllers.

Reported-by: Michael Guntsche 
Cc: Scott Wood 
Signed-off-by: Rojhalat Ibrahim 
---
 arch/powerpc/sysdev/fsl_pci.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 028ac1f..45670df 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -97,22 +97,23 @@ static int fsl_indirect_read_config(struct pci_bus *bus, 
unsigned int devfn,
return indirect_read_config(bus, devfn, offset, len, val);
 }
 
-static struct pci_ops fsl_indirect_pci_ops =
+static struct pci_ops fsl_indirect_pcie_ops =
 {
.read = fsl_indirect_read_config,
.write = indirect_write_config,
 };
 
+#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
+
 static void __init fsl_setup_indirect_pci(struct pci_controller* hose,
  resource_size_t cfg_addr,
  resource_size_t cfg_data, u32 flags)
 {
setup_indirect_pci(hose, cfg_addr, cfg_data, flags);
-   hose->ops = &fsl_indirect_pci_ops;
+   if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP))  /* PCIe */
+   hose->ops = &fsl_indirect_pcie_ops;
 }
 
-#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
-
 #define MAX_PHYS_ADDR_BITS 40
 static u64 pci64_dma_offset = 1ull << MAX_PHYS_ADDR_BITS;
 
@@ -814,8 +815,8 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
if (ret)
goto err0;
} else {
-   fsl_setup_indirect_pci(hose, rsrc_cfg.start,
-  rsrc_cfg.start + 4, 0);
+   setup_indirect_pci(hose, rsrc_cfg.start,
+  rsrc_cfg.start + 4, 0);
}
 
printk(KERN_INFO "Found FSL PCI host bridge at 0x%016llx. "

--
1.8.1.5

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

[PATCH] ipvs: sloppy TCP and SCTP

[Alexander Frolkin]

This adds support for sloppy TCP and SCTP modes to IPVS.

When enabled (sysctls net.ipv4.vs.sloppy_tcp and
net.ipv4.vs.sloppy_sctp), allows IPVS to create connection state on any
packet, not just a TCP SYN (or SCTP INIT).

This allows connections to fail over from one IPVS director to another
mid-flight.

Signed-off-by: Alexander Frolkin 
---
The patch is against the ipvs-next tree.

diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 4405886..22bea5d 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1002,6 +1002,8 @@ struct netns_ipvs {
int sysctl_sync_sock_size;
int sysctl_cache_bypass;
int sysctl_expire_nodest_conn;
+   int sysctl_sloppy_tcp;
+   int sysctl_sloppy_sctp;
int sysctl_expire_quiescent_template;
int sysctl_sync_threshold[2];
unsigned intsysctl_sync_refresh_period;
@@ -1044,6 +1046,8 @@ struct netns_ipvs {
 #define DEFAULT_SYNC_THRESHOLD 3
 #define DEFAULT_SYNC_PERIOD50
 #define DEFAULT_SYNC_VER   1
+#define DEFAULT_SLOPPY_TCP 0
+#define DEFAULT_SLOPPY_SCTP0
 #define DEFAULT_SYNC_REFRESH_PERIOD(0U * HZ)
 #define DEFAULT_SYNC_RETRIES   0
 #define IPVS_SYNC_WAKEUP_RATE  8
@@ -1080,6 +1084,16 @@ static inline int sysctl_sync_ver(struct netns_ipvs 
*ipvs)
return ipvs->sysctl_sync_ver;
 }
 
+static inline int sysctl_sloppy_tcp(struct netns_ipvs *ipvs)
+{
+   return ipvs->sysctl_sloppy_tcp;
+}
+
+static inline int sysctl_sloppy_sctp(struct netns_ipvs *ipvs)
+{
+   return ipvs->sysctl_sloppy_sctp;
+}
+
 static inline int sysctl_sync_ports(struct netns_ipvs *ipvs)
 {
return ACCESS_ONCE(ipvs->sysctl_sync_ports);
@@ -1133,6 +1147,16 @@ static inline int sysctl_sync_ver(struct netns_ipvs 
*ipvs)
return DEFAULT_SYNC_VER;
 }
 
+static inline int sysctl_sloppy_tcp(struct netns_ipvs *ipvs)
+{
+   return DEFAULT_SLOPPY_TCP;
+}
+
+static inline int sysctl_sloppy_sctp(struct netns_ipvs *ipvs)
+{
+   return DEFAULT_SLOPPY_SCTP;
+}
+
 static inline int sysctl_sync_ports(struct netns_ipvs *ipvs)
 {
return 1;
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 7014649..04f8cbc 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -1739,6 +1739,18 @@ static struct ctl_table vs_vars[] = {
.proc_handler   = proc_dointvec,
},
{
+   .procname   = "sloppy_tcp",
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
+   {
+   .procname   = "sloppy_sctp",
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
+   {
.procname   = "expire_quiescent_template",
.maxlen = sizeof(int),
.mode   = 0644,
@@ -3722,6 +3734,8 @@ static int __net_init 
ip_vs_control_net_init_sysctl(struct net *net)
tbl[idx++].data = &ipvs->sysctl_sync_sock_size;
tbl[idx++].data = &ipvs->sysctl_cache_bypass;
tbl[idx++].data = &ipvs->sysctl_expire_nodest_conn;
+   tbl[idx++].data = &ipvs->sysctl_sloppy_tcp;
+   tbl[idx++].data = &ipvs->sysctl_sloppy_sctp;
tbl[idx++].data = &ipvs->sysctl_expire_quiescent_template;
ipvs->sysctl_sync_threshold[0] = DEFAULT_SYNC_THRESHOLD;
ipvs->sysctl_sync_threshold[1] = DEFAULT_SYNC_PERIOD;
diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c 
b/net/netfilter/ipvs/ip_vs_proto_sctp.c
index 8646488..df29d64 100644
--- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
@@ -15,6 +15,7 @@ sctp_conn_schedule(int af, struct sk_buff *skb, struct 
ip_vs_proto_data *pd,
 {
struct net *net;
struct ip_vs_service *svc;
+   struct netns_ipvs *ipvs;
sctp_chunkhdr_t _schunkh, *sch;
sctp_sctphdr_t *sh, _sctph;
 
@@ -27,13 +28,14 @@ sctp_conn_schedule(int af, struct sk_buff *skb, struct 
ip_vs_proto_data *pd,
if (sch == NULL)
return 0;
net = skb_net(skb);
+   ipvs = net_ipvs(net);
rcu_read_lock();
-   if ((sch->type == SCTP_CID_INIT) &&
+   if ((sch->type == SCTP_CID_INIT || sysctl_sloppy_sctp(ipvs)) &&
(svc = ip_vs_service_find(net, af, skb->mark, iph->protocol,
  &iph->daddr, sh->dest))) {
int ignored;
 
-   if (ip_vs_todrop(net_ipvs(net))) {
+   if (ip_vs_todrop(ipvs)) {
/*
 * It seems that we are very loaded.
 * We have to drop this packet :(
@@ -232,21 +234,21 @@ static struct ipvs_sctp_nextstate
 * STATE : IP_VS_SCTP_S_

Re: [RFC] PTR_ERR: return 0 if ptr isn't an error value.

[Julia Lawall]

On Thu, 13 Jun 2013, Michael S. Tsirkin wrote:

> On Thu, Jun 13, 2013 at 02:07:40PM +0930, Rusty Russell wrote:
> > Julia Lawall  writes:
> > > On Mon, 3 Jun 2013, Uwe Kleine-König wrote:
> > > For a random example, here is a function that currently uses PTR_RET:
> >
> > Heheh, nice choice: I think I wrote that code originally :)
> >
> > > static int __net_init iptable_raw_net_init(struct net *net)
> > > {
> > > struct ipt_replace *repl;
> > >
> > > repl = ipt_alloc_initial_table(&packet_raw);
> > >   if (repl == NULL)
> > > return -ENOMEM;
> > > net->ipv4.iptable_raw =
> > > ipt_register_table(net, &packet_raw, repl);
> > >   kfree(repl);
> > > return PTR_RET(net->ipv4.iptable_raw);
> > > }
> > >
> > > If it becomes return PTR_ERR(...); at the end, won't it look like the
> > > function always fails?
> >
> > That is a valid point, though in this case the reader will know that
> > can't be the case.
> >
> > On the other hand, there's an incremental learning curve cost to every
> > convenience function we add.  There are only 50 places where we use
> > PTR_RET(), so it's not saving us very much typing over the clearest
> > solution: open-coding the test.
> >
> > I think using PTR_ERR() is a less bad solution than promoting PTR_RET,
> > which has a non-obvious name.
> >
> > Cheers,
> > Rusty.
>
> Will a longer name make the function more obvious?
>   PTR_ERR_OR_ZERO() ?
>   PTR_ERR0() ?
> PTR_ERR() can then stay simple for cases where we know we
> are on the error path.

I was thinking of something along those lines.  And in that case, PTR_ERR
could stay without the additional test.

julia

Re: [RFC v1] MFD: Change TWL6025 references to TWL6032

[Oleksandr Kozaruk]

On 06/07/2013 05:44 PM, g...@slimlogic.co.uk wrote:

On 2013-06-07 15:36, Mark Brown wrote:

On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote:

From: Graeme Gregory 

The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference the TWL6032 class and name the registers to twl6032 in 
line with

an actual released chip name to avoid confusion.

Currently there is no users of TWL6025 in the code.


Given that the chip exists even if not widely distributed it seems as
well to keep the twl6025 references in there at least in the device ID
table - it won't do any harm to people using the twl6032 name and might
help someone who happens to pick up an old board for whatever reason.


I do not think any "old boards" exist, it really was a limited run!

Graeme


Hello Mark, Graeme

So, what is your opinion? Could we move forward with this?

In addition, If twl6032 will be added on top of twl6025 there will be no 
guarantee

that twl6025 will work because:
- there is no HW to verify
- there is no documentation on twl6025 available, so, in case if current 
implementation is

  different from what is needed for twl6032 - it can't be handled properly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next 1/2] net: remove NET_LL_RX_POLL config menue

[Daniel Borkmann]

On 06/13/2013 04:13 AM, Eliezer Tamir wrote:

On 13/06/2013 05:01, Stephen Hemminger wrote:

On Wed, 12 Jun 2013 15:12:05 -0700 (PDT)
David Miller  wrote:


From: Eliezer Tamir 
Date: Tue, 11 Jun 2013 17:24:28 +0300


  depends on X86_TSC


Wait a second, I didn't notice this before.  There needs to be a better
way to test for the accuracy you need, or if the issue is lack of a proper
API for cycle counter reading, fix that rather than add ugly arch
specific dependencies to generic networking code.


This should be sched_clock(), rather than direct TSC access.
Also any code using TSC or sched_clock has to be carefully audited to deal with
clocks running at different rates on different CPU's. Basically value is only
meaning full on same CPU.


OK,

If we covert to sched_clock(), would adding a define such as 
HAVE_HIGH_PRECISION_CLOCK to architectures that have both a high precision 
clock and a 64 bit cycles_t be a good solution?

(if not any other suggestion?)


Hm, probably cpu_clock() and similar might be better, since they use
sched_clock() in the background when !CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
(meaning when sched_clock() provides synchronized highres time source from
the architecture), and, quoting 

 Otherwise it tries to create a semi stable clock from a mixture of other
 clocks, including:

  - GTOD (clock monotomic)
  - sched_clock()
  - explicit idle events

But yeah, it needs to be evaluated regarding the drift between CPUs in
general.

Then, eventually, you could get rid of the entire NET_LL_RX_POLL config
option plus related ifdefs in the code and have it built-in in general?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.10-rc: bluetooth disappeared on thinkpad x60 (regression)

[Johan Hedberg]

Hi Pavel,

On Thu, Jun 13, 2013, Johan Hedberg wrote:
> On Wed, Jun 12, 2013, Pavel Machek wrote:
> > < HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
> > > HCI Event: Command Complete (0x0e) plen 68
> > Read Local Supported Commands (0x04|0x0002) ncmd 1
> > status 0x00
> > Commands: 130f3f
> 
> As I suspected, even though the Delete Stored Link Key command is
> mandatory from Bluetooth version 1.1 onwards (this controller supports
> 2.0) this controller doesn't have it mentioned in its supported commands
> response (counting from 0 it should be bit 7 of octet 6). Therefore, it
> might be possible to just move sending of this problematic command to
> after receiving the supported commands response and making it
> conditional to having its respective bit set in the mask. I'll be
> sending another patch proposal soon.

I just sent a patch to linux-bluetooth for this. It would be nice if you
could revert the previous patch, apply this one instead (also attached
to this email) and let us know if it works fine.

Johan
>From b7b3eb3d3cf615d1249dc9387a619f2729cf0d84 Mon Sep 17 00:00:00 2001
From: Johan Hedberg 
Date: Thu, 13 Jun 2013 10:53:48 +0300
Subject: [PATCH] Bluetooth: Fix conditions for HCI_Delete_Stored_Link_Key

Even though the HCI_Delete_Stored_Link_Key command is mandatory for 1.1
and later controllers some controllers do not seem to support it
properly as was witnessed by one Broadcom based controller:

< HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7
bdaddr 00:00:00:00:00:00 all 1
> HCI Event: Command Complete (0x0e) plen 4
Delete Stored Link Key (0x03|0x0012) ncmd 1
status 0x11 deleted 0
Error: Unsupported Feature or Parameter Value

Luckily this same controller also doesn't list the command in its
supported commands bit mask (counting from 0 bit 7 of octet 6):

< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
> HCI Event: Command Complete (0x0e) plen 68
Read Local Supported Commands (0x04|0x0002) ncmd 1
status 0x00
Commands: 130f3f

Therefore, it makes sense to move sending of HCI_Delete_Stored_Link_Key
to after receiving the supported commands response and to only send it
if its respective bit in the mask is set. The downside of this is that
we no longer send the HCI_Delete_Stored_Link_Key command for Bluetooth
1.1 controllers since HCI_Read_Local_Supported_Command was introduced in
version 1.2, but this is an acceptable penalty as the command in
question shouldn't affect critical behavior.

Reported-by: Pavel Machek 
Signed-off-by: Johan Hedberg 
---
 net/bluetooth/hci_core.c |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d817c93..d68425c 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -341,7 +341,6 @@ static void hci_init1_req(struct hci_request *req, unsigned 
long opt)
 
 static void bredr_setup(struct hci_request *req)
 {
-   struct hci_cp_delete_stored_link_key cp;
__le16 param;
__u8 flt_type;
 
@@ -365,10 +364,6 @@ static void bredr_setup(struct hci_request *req)
param = __constant_cpu_to_le16(0x7d00);
hci_req_add(req, HCI_OP_WRITE_CA_TIMEOUT, 2, ¶m);
 
-   bacpy(&cp.bdaddr, BDADDR_ANY);
-   cp.delete_all = 0x01;
-   hci_req_add(req, HCI_OP_DELETE_STORED_LINK_KEY, sizeof(cp), &cp);
-
/* Read page scan parameters */
if (req->hdev->hci_ver > BLUETOOTH_VER_1_1) {
hci_req_add(req, HCI_OP_READ_PAGE_SCAN_ACTIVITY, 0, NULL);
@@ -602,6 +597,15 @@ static void hci_init3_req(struct hci_request *req, 
unsigned long opt)
struct hci_dev *hdev = req->hdev;
u8 p;
 
+   if (hdev->commands[6] & 0x80) {
+   struct hci_cp_delete_stored_link_key cp;
+
+   bacpy(&cp.bdaddr, BDADDR_ANY);
+   cp.delete_all = 0x01;
+   hci_req_add(req, HCI_OP_DELETE_STORED_LINK_KEY,
+   sizeof(cp), &cp);
+   }
+
if (hdev->commands[5] & 0x10)
hci_setup_link_policy(req);
 
-- 
1.7.10.4

Re: [PATCH 1/2] pinctrl: add function to parse generic pinconfig properties from a dt node

[Linus Walleij]

Tisdagen den 13:e Juni 2013 klock 12:22 AM, skrev Heiko Stübner
:
> Am Mittwoch, 12. Juni 2013, 16:55:12 schrieb James Hogan:

>> > +static struct pinconf_generic_dt_params dt_params[] = {
>> > +   { "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
>> > +   { "bias-high-impedance", PIN_CONFIG_BIAS_HIGH_IMPEDANCE, 0 },
>> > +   { "bias-bus-hold", PIN_CONFIG_BIAS_BUS_HOLD, 0 },
>> > +   { "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 0 },
>> > +   { "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 0 },
>> > +   { "bias-pull-pin-default", PIN_CONFIG_BIAS_PULL_PIN_DEFAULT, 0 },
>> > +   { "drive-push-pull", PIN_CONFIG_DRIVE_PUSH_PULL, 0 },
>> > +   { "drive-open-drain", PIN_CONFIG_DRIVE_OPEN_DRAIN, 0 },
>> > +   { "drive-open-source", PIN_CONFIG_DRIVE_OPEN_SOURCE, 0 },
>> > +   { "drive-strength", PIN_CONFIG_DRIVE_STRENGTH, 0 },
>> > +   { "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
>> > +   { "input-schmitt-disable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
>> > +   { "input-schmitt", PIN_CONFIG_INPUT_SCHMITT, 0 },
>> > +   { "input-debounce", PIN_CONFIG_INPUT_DEBOUNCE, 0 },
>> > +   { "power-source", PIN_CONFIG_POWER_SOURCE, 0 },
>> > +   { "slew-rate", PIN_CONFIG_SLEW_RATE, 0 },
>> > +   { "low-power-mode", PIN_CONFIG_LOW_POWER_MODE, 0 },
>> > +   { "output-low", PIN_CONFIG_OUTPUT, 0, },
>> > +   { "output-high", PIN_CONFIG_OUTPUT, 1, },
>>
>> shouldn't half of these default to 1 instead of 0? i.e. it's much nicer
>> for the lone flag "bias-pull-up" to enable pull up rather than disable
>> it (you even do this in the DT example in the bindings doc).
>
> on closer inspection it seems that you may be right.

Heiko can you write a patch for this? You can hit both this code and
the Rockchip driver at the same time for sure. Please check that
the bindings are consistent.

> The documentation to the
> options in the pinconf-generic header even tells that for example the pull
> options do have a 0 or 1 argument.

Yeah. Well.

Actually there has been plans to have the argument represent the
number of Ohms on the pull-up, but we haven't seen any hardware
that can actually select that.

Maybe we should add that now? It will still be that != 0 implies
enablement on platforms that does not support specifying the
pull up/down resistance.

> But I'm not sure if I understand everything correctly :-) ... isn't the bias-
> disable the opposite of turning on a pull (like the sh-pfc/pinctrl does) and
> same with switching from one pull type to another, i.e. activating a pull up
> would turn off a pull down and on the whole making the argument redundant?

This is true, and the plan is surely for the core to not allow or print
a big fat warning if someone does something really stupid like
activate pull up and pull down at the same time (unless s/he's
constructing a heater radiator or something).

Currently we don't make any sanity checks like that, BUT your
generic parser could actually be extended to do that.

Patches welcome ;-)

> The only other candidate I could find was low-power-mode which really could
> use a "1" as default. All the other pinconf options either use custom
> arguments or ignore teir argument.

A "1" for what? Not quite following

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fuse: hold i_mutex in fuse_file_fallocate() - v2

[Maxim Patlasov]

Changing size of a file on server and local update (fuse_write_update_size)
should be always protected by inode->i_mutex. Otherwise a race like this is
possible:

1. Process 'A' calls fallocate(2) to extend file (~FALLOC_FL_KEEP_SIZE).
fuse_file_fallocate() sends FUSE_FALLOCATE request to the server.
2. Process 'B' calls ftruncate(2) shrinking the file. fuse_do_setattr()
sends shrinking FUSE_SETATTR request to the server and updates local i_size
by i_size_write(inode, outarg.attr.size).
3. Process 'A' resumes execution of fuse_file_fallocate() and calls
fuse_write_update_size(inode, offset + length). But 'offset + length' was
obsoleted by ftruncate from previous step.

Changed in v2 (thanks Brian and Anand for suggestions):
 - made relation between mutex_lock() and fuse_set_nowrite(inode) more
   explicit and clear.
 - updated patch description to use ftruncate(2) in example

Signed-off-by: Maxim V. Patlasov 
---
 fs/fuse/file.c |   12 
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index e570081..35f2810 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -2470,13 +2470,16 @@ static long fuse_file_fallocate(struct file *file, int 
mode, loff_t offset,
.mode = mode
};
int err;
+   bool lock_inode = !(mode & FALLOC_FL_KEEP_SIZE) ||
+  (mode & FALLOC_FL_PUNCH_HOLE);
 
if (fc->no_fallocate)
return -EOPNOTSUPP;
 
-   if (mode & FALLOC_FL_PUNCH_HOLE) {
+   if (lock_inode) {
mutex_lock(&inode->i_mutex);
-   fuse_set_nowrite(inode);
+   if (mode & FALLOC_FL_PUNCH_HOLE)
+   fuse_set_nowrite(inode);
}
 
req = fuse_get_req_nopages(fc);
@@ -2511,8 +2514,9 @@ static long fuse_file_fallocate(struct file *file, int 
mode, loff_t offset,
fuse_invalidate_attr(inode);
 
 out:
-   if (mode & FALLOC_FL_PUNCH_HOLE) {
-   fuse_release_nowrite(inode);
+   if (lock_inode) {
+   if (mode & FALLOC_FL_PUNCH_HOLE)
+   fuse_release_nowrite(inode);
mutex_unlock(&inode->i_mutex);
}
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] macvlan: don't touch promisc without passthrough

[David Miller]

From: "Michael S. Tsirkin" 
Date: Thu, 13 Jun 2013 10:07:29 +0300

> commit df8ef8f3aaa6692970a436204c4429210addb23a
> "macvlan: add FDB bridge ops and macvlan flags"
> added a way to control NOPROMISC macvlan flag through netlink.
> 
> However, with a non passthrough device we never set promisc on open,
> even if NOPROMISC is off.  As a result:
> 
> If userspace clears NOPROMISC on open, then does not clear it on a
> netlink command, promisc counter is not decremented on stop and there
> will be no way to clear it once macvlan is detached.
> 
> If userspace does not clear NOPROMISC on open, then sets NOPROMISC on a
> netlink command, promisc counter will be decremented from 0 and overflow
> to f with no way to clear promisc.
> 
> To fix, simply ignore NOPROMISC flag in a netlink command for
> non-passthrough devices, same as we do at open/close.
> 
> Since we touch this code anyway - check dev_set_promiscuity return code
> and pass it to users (though an error here is unlikely).
> 
> Cc: "David S. Miller" 
> Reviewed-by: John Fastabend 
> Signed-off-by: Michael S. Tsirkin 

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

Re: [PATCH 0/3]

[Daniel Vetter]

On Thu, Jun 06, 2013 at 04:59:26PM +0300, Jani Nikula wrote:
> 
> With Greg's address fixed. Please drop the old one from any
> replies. Sorry for the noise.

Oops, replied with the old one still there.

Greg, Andrew: Imo it's best to merge all three patches through the same
tree, so:

Acked-by: Daniel Vetter 

on the i915 parts of it. If you want I can also slurp them in through the
intel tree, including the new dmi match code.

Thanks, Daniel

> 
> On Thu, 06 Jun 2013, Jani Nikula  wrote:
> > Hi Greg, Andrew -
> >
> > Patch 1 is for DMI, bugfixes in patches 2-3 for i915 and included for
> > completeness. After a tested-by they should be good for stable. I'll
> > leave it to Daniel to sort out how the last two get in.
> >
> > BR,
> > Jani.
> >
> > Chris Wilson (1):
> >   drm/i915: Quirk away phantom LVDS on Intel's D510MO mainboard
> >
> > Jani Nikula (2):
> >   dmi: add support for exact DMI matches in addition to substring
> > matching
> >   drm/i915: Quirk away phantom LVDS on Intel's D525MW mainboard
> >
> >  drivers/firmware/dmi_scan.c   |   12 +---
> >  drivers/gpu/drm/i915/intel_lvds.c |   16 
> >  include/linux/mod_devicetable.h   |6 --
> >  3 files changed, 29 insertions(+), 5 deletions(-)
> >
> > -- 
> > 1.7.9.5
> >
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [net-next PATCH V2 1/2] macvtap: slient sparse warnings

[David Miller]

From: Jason Wang 
Date: Thu, 13 Jun 2013 14:23:35 +0800

> This patch silents the following sparse warnings:
 ...
> Signed-off-by: Jason Wang 

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

Re: [net-next PATCH V2 2/2] macvtap: fix uninitialized return value macvtap_ioctl_set_queue()

[David Miller]

From: Jason Wang 
Date: Thu, 13 Jun 2013 14:23:36 +0800

> Return -EINVAL on illegal flag instead of uninitialized value. This fixes the
> kbuild test warning.
> 
> Signed-off-by: Jason Wang 

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

Re: [Update][PATCH] ACPI / scan: Simplify ACPI driver probing

[Aaron Lu]

On 06/10/2013 06:18 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> Subject: ACPI / scan: Simplify ACPI driver probing
> 
> There is no particular reason why acpi_bus_driver_init() needs to be
> a separate function and its location with respect to its only caller,
> acpi_device_probe(), makes the code a bit difficult to follow.
> 
> Besides, it doesn't really make sense to check if 'device' is not
> NULL in acpi_bus_driver_init(), because we've already dereferenced
> dev->driver in acpi_device_probe() at that point and, moreover,
> 'device' cannot be NULL then, because acpi_device_probe() is called
> via really_probe() (which also sets dev->driver for that matter).
> 
> For these reasons, drop acpi_bus_driver_init() altogether and move
> the remaining code from it directly into acpi_device_probe().

Tested on one desktop and two laptops, no problems found.

Thanks,
Aaron

> 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> It's in the bleeding-edge branch of the linux-pm.git tree already.
> 
> Thanks,
> Rafael
> 
> ---
>  drivers/acpi/scan.c |   81 
> +---
>  1 file changed, 27 insertions(+), 54 deletions(-)
> 
> Index: linux-pm/drivers/acpi/scan.c
> ===
> --- linux-pm.orig/drivers/acpi/scan.c
> +++ linux-pm/drivers/acpi/scan.c
> @@ -933,32 +933,40 @@ static void acpi_device_remove_notify_ha
>  acpi_device_notify);
>  }
>  
> -static int acpi_bus_driver_init(struct acpi_device *, struct acpi_driver *);
> -static int acpi_device_probe(struct device * dev)
> +static int acpi_device_probe(struct device *dev)
>  {
>   struct acpi_device *acpi_dev = to_acpi_device(dev);
>   struct acpi_driver *acpi_drv = to_acpi_driver(dev->driver);
>   int ret;
>  
> - ret = acpi_bus_driver_init(acpi_dev, acpi_drv);
> - if (!ret) {
> - if (acpi_drv->ops.notify) {
> - ret = acpi_device_install_notify_handler(acpi_dev);
> - if (ret) {
> - if (acpi_drv->ops.remove)
> - acpi_drv->ops.remove(acpi_dev);
> - acpi_dev->driver = NULL;
> - acpi_dev->driver_data = NULL;
> - return ret;
> - }
> - }
> + if (!acpi_drv->ops.add)
> + return -ENOSYS;
> +
> + ret = acpi_drv->ops.add(acpi_dev);
> + if (ret)
> + return ret;
>  
> - ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> - "Found driver [%s] for device [%s]\n",
> - acpi_drv->name, acpi_dev->pnp.bus_id));
> - get_device(dev);
> + acpi_dev->driver = acpi_drv;
> + ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> +   "Driver [%s] successfully bound to device [%s]\n",
> +   acpi_drv->name, acpi_dev->pnp.bus_id));
> +
> + if (acpi_drv->ops.notify) {
> + ret = acpi_device_install_notify_handler(acpi_dev);
> + if (ret) {
> + if (acpi_drv->ops.remove)
> + acpi_drv->ops.remove(acpi_dev);
> +
> + acpi_dev->driver = NULL;
> + acpi_dev->driver_data = NULL;
> + return ret;
> + }
>   }
> - return ret;
> +
> + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Found driver [%s] for device [%s]\n",
> +   acpi_drv->name, acpi_dev->pnp.bus_id));
> + get_device(dev);
> + return 0;
>  }
>  
>  static int acpi_device_remove(struct device * dev)
> @@ -1114,41 +1122,6 @@ static void acpi_device_unregister(struc
>   Driver Management
> 
> -- */
>  /**
> - * acpi_bus_driver_init - add a device to a driver
> - * @device: the device to add and initialize
> - * @driver: driver for the device
> - *
> - * Used to initialize a device via its device driver.  Called whenever a
> - * driver is bound to a device.  Invokes the driver's add() ops.
> - */
> -static int
> -acpi_bus_driver_init(struct acpi_device *device, struct acpi_driver *driver)
> -{
> - int result = 0;
> -
> - if (!device || !driver)
> - return -EINVAL;
> -
> - if (!driver->ops.add)
> - return -ENOSYS;
> -
> - result = driver->ops.add(device);
> - if (result)
> - return result;
> -
> - device->driver = driver;
> -
> - /*
> -  * TBD - Configuration Management: Assign resources to device based
> -  * upon possible configuration and currently allocated resources.
> -  */
> -
> - ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> -   "Driver successfully bound to device\n"));
> - return 0;
> -}
> -
> -/**
>   * acpi_bus_register_driver - register a driver with the ACPI bus
>   * @dr

Re: [PATCH V3] irqchip: Add TB10x interrupt controller driver

[Christian Ruppert]

On Sat, Jun 01, 2013 at 01:01:33PM +0200, Christian Ruppert wrote:
> On Fri, May 31, 2013 at 11:18:14PM +0100, Grant Likely wrote:
> > On Fri, 31 May 2013 19:32:34 +0200 (CEST), Thomas Gleixner 
> >  wrote:
> > > On Fri, 31 May 2013, Christian Ruppert wrote:
> > > 
> > > > The SOC interrupt controller driver for the Abilis Systems TB10x series 
> > > > of
> > > > SOCs based on ARC700 CPUs.
> > > > 
> > > > This patch depends on commits eb76bdd407d8a90e59a06cb0158886df390e5d1c 
> > > > and
> > > > 712bc93df9e7f14b8a163148d2aa7c778e151627 from branch irq/for-arm of
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git.
> > > 
> > > That branch can be pulled into ARC as well. It only contains the
> > > changes, which are necessary for the irq domain support of the generic
> > > irq chip.
> 
> Vineet, what do you think about this? For the moment I have pulled the
> patch set into our local branch and to me it doesn't matter, we just
> have to make sure to respect this dependency when merging everything
> together.
> 
> > > > +static void tb10x_irq_cascade(unsigned int irq, struct irq_desc *desc)
> > > > +{
> > > > +   struct irq_domain *domain = irq_desc_get_handler_data(desc);
> > > > +
> > > > +   generic_handle_irq(irq_find_mapping(domain, irq));
> > > > +}
> > > 
> > > ...
> > > 
> > > > +   for (i = 0; i < nrirqs; i++) {
> > > > +   unsigned int irq = irq_of_parse_and_map(ictl, i);
> > > > +
> > > > +   irq_set_handler_data(irq, domain);
> > > > +   irq_set_chained_handler(irq, tb10x_irq_cascade);
> > > > +   }
> > > 
> > > I might be completely confused, but this does not make any sense at
> > > all.
> > > 
> > > You allocate a linear domain and then map the interrupts in the
> > > domain. The mapping function retrieves the hardware interrupt number
> > > and creates a virtual interrupt number, installs the chip and the
> > > handler for the interrupt and finally returns the virtual interrupt
> > > number.
> > > 
> > > Now you take that virtual interrupt number and install
> > > tb10x_irq_cascade as the handler. irq_set_chained_handler() will
> > > startup (unmask) the interrupt right away.
> > > 
> > > In the cascade handler you take the virtual interrupt number, which
> > > you get as argument, and find the mapping, i.e. the matching VIRTUAL
> > > interrupt number for the VIRTUAL interrupt number and then call the
> > > handler.
> > > 
> > > How is this supposed to work?
> > 
> > I think what is going on here is that the tb10x interrupt controller
> > appears to be more of a front-end to another interrupt controller with
> > each input wired up 1:1 to the interrupt inputs of the other controller.
> 
> Exactly. The TB10x interrupt controller is a front-end for the ARC CPU
> built-in interrupt controller.
> 
> > (I don't know why someone would design an interrupt controller that way,
> > but that's another issue).
> 
> There are several technical reasons for this front-end. The one that
> concerns us most in the kernel is that the TB10x front-end does the
> translation from all kinds of interrupt trigger modes to the level
> triggered interrupts natively understood by the ARC CPU built-in
> controller.
> 
> > The loop above is mapping each of the
> > interrupt inputs on the parent controller so that each child controller
> > can be chained to it as an input. I can't think of how else it could be
> > set up with the current code if the drivers were kept separate.
> 
> This is exactly the intention. I haven't found an easier way to do this
> either but I'm open to suggestions. Btw, I have noticed that the parent
> controller interrupts from this loop are not listed in /proc/interrupts.
> I'm not sure if what is done in the loop is sufficient or if I should
> add something else (the naive option of using request_irq doesn't work,
> the kernel saying something in the lines of "irq XX triggered but noone
> cares").
> 
> > Christian, what is the parent interrupt controller for this SoC? It
> > really feels like the tb10x-ictl belongs as part of the parent
> > controller. I went and looked at the parent node, and I saw this:
> > 
> > intc: interrupt-controller {
> > compatible = "snps,arc700-intc";
> > interrupt-controller;
> > #interrupt-cells = <1>;
> > };
> > 
> > I noticed the conspicuous absence of a reg property. Is this something
> > architectural?
> 
> The parent controller is part of the CPU itself, see
> arch/arc/kernel/irq.c. This controller is maintained by Vineet and IMHO
> we should keep it separate from the TB10x one since it is implicitly
> used in all ARC-based platforms whereas the TB10x controller is used in
> Abilis chips only.
> 
> > If I were working on this system I'd drop the
> > snps,arc700-intc node entirely and have a single abilis,tb10x-intc that
> > encapsulated the properties of both (you would of course want to 

Re: [PATCH] ipvs: sloppy TCP and SCTP

[Julian Anastasov]

Hello,

On Thu, 13 Jun 2013, Alexander Frolkin wrote:

> This adds support for sloppy TCP and SCTP modes to IPVS.
> 
> When enabled (sysctls net.ipv4.vs.sloppy_tcp and
> net.ipv4.vs.sloppy_sctp), allows IPVS to create connection state on any
> packet, not just a TCP SYN (or SCTP INIT).
> 
> This allows connections to fail over from one IPVS director to another
> mid-flight.
> 
> Signed-off-by: Alexander Frolkin 

Thanks! Simon, please apply to ipvs-next tree!

Signed-off-by: Julian Anastasov 

> ---
> The patch is against the ipvs-next tree.
> 
> diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> index 4405886..22bea5d 100644
> --- a/include/net/ip_vs.h
> +++ b/include/net/ip_vs.h
> @@ -1002,6 +1002,8 @@ struct netns_ipvs {
>   int sysctl_sync_sock_size;
>   int sysctl_cache_bypass;
>   int sysctl_expire_nodest_conn;
> + int sysctl_sloppy_tcp;
> + int sysctl_sloppy_sctp;
>   int sysctl_expire_quiescent_template;
>   int sysctl_sync_threshold[2];
>   unsigned intsysctl_sync_refresh_period;
> @@ -1044,6 +1046,8 @@ struct netns_ipvs {
>  #define DEFAULT_SYNC_THRESHOLD   3
>  #define DEFAULT_SYNC_PERIOD  50
>  #define DEFAULT_SYNC_VER 1
> +#define DEFAULT_SLOPPY_TCP   0
> +#define DEFAULT_SLOPPY_SCTP  0
>  #define DEFAULT_SYNC_REFRESH_PERIOD  (0U * HZ)
>  #define DEFAULT_SYNC_RETRIES 0
>  #define IPVS_SYNC_WAKEUP_RATE8
> @@ -1080,6 +1084,16 @@ static inline int sysctl_sync_ver(struct netns_ipvs 
> *ipvs)
>   return ipvs->sysctl_sync_ver;
>  }
>  
> +static inline int sysctl_sloppy_tcp(struct netns_ipvs *ipvs)
> +{
> + return ipvs->sysctl_sloppy_tcp;
> +}
> +
> +static inline int sysctl_sloppy_sctp(struct netns_ipvs *ipvs)
> +{
> + return ipvs->sysctl_sloppy_sctp;
> +}
> +
>  static inline int sysctl_sync_ports(struct netns_ipvs *ipvs)
>  {
>   return ACCESS_ONCE(ipvs->sysctl_sync_ports);
> @@ -1133,6 +1147,16 @@ static inline int sysctl_sync_ver(struct netns_ipvs 
> *ipvs)
>   return DEFAULT_SYNC_VER;
>  }
>  
> +static inline int sysctl_sloppy_tcp(struct netns_ipvs *ipvs)
> +{
> + return DEFAULT_SLOPPY_TCP;
> +}
> +
> +static inline int sysctl_sloppy_sctp(struct netns_ipvs *ipvs)
> +{
> + return DEFAULT_SLOPPY_SCTP;
> +}
> +
>  static inline int sysctl_sync_ports(struct netns_ipvs *ipvs)
>  {
>   return 1;
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 7014649..04f8cbc 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -1739,6 +1739,18 @@ static struct ctl_table vs_vars[] = {
>   .proc_handler   = proc_dointvec,
>   },
>   {
> + .procname   = "sloppy_tcp",
> + .maxlen = sizeof(int),
> + .mode   = 0644,
> + .proc_handler   = proc_dointvec,
> + },
> + {
> + .procname   = "sloppy_sctp",
> + .maxlen = sizeof(int),
> + .mode   = 0644,
> + .proc_handler   = proc_dointvec,
> + },
> + {
>   .procname   = "expire_quiescent_template",
>   .maxlen = sizeof(int),
>   .mode   = 0644,
> @@ -3722,6 +3734,8 @@ static int __net_init 
> ip_vs_control_net_init_sysctl(struct net *net)
>   tbl[idx++].data = &ipvs->sysctl_sync_sock_size;
>   tbl[idx++].data = &ipvs->sysctl_cache_bypass;
>   tbl[idx++].data = &ipvs->sysctl_expire_nodest_conn;
> + tbl[idx++].data = &ipvs->sysctl_sloppy_tcp;
> + tbl[idx++].data = &ipvs->sysctl_sloppy_sctp;
>   tbl[idx++].data = &ipvs->sysctl_expire_quiescent_template;
>   ipvs->sysctl_sync_threshold[0] = DEFAULT_SYNC_THRESHOLD;
>   ipvs->sysctl_sync_threshold[1] = DEFAULT_SYNC_PERIOD;
> diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c 
> b/net/netfilter/ipvs/ip_vs_proto_sctp.c
> index 8646488..df29d64 100644
> --- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
> +++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
> @@ -15,6 +15,7 @@ sctp_conn_schedule(int af, struct sk_buff *skb, struct 
> ip_vs_proto_data *pd,
>  {
>   struct net *net;
>   struct ip_vs_service *svc;
> + struct netns_ipvs *ipvs;
>   sctp_chunkhdr_t _schunkh, *sch;
>   sctp_sctphdr_t *sh, _sctph;
>  
> @@ -27,13 +28,14 @@ sctp_conn_schedule(int af, struct sk_buff *skb, struct 
> ip_vs_proto_data *pd,
>   if (sch == NULL)
>   return 0;
>   net = skb_net(skb);
> + ipvs = net_ipvs(net);
>   rcu_read_lock();
> - if ((sch->type == SCTP_CID_INIT) &&
> + if ((sch->type == SCTP_CID_INIT || sysctl_sloppy_sctp(ipvs)) &&
>   (svc = ip_vs_service_find(net, af, skb->mark, iph->protocol,
> &iph->daddr, sh->dest))) {
>   int ignored;
>  
> - if (ip_v

Re: [PATCH 03/11] gpio: davinci: Modify to platform driver

[Sekhar Nori]

On 6/13/2013 1:02 PM, Philip, Avinash wrote:

> With tnetv107x_defconfig build is failing
> 
> arch/arm/mach-davinci/board-tnetv107x-evm.c:282:15: error:
>  'davinci_timer_init' undeclared here (not in a function)
> arch/arm/mach-davinci/board-tnetv107x-evm.c:284:15: error:
>  'davinci_init_late' undeclared here (not in a function)
> make[1]: *** [arch/arm/mach-davinci/board-tnetv107x-evm.o] Error 1
> 
> Following patch fixes the build above breakage

The error you are seeing and the patch you provided below have no
correlation.

> 
> diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c 
> b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> index ba79837..4a9c320 100644
> --- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
> +++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -147,7 +148,7 @@ static struct davinci_nand_pdata nand_config = {
> .ecc_bits   = 1,
>  };
> 
> -static struct davinci_uart_config serial_config __initconst = {
> +static struct davinci_uart_config serial_config = {
> .enabled_uarts  = BIT(1),
>  };

You can make this __initdata instead - assuming its okay to have this
memory discarded at init.

> 
> @@ -245,7 +246,7 @@ static struct ti_ssp_data ssp_config = {
> },
>  };
> 
> -static struct tnetv107x_device_info evm_device_info __initconst = {
> +static struct tnetv107x_device_info evm_device_info = {

Same here. You can make this __initdata.

Please send a formal patch for the errors you have seen.

> .serial_config  = &serial_config,
> .mmc_config[1]  = &mmc_config,  /* controller 1 */
> .nand_config[0] = &nand_config, /* chip select 0 */
> 
> 
> 
>>
>>>
>>> So I prefer to leave tnetv107x platform for now.
>>
>> I don't think that's acceptable. At least by me.
> 
> I think 2 options are available
> 1. Convert gpio-tnetv107x.c to platform driver. This will help in
>   removing gpio references in davinci_soc_info structure.
> 2. Remove inline gpio api support and start use gpiolib support.
> 
> I prefer first option. It will help in removing
> .

Okay. Can you take this up in this series? I understand you may not have
an tnetv107x board, but at least you can get to a series that builds.

Even if you choose to do just option #2, I am OK. What I really want to
see is inline API gone completely (not just remain largely unused). This
will also help you avoid exposing internal data structures like
davinci_gpio_controller exposed to the whole kernel. The worse part
right now is you have two copies of the same structure exposed globally
from two different include folders.

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

Re: [PATCH] drivers/net/ethernet/3com: Drop EISA dependency from VORTEX

[David Miller]

From: Sergei Shtylyov 
Date: Wed, 12 Jun 2013 00:45:54 +0400

>We have the user of 3Com EISA cards on this list and I've fixed EISA
> specific bug in this driver not long ago.

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

Re: [PATCH] drivers/net/ethernet/3com: Drop EISA dependency from VORTEX

[Markos Chandras]

On 06/13/13 09:34, David Miller wrote:

From: Sergei Shtylyov 
Date: Wed, 12 Jun 2013 00:45:54 +0400


We have the user of 3Com EISA cards on this list and I've fixed EISA
specific bug in this driver not long ago.


Then I obviously must reject this patch.


Hi David,

Yes please reject this patch

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

[PATCH v3 0/2] dmaengine: at_hdmac: dt dma bindings update

[ludovic.desroches]

From: Ludovic Desroches 

Vinod,

This version removes the extra tab in patch 2/2 and add Arnd's ack.


Thanks

Regards

Ludovic


This set of patches update the dt dma binding for at_hdmac since we need one
more parameter. In order to keep backward compatibility, an existing cell will
be used to add this parameter. Since the content of that cell will become a
magic value due to the concatenation of the two parameters, it is time to
use macros.

v3:
- remove extra tab in patch 2/2
v2:
- rebased on slave-dma/next


Ludovic Desroches (2):
  ARM: at91: dt: add header to define at_hdmac configuration
  at_hdmac: add FIFO configuration parameter to DMA DT binding

 .../devicetree/bindings/dma/atmel-dma.txt  |  7 --
 drivers/dma/at_hdmac.c | 25 
 include/dt-bindings/dma/at91.h | 27 ++
 3 files changed, 53 insertions(+), 6 deletions(-)
 create mode 100644 include/dt-bindings/dma/at91.h

-- 
1.7.11.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 v3 2/2] at_hdmac: add FIFO configuration parameter to DMA DT binding

[ludovic.desroches]

From: Ludovic Desroches 

For most devices the FIFO configuration is the same i.e. when half FIFO size is
available/filled, a source/destination request is serviced. But USART devices
have to do it when there is enough space/data available to perform a single
AHB access so the ASAP configuration.

Acked-by: Nicolas Ferre 
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 
Signed-off-by: Ludovic Desroches 
---
 .../devicetree/bindings/dma/atmel-dma.txt  |  7 --
 drivers/dma/at_hdmac.c | 25 ++
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt 
b/Documentation/devicetree/bindings/dma/atmel-dma.txt
index c80e8a3..c280a0e 100644
--- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
+++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
@@ -24,8 +24,11 @@ The three cells in order are:
 1. A phandle pointing to the DMA controller.
 2. The memory interface (16 most significant bits), the peripheral interface
 (16 less significant bits).
-3. The peripheral identifier for the hardware handshaking interface. The
-identifier can be different for tx and rx.
+3. Parameters for the at91 DMA configuration register which are device
+dependant:
+  - bit 7-0: peripheral identifier for the hardware handshaking interface. The
+  identifier can be different for tx and rx.
+  - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 1 for ASAP.
 
 Example:
 
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 6db5228..b7050a4 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -14,6 +14,7 @@
  * found on AT91SAM9263.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1320,15 +1321,31 @@ static struct dma_chan *at_dma_xlate(struct 
of_phandle_args *dma_spec,
atslave = devm_kzalloc(&dmac_pdev->dev, sizeof(*atslave), GFP_KERNEL);
if (!atslave)
return NULL;
+
+   atslave->cfg = ATC_DST_H2SEL_HW | ATC_SRC_H2SEL_HW;
/*
 * We can fill both SRC_PER and DST_PER, one of these fields will be
 * ignored depending on DMA transfer direction.
 */
-   per_id = dma_spec->args[1];
-   atslave->cfg = ATC_FIFOCFG_HALFFIFO
-| ATC_DST_H2SEL_HW | ATC_SRC_H2SEL_HW
-| ATC_DST_PER_MSB(per_id) | ATC_DST_PER(per_id)
+   per_id = dma_spec->args[1] & AT91_DMA_CFG_PER_ID_MASK;
+   atslave->cfg |= ATC_DST_PER_MSB(per_id) | ATC_DST_PER(per_id)
 | ATC_SRC_PER_MSB(per_id) | ATC_SRC_PER(per_id);
+   /*
+* We have to translate the value we get from the device tree since
+* the half FIFO configuration value had to be 0 to keep backward
+* compatibility.
+*/
+   switch (dma_spec->args[1] & AT91_DMA_CFG_FIFOCFG_MASK) {
+   case AT91_DMA_CFG_FIFOCFG_ALAP:
+   atslave->cfg |= ATC_FIFOCFG_LARGESTBURST;
+   break;
+   case AT91_DMA_CFG_FIFOCFG_ASAP:
+   atslave->cfg |= ATC_FIFOCFG_ENOUGHSPACE;
+   break;
+   case AT91_DMA_CFG_FIFOCFG_HALF:
+   default:
+   atslave->cfg |= ATC_FIFOCFG_HALFFIFO;
+   }
atslave->dma_dev = &dmac_pdev->dev;
 
chan = dma_request_channel(mask, at_dma_filter, atslave);
-- 
1.7.11.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 v4] cpufreq: fix governor start/stop race condition

[Viresh Kumar]

On 13 June 2013 12:49, Xiaoguang Chen  wrote:

> So you add the return value checking, I was about to do it in another patch :)

What? I couldn't related that statement to my code.

> this patch is simpler than my previous patch,  it is ok for me.
> Do I need to submit it again or it can be merged?

Yeah.. Send this patch as another version so that Rafael can easily pick it
up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/2] ARM: at91: dt: add header to define at_hdmac configuration

[ludovic.desroches]

From: Ludovic Desroches 

DMA-cell content is a concatenation of several values. In order to keep this
stuff human readable, macros are introduced.

The values for the FIFO configuration are not the same as the ones used in the
configuration register in order to keep backward compatibility. Most devices
use the half FIFO configuration but USART ones have to use the ASAP
configuration. This parameter was not initially planed to be into the at91 dma
dt binding. The third cell will be used to store this parameter, it will
become a concatenation of the FIFO configuration and of the peripheral ID. In
order to keep backward compatibility i.e. FIFO configuration is equal to 0, we
have to perform a translation since the value to put in the register to set
half FIFO is 1.

Acked-by: Arnd Bergmann 
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 
Signed-off-by: Ludovic Desroches 
---
 include/dt-bindings/dma/at91.h | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 include/dt-bindings/dma/at91.h

diff --git a/include/dt-bindings/dma/at91.h b/include/dt-bindings/dma/at91.h
new file mode 100644
index 000..e835037
--- /dev/null
+++ b/include/dt-bindings/dma/at91.h
@@ -0,0 +1,27 @@
+/*
+ * This header provides macros for at91 dma bindings.
+ *
+ * Copyright (C) 2013 Ludovic Desroches 
+ *
+ * GPLv2 only
+ */
+
+#ifndef __DT_BINDINGS_AT91_DMA_H__
+#define __DT_BINDINGS_AT91_DMA_H__
+
+/*
+ * Source and/or destination peripheral ID
+ */
+#define AT91_DMA_CFG_PER_ID_MASK   (0xff)
+#define AT91_DMA_CFG_PER_ID(id)(id & AT91_DMA_CFG_PER_ID_MASK)
+
+/*
+ * FIFO configuration: it defines when a request is serviced.
+ */
+#define AT91_DMA_CFG_FIFOCFG_OFFSET(8)
+#define AT91_DMA_CFG_FIFOCFG_MASK  (0xf << AT91_DMA_CFG_FIFOCFG_OFFSET)
+#define AT91_DMA_CFG_FIFOCFG_HALF  (0x0 << AT91_DMA_CFG_FIFOCFG_OFFSET)
/* half FIFO (default behavior) */
+#define AT91_DMA_CFG_FIFOCFG_ALAP  (0x1 << AT91_DMA_CFG_FIFOCFG_OFFSET)
/* largest defined AHB burst */
+#define AT91_DMA_CFG_FIFOCFG_ASAP  (0x2 << AT91_DMA_CFG_FIFOCFG_OFFSET)
/* single AHB access */
+
+#endif /* __DT_BINDINGS_AT91_DMA_H__ */
-- 
1.7.11.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 00/32] ARM: ux500: Enable clocks for Device Tree

[Linus Walleij]

On Wed, Jun 12, 2013 at 3:27 PM, Lee Jones  wrote:
>> After this patchset has been applied, we can request clocks directly
>> from Device Tree without using any AUXDATA device-name hacks. We also
>> take care to remove all of thos at the end of the set.
>
> So it looks like Mike and Grant have okayed the actual design of this
> patch-set, which is great. Is there any chance on some proper Acks from
> Linus and Mike please?

I will get to it. Basically I don't see there is a hurry as this has
no chance to hit the v3.11 merge window anyway so we'll have
lots of time to discuss it.

Why 3.12: my five pull request for ux500 stuff to ARM SoC is still
outstanding, and this stuff will clash with that unless we get
a common merge base. So we have to wait for ARM SoC
to settle at this point.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 9/9] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

[Kishon Vijay Abraham I]

Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/phy/phy-twl4030-usb.c |   55 -
 1 file changed, 12 insertions(+), 43 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index fba9697..5245b86 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl, 
int on)
}
 }
 
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
 {
+   struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
if (twl->asleep)
-   return;
+   return 0;
 
twl4030_phy_power(twl, 0);
twl->asleep = 1;
dev_dbg(twl->dev, "%s\n", __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
-   struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
-
-   twl4030_phy_suspend(twl, 0);
return 0;
 }
 
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
 {
twl4030_phy_power(twl, 1);
twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
twl4030_i2c_access(twl, 0);
 }
 
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
 {
+   struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
if (!twl->asleep)
-   return;
-   __twl4030_phy_resume(twl);
+   return 0;
+   __twl4030_phy_power_on(twl);
twl->asleep = 0;
dev_dbg(twl->dev, "%s\n", __func__);
 
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
cancel_delayed_work(&twl->id_workaround_work);
schedule_delayed_work(&twl->id_workaround_work, HZ);
}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
-   struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
-
-   twl4030_phy_resume(twl);
return 0;
 }
 
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct 
*work)
}
 }
 
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
 {
-   struct twl4030_usb *twl = phy_to_twl(phy);
+   struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
enum omap_musb_vbus_id_status status;
 
/*
@@ -628,25 +618,6 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
return 0;
 }
 
-static int twl4030_phy_init(struct phy *phy)
-{
-   struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
-
-   return twl4030_usb_phy_init(&twl->phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
-   struct twl4030_usb *twl = phy_to_twl(x);
-
-   if (suspend)
-   twl4030_phy_suspend(twl, 1);
-   else
-   twl4030_phy_resume(twl);
-
-   return 0;
-}
-
 static int twl4030_set_peripheral(struct usb_otg *otg,
struct usb_gadget *gadget)
 {
@@ -717,8 +688,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl->phy.label  = "twl4030";
twl->phy.otg= otg;
twl->phy.type   = USB_PHY_TYPE_USB2;
-   twl->phy.set_suspend= twl4030_set_suspend;
-   twl->phy.init   = twl4030_usb_phy_init;
 
otg->phy= &twl->phy;
otg->set_host   = twl4030_set_host;
-- 
1.7.10.4

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

[PATCH v7 3/9] usb: phy: twl4030: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed.

However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/phy/phy-twl4030-usb.c |   48 -
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..65a5e43 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -431,6 +432,14 @@ static void twl4030_phy_suspend(struct twl4030_usb *twl, 
int controller_off)
dev_dbg(twl->dev, "%s\n", __func__);
 }
 
+static int twl4030_phy_power_off(struct phy *phy)
+{
+   struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+   twl4030_phy_suspend(twl, 0);
+   return 0;
+}
+
 static void __twl4030_phy_resume(struct twl4030_usb *twl)
 {
twl4030_phy_power(twl, 1);
@@ -459,6 +468,14 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
}
 }
 
+static int twl4030_phy_power_on(struct phy *phy)
+{
+   struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+   twl4030_phy_resume(twl);
+   return 0;
+}
+
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 {
/* Enable writing to power configuration registers */
@@ -602,13 +619,22 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
status = twl4030_usb_linkstat(twl);
twl->linkstat = status;
 
-   if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
+   if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
omap_musb_mailbox(twl->linkstat);
+   twl4030_phy_power_on(phy);
+   }
 
sysfs_notify(&twl->dev->kobj, NULL, "vbus");
return 0;
 }
 
+static int twl4030_phy_init(struct phy *phy)
+{
+   struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+   return twl4030_usb_phy_init(&twl->phy);
+}
+
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
 {
struct twl4030_usb *twl = phy_to_twl(x);
@@ -646,13 +672,22 @@ static int twl4030_set_host(struct usb_otg *otg, struct 
usb_bus *host)
return 0;
 }
 
+static const struct phy_ops ops = {
+   .init   = twl4030_phy_init,
+   .power_on   = twl4030_phy_power_on,
+   .power_off  = twl4030_phy_power_off,
+   .owner  = THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
struct twl4030_usb_data *pdata = pdev->dev.platform_data;
struct twl4030_usb  *twl;
+   struct phy  *phy;
int status, err;
struct usb_otg  *otg;
struct device_node  *np = pdev->dev.of_node;
+   struct phy_provider *phy_provider;
 
twl = devm_kzalloc(&pdev->dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -689,6 +724,17 @@ static int twl4030_usb_probe(struct platform_device *pdev)
otg->set_host   = twl4030_set_host;
otg->set_peripheral = twl4030_set_peripheral;
 
+   phy_provider = devm_of_phy_provider_register(twl->dev, THIS_MODULE,
+   of_phy_simple_xlate);
+   if (IS_ERR(phy_provider))
+   return PTR_ERR(phy_provider);
+
+   phy = devm_phy_create(twl->dev, 0, &ops, "twl4030", twl);
+   if (IS_ERR(phy)) {
+   dev_dbg(&pdev->dev, "Failed to create PHY\n");
+   return PTR_ERR(phy);
+   }
+
/* init spinlock for workqueue */
spin_lock_init(&twl->lock);
 
-- 
1.7.10.4

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

Re: 3.10-rc: bluetooth disappeared on thinkpad x60 (regression)

[Pavel Machek]

On Thu 2013-06-13 11:04:42, Johan Hedberg wrote:
> Hi Pavel,
> 
> On Thu, Jun 13, 2013, Johan Hedberg wrote:
> > On Wed, Jun 12, 2013, Pavel Machek wrote:
> > > < HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
> > > > HCI Event: Command Complete (0x0e) plen 68
> > > Read Local Supported Commands (0x04|0x0002) ncmd 1
> > > status 0x00
> > > Commands: 130f3f
> > 
> > As I suspected, even though the Delete Stored Link Key command is
> > mandatory from Bluetooth version 1.1 onwards (this controller supports
> > 2.0) this controller doesn't have it mentioned in its supported commands
> > response (counting from 0 it should be bit 7 of octet 6). Therefore, it
> > might be possible to just move sending of this problematic command to
> > after receiving the supported commands response and making it
> > conditional to having its respective bit set in the mask. I'll be
> > sending another patch proposal soon.
> 
> I just sent a patch to linux-bluetooth for this. It would be nice if you
> could revert the previous patch, apply this one instead (also attached
> to this email) and let us know if it works fine.

Patch works for me, thanks!

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 0/9] Generic PHY Framework

[Kishon Vijay Abraham I]

Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle.

This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded within the controller).

The intention of creating this framework is to bring the phy drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and to
increase code maintainability.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

If the PHY driver has to send notification on connect/disconnect, the PHY
driver should make use of the extcon framework. Using this susbsystem 
to use extcon framwork will have to be analysed.

Making omap-usb2 and twl4030 to use this framework is provided as a sample.

This patch series is developed on linux mainline tree.

Changes from v6
* corrected few typos in Documentation
* Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when
  PHY Subsystem is kept as module and the dependent modules are built-in)
* Added if pm_runtime_enabled check before runtime pm calls.

Changes from v5:
* removed the new sysfs entries as it dint have any new information other than
  what is already there in /sys/devices/...
* removed a bunch of APIs added to get the PHY and now only phy_get and
  devm_phy_get are used.
* Added new APIs to register/unregister the PHY provider. This is needed for
  dt boot case.
* Enabled pm runtime and incorporated the comments given by Alan Stern in a
  different patch series by Gautam.
* Removed the *phy_bind* API. Now the phy binding information should be passed
  using the platform data to the controller devices.
* Fixed a few typos.

Changes from v4:
* removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy 
providers*
  should use their custom implementation of of_xlate or use of_phy_xlate to get
  *phy instance* from *phy providers*.
* Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
* changed phy_core from having subsys_initcall to module_init.
* other minor fixes.

Changes from v3:
* Changed the return value of PHY APIs to ENOSYS
* Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting
  PHYs if the same IP implements multiple PHYs.
* modified phy_bind API so that the binding information can now be _updated_.
  In effect of this removed the binding information added in board files and
  added only in usb-musb.c. If a particular board uses a different phy binding,
  it can update it in board file after usb_musb_init().
* Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding
  information.

Changes from v2:
* removed phy_descriptor structure completely so changed the APIs which were
  taking phy_descriptor as parameters
* Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used
  by PHY user drivers which has *phy* and *phy-names* binding in the dt data
* Fixed a few typos
* Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and
  class_dev_iter_exit for traversing through the phy list. (Note we still need
  phy_bind list and phy_bind_mutex).
* Changed the sysfs entry name from *bind* to *phy_bind*.

Changes from v1:
* Added Documentation for the PHY framework
* Added few more APIs mostly w.r.t devres
* Modified omap-usb2 and twl4030 to make use of the new framework

Did USB enumeration testing in panda and beagle.

Kishon Vijay Abraham I (9):
  drivers: phy: add generic PHY framework
  usb: phy: omap-usb2: use the new generic PHY framework
  usb: phy: twl4030: use the new generic PHY framework
  usb: phy: twl4030: twl4030 shouldn't be subsys_initcall
  ARM: OMAP: USB: Add phy binding information
  ARM: dts: omap: update usb_otg_hs data
  usb: musb: omap2430: use the new generic PHY framework
  usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
  usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

 .../devicetree/bindings/phy/phy-bindings.txt   |   66 +++
 Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |6 +
 Documentation/phy.txt  |  124 +
 MAINTAINERS|7 +
 arch/arm/boot/dts/omap3-beagle-xm.dts  |2 +
 arch/arm/boot/dts/omap3-evm.dts|2 +
 arch/arm/boot/dts/omap3-overo.dtsi |2 +
 arch/arm/boot/dts/omap4.dtsi   |3 +
 arch/arm/boot/dts/twl4030.dtsi |1 +
 arch/arm/mach-omap2/usb-musb.c |6 +-
 drivers/Kconfig|2 +
 drivers/Makefile   |2 +
 drivers/phy/Kconfig|   13 +
 drivers/phy/Makefile

[PATCH v7 1/9] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.

PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I 
---
 .../devicetree/bindings/phy/phy-bindings.txt   |   66 +++
 Documentation/phy.txt  |  124 +
 MAINTAINERS|7 +
 drivers/Kconfig|2 +
 drivers/Makefile   |2 +
 drivers/phy/Kconfig|   13 +
 drivers/phy/Makefile   |5 +
 drivers/phy/phy-core.c |  543 
 include/linux/phy/phy.h|  284 ++
 9 files changed, 1046 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt 
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===
+
+Required Properties:
+#phy-cells:Number of cells in a PHY specifier;  The meaning of all those
+   cells is defined by the binding for the phy node. The PHY
+   provider can use the values in cells to find the appropriate
+   PHY.
+
+For example:
+
+phys: phy {
+compatible = "xxx";
+reg = <...>;
+.
+.
+#phy-cells = <1>;
+.
+.
+};
+
+That node describes an IP block (PHY provider) that implements 2 different 
PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should 
be
+given while trying to get a reference to it.
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+compatible = "xxx";
+reg = ;
+.
+.
+phys = <&usb2_phy>, <&usb3_phy>;
+phy-names = "usb2phy", "usb3phy";
+.
+.
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+compatible = "xxx";
+reg = ;
+.
+.
+phys = <&phys 1>;
+phy-names = "usbphy";
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+"1" to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 000..059ef0e
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,124 @@
+   PHY SUBSYSTEM
+ Kishon Vijay Abraham I 
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the PHY drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the PHY, the framework provides its own implementation of of_xlate in
+of_phy_simple_xlate. If the PHY provider implements multiple instances, it
+should provide its own implementat

[PATCH v7 7/9] usb: musb: omap2430: use the new generic PHY framework

[Kishon Vijay Abraham I]

Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on/get_sync and
power_off/put_sync to align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/musb/musb_core.c |1 +
 drivers/usb/musb/musb_core.h |3 +++
 drivers/usb/musb/omap2430.c  |   29 +
 3 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 37a261a..f732bcc 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1864,6 +1864,7 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
musb->board_set_power = plat->set_power;
musb->min_power = plat->min_power;
musb->ops = plat->platform_ops;
+   musb->phy_label = plat->phy_label;
 
/* The musb_platform_init() call:
 *   - adjusts musb->mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..498ae21 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct musb;
 struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
u16 int_tx;
 
struct usb_phy  *xceiv;
+   struct phy  *phy;
 
int nIrq;
unsignedirq_wake:1;
@@ -434,6 +436,7 @@ struct musb {
unsigneddouble_buffer_not_ok:1;
 
struct musb_hdrc_config *config;
+   const char  *phy_label;
 
 #ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 628b93f..c62a004 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,14 +348,24 @@ static int omap2430_musb_init(struct musb *musb)
 * up through ULPI.  TWL4030-family PMICs include one,
 * which needs a driver, drivers aren't always needed.
 */
-   if (dev->parent->of_node)
+   if (dev->parent->of_node) {
+   musb->phy = devm_phy_get(dev->parent, "usb2-phy");
+
+   /* We can't totally remove musb->xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
"usb-phy", 0);
-   else
+   } else {
musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+   musb->phy = devm_phy_get(dev, musb->phy_label);
+   }
 
-   if (IS_ERR(musb->xceiv)) {
-   status = PTR_ERR(musb->xceiv);
+   if (IS_ERR(musb->xceiv) || IS_ERR(musb->phy)) {
+   status = PTR_ERR(musb->xceiv) | PTR_ERR(musb->phy);
 
if (status == -ENXIO)
return status;
@@ -397,9 +407,10 @@ static int omap2430_musb_init(struct musb *musb)
if (glue->status != OMAP_MUSB_UNKNOWN)
omap_musb_set_mailbox(glue);
 
-   usb_phy_init(musb->xceiv);
+   phy_init(musb->phy);
 
pm_runtime_put_noidle(musb->controller);
+   phy_pm_runtime_put(musb->phy);
return 0;
 
 err1:
@@ -460,6 +471,7 @@ static int omap2430_musb_exit(struct musb *musb)
del_timer_sync(&musb_idle_timer);
 
omap2430_low_level_exit(musb);
+   phy_exit(musb->phy);
 
return 0;
 }
@@ -619,7 +631,8 @@ static int omap2430_runtime_suspend(struct device *dev)
OTG_INTERFSEL);
 
omap2430_low_level_exit(musb);
-   usb_phy_set_suspend(musb->xceiv, 1);
+   phy_power_off(musb->phy);
+   phy_pm_runtime_put(musb->phy);
}
 
return 0;
@@ -634,8 +647,8 @@ static int omap2430_runtime_resume(struct device *dev)
omap2430_low_level_init(musb);
musb_writel(musb->mregs, OTG_INTERFSEL,
musb->context.otg_interfsel);
-
-   usb_phy_set_suspend(musb->xceiv, 0);
+   phy_pm_runtime_get_sync(musb->phy);
+   phy_power_on(musb->phy);
}
 
return 0;
-- 
1.7.10.4

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

[PATCH v7 2/9] usb: phy: omap-usb2: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/phy/phy-omap-usb2.c |   40 +--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 844ab68..3c275e7 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int 
suspend)
return 0;
 }
 
+static int omap_usb_power_off(struct phy *x)
+{
+   struct omap_usb *phy = dev_get_drvdata(&x->dev);
+
+   omap_control_usb_phy_power(phy->control_dev, 0);
+
+   return 0;
+}
+
+static int omap_usb_power_on(struct phy *x)
+{
+   struct omap_usb *phy = dev_get_drvdata(&x->dev);
+
+   omap_control_usb_phy_power(phy->control_dev, 1);
+
+   return 0;
+}
+
+static struct phy_ops ops = {
+   .power_on   = omap_usb_power_on,
+   .power_off  = omap_usb_power_off,
+   .owner  = THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
struct omap_usb *phy;
+   struct phy  *generic_phy;
struct usb_otg  *otg;
+   struct phy_provider *phy_provider;
 
phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -144,6 +171,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.otg= otg;
phy->phy.type   = USB_PHY_TYPE_USB2;
 
+   phy_provider = devm_of_phy_provider_register(phy->dev, THIS_MODULE,
+   of_phy_simple_xlate);
+   if (IS_ERR(phy_provider))
+   return PTR_ERR(phy_provider);
+
phy->control_dev = omap_get_control_dev();
if (IS_ERR(phy->control_dev)) {
dev_dbg(&pdev->dev, "Failed to get control device\n");
@@ -159,6 +191,12 @@ static int omap_usb2_probe(struct platform_device *pdev)
otg->start_srp  = omap_usb_start_srp;
otg->phy= &phy->phy;
 
+   pm_runtime_enable(phy->dev);
+
+   generic_phy = devm_phy_create(phy->dev, 0, &ops, "omap-usb2", phy);
+   if (IS_ERR(generic_phy))
+   return PTR_ERR(generic_phy);
+
phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
if (IS_ERR(phy->wkupclk)) {
dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n");
@@ -176,8 +214,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, phy);
 
-   pm_runtime_enable(phy->dev);
-
return 0;
 }
 
-- 
1.7.10.4

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

[PATCH v7 6/9] ARM: dts: omap: update usb_otg_hs data

[Kishon Vijay Abraham I]

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |6 ++
 arch/arm/boot/dts/omap3-beagle-xm.dts  |2 ++
 arch/arm/boot/dts/omap3-evm.dts|2 ++
 arch/arm/boot/dts/omap3-overo.dtsi |2 ++
 arch/arm/boot/dts/omap4.dtsi   |3 +++
 arch/arm/boot/dts/twl4030.dtsi |1 +
 7 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f3..c0871a7 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be "50". This signifies the controller can supply upto
100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
num-eps = <16>;
ram-bits = <12>;
ctrl-module = <&omap_control_usb>;
+   phys = <&usb2_phy>;
+   phy-names = "usb2-phy";
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
compatible = "ti,omap-usb2";
reg = <0x4a0ad080 0x58>;
ctrl-module = <&omap_control_usb>;
+   #phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the 
registers
filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy@4a084400 {
  <0x4a084c00 0x40>;
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
ctrl-module = <&omap_control_usb>;
+   #phy-cells = <0>;
 };
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3046d1f..023596e 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -123,6 +123,8 @@
 &usb_otg_hs {
interface-type = <0>;
usb-phy = <&usb2_phy>;
+   phys = <&usb2_phy>;
+   phy-names = "usb2-phy";
mode = <3>;
power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 96d1c20..f2b8314 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -69,6 +69,8 @@
 &usb_otg_hs {
interface-type = <0>;
usb-phy = <&usb2_phy>;
+   phys = <&usb2_phy>;
+   phy-names = "usb2-phy";
mode = <3>;
power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index a626c50..b65916e 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -74,6 +74,8 @@
 &usb_otg_hs {
interface-type = <0>;
usb-phy = <&usb2_phy>;
+   phys = <&usb2_phy>;
+   phy-names = "usb2-phy";
mode = <3>;
power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..dae620b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -517,6 +517,7 @@
compatible = "ti,omap-usb2";
reg = <0x4a0ad080 0x58>;
ctrl-module = <&omap_control_usb>;
+   #phy-cells = <0>;
};
};
 
@@ -655,6 +656,8 @@
interrupt-names = "mc", "dma";
   

[PATCH v7 5/9] ARM: OMAP: USB: Add phy binding information

[Kishon Vijay Abraham I]

In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/mach-omap2/usb-musb.c |6 +-
 include/linux/usb/musb.h   |3 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..284ba51 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data 
*musb_board_data)
musb_plat.mode = board_data->mode;
musb_plat.extvbus = board_data->extvbus;
 
-   if (cpu_is_omap44xx())
+   if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+   musb_plat.phy_label = "omap-usb2";
+   } else if (cpu_is_omap34xx()) {
+   musb_plat.phy_label = "twl4030";
+   }
 
if (soc_is_am35xx()) {
oh_name = "am35x_otg_hs";
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..596f8c8 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
/* for clk_get() */
const char  *clock;
 
+   /* phy label */
+   const char  *phy_label;
+
/* (HOST or OTG) switch VBUS on/off */
int (*set_vbus)(struct device *dev, int is_on);
 
-- 
1.7.10.4

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

[PATCH v7 4/9] usb: phy: twl4030: twl4030 shouldn't be subsys_initcall

[Kishon Vijay Abraham I]

Changed the inticall from subsys_initcall to module_init for
twl4030-usb.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/phy/phy-twl4030-usb.c |   12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index 65a5e43..fba9697 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -822,17 +822,7 @@ static struct platform_driver twl4030_usb_driver = {
},
 };
 
-static int __init twl4030_usb_init(void)
-{
-   return platform_driver_register(&twl4030_usb_driver);
-}
-subsys_initcall(twl4030_usb_init);
-
-static void __exit twl4030_usb_exit(void)
-{
-   platform_driver_unregister(&twl4030_usb_driver);
-}
-module_exit(twl4030_usb_exit);
+module_platform_driver(twl4030_usb_driver);
 
 MODULE_ALIAS("platform:twl4030_usb");
 MODULE_AUTHOR("Texas Instruments, Inc, Nokia Corporation");
-- 
1.7.10.4

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

[PATCH v7 8/9] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2

[Kishon Vijay Abraham I]

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/phy/phy-omap-usb2.c |   24 
 1 file changed, 24 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 3c275e7..bd2e4ca 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-   u32 ret;
-   struct omap_usb *phy = phy_to_omapusb(x);
-
-   if (suspend && !phy->is_suspended) {
-   omap_control_usb_phy_power(phy->control_dev, 0);
-   pm_runtime_put_sync(phy->dev);
-   phy->is_suspended = 1;
-   } else if (!suspend && phy->is_suspended) {
-   ret = pm_runtime_get_sync(phy->dev);
-   if (ret < 0) {
-   dev_err(phy->dev, "get_sync failed with err %d\n",
-   ret);
-   return ret;
-   }
-   omap_control_usb_phy_power(phy->control_dev, 1);
-   phy->is_suspended = 0;
-   }
-
-   return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
struct omap_usb *phy = dev_get_drvdata(&x->dev);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
phy->phy.dev= phy->dev;
phy->phy.label  = "omap-usb2";
-   phy->phy.set_suspend= omap_usb2_suspend;
phy->phy.otg= otg;
phy->phy.type   = USB_PHY_TYPE_USB2;
 
-- 
1.7.10.4

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

Re: [PATCH] dma-mapping: Add BUG_ON for uninitialized dma_ops

[Marek Szyprowski]

On 6/12/2013 5:06 PM, Arnd Bergmann wrote:

On Tuesday 11 June 2013, James Bottomley wrote:
> Really, no, it's not a good idea at all.  It invites tons of patches
> littering the code with BUG_ONs where we might possibly get a NULL
> dereference.  All it does is add extra instructions to a code path for
> no actual benefit.
>
> If you can answer the question: what more information does the BUG_ON
> give you than the NULL deref Oops would not? then it might be
> reasonable.

The question is if a user can trigger the NULL dereference intentionally,
in which case they might get the kernel to jump into a  user-provided
buffer.


I don't any possibility for userspace to alter the ops pointer, so if you
think that BUG_ON() approach causes additional overhead then I'm fine to
remove it.

Best regards
--
Marek Szyprowski
Samsung R&D Institute Poland


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

Re: [PATCH v5 3/5] vmcore: Introduce remap_oldmem_pfn_range()

[Michael Holzheu]

On Thu, 13 Jun 2013 10:32:48 +0900
HATAYAMA Daisuke  wrote:

> > Perhaps one open issue remains:
> >
> > Can we remove the page from the page cache if __read_vmcore() fails?
> >  
> 
> Yes, use page_cache_release() after unlocking the page like:
> 
> if (__read_vmcore(buf, PAGE_SIZE, &src, 0) < 0) {
> unlock_page(page);
> +  page_cache_release(page);
> return VM_FAULT_SIGBUS;
> }
> 
> BTW, you now keep file->f_mapping in vma->vm_private_data, but the vma 
> already has the file object in its vma->vm_file member. You can get the 
> mapping by vma->vm_file->f_mapping without necessity of vma->vm_private_data.

Hello Hatayama,

Here the new function:

static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct address_space *mapping = vma->vm_file->f_mapping;
pgoff_t index = vmf->pgoff;
struct page *page;
loff_t src;
char *buf;
int rc;

page = find_or_create_page(mapping, index, GFP_KERNEL);
if (!page)
return VM_FAULT_OOM;
if (!PageUptodate(page)) {
src = index << PAGE_CACHE_SHIFT;
buf = (void *) (page_to_pfn(page) << PAGE_SHIFT);
rc = __read_vmcore(buf, PAGE_SIZE, &src, 0);
if (rc < 0) {
unlock_page(page);
page_cache_release(page);
return (rc == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
}
SetPageUptodate(page);
}
unlock_page(page);
vmf->page = page;
return 0;
}

Thanks for all the constructive feedback!

Best Regards,
Michael

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

[Minchan Kim]

Hey Jörn,

On Tue, Jun 11, 2013 at 05:53:20PM -0400, Jörn Engel wrote:
> On Tue, 11 June 2013 17:16:01 -0400, Johannes Weiner wrote:
> > On Tue, Jun 11, 2013 at 02:29:21PM -0400, Jörn Engel wrote:
> > > I've seen a couple of instances where people try to impose a vsize
> > > limit simply because there is no rss limit in Linux.  The vsize limit
> > > is a horrible approximation and even this patch seems to be an
> > > improvement.
> > > 
> > > Would there be strong opposition to actually supporting RLIMIT_RSS?
> > 
> > This is trivial to exploit by creating the mappings first and
> > populating them later, so while it may cover some use cases, it does
> > not have the protection against malicious programs aspect that all the
> > other rlimits have.
> 
> Hm.  The use case I have is that an application wants to limit itself.
> It is effectively a special assert to catch memory leaks and the like.
> So malicious programs are not my immediate concern.

Just out of curisoity.

It means you already know the max rss of the application in advance
so you can use taskstats's hiwater_rss if you don't need to catch
the moment which rss is over the limit.

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

[PATCH 0/3] some optimization & code cleanup

[Haicheng Li]

Fix some issues found by code review.

Haicheng Li (3):
  f2fs: remove unnecessary parameter "offset" from __add_sum_entry()
  f2fs: make locate_dirty_segment() as static
  f2fs: optimize do_write_data_page()

 fs/f2fs/data.c|5 +++--
 fs/f2fs/f2fs.h|1 -
 fs/f2fs/segment.c |   12 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

-- 
1.7.9.5

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

[PATCH 2/3] f2fs: make locate_dirty_segment() as static

[Haicheng Li]

It's used only locally and could be static.

Signed-off-by: Haicheng Li 
---
 fs/f2fs/f2fs.h|1 -
 fs/f2fs/segment.c |2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index a05aa65..3e7cb33 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -996,7 +996,6 @@ void destroy_node_manager_caches(void);
  */
 void f2fs_balance_fs(struct f2fs_sb_info *);
 void invalidate_blocks(struct f2fs_sb_info *, block_t);
-void locate_dirty_segment(struct f2fs_sb_info *, unsigned int);
 void clear_prefree_segments(struct f2fs_sb_info *);
 int npages_for_summary_flush(struct f2fs_sb_info *);
 void allocate_new_segments(struct f2fs_sb_info *);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 77f31c0..b15debc 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -94,7 +94,7 @@ static void __remove_dirty_segment(struct f2fs_sb_info *sbi, 
unsigned int segno,
  * Adding dirty entry into seglist is not critical operation.
  * If a given segment is one of current working segments, it won't be added.
  */
-void locate_dirty_segment(struct f2fs_sb_info *sbi, unsigned int segno)
+static void locate_dirty_segment(struct f2fs_sb_info *sbi, unsigned int segno)
 {
struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
unsigned short valid_blocks;
-- 
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: Commit f9afbd45b0d0 broke mips r4k.

[Ralf Baechle]

On Wed, Jun 12, 2013 at 09:35:16PM -0500, Rob Landley wrote:

> My aboriginal linux project builds tiny linux systems to run under
> qemu, producing as close to the same system as possible across a
> bunch of different architectures. The above change broke the mips
> r4k build I've been running under qemu.
> 
> Here's a toolchain and reproduction sequence:
> 
>   wget http://landley.net/aboriginal/bin/cross-compiler-mips.tar.bz2
>   tar xvjf cross-compiler-mips.tar.bz2
>   export PATH=$PWD/cross-compiler-mips/bin:$PATH
>   make ARCH=mips allnoconfig KCONFIG_ALLCONFIG=miniconfig.mips
>   make CROSS_COMPILE=mips- ARCH=mips
> 
> (The file miniconfig.mips is attached.)
> 
> It ends:
> 
>   CC  init/version.o
>   LD  init/built-in.o
> arch/mips/built-in.o: In function `local_r4k_flush_cache_page':
> c-r4k.c:(.text+0xe278): undefined reference to `kvm_local_flush_tlb_all'
> c-r4k.c:(.text+0xe278): relocation truncated to fit: R_MIPS_26
> against `kvm_local_flush_tlb_all'
> arch/mips/built-in.o: In function `local_flush_tlb_range':
> (.text+0xe938): undefined reference to `kvm_local_flush_tlb_all'
> arch/mips/built-in.o: In function `local_flush_tlb_range':
> (.text+0xe938): relocation truncated to fit: R_MIPS_26 against
> `kvm_local_flush_tlb_all'
> arch/mips/built-in.o: In function `local_flush_tlb_mm':
> (.text+0xed38): undefined reference to `kvm_local_flush_tlb_all'
> arch/mips/built-in.o: In function `local_flush_tlb_mm':
> (.text+0xed38): relocation truncated to fit: R_MIPS_26 against
> `kvm_local_flush_tlb_all'
> kernel/built-in.o: In function `__schedule':
> core.c:(.sched.text+0x16a0): undefined reference to
> `kvm_local_flush_tlb_all'
> core.c:(.sched.text+0x16a0): relocation truncated to fit: R_MIPS_26
> against `kvm_local_flush_tlb_all'
> mm/built-in.o: In function `use_mm':
> (.text+0x182c8): undefined reference to `kvm_local_flush_tlb_all'
> mm/built-in.o: In function `use_mm':
> (.text+0x182c8): relocation truncated to fit: R_MIPS_26 against
> `kvm_local_flush_tlb_all'
> fs/built-in.o:(.text+0x7b50): more undefined references to
> `kvm_local_flush_tlb_all' follow
> fs/built-in.o: In function `flush_old_exec':
> (.text+0x7b50): relocation truncated to fit: R_MIPS_26 against
> `kvm_local_flush_tlb_all'
> 
> Revert the above commit and it builds to the end.

Commit d414976d1ca721456f7b7c603a8699d117c2ec07 [MIPS: include:
mmu_context.h: Replace VIRTUALIZATION with KVM] fixes the issue and
was pulled by Linus only yesterday.  I cannot reproduce the error
following your receipe using the latest Linux/MIPS tree.

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

[PATCH 1/3] f2fs: remove unnecessary parameter "offset" from __add_sum_entry()

[Haicheng Li]

We can get the value directly from pointer "curseg".

Signed-off-by: Haicheng Li 
---
 fs/f2fs/segment.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index be668ff..77f31c0 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -255,11 +255,11 @@ void invalidate_blocks(struct f2fs_sb_info *sbi, block_t 
addr)
  * This function should be resided under the curseg_mutex lock
  */
 static void __add_sum_entry(struct f2fs_sb_info *sbi, int type,
-   struct f2fs_summary *sum, unsigned short offset)
+   struct f2fs_summary *sum)
 {
struct curseg_info *curseg = CURSEG_I(sbi, type);
void *addr = curseg->sum_blk;
-   addr += offset * sizeof(struct f2fs_summary);
+   addr += curseg->next_blkoff * sizeof(struct f2fs_summary);
memcpy(addr, sum, sizeof(struct f2fs_summary));
return;
 }
@@ -845,7 +845,7 @@ static void do_write_page(struct f2fs_sb_info *sbi, struct 
page *page,
 * because, this function updates a summary entry in the
 * current summary block.
 */
-   __add_sum_entry(sbi, type, sum, curseg->next_blkoff);
+   __add_sum_entry(sbi, type, sum);
 
mutex_lock(&sit_i->sentry_lock);
__refresh_next_blkoff(sbi, curseg);
@@ -946,7 +946,7 @@ void recover_data_page(struct f2fs_sb_info *sbi,
 
curseg->next_blkoff = GET_SEGOFF_FROM_SEG0(sbi, new_blkaddr) &
(sbi->blocks_per_seg - 1);
-   __add_sum_entry(sbi, type, sum, curseg->next_blkoff);
+   __add_sum_entry(sbi, type, sum);
 
refresh_sit_entry(sbi, old_blkaddr, new_blkaddr);
 
@@ -983,7 +983,7 @@ void rewrite_node_page(struct f2fs_sb_info *sbi,
}
curseg->next_blkoff = GET_SEGOFF_FROM_SEG0(sbi, new_blkaddr) &
(sbi->blocks_per_seg - 1);
-   __add_sum_entry(sbi, type, sum, curseg->next_blkoff);
+   __add_sum_entry(sbi, type, sum);
 
/* change the current log to the next block addr in advance */
if (next_segno != segno) {
-- 
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: [RFC] Allow GPIO ranges based on pinctl pin groups

[Linus Walleij]

On Wed, Jun 12, 2013 at 6:44 PM, Christian Ruppert
 wrote:

> This patch allows the definition of GPIO ranges based on pin groups in
> addition to the traditional linear pin ranges. GPIO ranges based on pin
> groups have the following advantages over traditional pin ranges:
> . Previously, pins associated to a given functionality were defined
>   inside the pin controller (e.g. a pin controller can define a group
>   spi0_pins defining which pins are used by SPI port 0). This mechanism
>   did not apply to GPIO controllers, however, which had to define GPIO
>   ranges based on pin numbers otherwise confined to the pin controller.
>   With the possibility to use pin groups for pin ranges, the pins
>   associated to any functionality, including GPIO, can now be entirely
>   defined inside the pin controller. Everything that needs to be known
>   to the outside world is the name of the pin group.
> . Non-consecutive pin ranges and arbitrary pin ordering is now possible
>   in GPIO ranges.
> . Linux internal pin numbers now no longer leak out of the kernel, e.g.
>   to device tree. If the pinctrl driver author chooses to, GPIO range
>   management can now entirely be based on symbolic names of pin groups.
>
> Signed-off-by: Christian Ruppert 

Overall this approach looks nice.

There are details that need fixing though:

> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
(...)
> @@ -112,3 +112,39 @@ where,
>
>  The pinctrl node must have "#gpio-range-cells" property to show number of
>  arguments to pass with phandle from gpio controllers node.
> +
> +In addition, gpio ranges can be mapped to pin groups of a given pin
> +controller (see Documentation/pinctrl.txt):

Do not reference Linux particulars in bindings. The idea is to
reuse these bindings with other operating systems as well.

> +
> +   gpio_pio_g: gpio-controller@1480 {
> +   #gpio-cells = <2>;
> +   compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
> +   reg = <0x1480 0x18>;
> +   gpio-controller;
> +   gpio-pingrps = <&pinctrl1 0>, <&pinctrl2 3>;
> +   gpio-pingrp-names = "pctl1_gpio_g", "pctl2_gpio_g";
> +   }

End with semicolon?

> +where,
> +   &pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node.

There is something weird with spacing above.

> +   Next values specify the base GPIO offset of the pin range with respect to
> +   the GPIO controller's base. The number of pins in the range is the number
> +   of pins in the pin group.
> +
> +   gpio-pingrp-names defines the name of each pingroup of the respective pin
> +   controller.

That seems like a good idea.

> +The pinctrl node msut have a "#gpio-pingrp-cells" property set to one to

must

> +define the number of arguments to pass with the phandle.
> +
> +Both methods can be combined in the same GPIO controller, e.g.
> +
> +   gpio_pio_i: gpio-controller@14B0 {
> +   #gpio-cells = <2>;
> +   compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
> +   reg = <0x1480 0x18>;
> +   gpio-controller;
> +   gpio-ranges = <&pinctrl1 0 20 10>;
> +   gpio-pingrps = <&pinctrl2 10>;
> +   gpio-pingrp-names = "gpio_g_pins";
> +   }

Semicolon after that closing brace.

> +++ b/drivers/gpio/gpiolib-of.c
(...)
> +   index = 0;
> +   of_property_for_each_string(np, "gpio-pingrp-names", prop, name) {
> +   ret = of_parse_phandle_with_args(np, "gpio-pingrps",
> +   "#gpio-pingrp-cells",
> +   index, &pinspec);
> +   if (ret < 0)
> +   break;
> +
> +   index ++;
> +
> +   pctldev = of_pinctrl_get(pinspec.np);
> +
> +   gpiochip_add_pingroup_range(chip, pctldev,
> +   pinspec.args[0], name);
> +   }
>  }

This part looks fine.

(...)
> +++ b/drivers/gpio/gpiolib.c
> @@ -1318,6 +1318,54 @@ EXPORT_SYMBOL_GPL(gpiochip_find);
>  #ifdef CONFIG_PINCTRL
>
>  /**
> + * gpiochip_add_pingroup_range() - add a range for GPIO <-> pin mapping
> + * @chip: the gpiochip to add the range for
> + * @pinctrl: the dev_name() of the pin controller to map to
> + * @gpio_offset: the start offset in the current gpio_chip number space
> + * @pin_group: name of the pin group inside the pin controller
> + */
> +int gpiochip_add_pingroup_range(struct gpio_chip *chip,
> +   struct pinctrl_dev *pctldev,
> +   unsigned int gpio_offset, const char *pin_group)
> +{
> +   struct gpio_pin_range *pin_range;
> +   int ret;
> +
> +   pin_range = kzalloc(sizeof(*pin_range), GFP_KERNEL);
> +   if (!pin_range) {
> +   pr_err("%s: GPIO chip: failed to allocate pin ranges\n",
> +   chip->label);
> +   return -ENOMEM;
> +   

[PATCH 3/3] f2fs: optimize do_write_data_page()

[Haicheng Li]

Since "need_inplace_update() == true" is a very rare case, using unlikely()
to give compiler a chance to optimize the code.

Signed-off-by: Haicheng Li 
---
 fs/f2fs/data.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 5b145fc..6d4a743 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -497,8 +497,9 @@ int do_write_data_page(struct page *page)
 * If current allocation needs SSR,
 * it had better in-place writes for updated data.
 */
-   if (old_blk_addr != NEW_ADDR && !is_cold_data(page) &&
-   need_inplace_update(inode)) {
+   if (unlikely(old_blk_addr != NEW_ADDR &&
+   !is_cold_data(page) &&
+   need_inplace_update(inode))) {
rewrite_data_page(F2FS_SB(inode->i_sb), page,
old_blk_addr);
} else {
-- 
1.7.9.5

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

[PATCH v5] cpufreq: fix governor start/stop race condition

[Xiaoguang Chen]

cpufreq governor stop and start should be kept in sequence.
If not, there will be unexpected behavior, for example:

we have 4 cpus and policy->cpu=cpu0, cpu1/2/3 are linked to cpu0.
the normal sequence is as below:

1) Current governor is userspace, one application tries to set
governor to ondemand. it will call __cpufreq_set_policy in which it
will stop userspace governor and then start ondemand governor.

2) Current governor is userspace, now cpu0 hotplugs in cpu3, it will
call cpufreq_add_policy_cpu. on which it first stops userspace
governor, and then starts userspace governor.

Now if the sequence of above two cases interleaves, it becames
below sequence:

1) application stops userspace governor
2)  hotplug stops userspace governor
3) application starts ondemand governor
4)  hotplug starts a governor

in step 4, hotplug is supposed to start userspace governor, but now
the governor has been changed by application to ondemand, so hotplug
starts ondemand governor again 

The solution is: do not allow stop one policy's governor multi-times
Governor stop should only do once for one policy, after it is stopped,
no other governor stop should be executed. also add one mutext to
protect __cpufreq_governor so governor operation can be kept in sequence.

Signed-off-by: Xiaoguang Chen 
---
 drivers/cpufreq/cpufreq.c | 24 
 include/linux/cpufreq.h   |  1 +
 2 files changed, 25 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 2d53f47..b51473e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -46,6 +46,7 @@ static DEFINE_PER_CPU(struct cpufreq_policy *, 
cpufreq_cpu_data);
 static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor);
 #endif
 static DEFINE_RWLOCK(cpufreq_driver_lock);
+static DEFINE_MUTEX(cpufreq_governor_lock);
 
 /*
  * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
@@ -1562,6 +1563,21 @@ static int __cpufreq_governor(struct cpufreq_policy 
*policy,
 
pr_debug("__cpufreq_governor for CPU %u, event %u\n",
policy->cpu, event);
+
+   mutex_lock(&cpufreq_governor_lock);
+   if ((!policy->governor_enabled && (event == CPUFREQ_GOV_STOP)) ||
+   (policy->governor_enabled && (event == CPUFREQ_GOV_START))) {
+   mutex_unlock(&cpufreq_governor_lock);
+   return -EBUSY;
+   }
+
+   if (event == CPUFREQ_GOV_STOP)
+   policy->governor_enabled = 0;
+   else if (event == CPUFREQ_GOV_START)
+   policy->governor_enabled = 1;
+
+   mutex_unlock(&cpufreq_governor_lock);
+
ret = policy->governor->governor(policy, event);
 
if (!ret) {
@@ -1569,6 +1585,14 @@ static int __cpufreq_governor(struct cpufreq_policy 
*policy,
policy->governor->initialized++;
else if (event == CPUFREQ_GOV_POLICY_EXIT)
policy->governor->initialized--;
+   } else {
+   /* Restore original values */
+   mutex_lock(&cpufreq_governor_lock);
+   if (event == CPUFREQ_GOV_STOP)
+   policy->governor_enabled = 1;
+   else if (event == CPUFREQ_GOV_START)
+   policy->governor_enabled = 0;
+   mutex_unlock(&cpufreq_governor_lock);
}
 
/* we keep one module reference alive for
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 037d36a..c12db73 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -107,6 +107,7 @@ struct cpufreq_policy {
unsigned intpolicy; /* see above */
struct cpufreq_governor *governor; /* see below */
void*governor_data;
+   int governor_enabled; /* governor start/stop flag */
 
struct work_struct  update; /* if update_policy() needs to be
 * called, but you're in IRQ context */
-- 
1.8.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: am335x: TSC & ADC reworking including DT pieces, take 5

[Samuel Ortiz]

Hi Sebastian,

On Wed, Jun 12, 2013 at 06:58:01PM +0200, Sebastian Andrzej Siewior wrote:
> Hi Samuel,
> 
> I did the cosmetic changes of the subject line and removed the changes
> from within the sob lines in each patch. I dropped the "#define XPP
> STEPCONFIG_XPP" thingy and patch #1 which removed regmap from mfd. Not
> that I agree with it, I just do not want to miss the merge window due to
> this.
> 
> The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e:
> 
>   Linux 3.10-rc4 (2013-06-02 17:11:17 +0900)
> 
> are available in the git repository at:
> 
>   git://breakpoint.cc/bigeasy/linux tags/am335x_tsc-adc
Pulled and pushed back to mfd-next, thanks.
I fixed a couple of unused variable warnings on top of it.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.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 v2 1/3] ARM: tegra: basic support for Trusted Foundations

[Alexandre Courbot]

Add basic support for booting secondary processors on Tegra devices
using the Trusted Foundations secure monitor.

Signed-off-by: Alexandre Courbot 
---
 Documentation/devicetree/bindings/arm/tegra.txt| 11 +
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 arch/arm/configs/tegra_defconfig   |  1 +
 arch/arm/mach-tegra/Kconfig| 14 ++
 arch/arm/mach-tegra/Makefile   |  3 ++
 arch/arm/mach-tegra/common.c   |  2 +
 arch/arm/mach-tegra/firmware.c | 40 +
 arch/arm/mach-tegra/firmware.h | 19 
 arch/arm/mach-tegra/trusted_foundations.c  | 51 ++
 9 files changed, 142 insertions(+)
 create mode 100644 arch/arm/mach-tegra/firmware.c
 create mode 100644 arch/arm/mach-tegra/firmware.h
 create mode 100644 arch/arm/mach-tegra/trusted_foundations.c

diff --git a/Documentation/devicetree/bindings/arm/tegra.txt 
b/Documentation/devicetree/bindings/arm/tegra.txt
index ed9c853..d59bc19 100644
--- a/Documentation/devicetree/bindings/arm/tegra.txt
+++ b/Documentation/devicetree/bindings/arm/tegra.txt
@@ -32,3 +32,14 @@ board-specific compatible values:
   nvidia,whistler
   toradex,colibri_t20-512
   toradex,iris
+
+Optional nodes
+---
+
+Trusted Foundations:
+Boards using the Trusted Foundations secure monitor should signal its
+presence by declaring a node compatible with "tl,trusted-foundations":
+
+   firmware {
+   compatible = "tl,trusted-foundations";
+   };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 6931c43..c21e1e9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -58,6 +58,7 @@ stSTMicroelectronics
 steST-Ericsson
 stericsson ST-Ericsson
 ti Texas Instruments
+tl Trusted Logic
 toshibaToshiba Corporation
 viaVIA Technologies, Inc.
 wlfWolfson Microelectronics
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 4de3bce..3bf158a 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -28,6 +28,7 @@ CONFIG_ARCH_TEGRA_3x_SOC=y
 CONFIG_ARCH_TEGRA_114_SOC=y
 CONFIG_TEGRA_PCI=y
 CONFIG_TEGRA_EMC_SCALING_ENABLE=y
+CONFIG_TEGRA_TRUSTED_FOUNDATIONS=y
 CONFIG_SMP=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 84d72fc..055f496 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -87,4 +87,18 @@ config TEGRA_AHB
 config TEGRA_EMC_SCALING_ENABLE
bool "Enable scaling the memory frequency"
 
+config TEGRA_TRUSTED_FOUNDATIONS
+   bool "Trusted Foundations secure monitor support"
+   help
+ Many Tegra devices are booted with the Trusted Foundations secure
+ monitor active, requiring some core operations to be performed by
+ the secure monitor instead of the kernel.
+
+ This option allows the kernel to invoke the secure monitor when
+ required on devices using Trusted Foundations.
+
+ Devices using Trusted Foundations should pass a device tree containing
+ a node compatible with "tl,trusted-foundations" to signal the presence
+ of the secure monitor.
+
 endmenu
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index d011f0a..9fdc004 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -12,6 +12,7 @@ obj-y += pm.o
 obj-y  += reset.o
 obj-y  += reset-handler.o
 obj-y  += sleep.o
+obj-y  += firmware.o
 obj-y  += tegra.o
 obj-$(CONFIG_CPU_IDLE) += cpuidle.o
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= tegra20_speedo.o
@@ -37,3 +38,5 @@ endif
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= board-harmony-pcie.o
 
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= board-paz00.o
+
+obj-$(CONFIG_TEGRA_TRUSTED_FOUNDATIONS)+= trusted_foundations.o
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 9f852c6..4796bb0 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -37,6 +37,7 @@
 #include "sleep.h"
 #include "pm.h"
 #include "reset.h"
+#include "firmware.h"
 
 /*
  * Storage for debug-macro.S's state.
@@ -97,6 +98,7 @@ static void __init tegra_init_cache(void)
 
 void __init tegra_init_early(void)
 {
+   tegra_init_firmware();
tegra_cpu_reset_handler_init();
tegra_apb_io_init();
tegra_init_fuse();
diff --git a/arch/arm/mach-tegra/firmware.c b/arch/arm/mach-tegra/firmware.c
new file mode 100644
index 000..ea8

[PATCH v2 2/3] ARM: tegra: split setting of CPU reset handler

[Alexandre Courbot]

Not all Tegra devices need to set the CPU reset handler in the same way.
In particular, devices using a TrustZone secure monitor cannot set the
reset handler directly and need to do it through a firmware operation.

This patch separates the act of setting the reset handler from its
preparation, so the former can be implemented in a different way.

Signed-off-by: Alexandre Courbot 
---
 arch/arm/mach-tegra/reset.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index 1ac434e..6964117 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -33,26 +33,18 @@
 
 static bool is_enabled;
 
-static void __init tegra_cpu_reset_handler_enable(void)
+static void __init tegra_cpu_reset_handler_set(const u32 reset_address)
 {
-   void __iomem *iram_base = IO_ADDRESS(TEGRA_IRAM_RESET_BASE);
void __iomem *evp_cpu_reset =
IO_ADDRESS(TEGRA_EXCEPTION_VECTORS_BASE + 0x100);
void __iomem *sb_ctrl = IO_ADDRESS(TEGRA_SB_BASE);
u32 reg;
 
-   BUG_ON(is_enabled);
-   BUG_ON(tegra_cpu_reset_handler_size > TEGRA_IRAM_RESET_HANDLER_SIZE);
-
-   memcpy(iram_base, (void *)__tegra_cpu_reset_handler_start,
-   tegra_cpu_reset_handler_size);
-
/*
 * NOTE: This must be the one and only write to the EVP CPU reset
 *   vector in the entire system.
 */
-   writel(TEGRA_IRAM_RESET_BASE + tegra_cpu_reset_handler_offset,
-   evp_cpu_reset);
+   writel(reset_address, evp_cpu_reset);
wmb();
reg = readl(evp_cpu_reset);
 
@@ -66,6 +58,21 @@ static void __init tegra_cpu_reset_handler_enable(void)
writel(reg, sb_ctrl);
wmb();
}
+}
+
+static void __init tegra_cpu_reset_handler_enable(void)
+{
+   void __iomem *iram_base = IO_ADDRESS(TEGRA_IRAM_RESET_BASE);
+   const u32 reset_address = TEGRA_IRAM_RESET_BASE +
+   tegra_cpu_reset_handler_offset;
+
+   BUG_ON(is_enabled);
+   BUG_ON(tegra_cpu_reset_handler_size > TEGRA_IRAM_RESET_HANDLER_SIZE);
+
+   memcpy(iram_base, (void *)__tegra_cpu_reset_handler_start,
+   tegra_cpu_reset_handler_size);
+
+   tegra_cpu_reset_handler_set(reset_address);
 
is_enabled = true;
 }
-- 
1.8.3

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

[PATCH v2 3/3] ARM: tegra: set CPU reset handler with firmware op

[Alexandre Courbot]

Use a firmware operation to set the CPU reset handler and only resort to
doing it ourselves if there is none defined.

This supports the booting of secondary CPUs on devices using a TrustZone
secure monitor.

Signed-off-by: Alexandre Courbot 
---
 arch/arm/mach-tegra/reset.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index 6964117..40f110c 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 
 #include "iomap.h"
 #include "irammap.h"
@@ -65,6 +66,7 @@ static void __init tegra_cpu_reset_handler_enable(void)
void __iomem *iram_base = IO_ADDRESS(TEGRA_IRAM_RESET_BASE);
const u32 reset_address = TEGRA_IRAM_RESET_BASE +
tegra_cpu_reset_handler_offset;
+   int err;
 
BUG_ON(is_enabled);
BUG_ON(tegra_cpu_reset_handler_size > TEGRA_IRAM_RESET_HANDLER_SIZE);
@@ -72,9 +74,18 @@ static void __init tegra_cpu_reset_handler_enable(void)
memcpy(iram_base, (void *)__tegra_cpu_reset_handler_start,
tegra_cpu_reset_handler_size);
 
-   tegra_cpu_reset_handler_set(reset_address);
-
-   is_enabled = true;
+   err = call_firmware_op(set_cpu_boot_addr, 0, reset_address);
+   switch (err) {
+   case -ENOSYS:
+   tegra_cpu_reset_handler_set(reset_address);
+   /* pass-through */
+   case 0:
+   is_enabled = true;
+   break;
+   default:
+   pr_err("Cannot set CPU reset handler: %d\n", err);
+   break;
+   }
 }
 
 void __init tegra_cpu_reset_handler_init(void)
-- 
1.8.3

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

[PATCH v2 0/3] ARM: tegra: add basic support for Trusted Foundations

[Alexandre Courbot]

New revision of the initial patch, fixed according to the many suggestions
received. (thanks!)

Changes since v1:
- Split patch into logical chunks as suggested by Tomasz
- Simplified smc function according to comments from Russel and David
- Use proper "Trusted Foundations" naming for firmware instead of "SecureOS"
- Very simple firmware infrastructure in mach-tegra to support the use of other
  firmwares
- Presence of secure monitor is signaled through a DT node instead of a "chosen"
  property
- Complain if support for a declared secure monitor is not compiled in

Alexandre Courbot (3):
  ARM: tegra: basic support for Trusted Foundations
  ARM: tegra: split setting of CPU reset handler
  ARM: tegra: set CPU reset handler with firmware op

 Documentation/devicetree/bindings/arm/tegra.txt| 11 +
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 arch/arm/configs/tegra_defconfig   |  1 +
 arch/arm/mach-tegra/Kconfig| 14 ++
 arch/arm/mach-tegra/Makefile   |  3 ++
 arch/arm/mach-tegra/common.c   |  2 +
 arch/arm/mach-tegra/firmware.c | 40 +
 arch/arm/mach-tegra/firmware.h | 19 
 arch/arm/mach-tegra/reset.c| 40 -
 arch/arm/mach-tegra/trusted_foundations.c  | 51 ++
 10 files changed, 171 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm/mach-tegra/firmware.c
 create mode 100644 arch/arm/mach-tegra/firmware.h
 create mode 100644 arch/arm/mach-tegra/trusted_foundations.c

-- 
1.8.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 v5] cpufreq: fix governor start/stop race condition

[Viresh Kumar]

On 13 June 2013 14:31, Xiaoguang Chen  wrote:
> cpufreq governor stop and start should be kept in sequence.
> If not, there will be unexpected behavior, for example:
>
> we have 4 cpus and policy->cpu=cpu0, cpu1/2/3 are linked to cpu0.
> the normal sequence is as below:
>
> 1) Current governor is userspace, one application tries to set
> governor to ondemand. it will call __cpufreq_set_policy in which it
> will stop userspace governor and then start ondemand governor.
>
> 2) Current governor is userspace, now cpu0 hotplugs in cpu3, it will
> call cpufreq_add_policy_cpu. on which it first stops userspace
> governor, and then starts userspace governor.
>
> Now if the sequence of above two cases interleaves, it becames
> below sequence:
>
> 1) application stops userspace governor
> 2)  hotplug stops userspace governor
> 3) application starts ondemand governor
> 4)  hotplug starts a governor
>
> in step 4, hotplug is supposed to start userspace governor, but now
> the governor has been changed by application to ondemand, so hotplug
> starts ondemand governor again 
>
> The solution is: do not allow stop one policy's governor multi-times
> Governor stop should only do once for one policy, after it is stopped,
> no other governor stop should be executed. also add one mutext to
> protect __cpufreq_governor so governor operation can be kept in sequence.
>
> Signed-off-by: Xiaoguang Chen 
> ---
>  drivers/cpufreq/cpufreq.c | 24 
>  include/linux/cpufreq.h   |  1 +
>  2 files changed, 25 insertions(+)

I forgot to tell you earlier but please update changelog everytime you
send a new version.

Acked-by: Viresh Kumar 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/9] memcg: use css_get/put when charging/uncharging kmem

[Li Zefan]

Sorry for updating the patchset so late.

I've made some changes for the memory barrier thing, and I agree with
Michal that there can be improvement but can be a separate patch.

If this version is ok for everyone, I'll send the whole patchset out
to Andrew.

=

Use css_get/put instead of mem_cgroup_get/put.

We can't do a simple replacement, because here mem_cgroup_put()
is called during mem_cgroup_css_free(), while mem_cgroup_css_free()
won't be called until css refcnt goes down to 0.

Instead we increment css refcnt in mem_cgroup_css_offline(), and
then check if there's still kmem charges. If not, css refcnt will
be decremented immediately, otherwise the refcnt won't be decremented
when kmem charges goes down to 0.

v3:
- changed wmb() to smp_smb(), and moved it to memcg_kmem_mark_dead(),
  and added comment.

v2:
- added wmb() in kmem_cgroup_css_offline(), pointed out by Michal
- revised comments as suggested by Michal
- fixed to check if kmem is activated in kmem_cgroup_css_offline()

Signed-off-by: Li Zefan 
Acked-by: Michal Hocko 
Acked-by: KAMEZAWA Hiroyuki 
---
 mm/memcontrol.c | 70 -
 1 file changed, 45 insertions(+), 25 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 466c595..76dcd0e 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -416,6 +416,11 @@ static void memcg_kmem_clear_activated(struct mem_cgroup 
*memcg)
 
 static void memcg_kmem_mark_dead(struct mem_cgroup *memcg)
 {
+   /*
+* We need to call css_get() first, because memcg_uncharge_kmem()
+* will call css_put() if it sees the memcg is dead.
+*/
+   smb_wmb();
if (test_bit(KMEM_ACCOUNTED_ACTIVE, &memcg->kmem_account_flags))
set_bit(KMEM_ACCOUNTED_DEAD, &memcg->kmem_account_flags);
 }
@@ -3060,8 +3065,16 @@ static void memcg_uncharge_kmem(struct mem_cgroup 
*memcg, u64 size)
if (res_counter_uncharge(&memcg->kmem, size))
return;
 
+   /*
+* Releases a reference taken in kmem_cgroup_css_offline in case
+* this last uncharge is racing with the offlining code or it is
+* outliving the memcg existence.
+*
+* The memory barrier imposed by test&clear is paired with the
+* explicit one in memcg_kmem_mark_dead().
+*/
if (memcg_kmem_test_and_clear_dead(memcg))
-   mem_cgroup_put(memcg);
+   css_put(&memcg->css);
 }
 
 void memcg_cache_list_add(struct mem_cgroup *memcg, struct kmem_cache *cachep)
@@ -5165,14 +5178,6 @@ static int memcg_update_kmem_limit(struct cgroup *cont, 
u64 val)
 * starts accounting before all call sites are patched
 */
memcg_kmem_set_active(memcg);
-
-   /*
-* kmem charges can outlive the cgroup. In the case of slab
-* pages, for instance, a page contain objects from various
-* processes, so it is unfeasible to migrate them away. We
-* need to reference count the memcg because of that.
-*/
-   mem_cgroup_get(memcg);
} else
ret = res_counter_set_limit(&memcg->kmem, val);
 out:
@@ -5205,12 +5210,10 @@ static int memcg_propagate_kmem(struct mem_cgroup 
*memcg)
goto out;
 
/*
-* destroy(), called if we fail, will issue static_key_slow_inc() and
-* mem_cgroup_put() if kmem is enabled. We have to either call them
-* unconditionally, or clear the KMEM_ACTIVE flag. I personally find
-* this more consistent, since it always leads to the same destroy path
+* __mem_cgroup_free() will issue static_key_slow_dec() because this
+* memcg is active already. If the later initialization fails then the
+* cgroup core triggers the cleanup so we do not have to do it here.
 */
-   mem_cgroup_get(memcg);
static_key_slow_inc(&memcg_kmem_enabled_key);
 
mutex_lock(&set_limit_mutex);
@@ -5893,23 +5896,38 @@ static int memcg_init_kmem(struct mem_cgroup *memcg, 
struct cgroup_subsys *ss)
return mem_cgroup_sockets_init(memcg, ss);
 }
 
-static void kmem_cgroup_destroy(struct mem_cgroup *memcg)
+static void kmem_cgroup_css_offline(struct mem_cgroup *memcg)
 {
-   mem_cgroup_sockets_destroy(memcg);
+   if (!memcg_kmem_is_active(memcg))
+   return;
+
+   /*
+* kmem charges can outlive the cgroup. In the case of slab
+* pages, for instance, a page contain objects from various
+* processes. As we prevent from taking a reference for every
+* such allocation we have to be careful when doing uncharge
+* (see memcg_uncharge_kmem) and here during offlining.
+*
+* The idea is that that only the _last_ uncharge which sees
+* the dead memcg will drop the last reference. An additional
+* reference is taken here befor

RE: [PATCH 03/11] gpio: davinci: Modify to platform driver

[Philip, Avinash]

On Thu, Jun 13, 2013 at 13:59:53, Nori, Sekhar wrote:
> On 6/13/2013 1:02 PM, Philip, Avinash wrote:
> 
> > With tnetv107x_defconfig build is failing
> > 
> > arch/arm/mach-davinci/board-tnetv107x-evm.c:282:15: error:
> >  'davinci_timer_init' undeclared here (not in a function)
> > arch/arm/mach-davinci/board-tnetv107x-evm.c:284:15: error:
> >  'davinci_init_late' undeclared here (not in a function)
> > make[1]: *** [arch/arm/mach-davinci/board-tnetv107x-evm.o] Error 1
> > 
> > Following patch fixes the build above breakage
> 
> The error you are seeing and the patch you provided below have no
> correlation.

No. Above build error fixed by
 
+#include 

Other changes are not related to above error.

> 
> > 
> > diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c 
> > b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> > index ba79837..4a9c320 100644
> > --- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
> > +++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> > @@ -30,6 +30,7 @@
> >  #include 
> >  #include 
> > 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -147,7 +148,7 @@ static struct davinci_nand_pdata nand_config = {
> > .ecc_bits   = 1,
> >  };
> > 
> > -static struct davinci_uart_config serial_config __initconst = {
> > +static struct davinci_uart_config serial_config = {
> > .enabled_uarts  = BIT(1),
> >  };
> 
> You can make this __initdata instead - assuming its okay to have this
> memory discarded at init.

I will check.

> 
> > 
> > @@ -245,7 +246,7 @@ static struct ti_ssp_data ssp_config = {
> > },
> >  };
> > 
> > -static struct tnetv107x_device_info evm_device_info __initconst = {
> > +static struct tnetv107x_device_info evm_device_info = {
> 
> Same here. You can make this __initdata.
> 
> Please send a formal patch for the errors you have seen.

Ok

> 
> > .serial_config  = &serial_config,
> > .mmc_config[1]  = &mmc_config,  /* controller 1 */
> > .nand_config[0] = &nand_config, /* chip select 0 */
> > 
> > 
> > 
> >>
> >>>
> >>> So I prefer to leave tnetv107x platform for now.
> >>
> >> I don't think that's acceptable. At least by me.
> > 
> > I think 2 options are available
> > 1. Convert gpio-tnetv107x.c to platform driver. This will help in
> > removing gpio references in davinci_soc_info structure.
> > 2. Remove inline gpio api support and start use gpiolib support.
> > 
> > I prefer first option. It will help in removing
> > .
> 
> Okay. Can you take this up in this series? I understand you may not have
> an tnetv107x board, but at least you can get to a series that builds.
> 
> Even if you choose to do just option #2, I am OK. What I really want to
> see is inline API gone completely (not just remain largely unused). This
> will also help you avoid exposing internal data structures like
> davinci_gpio_controller exposed to the whole kernel. The worse part
> right now is you have two copies of the same structure exposed globally
> from two different include folders.

I understood. I will take option 2.

Thanks
Avinash

> 
> Thanks,
> Sekhar
> 

Re: am335x: TSC & ADC reworking including DT pieces, take 5

[Sebastian Andrzej Siewior]

On 06/13/2013 11:07 AM, Samuel Ortiz wrote:
> Hi Sebastian,

Hi Samuel,

> Pulled and pushed back to mfd-next, thanks.

Thank you.

> I fixed a couple of unused variable warnings on top of it.

I saw your patch at git.k.o and I am asking you not to taking it :)
The code is:

of_property_for_each_u32(node, "ti,adc-channels", prop, cur, val) {
 adc_channels++;
 if (val > 7) {
 dev_err(&pdev->dev, " PIN numbers are 0..7 (not
%d)\n",
 val);
 return -EINVAL;
 }
 }

and without CONFIG_OF of_property_for_each_u32() becomes most likely
empty. That is why I haven't seen it.
So either the macro should be changed to tell the compiler that the
variables are used (so the warning does not show up) or let the driver
depend on CONFIG_OF. I will look at the former and can prepare a patch
for the latter if you want.

> 
> Cheers,
> Samuel.
> 

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

Re: [PATCH 1/1] move exit_task_namespaces() outside of exit_notify()

[Andrew Vagin]

On Sat, Apr 13, 2013 at 05:55:21PM +0200, Oleg Nesterov wrote:
> exit_notify() does exit_task_namespaces() after
> forget_original_parent(). This was needed to ensure that ->nsproxy
> can't be cleared prematurely, an exiting child we are going to
> reparent can do do_notify_parent() and use the parent's (ours) pid_ns.
> 
> However, after 32084504 "pidns: use task_active_pid_ns in
> do_notify_parent" ->nsproxy != NULL is no longer needed, we rely
> on task_active_pid_ns().
> 
> Move exit_task_namespaces() from exit_notify() to do_exit(), after
> exit_fs() and before exit_task_work().
> 
> This solves the problem reported by Andrey, free_ipc_ns()->shm_destroy()
> does fput() which needs task_work_add(). And this allows us do simplify
> exit_notify(), we can avoid unlock/lock(tasklist) and we can change
> ->exit_state instead of PF_EXITING in forget_original_parent().
>

It looks good for me. kmemleak doesn't report any leaks. CRIU test
cases, which use namespaces, work without any errors.

Thanks.

Acked-by: Andrey Vagin 

> Reported-by: Andrey Vagin 
> Signed-off-by: Oleg Nesterov 
> 
> --- x/kernel/exit.c
> +++ x/kernel/exit.c
> @@ -649,7 +649,6 @@ static void exit_notify(struct task_stru
>*  jobs, send them a SIGHUP and then a SIGCONT.  (POSIX 3.2.2.2)
>*/
>   forget_original_parent(tsk);
> - exit_task_namespaces(tsk);
>  
>   write_lock_irq(&tasklist_lock);
>   if (group_dead)
> @@ -795,6 +794,7 @@ void do_exit(long code)
>   exit_shm(tsk);
>   exit_files(tsk);
>   exit_fs(tsk);
> + exit_task_namespaces(tsk);
>   exit_task_work(tsk);
>   check_stack_usage();
>   exit_thread();
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/11] ARM:stixxxx: Add stixxxx options to multi_v7_defconfig

[Srinivas KANDAGATLA]

On 10/06/13 14:15, Mark Rutland wrote:
> CONFIG_EXPERIMENTAL's gone as of 3d374d09f1: "final removal of
> CONFIG_EXPERIMENTAL", so that's fine to go. CONFIG_GPIO_PL061 and
> CONFIG_MMC_WMT get selected elsewhere, so that's fine.
> 

Am planning to send a patch to clean this up, so that any new platform
addition to the multi_v7_defconfig will not under go this discussion again..

> It looks like the architected timer deselection is fallout of my own making,
> the multi_v7_defconfig should now contain HAVE_ARM_ARCH_TIMER rather than
> ARM_ARCH_TIMER.
Why should it even contain HAVE_ARM_ARCH_TIMER/ARM_ARCH_TIMER?
The only reason I see for de-selection is because none of the platforms
in the multi_v7 defconfig selects it.

Looks like there is no platform in mulit_v7 config which requires this
support. If there is one I think it should select it.

Am I correct?

Thanks,
srini

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv7 01/11] clockevents: Prefer CPU local devices over global devices

[Daniel Lezcano]

On 06/12/2013 11:44 PM, Stephen Boyd wrote:
> On 06/06, Stephen Boyd wrote:
>> On 06/07, Daniel Lezcano wrote:
>>> On 06/06/2013 08:04 PM, Stephen Boyd wrote:
 On 06/06, Daniel Lezcano wrote:
> On 06/03/2013 10:33 PM, Stephen Boyd wrote:
>> On an SMP system with only one global clockevent and a dummy
>> clockevent per CPU we run into problems. We want the dummy
>> clockevents to be registered as the per CPU tick devices, but
>> we can only achieve that if we register the dummy clockevents
>> before the global clockevent or if we artificially inflate the
>> rating of the dummy clockevents to be higher than the rating
>> of the global clockevent. Failure to do so leads to boot
>> hangs when the dummy timers are registered on all other CPUs
>> besides the CPU that accepted the global clockevent as its tick
>> device and there is no broadcast timer to poke the dummy
>> devices.
>>
>> If we're registering multiple clockevents and one clockevent is
>> global and the other is local to a particular CPU we should
>> choose to use the local clockevent regardless of the rating of
>> the device. This way, if the clockevent is a dummy it will take
>> the tick device duty as long as there isn't a higher rated tick
>> device and any global clockevent will be bumped out into
>> broadcast mode, fixing the problem described above.
>
> It is not clear the connection between the changelog, the patch and the
> comment. Could you clarify a bit ?
>

 There is one tick device per-cpu and one broadcast device. The
 broadcast device can only be a global clockevent, whereas the
 per-cpu tick device can be a global clockevent or a per-cpu
 clockevent. The code tries hard to keep per-cpu clockevents in
 the tick device slots but it has an ordering/rating requirement
 that doesn't work when there are only dummy per-cpu devices and
 one global device.

 Perhaps an example will help. Let's say you only have one global
 clockevent such as the sp804, and you have SMP enabled. To
 support SMP we have to register dummy clockevents on each CPU so
 that the sp804 can go into broadcast mode. If we don't do this,
 only the CPU that registered the sp804 will get interrupts while
 the other CPUs will be left with no tick device and thus no
 scheduling. To fix this we register dummy clockevents on all the
 CPUs _before_ we register the sp804 to force the sp804 into the
 broadcast slot. Or we give the dummy clockevents a higher rating
 than the sp804 so that when we register them after the sp804 the
 sp804 is bumped out to broadcast duty.

 If the dummy devices are registered before the sp804 we can give
 the dummies a low rating and the sp804 will still go into the
 broadcast slot due to this code:

/*
 * If we have a cpu local device already, do not replace it
 * by a non cpu local device
 */
if (curdev && cpumask_equal(curdev->cpumask, cpumask_of(cpu)))
goto out_bc;

 If we register the sp804 before the dummies we're also fine as
 long as the rating of the dummy is more than the sp804.  Playing
 games with the dummy rating is not very nice so this patch fixes
 it by allowing the per-cpu device to replace the global device no
 matter what the rating of the global device is.

 This fixes the sp804 case when the dummy is rated lower than
 sp804 and it removes any ordering requirement from the
 registration of clockevents. It also completes the logic above
 where we prefer cpu local devices over non cpu local devices.
>>>
>>> Thanks for the detailed explanation.
>>>
>>> Did Thomas reacted to this patch ?
>>>
>>
>> So far there has been no response from Thomas.
>>
> 
> Will you ack this patch anyway? Or do we need Thomas to review
> this patch? It seems that this patch series has stalled again.

I prefer Thomas to have a look at it and ack it. I changed Cc to To for
Thomas.

Thanks
  -- Daniel


-- 
  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 00/32] ARM: ux500: Enable clocks for Device Tree

[Lee Jones]

On Thu, 13 Jun 2013, Linus Walleij wrote:

> On Wed, Jun 12, 2013 at 3:27 PM, Lee Jones  wrote:
> >> After this patchset has been applied, we can request clocks directly
> >> from Device Tree without using any AUXDATA device-name hacks. We also
> >> take care to remove all of thos at the end of the set.
> >
> > So it looks like Mike and Grant have okayed the actual design of this
> > patch-set, which is great. Is there any chance on some proper Acks from
> > Linus and Mike please?
> 
> I will get to it. Basically I don't see there is a hurry as this has
> no chance to hit the v3.11 merge window anyway so we'll have
> lots of time to discuss it.
> 
> Why 3.12: my five pull request for ux500 stuff to ARM SoC is still
> outstanding, and this stuff will clash with that unless we get
> a common merge base. So we have to wait for ARM SoC
> to settle at this point.

I understand, thanks for the clarification.

I'm fairly sure the semantics are sound, so I'll duplicate them for
the u8540 - working on that now.

-- 
Lee Jones
Linaro ST-Ericsson 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: am335x: TSC & ADC reworking including DT pieces, take 5

[Samuel Ortiz]

Hi Sebastian,

On Thu, Jun 13, 2013 at 11:25:26AM +0200, Sebastian Andrzej Siewior wrote:
> > I fixed a couple of unused variable warnings on top of it.
> 
> I saw your patch at git.k.o and I am asking you not to taking it :)
I understand why now, I'll remove it. Sorry about that.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.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 2/2] rtc: omap: add rtc wakeup support to alarm events

[Hebbar, Gururaja]

Hi Kevin,

On Mon, Jun 10, 2013 at 16:55:17, Hebbar, Gururaja wrote:
> On Fri, May 31, 2013 at 23:11:22, Kevin Hilman wrote:
> > Hebbar Gururaja  writes:
> > 
> > > On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
> > > is available to enable Wakeup feature for Alarm Events.
> > >
> > > Since new platforms/Boards are now added through DT only, this feature
> > > is supported via DT property only.
> > 
> > > Platforms using such IP should add the property "ti,has_irq_wake_enb"
> > > in rtc DT node.
> > 
> > This is a property of the IP, not the board.  Can't you detect this
> > based on the revision of the IP?
> 
> Here is what I found out till now.
> 
> 1. rtc-omap driver is used by Davinci, OMAP-1/2 & AM33xx SoC.
> 
> 2. Only AM33xx soc rtc ip has revision register (& populated). Older OMAP
>Or davinci doesn't have this register.
> 
> 3. AFAIK, this was the reason why Afzal used platform_device_id & 
>of_device_id->data method to detect new versions (commit
>9e0344dcc225fe1a0e8b8af9ff7df44ec4613580)
> 
> 
> So now either 
> a. I can follow the same method and add new member to omap_rtc_devtype & add 
> a new compatible in 
>  omap_rtc_of_match in rtc-omap.c
> 
> or
> 
> b. use dt property to indicate existence of above property.
> 
> 
> Kindly let me know your opinion about the same.

Any update on this. I have patch ready for both the choices. Waiting for your 
ok to send


> 
> > 
> > Kevin
> > 
> 
> 
> Regards, 
> Gururaja
> 


Regards, 
Gururaja
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 PATCH v3 0/2] drivers: mfd: Versatile Express SPC support

[Pawel Moll]

On Thu, 2013-06-13 at 01:13 +0100, Samuel Ortiz wrote:
> Now, about the driver itself, besides the really odd code design, the
> static variables all over the place, the nasty init hacks and the
> unneeded long function names, someone should refresh my memory and explain
> to me why is this guy under mfd. I can see it somehow supports IP blocks
> providing different functions, but the design is not sharing anything with
> most of the rest of the mfd drivers.

I belive the vexpress-sysreg.c is a Multi Function Device by all means.
It does so many things that only a water fountain is missing ;-)

If you feel strongly about it, I'm ready to split it into mfd_cells and
move the gpio and leds code into separate drivers, however I'm not
convinced that it's worth the effort.

Now, as to the vexpress-config.c... The first time I've posted the
series, all parts lived in "driver/misc(/vexpress)", but (if I remember
correctly) Arnd had some feelings about "misc" existence at all... I was
thinking about a separate directory for random "system/platform/machine
configuration" drivers, but the idea didn't get any traction.

> Not only that, but the whole vexpress-config code design is not the
> nicest piece of code I've ever seen. And I'm usually not picky. e.g. the
> whole vexpress-config ad-hoc API is awkward and I wonder if it could be
> implemented as a bus instead.

Funny you mention this :-) Again, the first version actually was a
vexpress-config bus. The feedback was - a whole bus_type is over the top
(I'm simplifying the letter slightly but this was the spirit).

> FWIW I take the blame here for not reviewing the initial driver
> submission that Arnd kindly sent to me...But now that I'm looking at it,
> I think it really is on the edge of being staging material. Any thought
> on that ?

I'm more than happy to improve it. The infrastructure (as in: the
hardware) itself is slightly strange and the code pretty much reflects
the situation. There is also a very good reason for some of the oddities
like static bridges array etc - the infrastructure must be functional
very early, long before slab is available (this also caused a lot of
issues with the bus-based implementation, as the device model does
kmalloc all over the place).

So to summarize - I'm open to any suggestions and ready to spend time on
this stuff.

Regards and thanks for your time!

Pawel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: add support for MOST protocol

[David Miller]

From: Giancarlo Asnaghi 
Date: Mon, 10 Jun 2013 14:52:25 +0200

> This patch adds core support for the MOST protocol. More information
> about the protocol can be found at: http://www.mostcooperation.com/
> 
> See the lkml message "[PATCH 0/3] MOST network protocol" sent on Jun
> 10th 2013 about this code and the missing "Signed-off" lines.

There are a lot of coding style issues in these patches, I'm only going
to point out one:

> + if (most_sk(sk)->dev_id == dev_id &&
> + most_sk(sk)->channel_type == most_cb(skb)->channel_type
> + && most_sk(sk)->rx_channel == most_cb(skb)->channel &&
> + sk->sk_state == MOST_BOUND) {

Frankly, this is very ugly, even ignoring the standard coding style rules.

First of all, never put the operators at the beginning of the line.
This code not only does that, but it mixes style every other line,
that's terrible.

Secondly, each line of the conditional after the first must line up
at the first column after the openning parenthesis of the if() statement
(or any inner parenthetical grouping the expression is a part of).

You achieve such alignment using the appropriate number of TAB and
space characters necessary to do so, for example:

if (x &&
y &&
z) {
...
}

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

[PATCH v2 0/4] gpu: host1x: add runtime pm support

[Mayuresh Kulkarni]

This patch-set series adds runtime pm support for host1x,
gr2d & dc. It retains the current behaviour if CONFIG_PM_RUNTIME
is not enabled.

For host1x & gr2d, the clocks are now enabled in .probe
and disabled on its exit. This is needed for correct
init of hardware.

Additionally for gr2d, the clocks are also enabled when
a new work is submitted and disabled when the work is done.
Due to parent->child relations between host1x->gr2d,
this scheme also ends up in enabling & disabling host1x clock

For dc, the clocks are enabled in .probe and disabled in
.remove but via runtime pm instead of direct clock APIs.

Mayuresh Kulkarni (4):
  gpu: host1x: shuffle job APIs
  gpu: host1x: add runtime pm support for gr2d
  gpu: host1x: add runtime pm support for dc
  gpu: host1x: add runtime pm support for host1x

 drivers/gpu/host1x/cdma.c |  2 ++
 drivers/gpu/host1x/channel.c  |  8 --
 drivers/gpu/host1x/channel.h  |  1 -
 drivers/gpu/host1x/dev.c  | 57 
 drivers/gpu/host1x/drm/dc.c   | 60 +++
 drivers/gpu/host1x/drm/gr2d.c | 56 +++-
 drivers/gpu/host1x/job.c  | 21 +++
 drivers/gpu/host1x/job.h  |  3 +++
 8 files changed, 193 insertions(+), 15 deletions(-)

-- 
1.8.1.5

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

[PATCH v2 1/4] gpu: host1x: shuffle job APIs

[Mayuresh Kulkarni]

This patch moves the API host1x_job_submit to job.c file. It also
adds a new API host1x_job_complete.

This is in preparation to add runtime PM support to host1x &
its modules. The idea is to call pm_runtime_get from
host1x_job_submit and pm_runtime_put from host1x_job_complete.

This way the runtime PM calls are localized to single file &
easy to maintain as well as debug

Signed-off-by: Mayuresh Kulkarni 
---
 drivers/gpu/host1x/cdma.c|  2 ++
 drivers/gpu/host1x/channel.c |  8 
 drivers/gpu/host1x/channel.h |  1 -
 drivers/gpu/host1x/job.c | 12 
 drivers/gpu/host1x/job.h |  3 +++
 5 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index de72172..910087b 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -252,6 +252,8 @@ static void update_cdma_locked(struct host1x_cdma *cdma)
signal = true;
}
 
+   host1x_job_complete(job);
+
list_del(&job->list);
host1x_job_put(job);
}
diff --git a/drivers/gpu/host1x/channel.c b/drivers/gpu/host1x/channel.c
index 83ea51b..c381441 100644
--- a/drivers/gpu/host1x/channel.c
+++ b/drivers/gpu/host1x/channel.c
@@ -21,7 +21,6 @@
 
 #include "channel.h"
 #include "dev.h"
-#include "job.h"
 
 /* Constructor for the host1x device list */
 int host1x_channel_list_init(struct host1x *host)
@@ -37,13 +36,6 @@ int host1x_channel_list_init(struct host1x *host)
return 0;
 }
 
-int host1x_job_submit(struct host1x_job *job)
-{
-   struct host1x *host = dev_get_drvdata(job->channel->dev->parent);
-
-   return host1x_hw_channel_submit(host, job);
-}
-
 struct host1x_channel *host1x_channel_get(struct host1x_channel *channel)
 {
int err = 0;
diff --git a/drivers/gpu/host1x/channel.h b/drivers/gpu/host1x/channel.h
index 48723b8..8401f25 100644
--- a/drivers/gpu/host1x/channel.h
+++ b/drivers/gpu/host1x/channel.h
@@ -44,7 +44,6 @@ struct host1x_channel *host1x_channel_request(struct device 
*dev);
 void host1x_channel_free(struct host1x_channel *channel);
 struct host1x_channel *host1x_channel_get(struct host1x_channel *channel);
 void host1x_channel_put(struct host1x_channel *channel);
-int host1x_job_submit(struct host1x_job *job);
 
 #define host1x_for_each_channel(host, channel) \
list_for_each_entry(channel, &host->chlist.list, list)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index cc80766..05bafa4 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -586,3 +586,15 @@ void host1x_job_dump(struct device *dev, struct host1x_job 
*job)
dev_dbg(dev, "NUM_SLOTS   %d\n", job->num_slots);
dev_dbg(dev, "NUM_HANDLES %d\n", job->num_unpins);
 }
+
+int host1x_job_submit(struct host1x_job *job)
+{
+   struct host1x *host = dev_get_drvdata(job->channel->dev->parent);
+
+   return host1x_hw_channel_submit(host, job);
+}
+
+int host1x_job_complete(struct host1x_job *job)
+{
+   return 0;
+}
diff --git a/drivers/gpu/host1x/job.h b/drivers/gpu/host1x/job.h
index fba45f2..e0249c3 100644
--- a/drivers/gpu/host1x/job.h
+++ b/drivers/gpu/host1x/job.h
@@ -159,4 +159,7 @@ void host1x_job_unpin(struct host1x_job *job);
  */
 void host1x_job_dump(struct device *dev, struct host1x_job *job);
 
+int host1x_job_submit(struct host1x_job *job);
+int host1x_job_complete(struct host1x_job *job);
+
 #endif
-- 
1.8.1.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 v2 02/14] ARM: OMAP2+: AM43x: Kconfig

[Tony Lindgren]

* Mohammed, Afzal  [130613 00:04]:
> Hi Tony,
> 
> On Wed, Jun 12, 2013 at 22:42:00, Tony Lindgren wrote:
> 
> > I've updated this patch to remove the "default y" and
> > "depends on ARCH_OMAP2PLUS" entries for the usual reasons
> > and applied the first ten patches into omap-for-v3.11/soc.
> 
> Thanks.
> 
> Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in
> omap-for-v3.11/soc branch and omap soc pull request, can you
> please help patch 10 also to go upstream.

Hmm if that's .dts changes, Benoit needs to queue that.

Regards,

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

Re: [RFC PATCH v3 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support

[Lorenzo Pieralisi]

Hi Samuel,

first things first, thanks a lot for having a look.

On Thu, Jun 13, 2013 at 01:01:43AM +0100, Samuel Ortiz wrote:
> Hi Lorenzo,
> 
> I don't particularily like this code, but I guess most of my dislike
> comes from the whole bridge interface API and how that forces you into
> implementing pretty much static code.

I do not particularly like it either; you have to grant us though, as Nico
explained, that the usage of this piece of hardware very early at boot is
forcing us to find a solution that is not necessarily easy to implement.

> A few nitpicks:
> 
> On Thu, Jun 06, 2013 at 10:59:23AM +0100, Lorenzo Pieralisi wrote:
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index d54e985..391eda1 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -1148,3 +1148,10 @@ config VEXPRESS_CONFIG
> > help
> >   Platform configuration infrastructure for the ARM Ltd.
> >   Versatile Express.
> > +
> > +config VEXPRESS_SPC
> > +   bool "Versatile Express SPC driver support"
> > +   depends on ARM
> > +   depends on VEXPRESS_CONFIG
> > +   help
> Please provide a detailed help entry here. 

Ok.

> > + Serial Power Controller driver for ARM Ltd. test chips.
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 718e94a..3a01203 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -153,5 +153,6 @@ obj-$(CONFIG_MFD_SEC_CORE)  += sec-core.o sec-irq.o
> >  obj-$(CONFIG_MFD_SYSCON)   += syscon.o
> >  obj-$(CONFIG_MFD_LM3533)   += lm3533-core.o lm3533-ctrlbank.o
> >  obj-$(CONFIG_VEXPRESS_CONFIG)  += vexpress-config.o vexpress-sysreg.o
> > +obj-$(CONFIG_VEXPRESS_SPC) += vexpress-spc.o
> So you have Versatile Express platforms that will not need SPC ? i.e.
> why isn't all that stuff under a generic CONFIG_VEXPRESS symbol ?

You answered your own question, the Serial Power Controller aka SPC is
present only in one of the many coretiles that can be stacked on top
of the versatile express motherboard, so it requires a specific entry
unless we want to compile it in for all vexpress platforms.

> > +static struct vexpress_spc_drvdata *info;
> > +static u32 *vexpress_spc_config_data;
> > +static struct vexpress_config_bridge *vexpress_spc_config_bridge;
> > +static struct vexpress_config_func *opp_func, *perf_func;
> > +
> > +static int vexpress_spc_load_result = -EAGAIN;
> As I said, quite static...

I will have a look and see if I can improve it, I could include some of
those variables in the driver data and alloc them dynamically.

> > +irqreturn_t vexpress_spc_irq_handler(int irq, void *data)
> missing a static here ?

Were not there enough :-) ? Correct, I will fix it.

> > +static bool __init __vexpress_spc_check_loaded(void);
> > +/*
> > + * Pointer spc_check_loaded is swapped after init hence it is safe
> > + * to initialize it to a function in the __init section
> > + */
> > +static bool (*spc_check_loaded)(void) __refdata = 
> > &__vexpress_spc_check_loaded;
> > +
> > +static bool __init __vexpress_spc_check_loaded(void)
> > +{
> > +   if (vexpress_spc_load_result == -EAGAIN)
> > +   vexpress_spc_load_result = vexpress_spc_init();
> > +   spc_check_loaded = &vexpress_spc_initialized;
> > +   return vexpress_spc_initialized();
> > +}
> > +
> > +/*
> > + * Function exported to manage early_initcall ordering.
> > + * SPC code is needed very early in the boot process
> > + * to bring CPUs out of reset and initialize power
> > + * management back-end. After boot swap pointers to
> > + * make the functionality check available to loadable
> > + * modules, when early boot init functions have been
> > + * already freed from kernel address space.
> > + */
> > +bool vexpress_spc_check_loaded(void)
> > +{
> > +   return spc_check_loaded();
> > +}
> > +EXPORT_SYMBOL_GPL(vexpress_spc_check_loaded);
> That one and the previous function look really nasty to me.
> The simple fact that you need a static variable in your code to check if
> your module is loaded sounds really fishy.

Nico explained the reasons behind this nasty hack, because that's what it
is. The only solution is resorting to vexpress platform code to initialize
this driver directly (providing a static virtual memory mapping since that
has to happen very early) to remove all needs for early_initcall
synchronization and remove that variable. It won't look nicer though.

I will review the code again to see how I can improve it.

Thanks a lot,
Lorenzo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] gpu: host1x: add runtime pm support for host1x

[Mayuresh Kulkarni]

Signed-off-by: Mayuresh Kulkarni 
---
 drivers/gpu/host1x/dev.c | 57 
 1 file changed, 57 insertions(+)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 28e28a2..b43eb29 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CREATE_TRACE_POINTS
 #include 
@@ -143,11 +144,16 @@ static int host1x_probe(struct platform_device *pdev)
return err;
}
 
+#ifdef CONFIG_PM_RUNTIME
+   pm_runtime_enable(&pdev->dev);
+   pm_runtime_get_sync(&pdev->dev);
+#else
err = clk_prepare_enable(host->clk);
if (err < 0) {
dev_err(&pdev->dev, "failed to enable clock\n");
return err;
}
+#endif
 
err = host1x_syncpt_init(host);
if (err) {
@@ -165,10 +171,17 @@ static int host1x_probe(struct platform_device *pdev)
 
host1x_drm_alloc(pdev);
 
+#ifdef CONFIG_PM_RUNTIME
+   pm_runtime_put(&pdev->dev);
+#endif
+
return 0;
 
 fail_deinit_syncpt:
host1x_syncpt_deinit(host);
+#ifdef CONFIG_PM_RUNTIME
+   pm_runtime_put(&pdev->dev);
+#endif
return err;
 }
 
@@ -179,10 +192,51 @@ static int __exit host1x_remove(struct platform_device 
*pdev)
host1x_intr_deinit(host);
host1x_syncpt_deinit(host);
clk_disable_unprepare(host->clk);
+#ifdef CONFIG_PM_RUNTIME
+   pm_runtime_disable(&pdev->dev);
+#endif
+
+   return 0;
+}
+
+#ifdef CONFIG_PM_RUNTIME
+static int host1x_runtime_suspend(struct device *dev)
+{
+   struct host1x *host;
+
+   host = dev_get_drvdata(dev);
+   if (!host)
+   return -EINVAL;
+
+   clk_disable_unprepare(host->clk);
 
return 0;
 }
 
+static int host1x_runtime_resume(struct device *dev)
+{
+   int err = 0;
+   struct host1x *host;
+
+   host = dev_get_drvdata(dev);
+   if (!host)
+   return -EINVAL;
+
+   err = clk_prepare_enable(host->clk);
+   if (err < 0)
+   dev_err(dev, "failed to enable clock\n");
+
+   return err;
+}
+#endif /* CONFIG_PM_RUNTIME */
+
+#ifdef CONFIG_PM
+static const struct dev_pm_ops host1x_pm_ops = {
+   SET_RUNTIME_PM_OPS(host1x_runtime_suspend,
+   host1x_runtime_resume, NULL)
+};
+#endif
+
 static struct platform_driver tegra_host1x_driver = {
.probe = host1x_probe,
.remove = __exit_p(host1x_remove),
@@ -190,6 +244,9 @@ static struct platform_driver tegra_host1x_driver = {
.owner = THIS_MODULE,
.name = "tegra-host1x",
.of_match_table = host1x_of_match,
+#ifdef CONFIG_PM
+   .pm = &host1x_pm_ops,
+#endif
},
 };
 
-- 
1.8.1.5

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

[PATCH v2 2/4] gpu: host1x: add runtime pm support for gr2d

[Mayuresh Kulkarni]

Signed-off-by: Mayuresh Kulkarni 
---
 drivers/gpu/host1x/drm/gr2d.c | 56 ++-
 drivers/gpu/host1x/job.c  |  9 +++
 2 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
index 27ffcf1..eb506cd 100644
--- a/drivers/gpu/host1x/drm/gr2d.c
+++ b/drivers/gpu/host1x/drm/gr2d.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "channel.h"
 #include "drm.h"
@@ -275,11 +276,18 @@ static int gr2d_probe(struct platform_device *pdev)
return PTR_ERR(gr2d->clk);
}
 
+   platform_set_drvdata(pdev, gr2d);
+
+#ifdef CONFIG_PM_RUNTIME
+   pm_runtime_enable(&pdev->dev);
+   pm_runtime_get_sync(&pdev->dev);
+#else
err = clk_prepare_enable(gr2d->clk);
if (err) {
dev_err(dev, "cannot turn on clock\n");
return err;
}
+#endif
 
gr2d->channel = host1x_channel_request(dev);
if (!gr2d->channel)
@@ -305,7 +313,9 @@ static int gr2d_probe(struct platform_device *pdev)
 
gr2d_init_addr_reg_map(dev, gr2d);
 
-   platform_set_drvdata(pdev, gr2d);
+#ifdef CONFIG_PM_RUNTIME
+   pm_runtime_put(&pdev->dev);
+#endif
 
return 0;
 }
@@ -328,10 +338,51 @@ static int __exit gr2d_remove(struct platform_device 
*pdev)
 
host1x_channel_free(gr2d->channel);
clk_disable_unprepare(gr2d->clk);
+#ifdef CONFIG_PM_RUNTIME
+   pm_runtime_disable(&pdev->dev);
+#endif
+
+   return 0;
+}
+
+#ifdef CONFIG_PM_RUNTIME
+static int gr2d_runtime_suspend(struct device *dev)
+{
+   struct gr2d *gr2d;
+
+   gr2d = dev_get_drvdata(dev);
+   if (!gr2d)
+   return -EINVAL;
+
+   clk_disable_unprepare(gr2d->clk);
 
return 0;
 }
 
+static int gr2d_runtime_resume(struct device *dev)
+{
+   int err = 0;
+   struct gr2d *gr2d;
+
+   gr2d = dev_get_drvdata(dev);
+   if (!gr2d)
+   return -EINVAL;
+
+   err = clk_prepare_enable(gr2d->clk);
+   if (err < 0)
+   dev_err(dev, "failed to enable clock\n");
+
+   return err;
+}
+#endif /* CONFIG_PM_RUNTIME */
+
+#ifdef CONFIG_PM
+static const struct dev_pm_ops gr2d_pm_ops = {
+   SET_RUNTIME_PM_OPS(gr2d_runtime_suspend,
+   gr2d_runtime_resume, NULL)
+};
+#endif
+
 struct platform_driver tegra_gr2d_driver = {
.probe = gr2d_probe,
.remove = __exit_p(gr2d_remove),
@@ -339,5 +390,8 @@ struct platform_driver tegra_gr2d_driver = {
.owner = THIS_MODULE,
.name = "gr2d",
.of_match_table = gr2d_match,
+#ifdef CONFIG_PM
+   .pm = &gr2d_pm_ops,
+#endif
}
 };
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 05bafa4..a1b05f0 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "channel.h"
@@ -591,10 +592,18 @@ int host1x_job_submit(struct host1x_job *job)
 {
struct host1x *host = dev_get_drvdata(job->channel->dev->parent);
 
+#ifdef CONFIG_PM_RUNTIME
+   pm_runtime_get_sync(job->channel->dev);
+#endif
+
return host1x_hw_channel_submit(host, job);
 }
 
 int host1x_job_complete(struct host1x_job *job)
 {
+#ifdef CONFIG_PM_RUNTIME
+   return pm_runtime_put(job->channel->dev);
+#else
return 0;
+#endif
 }
-- 
1.8.1.5

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

[PATCH v2 3/4] gpu: host1x: add runtime pm support for dc

[Mayuresh Kulkarni]

As of now, the dc clock is enabled in its .probe via
runtime pm and disabled in .remove

Signed-off-by: Mayuresh Kulkarni 
---
 drivers/gpu/host1x/drm/dc.c | 60 +
 1 file changed, 55 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/host1x/drm/dc.c b/drivers/gpu/host1x/drm/dc.c
index 5360e5a..8e669a9 100644
--- a/drivers/gpu/host1x/drm/dc.c
+++ b/drivers/gpu/host1x/drm/dc.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "host1x_client.h"
 #include "dc.h"
@@ -1128,9 +1129,7 @@ static int tegra_dc_probe(struct platform_device *pdev)
return PTR_ERR(dc->clk);
}
 
-   err = clk_prepare_enable(dc->clk);
-   if (err < 0)
-   return err;
+   platform_set_drvdata(pdev, dc);
 
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dc->regs = devm_ioremap_resource(&pdev->dev, regs);
@@ -1147,6 +1146,15 @@ static int tegra_dc_probe(struct platform_device *pdev)
dc->client.ops = &dc_client_ops;
dc->client.dev = &pdev->dev;
 
+#ifdef CONFIG_PM_RUNTIME
+   pm_runtime_enable(&pdev->dev);
+   pm_runtime_get_sync(&pdev->dev);
+#else
+   err = clk_prepare_enable(dc->clk);
+   if (err < 0)
+   return err;
+#endif
+
err = tegra_dc_rgb_probe(dc);
if (err < 0 && err != -ENODEV) {
dev_err(&pdev->dev, "failed to probe RGB output: %d\n", err);
@@ -1160,8 +1168,6 @@ static int tegra_dc_probe(struct platform_device *pdev)
return err;
}
 
-   platform_set_drvdata(pdev, dc);
-
return 0;
 }
 
@@ -1178,11 +1184,52 @@ static int tegra_dc_remove(struct platform_device *pdev)
return err;
}
 
+#ifdef CONFIG_PM_RUNTIME
+   pm_runtime_put(&pdev->dev);
+   pm_runtime_disable(&pdev->dev);
+#endif
+
+   return 0;
+}
+
+#ifdef CONFIG_PM_RUNTIME
+static int tegra_dc_runtime_suspend(struct device *dev)
+{
+   struct tegra_dc *dc;
+
+   dc = dev_get_drvdata(dev);
+   if (!dc)
+   return -EINVAL;
+
clk_disable_unprepare(dc->clk);
 
return 0;
 }
 
+static int tegra_dc_runtime_resume(struct device *dev)
+{
+   int err = 0;
+   struct tegra_dc *dc;
+
+   dc = dev_get_drvdata(dev);
+   if (!dc)
+   return -EINVAL;
+
+   err = clk_prepare_enable(dc->clk);
+   if (err < 0)
+   dev_err(dev, "failed to enable clock\n");
+
+   return err;
+}
+#endif /* CONFIG_PM_RUNTIME */
+
+#ifdef CONFIG_PM
+static const struct dev_pm_ops tegra_dc_pm_ops = {
+   SET_RUNTIME_PM_OPS(tegra_dc_runtime_suspend,
+   tegra_dc_runtime_resume, NULL)
+};
+#endif
+
 static struct of_device_id tegra_dc_of_match[] = {
{ .compatible = "nvidia,tegra30-dc", },
{ .compatible = "nvidia,tegra20-dc", },
@@ -1194,6 +1241,9 @@ struct platform_driver tegra_dc_driver = {
.name = "tegra-dc",
.owner = THIS_MODULE,
.of_match_table = tegra_dc_of_match,
+#ifdef CONFIG_PM
+   .pm = &tegra_dc_pm_ops,
+#endif
},
.probe = tegra_dc_probe,
.remove = tegra_dc_remove,
-- 
1.8.1.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] Revert "V4L/DVB: uvc: Enable USB autosuspend by default on uvcvideo"

[Adam Lee]

On Thu, Apr 25, 2013 at 02:33:06PM +0800, Adam Lee wrote:
> On Wed, Apr 24, 2013 at 11:17:52AM +0200, Laurent Pinchart wrote:
> > Hi Adam,
> > 
> > Thanks for the patch.
> > 
> > On Wednesday 24 April 2013 15:57:19 adam@canonical.com wrote:
> > > From: Adam Lee 
> > > 
> > > This reverts commit 3dae8b41dc5651f8eb22cf310e8b116480ba25b7.
> > > 
> > > 1, I do have a Chicony webcam, implements autosuspend in a broken way,
> > > make `poweroff` performs rebooting when its autosuspend enabled.
> > > 
> > > 2, There are other webcams which don't support autosuspend too, like
> > > https://patchwork.kernel.org/patch/2356141/
> > > 
> > > 3, kernel removed USB_QUIRK_NO_AUTOSUSPEND in
> > > a691efa9888e71232dfb4088fb8a8304ffc7b0f9, because autosuspend is
> > > disabled by default.
> > > 
> > > So, we need to disable autosuspend in uvcvideo, maintaining a quirk list
> > > only for uvcvideo is not a good idea.
> > 
> > I've received very few bug reports about broken auto-suspend support in UVC 
> > devices. Most of them could be solved by setting the RESET_RESUME quirk in 
> > USB 
> > core, only the Creative Live! Cam Optia AF required a quirk in the uvcvideo 
> > driver. I would thus rather use the available quirks 
> > (USB_QUIRK_RESET_RESUME 
> > if possible, UVC_QUIRK_DISABLE_AUTOSUSPEND otherwise) than killing power 
> > management for the vast majority of webcams that behave correctly.
> 
> Here comes another one, integrated Chicony webcam 04f2:b39f, its
> autosuspend makes `poweroff` performs rebooting at the laptop I'm
> working on. I tried USB_QUIRK_RESET_RESUME, not helping.
> 
> The quirks list will go longer and longer absolutely, do uvcvideo wanna
> maintain that? And why only uvcvideo do this in kernel space which
> against general USB module?
> 
> I still suggest we disable it by default, people can enable it in udev
> just like almost all distroes do for udisks. Please consider about it.

Hi, Laurent

Any comment of this? I still think it's a risk to enable autosuspend in
uvcvideo by default, there must be users meeting weird issues but didn't
report to you becaue they didn't figured out the cause.

-- 
Regards,
Adam Lee
Hardware Enablement
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: NULL pointer dereference when loading the gre module (3.10.0-rc4)

[David Miller]

From: Eric Dumazet 
Date: Thu, 06 Jun 2013 20:59:48 -0700

> On Thu, 2013-06-06 at 23:06 -0400, Steven Rostedt wrote:
>> On Fri, Jun 07, 2013 at 12:16:56AM +0200, Steinar H. Gunderson wrote:
>> > Hi,
>> > 
>> > In 3.10.0-rc4, I get this on boot:
>> > 
>> > [   16.871043] BUG: unable to handle kernel NULL pointer dereference at 
>> > 0003
>> > [   16.879453] IP: [] 0xa0e52001
>> 
>> Strange, kallsyms should have registered the address already, even if it
>> crashed on early module load. Not sure why it's not reporting it. Well,
>> it seems to have reported some of the symbols of ip_gre below. Maybe
>> this pointer is just totally screwed up.
> 
> I could not reproduce this here.
> 
> Steinar, please make sure you recompiled your modules, because this
> looks like you loaded old modules.

I applied Eric's fixed version of the patch, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig

[Mohammed, Afzal]

Hi Tony,

On Thu, Jun 13, 2013 at 15:24:54, Tony Lindgren wrote:
> * Mohammed, Afzal  [130613 00:04]:

> > Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in
> > omap-for-v3.11/soc branch and omap soc pull request, can you
> > please help patch 10 also to go upstream.
> 
> Hmm if that's .dts changes, Benoit needs to queue that.

It is not dts change.

Patch 10 patches board-generic.c for DT boot (Benoit has already
picked up dts, that is patch 14).

Regards
Afzal

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

Re: [PATCH v5] cpufreq: fix governor start/stop race condition

[Xiaoguang Chen]

2013/6/13 Viresh Kumar :
> On 13 June 2013 14:31, Xiaoguang Chen  wrote:
>> cpufreq governor stop and start should be kept in sequence.
>> If not, there will be unexpected behavior, for example:
>>
>> we have 4 cpus and policy->cpu=cpu0, cpu1/2/3 are linked to cpu0.
>> the normal sequence is as below:
>>
>> 1) Current governor is userspace, one application tries to set
>> governor to ondemand. it will call __cpufreq_set_policy in which it
>> will stop userspace governor and then start ondemand governor.
>>
>> 2) Current governor is userspace, now cpu0 hotplugs in cpu3, it will
>> call cpufreq_add_policy_cpu. on which it first stops userspace
>> governor, and then starts userspace governor.
>>
>> Now if the sequence of above two cases interleaves, it becames
>> below sequence:
>>
>> 1) application stops userspace governor
>> 2)  hotplug stops userspace governor
>> 3) application starts ondemand governor
>> 4)  hotplug starts a governor
>>
>> in step 4, hotplug is supposed to start userspace governor, but now
>> the governor has been changed by application to ondemand, so hotplug
>> starts ondemand governor again 
>>
>> The solution is: do not allow stop one policy's governor multi-times
>> Governor stop should only do once for one policy, after it is stopped,
>> no other governor stop should be executed. also add one mutext to
>> protect __cpufreq_governor so governor operation can be kept in sequence.
>>
>> Signed-off-by: Xiaoguang Chen 
>> ---
>>  drivers/cpufreq/cpufreq.c | 24 
>>  include/linux/cpufreq.h   |  1 +
>>  2 files changed, 25 insertions(+)
>
> I forgot to tell you earlier but please update changelog everytime you
> send a new version.
>
> Acked-by: Viresh Kumar 

Thanks
I'll pay attention next time :)

Xiaoguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: fold ps3remote driver into generic Sony driver

[Jiri Kosina]

On Wed, 12 Jun 2013, David Dillow wrote:

> > I tried to test this tonight, but was thwarted by Fedora 16 on the only
> > readily available test platform -- old bluetoothd w/ the internal
> > driver. I'll need to upgrade that box, recreate the updated bluetooth
> > environment I had from some time ago, or try it on my myth frontend
> > (Ubuntu 13.04). I'll get another chance on the 9th; I won't have access
> > to the HW again until then. :/
> 
> Ok, finally wrestled Myth away from family long enough to test. All
> looks good, sorry about the delay.
> 
> Tested-by: David Dillow 

Perfect, thanks, queued for 3.11.

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

Re: pcie aspm link setup, grandparent instead of parent?

[Radim Krčmář]

2013-06-12 15:54-0600, Bjorn Helgaas:
> [+cc linux-pci, Myron, Joe]

I'll remember it.

> On Wed, Jun 12, 2013 at 11:21 AM, Radim Krčmář  wrote:
> > Hello,
> >
> > as a consequence of hitting a NULL dereference bug[1] while downstream
> > aspm is setting up link_state, I started to wonder why is the code
> > skipping its parent bus in favour of grandparent's link_state.[2]
> >
> > Is this right? (I have no device to test on ...)

No,
pcie_link_state covers both upstream and downstream port, so we skip
upstream port of current device.

Must the "parent device" (grandparent) have valid "->self"?
(qemu allows even topologies without the upstream port, so it does not
count for much ...)

> > Thanks.
> >
> > ---
> > 1: https://bugzilla.redhat.com/show_bug.cgi?id=972381
> >The bug is hit because "pdev->bus->parent" has NULL "->parent" and thus
> >NULL "->self".
> > 2: "pdev = bus->self", so "pdev->bus->parent == bus->parent->parent"
> >
> >
> > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> > index 403a443..d58e282 100644
> > --- a/drivers/pci/pcie/aspm.c
> > +++ b/drivers/pci/pcie/aspm.c
> > @@ -527,7 +527,7 @@ static struct pcie_link_state 
> > *alloc_pcie_link_state(struct pci_dev *pdev)
> > link->pdev = pdev;
> > if (pci_pcie_type(pdev) == PCI_EXP_TYPE_DOWNSTREAM) {
> > struct pcie_link_state *parent;
> > -   parent = pdev->bus->parent->self->link_state;
> > +   parent = pdev->bus->self->link_state;
> > if (!parent) {
> > kfree(link);
> > return NULL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next 1/2] net: remove NET_LL_RX_POLL config menue

[Eliezer Tamir]

On 13/06/2013 11:00, Daniel Borkmann wrote:

On 06/13/2013 04:13 AM, Eliezer Tamir wrote:

On 13/06/2013 05:01, Stephen Hemminger wrote:

On Wed, 12 Jun 2013 15:12:05 -0700 (PDT)
David Miller  wrote:


From: Eliezer Tamir 
Date: Tue, 11 Jun 2013 17:24:28 +0300


  depends on X86_TSC


Wait a second, I didn't notice this before.  There needs to be a better
way to test for the accuracy you need, or if the issue is lack of a
proper
API for cycle counter reading, fix that rather than add ugly arch
specific dependencies to generic networking code.


This should be sched_clock(), rather than direct TSC access.
Also any code using TSC or sched_clock has to be carefully audited to
deal with
clocks running at different rates on different CPU's. Basically value
is only
meaning full on same CPU.


OK,

If we covert to sched_clock(), would adding a define such as
HAVE_HIGH_PRECISION_CLOCK to architectures that have both a high
precision clock and a 64 bit cycles_t be a good solution?

(if not any other suggestion?)


Hm, probably cpu_clock() and similar might be better, since they use
sched_clock() in the background when !CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
(meaning when sched_clock() provides synchronized highres time source from
the architecture), and, quoting 


I don't think we want the overhead of disabling IRQs
that cpu_clock() adds.

We don't really care about precise measurement.
All we need is a sane cut-off for busy polling.
It's no big deal if on a rare occasion we poll less,
or even poll twice the time.
As long as it's rare it should not matter.

Maybe the answer is not to use cycle counting at all?
Maybe just wait the full sk_rcvtimo?
(resched() when proper, bail out if signal pending, etc.)

This could only be a safe/sane thing to do after we add
a socket option, because this can't be a global setting.

This would of course turn the option into a flag.
If it's set (and !nonblock), busy wait up to sk_recvtimo.

Opinions?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/14] ARM: OMAP2+: AM43x: Kconfig

[Tony Lindgren]

* Mohammed, Afzal  [130613 03:08]:
> Hi Tony,
> 
> On Thu, Jun 13, 2013 at 15:24:54, Tony Lindgren wrote:
> > * Mohammed, Afzal  [130613 00:04]:
> 
> > > Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in
> > > omap-for-v3.11/soc branch and omap soc pull request, can you
> > > please help patch 10 also to go upstream.
> > 
> > Hmm if that's .dts changes, Benoit needs to queue that.
> 
> It is not dts change.
> 
> Patch 10 patches board-generic.c for DT boot (Benoit has already
> picked up dts, that is patch 14).

Oops OK sorry I must have miscounted the patches that looked
ready to apply. Will apply.

Regards,

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

Re: [RFC v1] MFD: Change TWL6025 references to TWL6032

[Oleksandr Kozaruk]

On 06/07/2013 05:44 PM, g...@slimlogic.co.uk wrote:

On 2013-06-07 15:36, Mark Brown wrote:

On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote:

From: Graeme Gregory 

The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference the TWL6032 class and name the registers to twl6032 in 
line with

an actual released chip name to avoid confusion.

Currently there is no users of TWL6025 in the code.


Given that the chip exists even if not widely distributed it seems as
well to keep the twl6025 references in there at least in the device ID
table - it won't do any harm to people using the twl6032 name and might
help someone who happens to pick up an old board for whatever reason.


I do not think any "old boards" exist, it really was a limited run!

Graeme


Hello Mark, Graeme,

Taking in account that:
- there is no hardware to test twl6025, testing is not possible;
- there is no documentation for twl6025, and if there are any changes to 
twl6032 is not known;
- twl6032 is available, and in production, twl6025 is not even found on 
ti.com 


So, what do you think, can this change be accepted?

// I apologize for sending personal e-mails, not to the mail list
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drm/omap: change "!CONFIG_FB_OMAP2" to "!FB_OMAP2"

[Paul Bolle]

On Wed, 2013-03-13 at 20:48 +0100, Paul Bolle wrote:
> Signed-off-by: Paul Bolle 
> ---
> Untested. Perhaps the first test that people with access to the relevant
> hardware might do, is to test _before applying this patch_ with FB_OMAP2
> set. Perhaps this negative dependency isn't needed at all. Or is it
> obvious?
> 
>  drivers/gpu/drm/omapdrm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This patch was sent exactly three months ago, shortly after v3.9-rc2 was
released. This obvious typo is still present in v3.10-rc5.

I didn't received any feedback on this patch. Did anyone had a look at
it? Is it perhaps queued somewhere?


Paul Bolle

> diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
> index 09f65dc..45875a0 100644
> --- a/drivers/gpu/drm/omapdrm/Kconfig
> +++ b/drivers/gpu/drm/omapdrm/Kconfig
> @@ -1,7 +1,7 @@
>  
>  config DRM_OMAP
>   tristate "OMAP DRM"
> - depends on DRM && !CONFIG_FB_OMAP2
> + depends on DRM && !FB_OMAP2
>   depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
>   depends on OMAP2_DSS
>   select DRM_KMS_HELPER


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1] MFD: Change TWL6025 references to TWL6032

[Oleksandr Kozaruk]

On 06/07/2013 05:44 PM, g...@slimlogic.co.uk wrote:

On 2013-06-07 15:36, Mark Brown wrote:

On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote:

From: Graeme Gregory 

The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference the TWL6032 class and name the registers to twl6032 in 
line with

an actual released chip name to avoid confusion.

Currently there is no users of TWL6025 in the code.


Given that the chip exists even if not widely distributed it seems as
well to keep the twl6025 references in there at least in the device ID
table - it won't do any harm to people using the twl6032 name and might
help someone who happens to pick up an old board for whatever reason.


I do not think any "old boards" exist, it really was a limited run!

Graeme


Hello Mark, Graeme,

Taking in account that:
- there is no hardware to test twl6025, testing is not possible;
- there is no documentation for twl6025, and if there are any changes to 
twl6032 is not known;
- twl6032 is available, and in production, twl6025 is not even found on 
ti.com 



So, what do you think, can this change be accepted?

// I apologize for sending previous email as personal, not to mail list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Strange intermittent EIO error when writing to stdout since v3.8.0

[Markus Trippelsdorf]

On 2013.06.07 at 20:22 +0200, Mikael Pettersson wrote:
> Peter Hurley writes:
>  > Based on the other reports from Mikael and David, I suspect this problem
>  > may have to do with my commit 699390354da6c258b65bf8fa79cfd5feaede50b6:
>  > 
>  >pty: Ignore slave pty close() if never successfully opened
>  > 
>  > This commit poisons the pty under certain error conditions that may
>  > occur from parallel open()s (or parallel close() with pending write()).
>  > 
>  > It's unclear to me which error condition is triggered and how user-space
>  > got an open file descriptor but that seems the most likely. Is the problem
>  > reproducible enough that a debug patch would likely trigger?
> 
> In my case the problem occurred frequently enough that I've been forced
> to change my build procedures to avoid it.  I'd welcome a debug patch.

Since apparently no debugging patch is forthcoming, maybe it's time to
test the simple revert of commit 699390354da.

So can you guys please apply the following patch and see if the issue
goes away?

Thanks.

diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 59bfaec..f5801a6 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -38,12 +38,9 @@ static void pty_close(struct tty_struct *tty, struct file 
*filp)
if (tty->driver->subtype == PTY_TYPE_MASTER)
WARN_ON(tty->count > 1);
else {
-   if (test_bit(TTY_IO_ERROR, &tty->flags))
-   return;
if (tty->count > 2)
return;
}
-   set_bit(TTY_IO_ERROR, &tty->flags);
wake_up_interruptible(&tty->read_wait);
wake_up_interruptible(&tty->write_wait);
tty->packet = 0;
@@ -249,8 +246,6 @@ static int pty_open(struct tty_struct *tty, struct file 
*filp)
if (!tty || !tty->link)
goto out;
 
-   set_bit(TTY_IO_ERROR, &tty->flags);
-
retval = -EIO;
if (test_bit(TTY_OTHER_CLOSED, &tty->flags))
goto out;
@@ -259,7 +254,6 @@ static int pty_open(struct tty_struct *tty, struct file 
*filp)
if (tty->driver->subtype == PTY_TYPE_SLAVE && tty->link->count != 1)
goto out;
 
-   clear_bit(TTY_IO_ERROR, &tty->flags);
clear_bit(TTY_OTHER_CLOSED, &tty->link->flags);
set_bit(TTY_THROTTLED, &tty->flags);
retval = 0;

-- 
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Strange intermittent EIO error when writing to stdout since v3.8.0

[Markus Trippelsdorf]

On 2013.06.11 at 22:14 +, Orion Poplawski wrote:
> Peter Hurley  hurleysoftware.com> writes:
> > Based on the other reports from Mikael and David, I suspect this problem
> > may have to do with my commit 699390354da6c258b65bf8fa79cfd5feaede50b6:
> > 
> >pty: Ignore slave pty close() if never successfully opened
> > 
> > This commit poisons the pty under certain error conditions that may
> > occur from parallel open()s (or parallel close() with pending write()).
> > 
> > It's unclear to me which error condition is triggered and how user-space
> > got an open file descriptor but that seems the most likely. Is the problem
> > reproducible enough that a debug patch would likely trigger?
> 
> I get this pretty frequently on my machine with rpmbuild -ba 2>&1 | tee. 
> I'd be happy to help to debug.

Since apparently no debugging patch is forthcoming, maybe it's time to
test the simple revert of commit 699390354da.

So can you guys please apply the following patch and see if the issue
goes away?

Thanks.

diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 59bfaec..f5801a6 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -38,12 +38,9 @@ static void pty_close(struct tty_struct *tty, struct file 
*filp)
if (tty->driver->subtype == PTY_TYPE_MASTER)
WARN_ON(tty->count > 1);
else {
-   if (test_bit(TTY_IO_ERROR, &tty->flags))
-   return;
if (tty->count > 2)
return;
}
-   set_bit(TTY_IO_ERROR, &tty->flags);
wake_up_interruptible(&tty->read_wait);
wake_up_interruptible(&tty->write_wait);
tty->packet = 0;
@@ -249,8 +246,6 @@ static int pty_open(struct tty_struct *tty, struct file 
*filp)
if (!tty || !tty->link)
goto out;
 
-   set_bit(TTY_IO_ERROR, &tty->flags);
-
retval = -EIO;
if (test_bit(TTY_OTHER_CLOSED, &tty->flags))
goto out;
@@ -259,7 +254,6 @@ static int pty_open(struct tty_struct *tty, struct file 
*filp)
if (tty->driver->subtype == PTY_TYPE_SLAVE && tty->link->count != 1)
goto out;
 
-   clear_bit(TTY_IO_ERROR, &tty->flags);
clear_bit(TTY_OTHER_CLOSED, &tty->link->flags);
set_bit(TTY_THROTTLED, &tty->flags);
retval = 0;

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

hwmon: add support for SMSC EMC2305/03/02/01 fan controller

[Reinhard Pfau]

Hi,

I would like to provide a driver for the SMSC EMC2305 fan controller which
we use in our devices in the hope that others might find it useful, too.
 

The driver also supports the SMSC EMC2303, EMC2302 and EMC2301 fan
controller chips which have same functionality and register layout, but
support less fans.

Testing is done only with EMC2305 fan controller (since this is the chip we
use; support for the other chips was included by using data sheets only) on
a PowerPC platform. Driver was tested as module and builtin.

The patch also adds me to the MAINTAINERS for this driver.

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