Re: [RFC 01/10] iommu: Add IOMMU device registry

[Thierry Reding]

On Thu, Jun 26, 2014 at 10:49:41PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Add an IOMMU device registry for drivers to register with and implement
> a method for users of the IOMMU API to attach to an IOMMU device. This
> allows to support deferred probing and gives the IOMMU API a convenient
> hook to perform early initialization of a device if necessary.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/iommu/iommu.c | 93 
> +++
>  include/linux/iommu.h | 27 +++
>  2 files changed, 120 insertions(+)

I thought that perhaps I should elaborate on this a bit since I have a
few ideas on how the API could be enhanced.

> +static int of_iommu_attach(struct device *dev)
> +{
> + struct of_phandle_iter iter;
> + struct iommu *iommu;
> +
> + mutex_lock(&iommus_lock);
> +
> + of_property_for_each_phandle_with_args(iter, dev->of_node, "iommus",
> +"#iommu-cells", 0) {
> + bool found = false;
> + int err;
> +
> + /* skip disabled IOMMUs */
> + if (!of_device_is_available(iter.out_args.np))
> + continue;
> +
> + list_for_each_entry(iommu, &iommus, list) {
> + if (iommu->dev->of_node == iter.out_args.np) {
> + err = iommu->ops->attach(iommu, dev);
> + if (err < 0) {
> + }
> +
> + found = true;
> + }
> + }
> +
> + if (!found) {
> + mutex_unlock(&iommus_lock);
> + return -EPROBE_DEFER;
> + }
> + }
> +
> + mutex_unlock(&iommus_lock);
> +
> + return 0;
> +}
> +
> +static int of_iommu_detach(struct device *dev)
> +{
> + /* TODO: implement */
> + return -ENOSYS;
> +}
> +
> +int iommu_attach(struct device *dev)
> +{
> + int err = 0;
> +
> + if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> + err = of_iommu_attach(dev);
> + if (!err)
> + return 0;
> + }
> +
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(iommu_attach);

I think it might make sense to introduce an explicit object for an IOMMU
master attachment. Maybe something like:

struct iommu_master {
struct iommu *iommu;
struct device *dev;

...
};

iommu_attach() could then return a pointer to that attachment and the
IOMMU user driver could subsequently use that as a handle to access
other parts of the API.

The reason is that if we ever need to support more than a single master
interface (and perhaps even multiple master interfaces on different
IOMMUs) for a single device, then we need a way for the IOMMU user to
differentiate between its master interfaces.

> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 284a4683fdc1..ac2ceef194d4 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -43,6 +43,17 @@ struct notifier_block;
>  typedef int (*iommu_fault_handler_t)(struct iommu_domain *,
>   struct device *, unsigned long, int, void *);
>  
> +struct iommu {
> + struct device *dev;
> +
> + struct list_head list;
> +
> + const struct iommu_ops *ops;
> +};

For reasons explained above, I also think that it would be a good idea
to modify the iommu_ops functions to take a struct iommu * as their
first argument. This may become important when one driver needs to
support multiple IOMMU devices. With the current API drivers have to
rely on global variables to track the driver-specific context. As far as
I can tell, only .domain_init(), .add_device(), .remove_device() and
.device_group(). .domain_init() could set up a pointer to struct iommu
in struct iommu_domain so the functions dealing with domains could gain
access to the IOMMU device via that pointer.

Thierry


pgp0cRaMF09mI.pgp
Description: PGP signature

[PATCH v2] iommu: Constify struct iommu_ops

[Thierry Reding]

From: Thierry Reding 

This structure is read-only data and should never be modified.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- add missing hunk from include/device.h

 drivers/iommu/amd_iommu.c   |  4 ++--
 drivers/iommu/arm-smmu.c|  2 +-
 drivers/iommu/exynos-iommu.c|  2 +-
 drivers/iommu/fsl_pamu_domain.c |  2 +-
 drivers/iommu/intel-iommu.c |  4 ++--
 drivers/iommu/iommu.c   | 19 ++-
 drivers/iommu/ipmmu-vmsa.c  |  2 +-
 drivers/iommu/msm_iommu.c   |  2 +-
 drivers/iommu/omap-iommu.c  |  2 +-
 drivers/iommu/shmobile-iommu.c  |  2 +-
 drivers/iommu/tegra-gart.c  |  2 +-
 drivers/iommu/tegra-smmu.c  |  2 +-
 include/linux/device.h  |  2 +-
 include/linux/iommu.h   |  4 ++--
 14 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 4aec6a29e316..7eb0e4246a79 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -81,7 +81,7 @@ LIST_HEAD(hpet_map);
  */
 static struct protection_domain *pt_domain;
 
-static struct iommu_ops amd_iommu_ops;
+static const struct iommu_ops amd_iommu_ops;
 
 static ATOMIC_NOTIFIER_HEAD(ppr_notifier);
 int amd_iommu_max_glx_val = -1;
@@ -3473,7 +3473,7 @@ static int amd_iommu_domain_has_cap(struct iommu_domain 
*domain,
return 0;
 }
 
-static struct iommu_ops amd_iommu_ops = {
+static const struct iommu_ops amd_iommu_ops = {
.domain_init = amd_iommu_domain_init,
.domain_destroy = amd_iommu_domain_destroy,
.attach_dev = amd_iommu_attach_device,
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 1599354e974d..67727294e6b5 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1609,7 +1609,7 @@ static void arm_smmu_remove_device(struct device *dev)
iommu_group_remove_device(dev);
 }
 
-static struct iommu_ops arm_smmu_ops = {
+static const struct iommu_ops arm_smmu_ops = {
.domain_init= arm_smmu_domain_init,
.domain_destroy = arm_smmu_domain_destroy,
.attach_dev = arm_smmu_attach_dev,
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 99054d2c040d..d037e87a1fe5 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1170,7 +1170,7 @@ static void exynos_iommu_remove_device(struct device *dev)
iommu_group_remove_device(dev);
 }
 
-static struct iommu_ops exynos_iommu_ops = {
+static const struct iommu_ops exynos_iommu_ops = {
.domain_init = exynos_iommu_domain_init,
.domain_destroy = exynos_iommu_domain_destroy,
.attach_dev = exynos_iommu_attach_device,
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 93072ba44b1d..5b47c5495873 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -1140,7 +1140,7 @@ static u32 fsl_pamu_get_windows(struct iommu_domain 
*domain)
return dma_domain->win_cnt;
 }
 
-static struct iommu_ops fsl_pamu_ops = {
+static const struct iommu_ops fsl_pamu_ops = {
.domain_init= fsl_pamu_domain_init,
.domain_destroy = fsl_pamu_domain_destroy,
.attach_dev = fsl_pamu_attach_device,
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 51b6b77dc3e5..9aab7963f424 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -451,7 +451,7 @@ EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
 static DEFINE_SPINLOCK(device_domain_lock);
 static LIST_HEAD(device_domain_list);
 
-static struct iommu_ops intel_iommu_ops;
+static const struct iommu_ops intel_iommu_ops;
 
 static int __init intel_iommu_setup(char *str)
 {
@@ -4465,7 +4465,7 @@ static void intel_iommu_remove_device(struct device *dev)
iommu_group_remove_device(dev);
 }
 
-static struct iommu_ops intel_iommu_ops = {
+static const struct iommu_ops intel_iommu_ops = {
.domain_init= intel_iommu_domain_init,
.domain_destroy = intel_iommu_domain_destroy,
.attach_dev = intel_iommu_attach_device,
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index efcfe703..806b55d056b7 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -35,6 +35,10 @@ static struct kset *iommu_group_kset;
 static struct ida iommu_group_ida;
 static struct mutex iommu_group_mutex;
 
+struct iommu_callback_data {
+   const struct iommu_ops *ops;
+};
+
 struct iommu_group {
struct kobject kobj;
struct kobject *devices_kobj;
@@ -516,7 +520,8 @@ EXPORT_SYMBOL_GPL(iommu_group_id);
 
 static int add_iommu_group(struct device *dev, void *data)
 {
-   struct iommu_ops *ops = data;
+   struct iommu_callback_data *cb = data;
+   const struct iommu_ops *ops = cb->ops;
 
if (!ops->add_device)
return -ENODEV;
@@ -532,7 +537,7 @@ static int iommu_bus_notifier(struct notifier_block *nb,
  unsigned long action, vo

[PATCH v2 1/3] cgroup: fix mount failure in a corner case

[Li Zefan]

  # cat test.sh
  #! /bin/bash

  mount -t cgroup -o cpu xxx /cgroup
  umount /cgroup

  mount -t cgroup -o cpu,cpuacct xxx /cgroup
  umount /cgroup
  # ./test.sh
  mount: xxx already mounted or /mnt busy
  mount: according to mtab, xxx is already mounted on /mnt

It's because the cgroupfs_root of the first mount was under destruction
asynchronously.

Fix this by delaying and then retrying mount for this case.

v2:
- use percpu_ref_tryget_live() rather that introducing
  percpu_ref_alive(). (Tejun)
- adjust comment.

Signed-off-by: Li Zefan 
---
 kernel/cgroup.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 1c65f24..ae2b382 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1648,10 +1648,12 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
 int flags, const char *unused_dev_name,
 void *data)
 {
+   struct cgroup_subsys *ss;
struct cgroup_root *root;
struct cgroup_sb_opts opts;
struct dentry *dentry;
int ret;
+   int i, j = -1;
bool new_sb;
 
/*
@@ -1677,6 +1679,23 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
goto out_unlock;
}
 
+   /*
+* Destruction of cgroup root is asynchronous, so we may fail to
+* mount a cgroupfs if it immediately follows a umount. Let's wait
+* a little bit and retry.
+*/
+   for_each_subsys(ss, i) {
+   if (!(opts.subsys_mask & (1 << i)))
+   continue;
+   if (!percpu_ref_tryget_live(&ss->root->cgrp.self.refcnt)) {
+   mutex_unlock(&cgroup_mutex);
+   msleep(10);
+   ret = restart_syscall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cgroup: fix a race between cgroup_mount() and cgroup_kill_sb()

[Li Zefan]

We've converted cgroup to kernfs so cgroup won't be intertwined with
vfs objects and locking, but there are dark areas.

Run two instances of this script concurrently:

for ((; ;))
{
mount -t cgroup -o cpuacct xxx /cgroup
umount /cgroup
}

After a while, I saw two mount processes were stuck at retrying, because
they were waiting for a subsystem to become free, but the root associated
with this subsystem never got freed.

This can happen, if thread A is in the process of killing superblock but
hasn't called percpu_ref_kill(), and at this time thread B is mounting
the same cgroup root and finds the root in the root list and performs
percpu_ref_try_get().

To fix this, we try to increase both the refcnt of the superblock and the
percpu refcnt of cgroup root.

v2:
- we should try to get both the superblock refcnt and cgroup_root refcnt,
  because cgroup_root may have no superblock assosiated with it.
- adjust/add comments.

Signed-off-by: Li Zefan 
---
 kernel/cgroup.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ae2b382..111b7c3 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1655,6 +1655,7 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
int ret;
int i, j = -1;
bool new_sb;
+   struct super_block *sb = NULL;
 
/*
 * The first time anyone tries to mount a cgroup, enable the list
@@ -1737,14 +1738,18 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
 
/*
 * A root's lifetime is governed by its root cgroup.
-* tryget_live failure indicate that the root is being
-* destroyed.  Wait for destruction to complete so that the
-* subsystems are free.  We can use wait_queue for the wait
-* but this path is super cold.  Let's just sleep for a bit
-* and retry.
+* pin_sb and tryget_live failure indicate that the root is
+* being destroyed.  Wait for destruction to complete so that
+* the subsystems are free.  We can use wait_queue for the
+* wait but this path is super cold.  Let's just sleep for
+* a bit and retry.
 */
-   if (!percpu_ref_tryget_live(&root->cgrp.self.refcnt)) {
+   sb = kernfs_pin_sb(root->kf_root, NULL);
+   if (IS_ERR(sb) ||
+   !percpu_ref_tryget_live(&root->cgrp.self.refcnt)) {
mutex_unlock(&cgroup_mutex);
+   if (!IS_ERR_OR_NULL(sb))
+   deactivate_super(sb);
msleep(10);
ret = restart_syscall();
goto out_free;
@@ -1796,6 +1801,17 @@ out_free:
dentry = kernfs_mount(fs_type, flags, root->kf_root, &new_sb);
if (IS_ERR(dentry) || !new_sb)
cgroup_put(&root->cgrp);
+
+   if (sb) {
+   /*
+* On success kernfs_mount() returns with sb->s_umount held,
+* but kernfs_mount() also increases the superblock's refcnt,
+* so calling deactivate_super() to drop the refcnt we got when
+* looking up cgroup root won't acquire sb->s_umount again.
+*/
+   WARN_ON(new_sb);
+   deactivate_super(sb);
+   }
return dentry;
 }
 
-- 
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/

[PATCH v2 2/3] kernfs: introduce kernfs_pin_sb()

[Li Zefan]

kernfs_pin_sb() tries to get a refcnt of the superblock.

This will be used by cgroupfs.

v2:
- make kernfs_pin_sb() return pointer to the superblock.
- drop kernfs_drop_sb().

Signed-off-by: Li Zefan 
---
 fs/kernfs/mount.c  | 27 +++
 include/linux/kernfs.h |  1 +
 2 files changed, 28 insertions(+)

diff --git a/fs/kernfs/mount.c b/fs/kernfs/mount.c
index f25a7c0..616c5c4 100644
--- a/fs/kernfs/mount.c
+++ b/fs/kernfs/mount.c
@@ -210,6 +210,33 @@ void kernfs_kill_sb(struct super_block *sb)
kernfs_put(root_kn);
 }
 
+/**
+ * kernfs_pin_sb: try to pin the superblock associated with a kernfs_root
+ * @kernfs_root: the kernfs_root in question
+ * @ns: the namespace tag
+ *
+ * Pin the superblock so the superblock won't be destroyed in subsequent
+ * operations. Return NULL if there's no superblock associated to this
+ * kernfs_root, or -EINVAL if the superblock is being freed.
+ */
+struct super_block *kernfs_pin_sb(struct kernfs_root *root, const void *ns)
+{
+   struct kernfs_super_info *info;
+   struct super_block *sb = NULL;
+
+   mutex_lock(&kernfs_mutex);
+   list_for_each_entry(info, &root->supers, node) {
+   if (info->ns == ns) {
+   sb = info->sb;
+   if (!atomic_inc_not_zero(&info->sb->s_active))
+   sb = ERR_PTR(-EINVAL);
+   break;
+   }
+   }
+   mutex_unlock(&kernfs_mutex);
+   return sb;
+}
+
 void __init kernfs_init(void)
 {
kernfs_node_cache = kmem_cache_create("kernfs_node_cache",
diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 589318b..9096296 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -287,6 +287,7 @@ struct dentry *kernfs_mount_ns(struct file_system_type 
*fs_type, int flags,
   struct kernfs_root *root, bool *new_sb_created,
   const void *ns);
 void kernfs_kill_sb(struct super_block *sb);
+struct super_block *kernfs_pin_sb(struct kernfs_root *root, const void *ns);
 
 void kernfs_init(void);
 
-- 
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 v2] USB: ehci-pci: USB host controller support for Intel Quark X1000

[Chen, Alvin]

> > > The EHCI packet buffer in/out threshold is programmable for Intel
> > > Quark X1000 USB host controller, and the default value is 0x20
> > > dwords. The in/out threshold can be programmed to 0x80 dwords, but
> > > only when isochronous/interrupt transactions are not initiated by
> > > the USB host controller. This patch is to reconfigure the packet
> > > buffer in/out threshold as maximal as possible, and it is 0x7F dwords 
> > > since
> the USB host controller initiates isochronous/interrupt transactions.
> >
> > So, what is the reason to set the value as 0x80?
> >   1. The default value 0x20 makes some problems such as...
> >   2. To maximize the performance, ...
> >   3. Both
> > Please add the reason why 0x80 is necessary, as possible.
> >
> > Then, 0x7F means 508 bytes? 'Intel Quark X1000 USB host controller'
> > can support 0x80 (512bytes), however, in this case,
> > isochronous/interrupt transactions cannot be initiated by 'Intel Quark X1000
> USB host controller'.
> > Right?
> >
> > So, 0x79 (508bytes?) should be used, because the isochronous/interrupt
> > transactions can be initiated by 'Intel Quark X1000 USB host controller'.
> > Right?
> >
Yes, to maximize the performance, we set the threshold as maximal as possible. 
Intel Quark X1000 can support 0x80 dwords (512Bytes), but 0x7F dwords (508 
Bytes) should be used since the isochronous/interrupt
transactions can be initiated by Intel Quark X1000 USB host controller. I will 
update the descriptions.

> > > /*--
> > > ---*/
> > > +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC  0x0939
> > > +static inline bool usb_is_intel_quark_x1000(struct pci_dev *pdev) {
> > > + return pdev->vendor == PCI_VENDOR_ID_INTEL &&
> > > + pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
> > > +
> >
> > Please don't add this unnecessary line.
OK, I will remove it.

> >
> > > +}
> > > +
> > > +/* Register offset of in/out threshold */
> > > +#define EHCI_INSNREG01   0x84
> > > +/* The maximal threshold is 0x80 Dword */
> > > +#define EHCI_MAX_THRESHOLD  0X80
> >
> > s/0X80/0x80
> >
> > 0x80 means 512 bytes. So, how about mentioning '0x80 means 512 bytes'
> > in this comment or the commit message?
> >
> > Maybe, how about the following?
> >
> > /* The maximal threshold value is 0x80, which means 512 bytes */
> > #define EHCI_THRESHOLD_512BYTES 0x80
> >
> > > +/* Lower word is 'in' threshold, and higher word is 'out'
> > > +threshold*/ #define EHCI_INSNREG01_THRESH \
> > > + ((EHCI_MAX_THRESHOLD - 1)<<16 | (EHCI_MAX_THRESHOLD - 1))
> >
> > Um, how about the following?
> >
> > /* Register offset of in/out threshold */
> > #define EHCI_INSNREG01  0x84
> > /* The maximal threshold value is 0x80, which means 512 bytes */
> > #define EHCI_THRESHOLD_512BYTES 0x80
> > #define EHCI_THRESHOLD_508BYTES 0x79
> > #define EHCI_THRESHOLD_OUT_SHIFT16
> > #define EHCI_THRESHOLD_IN_SHIFT 0
> >
> > ..
> >
> > /*
> >  * In order to support the isochronous/interrupt transactions,
> >  * 508 bytes should be used as max threshold values */
> >  */
> > val =   ((EHCI_THRESHOLD_512BYTES - 1) <<
> EHCI_THRESHOLD_OUT_SHIFT |
> > (EHCI_THRESHOLD_512BYTES - 1) << EHCI_THRESHOLD_IN_SHIFT);
> > writel(val, op_reg_base + EHCI_INSNREG01);
> 
> Sorry, please refer to the following.
> 
> /* Register offset of in/out threshold */
> #define EHCI_INSNREG010x84
> /* The maximal threshold value is 0x80, which means 512 bytes */
> #define EHCI_THRESHOLD_512BYTES   0x80
> #define EHCI_THRESHOLD_508BYTES   0x79
> #define EHCI_THRESHOLD_OUT_SHIFT  16
> #define EHCI_THRESHOLD_IN_SHIFT   0
> 
>   ..
> 
>   /*
>* In order to support the isochronous/interrupt transactions,
>* 508 bytes should be used as max threshold values */
>*/
>   val =   (EHCI_THRESHOLD_508BYTES <<
> EHCI_THRESHOLD_OUT_SHIFT |
>   (EHCI_THRESHOLD_508BYTES << EHCI_THRESHOLD_IN_SHIFT);
>   writel(val, op_reg_base + EHCI_INSNREG01);
> 
I will improve the according to your suggestions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] block: fix uint overflow when merging io requests

[Junxiao Bi]

This uint overflow will cause req->__data_len < req->bio->bi_size,
this will confuse block layer and device driver.

I watched a panic caused by this when mkfs.ext4 a volume of a large
virtual disk on vm guest, blkdev_issue_discard() issue two bio with
a total size over UINT_MAX, but the check in ll_back_merge_fn() didn't
take affect due to the overflow and they were merged into one request.
After the request is done, in blk_end_request_all(), BUG_ON(pending)
was triggered and kernel panic. "pending" is true is because
blk_update_request() return ture when req->__data_len is less
than req->bio->bi_size.

Signed-off-by: Junxiao Bi 
---
 block/blk-merge.c |   40 ++--
 1 file changed, 34 insertions(+), 6 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index b3bf0df..340c0a7 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -325,11 +325,41 @@ no_merge:
return 0;
 }
 
-int ll_back_merge_fn(struct request_queue *q, struct request *req,
+static inline bool ll_allow_merge_bio(struct request *req,
 struct bio *bio)
 {
if (blk_rq_sectors(req) + bio_sectors(bio) >
-   blk_rq_get_max_sectors(req)) {
+   blk_rq_get_max_sectors(req))
+   return false;
+
+   /* check uint overflow */
+   if (blk_rq_sectors(req) + bio_sectors(bio) < blk_rq_sectors(req)
+   || blk_rq_sectors(req) + bio_sectors(bio) < bio_sectors(bio))
+   return false;
+
+   return true;
+}
+
+static inline bool ll_allow_merge_req(struct request *req,
+struct request *next)
+{
+   if (blk_rq_sectors(req) + blk_rq_sectors(next) >
+   blk_rq_get_max_sectors(req))
+   return false;
+
+   /* check uint overflow */
+   if (blk_rq_sectors(req) + blk_rq_sectors(next) < blk_rq_sectors(req)
+   || blk_rq_sectors(req) + blk_rq_sectors(next) <
+   blk_rq_sectors(next))
+   return false;
+
+   return true;
+}
+
+int ll_back_merge_fn(struct request_queue *q, struct request *req,
+struct bio *bio)
+{
+   if (!ll_allow_merge_bio(req, bio)) {
req->cmd_flags |= REQ_NOMERGE;
if (req == q->last_merge)
q->last_merge = NULL;
@@ -346,8 +376,7 @@ int ll_back_merge_fn(struct request_queue *q, struct 
request *req,
 int ll_front_merge_fn(struct request_queue *q, struct request *req,
  struct bio *bio)
 {
-   if (blk_rq_sectors(req) + bio_sectors(bio) >
-   blk_rq_get_max_sectors(req)) {
+   if (!ll_allow_merge_bio(req, bio)) {
req->cmd_flags |= REQ_NOMERGE;
if (req == q->last_merge)
q->last_merge = NULL;
@@ -389,8 +418,7 @@ static int ll_merge_requests_fn(struct request_queue *q, 
struct request *req,
/*
 * Will it become too large?
 */
-   if ((blk_rq_sectors(req) + blk_rq_sectors(next)) >
-   blk_rq_get_max_sectors(req))
+   if (!ll_allow_merge_req(req, next))
return 0;
 
total_phys_segments = req->nr_phys_segments + next->nr_phys_segments;
-- 
1.7.9.5

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

Re: [PATCH V7 1/6] power: reset: Add generic SYSCON register mapped reset

[Arnd Bergmann]

On Thursday 26 June 2014 09:51:14 Feng Kan wrote:
> >> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> >> index bdcf517..7035236 100644
> >> --- a/drivers/power/reset/Kconfig
> >> +++ b/drivers/power/reset/Kconfig
> >> @@ -80,3 +80,9 @@ config POWER_RESET_KEYSTONE
> >> help
> >>   Reboot support for the KEYSTONE SoCs.
> >>
> >> +config POWER_RESET_SYSCON
> >> +   bool "Generic SYSCON regmap reset driver"
> >> +   depends on ARCH_XGENE
> >
> > If this is supposed to be generic, why are you depending on
> > a certain platform?
> 
> Yes, the problem was that it was breaking the x86 build.

You probably need to list the exact dependencies then, at least make
it depend on MFD_SYSCON and OF. We generally want all drivers to
build without warnings on all architectures. You can limit it to
(ARM || ARM64 || COMPILE_TEST) if you don't want it to show up on
x86 by default, but it should still be possible to build it when
COMPILE_TEST is set.

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

Re: [PATCH RESEND] clk: flatten clk tree in debugfs

[Peter De Schrijver]

On Thu, Jun 26, 2014 at 11:36:45PM +0200, Mike Turquette wrote:
> Quoting Peter De Schrijver (2014-06-26 09:39:06)
> > On Fri, Jun 13, 2014 at 10:02:39AM +0200, Peter De Schrijver wrote:
> > > On Fri, May 30, 2014 at 05:03:57PM +0200, Peter De Schrijver wrote:
> > > > This patch flattens the clk tree in CCF debugfs. Instead of 
> > > > representing the
> > > > clocks and their hierarchy as a directory structure under
> > > > /sys/kernel/debug/clk, each clock gets a single directory directly under
> > > > /sys/kernel/debug/clk. The orphans directory is replaced by a file 
> > > > called
> > > > clk_orphan_summary.
> > > 
> > > Mike,
> > > 
> > > Any problems with this? What needs to be done to make this patch go 
> > > forward?
> 
> Applied to clk-next.
> 

Thanks!

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

Re: [PATCH RESEND] clk: flatten clk tree in debugfs

[Peter De Schrijver]

On Thu, Jun 26, 2014 at 11:36:45PM +0200, Mike Turquette wrote:
> Quoting Peter De Schrijver (2014-06-26 09:39:06)
> > On Fri, Jun 13, 2014 at 10:02:39AM +0200, Peter De Schrijver wrote:
> > > On Fri, May 30, 2014 at 05:03:57PM +0200, Peter De Schrijver wrote:
> > > > This patch flattens the clk tree in CCF debugfs. Instead of 
> > > > representing the
> > > > clocks and their hierarchy as a directory structure under
> > > > /sys/kernel/debug/clk, each clock gets a single directory directly under
> > > > /sys/kernel/debug/clk. The orphans directory is replaced by a file 
> > > > called
> > > > clk_orphan_summary.
> > > 
> > > Mike,
> > > 
> > > Any problems with this? What needs to be done to make this patch go 
> > > forward?
> 
> Applied to clk-next.
> 

Thanks!

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

Re: [RFC][PATCH 1/5 v2] tracing: Add trace_seq_buffer_ptr() helper function

[Paolo Bonzini]

Il 27/06/2014 03:06, Steven Rostedt ha scritto:


As this patch is in my 3.17 queue and it touches the kvm and scsi
tracepoint code, I figured I should at least do the courtesy of
notifying the maintainers of those subsystems.

Do you have any issues with this going through my tree? If not, please
give me an Acked-by.


No problem absolutely.

Acked-by: Paolo Bonzini 

Paolo


Thanks!

-- Steve

On Thu, 26 Jun 2014 17:49:02 -0400
Steven Rostedt  wrote:


From: "Steven Rostedt (Red Hat)" 

There's several locations in the kernel that open code the calculation
of the next location in the trace_seq buffer. This is usually done with

  p->buffer + p->len

Instead of having this open coded, supply a helper function in the
header to do it for them. This function is called trace_seq_buffer_ptr().

Signed-off-by: Steven Rostedt 
---
 arch/x86/kvm/mmutrace.h |  2 +-
 drivers/scsi/scsi_trace.c   | 16 
 include/linux/trace_seq.h   | 15 +++
 kernel/trace/trace_output.c | 14 +++---
 4 files changed, 31 insertions(+), 16 deletions(-)

diff --git a/arch/x86/kvm/mmutrace.h b/arch/x86/kvm/mmutrace.h
index 9d2e0ffcb190..2e5652b62fd6 100644
--- a/arch/x86/kvm/mmutrace.h
+++ b/arch/x86/kvm/mmutrace.h
@@ -22,7 +22,7 @@
__entry->unsync = sp->unsync;

 #define KVM_MMU_PAGE_PRINTK() ({   \
-   const char *ret = p->buffer + p->len; \
+   const char *ret = trace_seq_buffer_ptr(p);  \
static const char *access_str[] = { \
"---", "--x", "w--", "w-x", "-u-", "-ux", "wu-", "wux"  \
};  \
diff --git a/drivers/scsi/scsi_trace.c b/drivers/scsi/scsi_trace.c
index 2bea4f0b684a..503594e5f76d 100644
--- a/drivers/scsi/scsi_trace.c
+++ b/drivers/scsi/scsi_trace.c
@@ -28,7 +28,7 @@ scsi_trace_misc(struct trace_seq *, unsigned char *, int);
 static const char *
 scsi_trace_rw6(struct trace_seq *p, unsigned char *cdb, int len)
 {
-   const char *ret = p->buffer + p->len;
+   const char *ret = trace_seq_buffer_ptr(p);
sector_t lba = 0, txlen = 0;

lba |= ((cdb[1] & 0x1F) << 16);
@@ -46,7 +46,7 @@ scsi_trace_rw6(struct trace_seq *p, unsigned char *cdb, int 
len)
 static const char *
 scsi_trace_rw10(struct trace_seq *p, unsigned char *cdb, int len)
 {
-   const char *ret = p->buffer + p->len;
+   const char *ret = trace_seq_buffer_ptr(p);
sector_t lba = 0, txlen = 0;

lba |= (cdb[2] << 24);
@@ -71,7 +71,7 @@ scsi_trace_rw10(struct trace_seq *p, unsigned char *cdb, int 
len)
 static const char *
 scsi_trace_rw12(struct trace_seq *p, unsigned char *cdb, int len)
 {
-   const char *ret = p->buffer + p->len;
+   const char *ret = trace_seq_buffer_ptr(p);
sector_t lba = 0, txlen = 0;

lba |= (cdb[2] << 24);
@@ -94,7 +94,7 @@ scsi_trace_rw12(struct trace_seq *p, unsigned char *cdb, int 
len)
 static const char *
 scsi_trace_rw16(struct trace_seq *p, unsigned char *cdb, int len)
 {
-   const char *ret = p->buffer + p->len;
+   const char *ret = trace_seq_buffer_ptr(p);
sector_t lba = 0, txlen = 0;

lba |= ((u64)cdb[2] << 56);
@@ -125,7 +125,7 @@ scsi_trace_rw16(struct trace_seq *p, unsigned char *cdb, 
int len)
 static const char *
 scsi_trace_rw32(struct trace_seq *p, unsigned char *cdb, int len)
 {
-   const char *ret = p->buffer + p->len, *cmd;
+   const char *ret = trace_seq_buffer_ptr(p), *cmd;
sector_t lba = 0, txlen = 0;
u32 ei_lbrt = 0;

@@ -180,7 +180,7 @@ out:
 static const char *
 scsi_trace_unmap(struct trace_seq *p, unsigned char *cdb, int len)
 {
-   const char *ret = p->buffer + p->len;
+   const char *ret = trace_seq_buffer_ptr(p);
unsigned int regions = cdb[7] << 8 | cdb[8];

trace_seq_printf(p, "regions=%u", (regions - 8) / 16);
@@ -192,7 +192,7 @@ scsi_trace_unmap(struct trace_seq *p, unsigned char *cdb, 
int len)
 static const char *
 scsi_trace_service_action_in(struct trace_seq *p, unsigned char *cdb, int len)
 {
-   const char *ret = p->buffer + p->len, *cmd;
+   const char *ret = trace_seq_buffer_ptr(p), *cmd;
sector_t lba = 0;
u32 alloc_len = 0;

@@ -247,7 +247,7 @@ scsi_trace_varlen(struct trace_seq *p, unsigned char *cdb, 
int len)
 static const char *
 scsi_trace_misc(struct trace_seq *p, unsigned char *cdb, int len)
 {
-   const char *ret = p->buffer + p->len;
+   const char *ret = trace_seq_buffer_ptr(p);

trace_seq_printf(p, "-");
trace_seq_putc(p, 0);
diff --git a/include/linux/trace_seq.h b/include/linux/trace_seq.h
index dd85753e1bb0..ea6c9dea79e3 100644
--- a/include/linux/trace_seq.h
+++ b/include/linux/trace_seq.h
@@ -25,6 +25,21 @@ trace_seq_init(struct trace_seq *s)
s->full = 0;
 }

+/**
+ * trace_seq_buffer_ptr - return pointer to next location in buffer
+ * @s: t

Re: [RFC 04/10] memory: Add Tegra124 memory controller support

[Joseph Lo]

Hi Thierry,

On 06/27/2014 04:49 AM, Thierry Reding wrote:
[snip]

+
+#define MC_INTSTATUS 0x000
+#define  MC_INT_DECERR_MTS (1 << 16)
+#define  MC_INT_SECERR_SEC (1 << 13)
+#define  MC_INT_DECERR_VPR (1 << 12)
+#define  MC_INT_INVALID_APB_ASID_UPDATE (1 << 11)
+#define  MC_INT_INVALID_SMMU_PAGE (1 << 10)
+#define  MC_INT_ARBITRATION_EMEM (1 << 9)
+#define  MC_INT_SECURITY_VIOLATION (1 << 8)
+#define  MC_INT_DECERR_EMEM (1 << 6)
+#define MC_INTMASK 0x004
+#define MC_ERR_STATUS 0x08
+#define MC_ERR_ADR 0x0c
+

[snip]

+
+#define SMMU_PDE_ATTR  (SMMU_PDE_READABLE | SMMU_PDE_WRITABLE | \
+SMMU_PDE_NONSECURE)
+#define SMMU_PTE_ATTR  (SMMU_PTE_READABLE | SMMU_PTE_WRITABLE | \
+SMMU_PTE_NONSECURE)
+
+#define SMMU_PDE_VACANT(n) (((n) << 10) | SMMU_PDE_ATTR)
+#define SMMU_PTE_VACANT(n) (((n) << 12) | SMMU_PTE_ATTR)


There is an ISR to catch the invalid SMMU translation. Do you want to 
modify the identity mapping with read/write attribute of the unused SMMU 
pages?


This can make sure we capture the invalid SMMU translation. And helps 
for driver to capture issues when using SMMU.


-joseph


+static irqreturn_t tegra124_mc_irq(int irq, void *data)
+{
+   struct tegra_mc *mc = data;
+   u32 value, status, mask;
+
+   /* mask all interrupts to avoid flooding */
+   mask = mc_readl(mc, MC_INTMASK);
+   mc_writel(mc, 0, MC_INTMASK);
+
+   status = mc_readl(mc, MC_INTSTATUS);
+   mc_writel(mc, status, MC_INTSTATUS);
+
+   dev_dbg(mc->dev, "INTSTATUS: %08x\n", status);
+
+   if (status & MC_INT_DECERR_MTS)
+   dev_dbg(mc->dev, "  DECERR_MTS\n");
+
+   if (status & MC_INT_SECERR_SEC)
+   dev_dbg(mc->dev, "  SECERR_SEC\n");
+
+   if (status & MC_INT_DECERR_VPR)
+   dev_dbg(mc->dev, "  DECERR_VPR\n");
+
+   if (status & MC_INT_INVALID_APB_ASID_UPDATE)
+   dev_dbg(mc->dev, "  INVALID_APB_ASID_UPDATE\n");
+
+   if (status & MC_INT_INVALID_SMMU_PAGE)
+   dev_dbg(mc->dev, "  INVALID_SMMU_PAGE\n");
+
+   if (status & MC_INT_ARBITRATION_EMEM)
+   dev_dbg(mc->dev, "  ARBITRATION_EMEM\n");
+
+   if (status & MC_INT_SECURITY_VIOLATION)
+   dev_dbg(mc->dev, "  SECURITY_VIOLATION\n");
+
+   if (status & MC_INT_DECERR_EMEM)
+   dev_dbg(mc->dev, "  DECERR_EMEM\n");
+
+   value = mc_readl(mc, MC_ERR_STATUS);
+
+   dev_dbg(mc->dev, "ERR_STATUS: %08x\n", value);
+   dev_dbg(mc->dev, "  type: %x\n", (value >> 28) & 0x7);
+   dev_dbg(mc->dev, "  protection: %x\n", (value >> 25) & 0x7);
+   dev_dbg(mc->dev, "  adr_hi: %x\n", (value >> 20) & 0x3);
+   dev_dbg(mc->dev, "  swap: %x\n", (value >> 18) & 0x1);
+   dev_dbg(mc->dev, "  security: %x\n", (value >> 17) & 0x1);
+   dev_dbg(mc->dev, "  r/w: %x\n", (value >> 16) & 0x1);
+   dev_dbg(mc->dev, "  adr1: %x\n", (value >> 12) & 0x7);
+   dev_dbg(mc->dev, "  client: %x\n", value & 0x7f);
+
+   value = mc_readl(mc, MC_ERR_ADR);
+   dev_dbg(mc->dev, "ERR_ADR: %08x\n", value);
+
+   mc_writel(mc, mask, MC_INTMASK);
+
+   return IRQ_HANDLED;
+}
+

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

Re: [PATCH v2 1/6] ARM: mm: cache-l2x0: Add base address argument to write_sec callback

[Linus Walleij]

On Wed, Jun 25, 2014 at 3:37 PM, Tomasz Figa  wrote:

> For certain platforms (e.g. Exynos) it is necessary to read back some
> values from registers before they can be written (i.e. SMC calls that
> set multiple registers per call), so base address of L2C controller is
> needed for .write_sec operation. This patch adds base argument to
> .write_sec callback so that its implementation can also access registers
> directly.
>
> Signed-off-by: Tomasz Figa 

>  arch/arm/mach-ux500/cache-l2x0.c   | 3 ++-

In our case just changing the signature of the function I see so:
Acked-by: Linus Walleij 

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/

[RFC] squashfs: A possible memory leak in squashfs

[Gioh Kim]

Hello,

I have been trying to apply CMA feature to my platform, based on ver. 3.10.
And I am suffering failures of allocation in CMA area.
I made a patch like below (I copied it after kernel log) and found that a 
buffer-head is not released.
As you know the CMA try to migrate movable pages. If any buffer-head related to 
a page is not released CMA cannot migrate the page.

I am writing about my problem. Please reply me if you need any information.

Howto generate problem:
1. The chrome is stored in squashfs partition. The size of CMA area is 256MB.
2. start chrome
3. connect any site
4. About 100MB of CMA area is used. The remain of CMA area is free.
5. Try to allocate all memory (256MB) of CMA with dma_alloc_coherent.
6. Some buffer-heads are busy so that allocation is failed.
7. The busy buffer-head was released by squash_read_data and b_count of the 
buffer-head became 1.
8. The b_count of the busy buffer-head will never become 0. Even-if I turn off 
platform, it is not released.
9. Is it possible that a buffer-head is not released forever? And why?

Followings are kernel log messages.
At first buffer-head which is located at 0x9499a500 is released by 
squashfs_read_data.
I think the buffer-head contains a data of squashfs partition.
The referenct count of buffer-head become 1 becauseof the release.
I think the buffer-head must be released again but it is not.
Even-if I turn off the platform I cannot see the message that 0x9499a500 is 
released.


[  243.909446] BUFFER_INFO: (put_bh) bh 9499a500 count 2 page 0x28e5d   
> log from free_buffer_head
[  243.909455] CPU: 1 PID:  Comm: chrome Tainted: P   O 3.10.19-32 
#67
[  243.909486] [<80013ef0>] (unwind_backtrace+0x0/0xf8) from [<80011d00>] 
(show_stack+0x10/0x14)
[  243.909510] [<80011d00>] (show_stack+0x10/0x14) from [<801c994c>] 
(lzo_uncompress+0x110/0x270)
[  243.909524] [<801c994c>] (lzo_uncompress+0x110/0x270) from [<801c618c>] 
(squashfs_read_data+0x254/0x714)
[  243.909535] [<801c618c>] (squashfs_read_data+0x254/0x714) from [<801c680c>] 
(squashfs_cache_get+0x1c0/0x3c8)
[  243.909545] [<801c680c>] (squashfs_cache_get+0x1c0/0x3c8) from [<801c7df8>] 
(squashfs_readpage+0x794/0x8a8)
[  243.909566] [<801c7df8>] (squashfs_readpage+0x794/0x8a8) from [<800b8914>] 
(__do_page_cache_readahead+0x254/0x264)
[  243.909579] [<800b8914>] (__do_page_cache_readahead+0x254/0x264) from 
[<800b8c04>] (ra_submit+0x28/0x30)
[  243.909589] [<800b8c04>] (ra_submit+0x28/0x30) from [<800afea8>] 
(filemap_fault+0x368/0x460)
[  243.909604] [<800afea8>] (filemap_fault+0x368/0x460) from [<800cd864>] 
(__do_fault+0x6c/0x4dc)
[  243.909615] [<800cd864>] (__do_fault+0x6c/0x4dc) from [<800d0a1c>] 
(handle_pte_fault+0xb4/0x77c)
[  243.909625] [<800d0a1c>] (handle_pte_fault+0xb4/0x77c) from [<800d1190>] 
(handle_mm_fault+0xac/0xe8)
[  243.909637] [<800d1190>] (handle_mm_fault+0xac/0xe8) from [<8001889c>] 
(do_page_fault+0x20c/0x360)
[  243.909648] [<8001889c>] (do_page_fault+0x20c/0x360) from [<80008560>] 
(do_PrefetchAbort+0x34/0x9c)
[  243.909661] [<80008560>] (do_PrefetchAbort+0x34/0x9c) from [<8000e314>] 
(ret_from_exception+0x0/0x10)
[  243.909665] Exception stack(0xb1d7dfb0 to 0xb1d7dff8)
[  243.909671] dfa0: 6ca7b1e8  
6c393234 7ef8a8f0
[  243.909678] dfc0: 0001 c2a4 cf54 6c393220 6c393238 0003 
 0001
[  243.909683] dfe0:  7ef8a688 752711a4 74bd1fe0 28000110 
[  243.909737] busy bh=9499a500, 10029 count=1
[  243.909739] debug=9499a500
[  243.909741] debug=9499a4c0
[  243.909742] debug=9499a480
[  243.909750] sb-type=squashfs sb-root=/ disk=mmcblk0 first_minor=0 minors=64 
partno=0 blocksize=1024
[  243.909777] busy bh=9499a500, 10029 count=1  
  > 9499a500 buffer-head is not release forever
[  243.909778] debug=9499a500
[  243.909780] debug=9499a4c0
[  243.909781] debug=9499a480
[  243.909787] sb-type=squashfs sb-root=/ disk=mmcblk0 first_minor=0 minors=64 
partno=0 blocksize=1024
[  243.909809] busy bh=9499a500, 10029 count=1
[  243.909810] debug=9499a500
[  243.909812] debug=9499a4c0
[  243.909813] debug=9499a480
[  243.909818] sb-type=squashfs sb-root=/ disk=mmcblk0 first_minor=0 minors=64 
partno=0 blocksize=1024
[  243.909840] busy bh=9499a500, 10029 count=1
[  243.909841] debug=9499a500
[  243.909843] debug=9499a4c0
[  243.909844] debug=9499a480
[  243.909850] sb-type=squashfs sb-root=/ disk=mmcblk0 first_minor=0 minors=64 
partno=0 blocksize=1024
[  243.909872] busy bh=9499a500, 10029 count=1
[  243.909874] debug=9499a500
[  243.909875] debug=9499a4c0
[  243.909876] debug=9499a480
[  243.909882] sb-type=squashfs sb-root=/ disk=mmcblk0 first_minor=0 minors=64 
partno=0 blocksize=1024
[  243.909903] busy bh=9499a500, 10029 count=1
[  243.909904] debug=9499a500
[  243.909906] debug=9499a4c0
[  243.909907] debug=9499a480
[  243.909912] sb-type=squashfs sb-root=/ disk=mmcblk0 first_minor=0 minors=64 
part

Re: [PATCH] ring-buffer: Race when writing and swapping cpu buffer in parallel

[Petr Mládek]

On Thu 2014-06-26 20:55:00, Steven Rostedt wrote:
> On Thu, 26 Jun 2014 09:58:31 -0400
> Steven Rostedt  wrote:
> 
> > What we can do is force ring_buffer_swap_cpu() to only work for the CPU
> > that it is on. As we have snapshot in per_cpu buffers, to make that
> > work, we will need to change the per_cpu version of snapshot to do a
> > smp_call_function_single() to the CPU that it wants to take a snapshot
> > of, and run the swap there.
> > 
> > To force this, we can remove the cpu parameter from the
> > ring_buffer_swap_cpu(). By doing this, we may be able to remove some of
> > the CONFIG_RING_BUFFER_ALLOW_SWAP hacks too!
> > 
> > I'm not going to sacrifice the general performance of the ring buffer
> > for a feature that is seldom (if ever) used.

Fair enough. I see the point.

> Did you want to do the above, or do you want me to write something up?

I could look at it the following week.

When I think about it, the race is not that critical. In the worst
case, it slightly modifies the swapped buffer but there should not
be danger of any data corruption. Anyway, I will try to get rid of
it the way you suggested. It might be more important when the
ringbuffer has more users.

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

Re: [PATCH v5 03/14] clk: max77686: Add DT include for MAX77686 PMIC clock

[Andreas Färber]

Am 26.06.2014 20:15, schrieb Javier Martinez Canillas:
> This patch adds a dt-binding include for Maxim 77686
> PMIC clock IDs that can be to be shared between the

"can be shared"?

Regards,
Andreas

> clk-max77686 clock driver and DeviceTree source files.
> 
> Signed-off-by: Javier Martinez Canillas 
> Reviewed-by: Krzysztof Kozlowski 
> ---
> 
> Changes since v4: None
> 
> Changes since v3: None

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] Documentation: Document Hisilicon hix5hd2 sata PHY

[Arnd Bergmann]

On Friday 27 June 2014 11:37:18 zhangfei wrote:
> >
> 
> Sorry for the confusion.
> 
> The phy is rather an analog controller, without standard register.
> Instead, the phy interface is just some pin / analog interface.
> The register is in fact hix5hd2 register, controls all the analog 
> output, including reset, power, speed, para tunning.

Ok, thanks for the explanation.

> Even the same phy is used in other soc, they can not share this driver, 
> since the connection must be different, as well as internal soc register 
> layout.
> Only if the same controller & phy are reused in other hisilicon soc, 
> this driver can be shared.
> 
> Since what we control is hix5hd2 controller itself, so it may not 
> suitable to put snps here.

Makes sense.

> And about hix5hd2 name: x is not wildcard.
> 
> Currently hix5hd2 is series of hi3716c v200, hi3719c v100, hi3718c v100.
> They are same soc, except minus pin assembles different.
> 
> However, not all hi37x is in this series, for example hi3716c v100 is a 
> different soc.
> 
> In the future hi3719m, hi3718m may also plan to add to hix5hd2 series.
> The difference will be different cpu core number, different gpu core 
> number. Also use different ethernet controller.

Ah, I think you explained this before, sorry for misremembering it.
 
> So we may still keep "hisilicon,hix5hd2-sata-phy" unchanged.
> What do you think?

Yes, please keep this string, it's good.

Thanks for your patience,

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/14] clk: max77802: Add DT binding documentation

[Andreas Färber]

Am 26.06.2014 20:15, schrieb Javier Martinez Canillas:
> Add Device Tree binding documentation for the clocks
> outputs in the Maxim 77802 Power Management IC.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
> Changes since v4: None
> 
> Changes since v3:
>  - Don't use the same clock driver name in clock-names since it's a consumer
>concept and most probably will be different. Suggested by Doug Anderson.
> 
> Changes since v2:
>  - Split the DT binding documentation in a separate patch.
> 
>  .../devicetree/bindings/clock/maxim,max77802.txt   | 42 
> ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/maxim,max77802.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/maxim,max77802.txt 
> b/Documentation/devicetree/bindings/clock/maxim,max77802.txt
> new file mode 100644
> index 000..26bc4f7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/maxim,max77802.txt
> @@ -0,0 +1,42 @@
> +Binding for Maxim MAX77802 32k clock generator block
> +
> +This is a part of device tree bindings of MAX77802 multi-function device.
> +More information can be found in bindings/mfd/max77802.txt file.
> +
> +The MAX77802 contains two 32.768khz clock outputs that can be controlled
> +(gated/ungated) over I2C.
> +
> +Following properties should be presend in main device node of the MFD chip.

"present"

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] ARM: at91/dt: describe rgmii ethernet phy connected to sama5d3xek boards

[Nicolas Ferre]

On 26/06/2014 22:01, Boris BREZILLON :
> Hi Florian,
> 
> On 26/06/2014 20:15, Florian Fainelli wrote:
>> Hi Boris,
>>
>> 2014-06-26 3:13 GMT-07:00 Boris BREZILLON 
>> :
>>> Add ethernet-phy node and specify phy interrupt (connected to pin PB25).
>>>
>>> The PHY address is not specified here because atmel have 2 different
>>> designs
>>> for its CPU modules: one is connecting PHYAD[0-2] pins to pull up resistors
>>> (Embest design) and the other one is connection PHYAD0 to a pull up
>>> resistor and PHYAD[1-2] to pull down resistors (Ronetix design).
>>> As a result, Ronetix design will have its PHY available at address 0x1 and
>>> Embest design at 0x7.
>>> Let the net PHY core automatically detect the PHY address by scanning the
>>> MDIO bus.
>> I though the compatible string was listed as a required property, but
>> it is not. The 'reg' property however is listed as required, although
>> the of_miodbus_register() works just fine without it, although that is
>> a Linux-specific implementation detail.
> 
> Indeed, it's listed in the required property list of the DT binding doc,
> but the code implement auto detection if reg is missing.
> However this line [1] clearly shows that specifying the reg property is
> the preferred way of doing things.
> 
> I could define 2 different sama5d3xcm.dtsi (sama5d3xcm-ronetix.dtsi and
> sama5d3xcm-embest.dtsi) to avoid this dirty hack,
> but then we would have 2 more dtb and the user would have to determine
> which CPU module he owns to choose the appropriate dtb.
> If at91, arm-soc and DT maintainers agree with this approach I can
> definitely propose something.

Yes Boris, I definitively prefer not to add another .dtsi file for this
series if we can avoid it.

So, I would push for this "reg-less" solution. If it is chosen, you can
add my:
Acked-by: Nicolas Ferre 

Thanks, bye.


>>> Define board specific delays to apply to RGMII signals.
>>>
>>> Signed-off-by: Boris BREZILLON 
>> Reviewed-by: Florian Fainelli 
> 
> Thanks for your review.
> 
> Best Regards,
> 
> Boris
> 
> [1] http://lxr.free-electrons.com/source/drivers/of/of_mdio.c#L187
> 


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

Re: [PATCH v5 03/14] clk: max77686: Add DT include for MAX77686 PMIC clock

[Javier Martinez Canillas]

Hello Andreas,

On 06/27/2014 09:48 AM, Andreas Färber wrote:
> Am 26.06.2014 20:15, schrieb Javier Martinez Canillas:
>> This patch adds a dt-binding include for Maxim 77686
>> PMIC clock IDs that can be to be shared between the
> 
> "can be shared"?
> 

As it should be quite clear right now I'm not a native English speaker. I meant
that the header file can be included by both Device Tree source files and the
max77802 driver.

> Regards,
> Andreas
> 

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

[PATCH] mm:vmscan: update the trace-vmscan-postprocess.pl for event vmscan/mm_vmscan_lru_isolate

[Chen Yucong]

When using *trace-vmscan-postprocess.pl* for checking the file/anon rate of 
scanning,
we can find that it can not be performed. At the same time, the following 
message will
be reported.

WARNING: Format not as expected for event vmscan/mm_vmscan_lru_isolate 'file' 
!= 'contig_taken'
Fewer fields than expected in format at ./trace-vmscan-postprocess.pl line 171, 
 line 76.

In trace-vmscan-postprocess.pl, (contig_taken, contig_dirty, and contig_failed) 
are be
associated respectively to (nr_lumpy_taken, nr_lumpy_dirty, and 
nr_lumpy_failed) for lumpy
reclaim. Via commit c53919adc045b(mm: vmscan: remove lumpy reclaim), lumpy 
reclaim had
already been removed by Mel, but the update for trace-vmscan-postprocess.pl was 
missed.

Signed-off-by: Chen Yucong 
---
 .../trace/postprocess/trace-vmscan-postprocess.pl|   14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl 
b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
index 00e425f..78c9a7b 100644
--- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
+++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
@@ -47,7 +47,6 @@ use constant HIGH_KSWAPD_REWAKEUP => 21;
 use constant HIGH_NR_SCANNED   => 22;
 use constant HIGH_NR_TAKEN => 23;
 use constant HIGH_NR_RECLAIMED => 24;
-use constant HIGH_NR_CONTIG_DIRTY  => 25;
 
 my %perprocesspid;
 my %perprocess;
@@ -105,7 +104,7 @@ my $regex_direct_end_default = 'nr_reclaimed=([0-9]*)';
 my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)';
 my $regex_kswapd_sleep_default = 'nid=([0-9]*)';
 my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)';
-my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) 
nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) 
contig_taken=([0-9]*) contig_dirty=([0-9]*) contig_failed=([0-9]*)';
+my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) 
nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) file=([0-9]*)';
 my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) zid=([0-9]*) 
nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)';
 my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) 
nr_rotated=([0-9]*) priority=([0-9]*)';
 my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)';
@@ -200,7 +199,7 @@ $regex_lru_isolate = generate_traceevent_regex(
$regex_lru_isolate_default,
"isolate_mode", "order",
"nr_requested", "nr_scanned", "nr_taken",
-   "contig_taken", "contig_dirty", "contig_failed");
+   "file");
 $regex_lru_shrink_inactive = generate_traceevent_regex(
"vmscan/mm_vmscan_lru_shrink_inactive",
$regex_lru_shrink_inactive_default,
@@ -375,7 +374,6 @@ EVENT_PROCESS:
}
my $isolate_mode = $1;
my $nr_scanned = $4;
-   my $nr_contig_dirty = $7;
 
# To closer match vmstat scanning statistics, only 
count isolate_both
# and isolate_inactive as scanning. isolate_active is 
rotation
@@ -385,7 +383,6 @@ EVENT_PROCESS:
if ($isolate_mode != 2) {
$perprocesspid{$process_pid}->{HIGH_NR_SCANNED} 
+= $nr_scanned;
}
-   $perprocesspid{$process_pid}->{HIGH_NR_CONTIG_DIRTY} += 
$nr_contig_dirty;
} elsif ($tracepoint eq "mm_vmscan_lru_shrink_inactive") {
$details = $6;
if ($details !~ /$regex_lru_shrink_inactive/o) {
@@ -539,13 +536,6 @@ sub dump_stats {
}
}
}
-   if ($stats{$process_pid}->{HIGH_NR_CONTIG_DIRTY}) {
-   print "  ";
-   my $count = 
$stats{$process_pid}->{HIGH_NR_CONTIG_DIRTY};
-   if ($count != 0) {
-   print "contig-dirty=$count ";
-   }
-   }
 
print "\n";
}
-- 
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 v5 12/14] clk: max77802: Add DT binding documentation

[Javier Martinez Canillas]

Hello Andres,

Thanks a lot for your feedback.

On 06/27/2014 09:52 AM, Andreas Färber wrote:
> Am 26.06.2014 20:15, schrieb Javier Martinez Canillas:
>> Add Device Tree binding documentation for the clocks
>> outputs in the Maxim 77802 Power Management IC.
>> 
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>> 
>> Changes since v4: None
>> 
>> Changes since v3:
>>  - Don't use the same clock driver name in clock-names since it's a consumer
>>concept and most probably will be different. Suggested by Doug Anderson.
>> 
>> Changes since v2:
>>  - Split the DT binding documentation in a separate patch.
>> 
>>  .../devicetree/bindings/clock/maxim,max77802.txt   | 42 
>> ++
>>  1 file changed, 42 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/clock/maxim,max77802.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/clock/maxim,max77802.txt 
>> b/Documentation/devicetree/bindings/clock/maxim,max77802.txt
>> new file mode 100644
>> index 000..26bc4f7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/maxim,max77802.txt
>> @@ -0,0 +1,42 @@
>> +Binding for Maxim MAX77802 32k clock generator block
>> +
>> +This is a part of device tree bindings of MAX77802 multi-function device.
>> +More information can be found in bindings/mfd/max77802.txt file.
>> +
>> +The MAX77802 contains two 32.768khz clock outputs that can be controlled
>> +(gated/ungated) over I2C.
>> +
>> +Following properties should be presend in main device node of the MFD chip.
> 
> "present"
>

Right, it's a typo. I'll wait for further feedback and will fix both issues you
pointed out in the next version of the series.

> Regards,
> Andreas
> 

Best regards,
Javier

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

[RFC 0/5] Per-user clock constraints

[Tomeu Vizoso]

Hi,

I'm retaking Rabin's patches [0] for splitting the clk API in two: one API for
clk consumers and another for providers. The consumer API uses a clk structure
that just keeps track of the consumer and has a reference to the actual
clk_core struct, which is used internally.

I have kept a patch from Rabin that aims to aid in debugging nested
enable/disable calls, though my personal aim is to allow more than one consumer
to influence the final, effective rate. For now this is limited to setting
floor and ceiling constraints.

For those functions in the consumer clk API that were called from providers, I
have added variants to clk-provider.h that are the same only that accept a
clk_core instead. In this first version of the patchset, these functions are
prepended with two underscores and have the _internal suffix at the end. Mike
has stated his preference of not prefixing with underscores any public API and
I agree with him, but we still need a way to distinguish e.g. clk_set_parent()
in the provider API from that in the consumer API (and from the lock-less
variant in clk-provider.h!).

Something else I have inconclusively wondered about are the clk_register_*()
functions, that are defined as part of the provider API but that are called
everywhere in arch/ and its returned clk is passed to all kinds of consumer
API.

I'm afraid this is still very preliminar, and the only platform that I have
checked that builds is Tegra. There will be a fair amount of changes needed in
arch/, but that depends on the outcome of this discussion.

[0] http://thread.gmane.org/gmane.linux.kernel/1402006

Thanks,

Tomeu

Rabin Vincent (2):
  clk: use struct clk only for external API
  clk: per-user clock accounting for debug

Tomeu Vizoso (3):
  clk: Add temporary mapping to the existing API
  clk: Move all drivers to use internal API
  clk: Add floor and ceiling constraints to clock rates

 drivers/clk/at91/clk-main.c   |  24 +-
 drivers/clk/at91/clk-master.c |   6 +-
 drivers/clk/at91/clk-peripheral.c |  12 +-
 drivers/clk/at91/clk-pll.c|   6 +-
 drivers/clk/at91/clk-plldiv.c |   6 +-
 drivers/clk/at91/clk-programmable.c   |  10 +-
 drivers/clk/at91/clk-slow.c   |  24 +-
 drivers/clk/at91/clk-smd.c|   6 +-
 drivers/clk/at91/clk-system.c |   6 +-
 drivers/clk/at91/clk-usb.c|  18 +-
 drivers/clk/at91/clk-utmi.c   |   6 +-
 drivers/clk/bcm/clk-kona-setup.c  |   6 +-
 drivers/clk/bcm/clk-kona.c|  12 +-
 drivers/clk/bcm/clk-kona.h|   2 +-
 drivers/clk/berlin/berlin2-avpll.c|   4 +-
 drivers/clk/berlin/berlin2-avpll.h|   4 +-
 drivers/clk/berlin/berlin2-div.c  |   2 +-
 drivers/clk/berlin/berlin2-div.h  |   2 +-
 drivers/clk/berlin/berlin2-pll.c  |   2 +-
 drivers/clk/berlin/berlin2-pll.h  |   2 +-
 drivers/clk/berlin/bg2.c  |  13 +-
 drivers/clk/berlin/bg2q.c |   9 +-
 drivers/clk/clk-axi-clkgen.c  |   2 +-
 drivers/clk/clk-axm5516.c |   4 +-
 drivers/clk/clk-bcm2835.c |   2 +-
 drivers/clk/clk-composite.c   |   6 +-
 drivers/clk/clk-devres.c  |  14 +-
 drivers/clk/clk-divider.c |   8 +-
 drivers/clk/clk-efm32gg.c |   2 +-
 drivers/clk/clk-fixed-factor.c|   6 +-
 drivers/clk/clk-fixed-rate.c  |   8 +-
 drivers/clk/clk-fractional-divider.c  |   4 +-
 drivers/clk/clk-gate.c|   4 +-
 drivers/clk/clk-highbank.c|   8 +-
 drivers/clk/clk-ls1x.c|  16 +-
 drivers/clk/clk-max77686.c|  10 +-
 drivers/clk/clk-moxart.c  |   8 +-
 drivers/clk/clk-mux.c |   6 +-
 drivers/clk/clk-nomadik.c |  14 +-
 drivers/clk/clk-nspire.c  |   4 +-
 drivers/clk/clk-ppc-corenet.c |   8 +-
 drivers/clk/clk-s2mps11.c |   6 +-
 drivers/clk/clk-si5351.c  |  17 +-
 drivers/clk/clk-si570.c   |   4 +-
 drivers/clk/clk-twl6040.c |   2 +-
 drivers/clk/clk-u300.c|  12 +-
 drivers/clk/clk-vt8500.c  |   4 +-
 drivers/clk/clk-wm831x.c  |   6 +-
 drivers/clk/clk-xgene.c   |  12 +-
 drivers/clk/clk.c | 666 --
 drivers/clk/clk.h |   9 +-
 drivers/clk/clkdev.c  | 102 +++--
 drivers/clk/hisilicon/clk-hi3620.c|   8 +-
 drivers/clk/hisilicon/clk.c   |  16 +-
 drivers/clk/hisilicon/clk.h   |   2 +-
 drivers/clk/hisilicon/clkgate-separated.c |   4 +-
 drivers/clk/keystone/gate.c   |   6 +-
 drivers/clk/keystone/pll.c|  10 +-
 drivers/clk/mmp/clk-apbc.c|   4 +

[RFC 4/5] clk: per-user clock accounting for debug

[Tomeu Vizoso]

From: Rabin Vincent 

When a clock has multiple users, the WARNING on imbalance of
enable/disable may not show the guilty party since although they may
have commited the error earlier, the warning is emitted later when some
other user, presumably innocent, disables the clock.

Provide per-user clock enable/disable accounting and disabler tracking
in order to help debug these problems.

NOTE: with this patch, clk_get_parent() behaves like clk_get(), i.e. it
needs to be matched with a clk_put().  Otherwise, memory will leak.

Signed-off-by: Tomeu Vizoso 
---
 drivers/clk/clk-devres.c|  3 ++-
 drivers/clk/clk-highbank.c  |  2 +-
 drivers/clk/clk.c   | 52 ++---
 drivers/clk/clk.h   |  2 +-
 drivers/clk/clkdev.c| 27 +
 drivers/clk/qcom/mmcc-msm8960.c |  9 ---
 drivers/clk/sunxi/clk-sunxi.c   |  2 +-
 drivers/clk/tegra/clk.c |  2 +-
 drivers/clk/zynq/clkc.c | 12 +-
 include/linux/clk-private.h |  6 -
 include/linux/clk-provider.h|  3 ++-
 11 files changed, 96 insertions(+), 24 deletions(-)

diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index 85a9b40..dcaabb0 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -37,7 +37,8 @@ EXPORT_SYMBOL(__devm_clk_get_internal);
 
 struct clk *devm_clk_get(struct device *dev, const char *id)
 {
-   return clk_core_to_clk(__devm_clk_get_internal(dev, id));
+   const char *dev_id = dev ? dev_name(dev) : NULL;
+   return clk_core_to_clk(__devm_clk_get_internal(dev, id), dev_id, id);
 }
 EXPORT_SYMBOL(devm_clk_get);
 
diff --git a/drivers/clk/clk-highbank.c b/drivers/clk/clk-highbank.c
index cc1bae1..4e38856 100644
--- a/drivers/clk/clk-highbank.c
+++ b/drivers/clk/clk-highbank.c
@@ -331,7 +331,7 @@ CLK_OF_DECLARE(hb_a9periph, "calxeda,hb-a9periph-clock", 
hb_a9periph_init);
 static void __init hb_a9bus_init(struct device_node *node)
 {
struct clk_core *clk = hb_clk_init(node, &a9bclk_ops);
-   clk_prepare_enable(clk_core_to_clk(clk));
+   clk_prepare_enable(clk_core_to_clk(clk, node->full_name, NULL));
 }
 CLK_OF_DECLARE(hb_a9bus, "calxeda,hb-a9bus-clock", hb_a9bus_init);
 
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index f9a603a..7fc1937 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -568,6 +568,28 @@ static int clk_disable_unused(void)
 }
 late_initcall_sync(clk_disable_unused);
 
+struct clk *clk_core_to_clk(struct clk_core *clk_core, const char *dev,
+   const char *con)
+{
+   struct clk *clk;
+
+   clk = kzalloc(sizeof(*clk), GFP_KERNEL);
+   if (!clk)
+   return ERR_PTR(-ENOMEM);
+
+   clk->core = clk_core;
+   clk->dev_id = dev;
+   clk->con_id = con;
+
+   return clk;
+}
+EXPORT_SYMBOL_GPL(clk_core_to_clk);
+
+struct clk_core *clk_to_clk_core(struct clk *clk)
+{
+   return clk->core;
+}
+
 /***helper functions   ***/
 
 const char *__clk_get_name(struct clk_core *clk)
@@ -935,7 +957,20 @@ static void __clk_disable_internal(struct clk_core *clk)
  */
 void clk_disable(struct clk *clk_user)
 {
-   __clk_disable_internal(clk_to_clk_core(clk_user));
+   struct clk_core *clk = clk_to_clk_core(clk_user);
+   unsigned long flags;
+
+   flags = clk_enable_lock();
+   if (!WARN(clk_user->enable_count == 0,
+ "incorrect disable clk dev %s con %s last disabler %pF\n",
+ clk_user->dev_id, clk_user->con_id, clk_user->last_disable)) {
+
+   clk_user->last_disable = __builtin_return_address(0);
+   clk_user->enable_count--;
+
+   __clk_disable(clk);
+   }
+   clk_enable_unlock(flags);
 }
 EXPORT_SYMBOL_GPL(clk_disable);
 
@@ -995,7 +1030,17 @@ static int __clk_enable_internal(struct clk_core *clk)
  */
 int clk_enable(struct clk *clk_user)
 {
-   return __clk_enable_internal(clk_to_clk_core(clk_user));
+   struct clk_core *clk = clk_to_clk_core(clk_user);
+   unsigned long flags;
+   int ret;
+
+   flags = clk_enable_lock();
+   ret = __clk_enable(clk);
+   if (!ret)
+   clk_user->enable_count++;
+   clk_enable_unlock(flags);
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(clk_enable);
 
@@ -1671,8 +1716,9 @@ EXPORT_SYMBOL_GPL(__clk_get_parent_internal);
 struct clk *clk_get_parent(struct clk *clk_user)
 {
struct clk_core *clk = clk_to_clk_core(clk_user);
+   struct clk_core *parent = __clk_get_parent_internal(clk);
 
-   return clk_core_to_clk(__clk_get_parent_internal(clk));
+   return clk_core_to_clk(parent, clk_user->dev_id, clk_user->con_id);
 }
 EXPORT_SYMBOL_GPL(clk_get_parent);
 
diff --git a/drivers/clk/clk.h b/drivers/clk/clk.h
index 677ced3..2f682bf 100644
--- a/drivers/clk/clk.h
+++ b/drivers/clk/clk.h
@@ -17,5 +17,5 @@ void of_clk_unlock(void);
 #endif
 
 #if defined(CONFIG_COMMON_CLK)
-#define clk_to_clk_core(clk)   ((struc

[RFC 1/5] clk: Add temporary mapping to the existing API

[Tomeu Vizoso]

To preserve git-bisectability, add aliases from the future provider API to the
existing public API.

Signed-off-by: Tomeu Vizoso 
---

Don't like this much, would be great to hear of alternatives.

 include/linux/clk-provider.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 0c287db..e9ccc50 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -16,6 +16,24 @@
 
 #ifdef CONFIG_COMMON_CLK
 
+/* Temporarily map the to-be-added API to the old API, just so stuff compiles 
*/
+#define clk_core   clk
+
+#define clk_core_to_clk
+
+#define __clk_get_internal clk_get
+#define __clk_get_sys_internal clk_get_sys
+#define __devm_clk_get_internaldevm_clk_get
+#define __of_clk_get_internal  of_clk_get
+#define __of_clk_get_by_name_internal  of_clk_get_by_name
+
+#define __clk_set_rate_internalclk_set_rate
+#define __clk_get_rate_internalclk_get_rate
+#define __clk_set_parent_internal  clk_set_parent
+#define __clk_get_parent_internal  clk_get_parent
+#define __clk_prepare_internal clk_prepare
+#define __clk_unprepare_internal   clk_unprepare
+
 /*
  * flags used across common struct clk.  these flags should only affect the
  * top-level framework.  custom flags for dealing with hardware specifics
-- 
1.9.3

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

[RFC 5/5] clk: Add floor and ceiling constraints to clock rates

[Tomeu Vizoso]

Adds a way for clock consumers to set maximum and minimum rates. This can be
used for thermal drivers to set ceiling rates, or by misc. drivers to set
floor rates to assure a minimum performance level.

Signed-off-by: Tomeu Vizoso 
---
 drivers/clk/clk.c   | 105 
 drivers/clk/clk.h   |   1 +
 drivers/clk/clkdev.c|   7 +--
 include/linux/clk-private.h |   1 +
 include/linux/clk.h |  18 
 5 files changed, 126 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 7fc1937..4d93066 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -23,6 +23,19 @@
 
 #include "clk.h"
 
+enum constraint_type {
+   CONSTRAINT_FLOOR,
+   CONSTRAINT_CEILING,
+};
+
+struct rate_constraint {
+   struct hlist_node   node;
+   const char  *dev_id;
+   const char  *con_id;
+   enum constraint_typetype;
+   unsigned long   rate;
+};
+
 static DEFINE_SPINLOCK(enable_lock);
 static DEFINE_MUTEX(prepare_lock);
 
@@ -1624,6 +1637,7 @@ static void clk_change_rate(struct clk_core *clk)
 int __clk_set_rate_internal(struct clk_core *clk, unsigned long rate)
 {
struct clk_core *top, *fail_clk;
+   struct rate_constraint *constraint;
int ret = 0;
 
if (!clk)
@@ -1632,6 +1646,17 @@ int __clk_set_rate_internal(struct clk_core *clk, 
unsigned long rate)
/* prevent racing with updates to the clock topology */
clk_prepare_lock();
 
+   hlist_for_each_entry(constraint, &clk->rate_constraints, node) {
+   switch(constraint->type) {
+   case CONSTRAINT_FLOOR:
+   rate = max(rate, constraint->rate);
+   break;
+   case CONSTRAINT_CEILING:
+   rate = min(rate, constraint->rate);
+   break;
+   }
+   }
+
/* bail early if nothing to do */
if (rate == __clk_get_rate_internal(clk))
goto out;
@@ -1695,6 +1720,67 @@ int clk_set_rate(struct clk *clk_user, unsigned long 
rate)
 }
 EXPORT_SYMBOL_GPL(clk_set_rate);
 
+static struct rate_constraint *__ensure_constraint(struct clk *clk_user,
+  enum constraint_type type)
+{
+   struct clk_core *clk = clk_to_clk_core(clk_user);
+   struct rate_constraint *constraint = NULL;
+   bool found = false;
+
+   hlist_for_each_entry(constraint, &clk->rate_constraints, node) {
+   if (constraint->dev_id == clk_user->dev_id &&
+   constraint->con_id == clk_user->con_id &&
+   constraint->type == type)
+   found = true;
+   }
+
+   if (!found) {
+   constraint = kzalloc(sizeof(*constraint), GFP_KERNEL);
+   if (!constraint) {
+   pr_err("%s: could not allocate constraint\n", __func__);
+   return NULL;
+   }
+   hlist_add_head(&constraint->node, &clk->rate_constraints);
+   }
+
+   return constraint;
+}
+
+static int __clk_set_constraint(struct clk *clk_user, unsigned long rate,
+   enum constraint_type type)
+{
+   struct clk_core *clk = clk_to_clk_core(clk_user);
+   struct rate_constraint *constraint;
+   int ret;
+
+   clk_prepare_lock();
+
+   constraint = __ensure_constraint(clk_user, type);
+   if (!constraint)
+   return -ENOMEM;
+
+   constraint->rate = rate;
+
+   /* Update the rate so the new constraint is taken into account */
+   ret = __clk_set_rate_internal(clk, __clk_get_rate_internal(clk));
+
+   clk_prepare_unlock();
+
+   return ret;
+}
+
+int clk_set_floor_rate(struct clk *clk_user, unsigned long rate)
+{
+   return __clk_set_constraint(clk_user, rate, CONSTRAINT_FLOOR);
+}
+EXPORT_SYMBOL_GPL(clk_set_floor_rate);
+
+int clk_set_ceiling_rate(struct clk *clk_user, unsigned long rate)
+{
+   return __clk_set_constraint(clk_user, rate, CONSTRAINT_CEILING);
+}
+EXPORT_SYMBOL_GPL(clk_set_ceiling_rate);
+
 struct clk_core *__clk_get_parent_internal(struct clk_core *clk)
 {
struct clk_core *parent;
@@ -2028,6 +2114,8 @@ int __clk_init(struct device *dev, struct clk_core *clk)
}
 }
 
+   INIT_HLIST_HEAD(&clk->rate_constraints);
+
/*
 * optional platform-specific magic
 *
@@ -2458,6 +2546,23 @@ int clk_notifier_unregister(struct clk *clk_user, struct 
notifier_block *nb)
 }
 EXPORT_SYMBOL_GPL(clk_notifier_unregister);
 
+void __clk_free_clk(struct clk *clk_user)
+{
+   struct clk_core *clk = clk_to_clk_core(clk_user);
+   struct rate_constraint *constraint;
+   struct hlist_node *tmp;
+
+   hlist_for_each_entry_safe(constraint, tmp, &clk->rate_constraints, 
node) {
+   if (constraint->dev_id == clk_user->dev_id &

Re: [PATCH] HID: roccat: Drop cast

[Julia Lawall]

On Thu, 26 Jun 2014, Joe Perches wrote:

> On Fri, 2014-06-27 at 07:29 +0200, Julia Lawall wrote:
> > On Thu, 26 Jun 2014, Joe Perches wrote:
> > > The cast of a const void * to a void * was odd.
> > >
> > > Maybe a mechanism to verify appropriateness of
> > > loss of constness for any pointer might be useful.
> >
> > I tried the following, but didn't find anything interesting:
> >
> > @disable drop_cast@
> > type T;
> > const T e;
> > @@
> >
> > * (T)e
>
> What code does this match?
> Do you have an example match?
>
> This doesn't find a cast of a void type like:
>
> void func(const void * const p)
> {
>   char *p2 = p;
>
>   p2[0] = 1;
> }

The results are below.  Except in the first case, none are pointer types.
The first case looks very intentional, although if the intention is
needed, perhaps the types should be listed differently.

I was surprised not to get more results.  Maybe there is not enough type
information.  I did use --all-includes but not --recursive-includes, ie
only explicitly mentioned include files are taken into account.

My rule doesn't consider implicit casts like in your example.  I can try
that.

julia


diff -u -p /var/linuxes/linux-next/lib/devres.c /tmp/nothing/lib/devres.c
--- /var/linuxes/linux-next/lib/devres.c
+++ /tmp/nothing/lib/devres.c
@@ -296,7 +296,6 @@ void __iomem *pcim_iomap(struct pci_dev

BUG_ON(bar >= PCIM_IOMAP_MAX);

-   tbl = (void __iomem **)pcim_iomap_table(pdev);
if (!tbl || tbl[bar])   /* duplicate mappings not allowed */
return NULL;

@@ -319,7 +318,6 @@ void pcim_iounmap(struct pci_dev *pdev,

pci_iounmap(pdev, addr);

-   tbl = (void __iomem **)pcim_iomap_table(pdev);
BUG_ON(!tbl);

for (i = 0; i < PCIM_IOMAP_MAX; i++)
diff -u -p /var/linuxes/linux-next/drivers/video/fbdev/smscufx.c 
/tmp/nothing/drivers/video/fbdev/smscufx.c
--- /var/linuxes/linux-next/drivers/video/fbdev/smscufx.c
+++ /tmp/nothing/drivers/video/fbdev/smscufx.c
@@ -976,7 +976,6 @@ static void ufx_dpy_deferred_io(struct f
const int width = dev->info->var.xres;
const int y = (cur->index << PAGE_SHIFT) / (width * 2);
int height = (PAGE_SIZE / (width * 2)) + 1;
-   height = min(height, (int)(dev->info->var.yres - y));

BUG_ON(y >= dev->info->var.yres);
BUG_ON((y + height) > dev->info->var.yres);
diff -u -p /var/linuxes/linux-next/drivers/mtd/chips/jedec_probe.c 
/tmp/nothing/drivers/mtd/chips/jedec_probe.c
--- /var/linuxes/linux-next/drivers/mtd/chips/jedec_probe.c
+++ /tmp/nothing/drivers/mtd/chips/jedec_probe.c
@@ -2027,11 +2027,8 @@ static inline int jedec_match( uint32_t
}
break;
case CFI_DEVICETYPE_X16:
-   mfr = (uint16_t)finfo->mfr_id;
-   id = (uint16_t)finfo->dev_id;
break;
case CFI_DEVICETYPE_X32:
-   mfr = (uint16_t)finfo->mfr_id;
id = (uint32_t)finfo->dev_id;
break;
default:
diff -u -p /var/linuxes/linux-next/drivers/net/wireless/libertas/defs.h 
/tmp/nothing/drivers/net/wireless/libertas/defs.h
--- /var/linuxes/linux-next/drivers/net/wireless/libertas/defs.h
+++ /tmp/nothing/drivers/net/wireless/libertas/defs.h
@@ -105,7 +105,6 @@ static inline void lbs_deb_hex(unsigned
printk("\n");
printk(DRV_NAME " %s: ", prompt);
}
-   printk("%02x ", (u8) * buf);
buf++;
}
printk("\n");
diff -u -p /var/linuxes/linux-next/drivers/media/i2c/tvp5150.c 
/tmp/nothing/drivers/media/i2c/tvp5150.c
--- /var/linuxes/linux-next/drivers/media/i2c/tvp5150.c
+++ /tmp/nothing/drivers/media/i2c/tvp5150.c
@@ -95,7 +95,6 @@ static void dump_reg_range(struct v4l2_s
 {
int i = 0;

-   while (init != (u8)(end + 1)) {
if ((i % max_line) == 0) {
if (i > 0)
printk("\n");
diff -u -p /var/linuxes/linux-next/net/netfilter/ipvs/ip_vs_sync.c 
/tmp/nothing/net/netfilter/ipvs/ip_vs_sync.c
--- /var/linuxes/linux-next/net/netfilter/ipvs/ip_vs_sync.c
+++ /tmp/nothing/net/netfilter/ipvs/ip_vs_sync.c
@@ -1543,7 +1543,6 @@ ip_vs_send_async(struct socket *sock, co
iov.iov_base = (void *)buffer;
iov.iov_len  = length;

-   len = kernel_sendmsg(sock, &msg, &iov, 1, (size_t)(length));

LeaveFunction(7);
return len;
@@ -1575,7 +1574,6 @@ ip_vs_receive(struct socket *sock, char

/* Receive a packet */
iov.iov_base = buffer;
-   iov.iov_len  = (size_t)buflen;

len = kernel_recvmsg(sock, &msg, &iov, 1, buflen, MSG_DONTWAIT);

diff -u -p /var/linuxes/linux-next/net/ipv4/tcp_output.c 
/tmp/nothing/net/ipv4/tcp_output.c
--- /var/linuxes/linux-next/net/ipv4/tcp_output.c
+++ /tmp/nothing/net/ipv4/tcp_output.

Re: [PATCH v5 08/14] mfd: max77802: Add DT binding documentation

[Andreas Färber]

Am 26.06.2014 20:15, schrieb Javier Martinez Canillas:
> Add Device Tree binding documentation for Maxim 77802 PMIC.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
> Changes since v4: None
> 
> Changes since v3: None
> 
> Changes since v2:
>  - Explain better the Dynamic Voltage Scaling (DVS) support in some Buck
>regulators and the max77802,pmic-buck-{dvs,selb}-gpios properties.
>Suggested by Mark Brown.
> 
>  Documentation/devicetree/bindings/mfd/max77802.txt | 97 
> ++
>  1 file changed, 97 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt 
> b/Documentation/devicetree/bindings/mfd/max77802.txt
> new file mode 100644
> index 000..f3b67c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/max77802.txt
> @@ -0,0 +1,97 @@
> +Maxim MAX77802 multi-function device
> +
> +MAX77802 is a Mulitifunction device with PMIC, RTC and Charger on chip. It is

"Multifunction"?

> +interfaced to host controller using i2c interface. PMIC, Charger and RTC
> +submodules are addressed using same i2c slave address.
> +
> +Buck regulators 1, 2, 3, 4 and 6 include Dynamic Voltage Scaling (DVS) that
> +allows each output voltage to change dynamically. Each Buck output voltage
> +is selected using a set of external inputs: DVS1-3 and SELB1, 2, 3 and 6.
> +
> +There are 8 DVS registers that can be used to configure the output voltage
> +for each Buck regulator and which one is active is controled by DVSx lines.
> +
> +SELBx lines are used to control if individual Buck lines are ON or OFF.
> +
> +This document describes the binding for mfd device and PMIC submodule.
> +
> +Binding for the built-in 32k clock generator block is defined separately
> +in bindings/clk/maxim,max77802.txt file.
> +
> +Required properties:
> +- compatible : Must be "maxim,max77802";
> +- reg : Specifies the i2c slave address of PMIC block.
> +- interrupts : This i2c device has an IRQ line connected to the main SoC.
> +- interrupt-parent : The parent interrupt controller.
> +
> +Optional properties:
> +- max77802,pmic-buck-default-dvs-idx: We'll always write this DVS index in 
> the
> +  PMIC for Bucks with DVS.
> +  NOTE: at the moment these bindings don't include enough details for actual
> +  GPIO-DVS--this just lets you choose which single slot to use.
> +
> +- max77802,pmic-buck-dvs-gpios: A GPIO array where each GPIO is connected to 
> a
> +  DVS line. We'll try to set these GPIOs to match pmic-buck-default-dvs-idx 
> at
> +  probe time if they are defined. If some or all of these GPIOs are not 
> defined
> +  it's assumed that the board has any missing GPIOs hardwired to match
> +  pmic-buck-default-dvs-idx.
> +
> +- max77802,pmic-buck-selb-gpios: A GPIO array where each GPIO is connected 
> to a
> +  SELBx line. Should be five values: 1, 2, 3, 4, 6. It is strongly suggested 
> to
> +  include these GPIOs if there's any chance that changing DVS GPIOs one line 
> at
> +  a time might glitch your DVS values.
> +
> +Optional node:
> +- regulators : The regulators of max77802 have to be instantiated
> +  under subnode named "regulators" using the following format.
> +
> + regulator_name {

The convention, I was told, would be regulator-name as node name.

> + standard regulator constraints
> + };
> + refer Documentation/devicetree/bindings/regulator/regulator.txt
> +
> +  The regulator node name should be initialized with a string
> +to get matched with their hardware counterparts as follow:
> +
> + -LDOn   :   for LDOs, where n can lie in range 1 to 35.
> + example: LDO1, LDO2, LDO35.
> + -BUCKn  :   for BUCKs, where n can lie in range 1 to 10.
> + example: BUCK1, BUCK5, BUCK10.
> +Example:
> +
> + max77802@09 {
> + compatible = "maxim,max77802";
> + interrupt-parent = <&wakeup_eint>;
> + interrupts = <26 0>;
> + reg = <0x09>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + max77802,pmic-buck-default-dvs-idx = <1>;
> + max77802,pmic-buck-dvs-gpios = <&gpy7 6 0>,
> +<&gpj4 2 0>,
> +<&gpj4 3 0>;
> + max77802,pmic-buck-selb-gpios = <&gph0 2 0>,
> + <&gph0 3 0>,
> + <&gph0 4 0>,
> + <&gph0 5 0>,
> + <&gph0 6 0>;
> +
> + regulators {
> + ldo11_reg: LDO11 {
> + regulator-compatible = "LDO11";
> + regulator-name = "vdd_ldo11";
> + regulator-min-microvolt = <190>;
> + regulator-max-microvolt = <190>

RE: [PATCH v2] USB: ehci-pci: USB host controller support for Intel Quark X1000

[David Laight]

From: Jingoo Han

...
> /* The maximal threshold value is 0x80, which means 512 bytes */
> #define EHCI_THRESHOLD_512BYTES   0x80
> #define EHCI_THRESHOLD_508BYTES   0x79

It would be better to define these using expressions. So:
#define EHCI_THRESHOLD_512BYTES (512u / 8u)
#define EHCI_THRESHOLD_508BYTES (508u / 8u)

Then you might decide to use:
#define EHCI_THRESHOLD(size) ((size) / 8u)

Then realise that the names are not generic EHCI, so need some
driver-specific prefix (for namespace reasons).

And that the defines are probably limit values, and should
be named as such.

David



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

[PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree

[Mikko Perttunen]

This adds the soctherm thermal sensing and management unit to the
Tegra124 device tree along with the four thermal zones it exports.

Signed-off-by: Mikko Perttunen 
---
 arch/arm/boot/dts/tegra124.dtsi | 48 +
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index d675186..853627f 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "skeleton.dtsi"
 
@@ -724,6 +725,53 @@
status = "disabled";
};
 
+   thermal-zones {
+   cpu {
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   <&soctherm TEGRA124_SOCTHERM_SENSOR_CPU>;
+   };
+
+   mem {
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   <&soctherm TEGRA124_SOCTHERM_SENSOR_MEM>;
+   };
+
+   gpu {
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   <&soctherm TEGRA124_SOCTHERM_SENSOR_GPU>;
+   };
+
+   pllx {
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+
+   thermal-sensors =
+   <&soctherm TEGRA124_SOCTHERM_SENSOR_PLLX>;
+   };
+   };
+
+   soctherm: soctherm@0,700e2000 {
+   compatible = "nvidia,tegra124-soctherm";
+   reg = <0x0 0x700e2000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&tegra_car TEGRA124_CLK_TSENSOR>,
+   <&tegra_car TEGRA124_CLK_SOC_THERM>;
+   clock-names = "tsensor", "soctherm";
+   resets = <&tegra_car 78>;
+   reset-names = "soctherm";
+
+   #thermal-sensor-cells = <1>;
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
-- 
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 6/6] thermal: Add Tegra SOCTHERM thermal management driver

[Mikko Perttunen]

This adds support for the Tegra SOCTHERM thermal sensing and management
system found in the Tegra124 system-on-chip. This initial driver supports
the four thermal zones with hardware-tracked trip points.

Signed-off-by: Mikko Perttunen 
---
 drivers/thermal/Kconfig  |   7 +
 drivers/thermal/Makefile |   1 +
 drivers/thermal/tegra_soctherm.c | 553 +++
 3 files changed, 561 insertions(+)
 create mode 100644 drivers/thermal/tegra_soctherm.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index f9a1386..cdd1f05 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -175,6 +175,13 @@ config ARMADA_THERMAL
  Enable this option if you want to have support for thermal management
  controller present in Armada 370 and Armada XP SoC.
 
+config TEGRA_SOCTHERM
+   bool "Tegra SOCTHERM thermal management"
+   depends on ARCH_TEGRA
+   help
+ Enable this option for integrated thermal management support on NVIDIA
+ Tegra124 systems-on-chip.
+
 config DB8500_CPUFREQ_COOLING
tristate "DB8500 cpufreq cooling"
depends on ARCH_U8500
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index de0636a..d5d964b 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_X86_PKG_TEMP_THERMAL)+= 
x86_pkg_temp_thermal.o
 obj-$(CONFIG_INTEL_SOC_DTS_THERMAL)+= intel_soc_dts_thermal.o
 obj-$(CONFIG_TI_SOC_THERMAL)   += ti-soc-thermal/
 obj-$(CONFIG_ACPI_INT3403_THERMAL) += int3403_thermal.o
+obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra_soctherm.o
diff --git a/drivers/thermal/tegra_soctherm.c b/drivers/thermal/tegra_soctherm.c
new file mode 100644
index 000..41e4dcf
--- /dev/null
+++ b/drivers/thermal/tegra_soctherm.c
@@ -0,0 +1,553 @@
+/*
+ * drivers/thermal/tegra_soctherm.c
+ *
+ * Copyright (c) 2014, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Author:
+ * Mikko Perttunen 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SENSOR_CONFIG0 0
+#defineSENSOR_CONFIG0_STOP BIT(0)
+#defineSENSOR_CONFIG0_TALL_SHIFT   8
+#defineSENSOR_CONFIG0_TCALC_OVER   BIT(4)
+#defineSENSOR_CONFIG0_OVER BIT(3)
+#defineSENSOR_CONFIG0_CPTR_OVERBIT(2)
+#define SENSOR_CONFIG1 4
+#defineSENSOR_CONFIG1_TSAMPLE_SHIFT0
+#defineSENSOR_CONFIG1_TIDDQ_EN_SHIFT   15
+#defineSENSOR_CONFIG1_TEN_COUNT_SHIFT  24
+#defineSENSOR_CONFIG1_TEMP_ENABLE  BIT(31)
+#define SENSOR_CONFIG2 8
+#defineSENSOR_CONFIG2_THERMA_SHIFT 16
+#defineSENSOR_CONFIG2_THERMB_SHIFT 0
+
+#define THERMCTL_LEVEL0_GROUP_CPU  0x0
+#defineTHERMCTL_LEVEL0_GROUP_ENBIT(8)
+#defineTHERMCTL_LEVEL0_GROUP_DN_THRESH_SHIFT 9
+#defineTHERMCTL_LEVEL0_GROUP_UP_THRESH_SHIFT 17
+
+#define THERMCTL_INTR_STATUS   0x84
+#define THERMCTL_INTR_EN   0x88
+
+#define SENSOR_PDIV0x1c0
+#defineSENSOR_PDIV_T1240x
+#define SENSOR_HOTSPOT_OFF 0x1c4
+#defineSENSOR_HOTSPOT_OFF_T124 0x00060600
+#define SENSOR_TEMP1   0x1c8
+#defineSENSOR_TEMP1_CPU_TEMP_SHIFT 16
+#defineSENSOR_TEMP1_GPU_TEMP_MASK  0x
+#define SENSOR_TEMP2   0x1cc
+#defineSENSOR_TEMP2_MEM_TEMP_SHIFT 16
+#defineSENSOR_TEMP2_PLLX_TEMP_MASK 0x
+
+#define FUSE_TSENSOR8_CALIB0x180
+#define FUSE_SPARE_REALIGNMENT_REG_0   0x1fc
+
+#define NOMINAL_CALIB_FT_T124  105
+
+struct tegra_tsensor_configuration {
+   u32 tall, tsample, tiddq_en, ten_count;
+   u32 pdiv, tsample_ate, pdiv_ate;
+};
+
+struct tegra_tsensor {
+   const char *name;
+   u32 base;
+   struct tegra_tsensor_configuration *config;
+   u32 calib_fuse_offset;
+   s32 fuse_corr_alpha, fuse_corr_beta;
+};
+
+struct tegra_thermctl_zone {
+   struct tegra_soctherm *tegra;
+   int sensor;
+};
+
+static struct tegra_tsensor_configuration t124_t

[PATCH 3/6] ARM: tegra: Add thermal trip points for Jetson TK1

[Mikko Perttunen]

This adds critical trip points to the Jetson TK1 device tree.
The device will do a controlled shutdown when either the CPU, GPU
or MEM thermal zone reaches 101 degrees Celsius.

Signed-off-by: Mikko Perttunen 
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts | 32 +++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 16082c0..c319443 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1825,4 +1825,36 @@
 <&tegra_car TEGRA124_CLK_EXTERN1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   thermal-zones {
+   cpu {
+   trips {
+   cpu-critical {
+   temperature = <101000>;
+   hysteresis = <0>;
+   type = "critical";
+   };
+   };
+   };
+
+   mem {
+   trips {
+   mem-critical {
+   temperature = <101000>;
+   hysteresis = <0>;
+   type = "critical";
+   };
+   };
+   };
+
+   gpu {
+   trips {
+   gpu-critical {
+   temperature = <101000>;
+   hysteresis = <0>;
+   type = "critical";
+   };
+   };
+   };
+   };
 };
-- 
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 5/6] clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table

[Mikko Perttunen]

This adds the two clocks, soctherm and tsensor, to the T124 initialization 
table.
They are required for soctherm-based thermal sensing.

Signed-off-by: Mikko Perttunen 
---
Peter, one more zero for TSENSOR, please :)
 drivers/clk/tegra/clk-tegra124.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
index 80efe51..abeec63 100644
--- a/drivers/clk/tegra/clk-tegra124.c
+++ b/drivers/clk/tegra/clk-tegra124.c
@@ -1369,6 +1369,8 @@ static struct tegra_clk_init_table init_table[] 
__initdata = {
{TEGRA124_CLK_XUSB_HS_SRC, TEGRA124_CLK_PLL_U_60M, 6000, 0},
{TEGRA124_CLK_XUSB_FALCON_SRC, TEGRA124_CLK_PLL_RE_OUT, 22400, 0},
{TEGRA124_CLK_XUSB_HOST_SRC, TEGRA124_CLK_PLL_RE_OUT, 11200, 0},
+   {TEGRA124_CLK_SOC_THERM, TEGRA124_CLK_PLL_P, 5100, 0},
+   {TEGRA124_CLK_TSENSOR, TEGRA124_CLK_CLK_M, 40, 0},
/* This MUST be the last entry. */
{TEGRA124_CLK_CLK_MAX, TEGRA124_CLK_CLK_MAX, 0, 0},
 };
-- 
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 1/6] thermal: of: Add support for hardware-tracked trip points

[Mikko Perttunen]

This adds support for hardware-tracked trip points to the device tree
thermal sensor framework.

The framework supports an arbitrary number of trip points. Whenever
the current temperature is updated, the trip points immediately
below and above the current temperature are found. A sensor driver
callback `set_trips' is then called with the temperatures.
If there is no trip point above or below the current temperature,
the passed trip temperature will be LONG_MAX or LONG_MIN respectively.
In this callback, the driver should program the hardware such that
it is notified when either of these trip points are triggered.
When a trip point is triggered, the driver should call
`thermal_zone_device_update' for the respective thermal zone. This
will cause the trip points to be updated again.

If the `set_trips' callback is not implemented (is NULL), the framework
behaves as before.

Signed-off-by: Mikko Perttunen 
---
 drivers/thermal/of-thermal.c | 97 ++--
 include/linux/thermal.h  |  3 +-
 2 files changed, 95 insertions(+), 5 deletions(-)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 04b1be7..bfccea5 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -89,6 +89,7 @@ struct __thermal_zone {
/* trip data */
int ntrips;
struct __thermal_trip *trips;
+   long prev_low_trip, prev_high_trip;
 
/* cooling binding data */
int num_tbps;
@@ -98,19 +99,66 @@ struct __thermal_zone {
void *sensor_data;
int (*get_temp)(void *, long *);
int (*get_trend)(void *, long *);
+   int (*set_trips)(void *, long, long);
 };
 
+/***   Automatic trip handling   ***/
+
+static int of_thermal_set_trips(struct thermal_zone_device *tz, long temp)
+{
+   struct __thermal_zone *data = tz->devdata;
+   long low = LONG_MIN, high = LONG_MAX;
+   int i;
+
+   /* Hardware trip points not supported */
+   if (!data->set_trips)
+   return 0;
+
+   /* No need to change trip points */
+   if (temp > data->prev_low_trip && temp < data->prev_high_trip)
+   return 0;
+
+   for (i = 0; i < data->ntrips; ++i) {
+   struct __thermal_trip *trip = data->trips + i;
+   long trip_low = trip->temperature - trip->hysteresis;
+
+   if (trip_low < temp && trip_low > low)
+   low = trip_low;
+
+   if (trip->temperature > temp && trip->temperature < high)
+   high = trip->temperature;
+   }
+
+   dev_dbg(&tz->device,
+   "temperature %ld, updating trip points to %ld, %ld\n",
+   temp, low, high);
+
+   data->prev_low_trip = low;
+   data->prev_high_trip = high;
+
+   return data->set_trips(data->sensor_data, low, high);
+}
+
 /***   DT thermal zone device callbacks   ***/
 
 static int of_thermal_get_temp(struct thermal_zone_device *tz,
   unsigned long *temp)
 {
struct __thermal_zone *data = tz->devdata;
+   int err;
 
if (!data->get_temp)
return -EINVAL;
 
-   return data->get_temp(data->sensor_data, temp);
+   err = data->get_temp(data->sensor_data, temp);
+   if (err)
+   return err;
+
+   err = of_thermal_set_trips(tz, *temp);
+   if (err)
+   return err;
+
+   return 0;
 }
 
 static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
@@ -222,6 +270,22 @@ static int of_thermal_set_mode(struct thermal_zone_device 
*tz,
return 0;
 }
 
+static int of_thermal_update_trips(struct thermal_zone_device *tz)
+{
+   long temp;
+   int err;
+
+   err = of_thermal_get_temp(tz, &temp);
+   if (err)
+   return err;
+
+   err = of_thermal_set_trips(tz, temp);
+   if (err)
+   return err;
+
+   return 0;
+}
+
 static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
enum thermal_trip_type *type)
 {
@@ -252,6 +316,7 @@ static int of_thermal_set_trip_temp(struct 
thermal_zone_device *tz, int trip,
unsigned long temp)
 {
struct __thermal_zone *data = tz->devdata;
+   int err;
 
if (trip >= data->ntrips || trip < 0)
return -EDOM;
@@ -259,6 +324,10 @@ static int of_thermal_set_trip_temp(struct 
thermal_zone_device *tz, int trip,
/* thermal framework should take care of data->mask & (1 << trip) */
data->trips[trip].temperature = temp;
 
+   err = of_thermal_update_trips(tz);
+   if (err)
+   return err;
+
return 0;
 }
 
@@ -279,6 +348,7 @@ static int of_thermal_set_trip_hyst(struct 
thermal_zone_device *tz, int trip,
unsigned long hyst)
 {
struct __thermal_zone *data = tz->devdata;
+   int err;
 
if (trip >= data->ntrips

[PATCH 0/6] of-thermal hardware trip points + Tegra124 SOCTHERM driver

[Mikko Perttunen]

Hi everyone,

this series adds support for hardware-tracked thermal trip points
for the device tree thermal framework and introduces a new Tegra124 thermal
driver that uses them.

Hardware-tracked trip points are trip points that do not need to be polled;
the hardware gives an interrupt when the trip point is reached. The device
tree thermal framework has not previously given the sensor driver any
information about set trip points, so using these has been impossible.
This series adds a new callback from of-thermal to the driver to allow telling
the driver about trip points. The driver only needs to track two trip points,
the framework ensures that the current temperature lies between those two.
Behavior for drivers that do not include this callback is unchanged.

The Tegra124 SOCTHERM thermal driver that is included exposes four thermal zones
(the thermctl thermal zones) with hardware-tracked trip point support. While the
hardware supports four tracked trip points, only one is used.

Mikko Perttunen (6):
  thermal: of: Add support for hardware-tracked trip points
  of: Add bindings for nvidia,tegra124-soctherm
  ARM: tegra: Add thermal trip points for Jetson TK1
  ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree
  clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table
  thermal: Add Tegra SOCTHERM thermal management driver

 .../devicetree/bindings/thermal/tegra-soctherm.txt |  32 ++
 arch/arm/boot/dts/tegra124-jetson-tk1.dts  |  32 ++
 arch/arm/boot/dts/tegra124.dtsi|  48 ++
 drivers/clk/tegra/clk-tegra124.c   |   2 +
 drivers/thermal/Kconfig|   7 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/of-thermal.c   |  97 +++-
 drivers/thermal/tegra_soctherm.c   | 553 +
 include/dt-bindings/thermal/tegra124-soctherm.h|  15 +
 include/linux/thermal.h|   3 +-
 10 files changed, 785 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
 create mode 100644 drivers/thermal/tegra_soctherm.c
 create mode 100644 include/dt-bindings/thermal/tegra124-soctherm.h

-- 
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 2/6] of: Add bindings for nvidia,tegra124-soctherm

[Mikko Perttunen]

This adds binding documentation and headers for the Tegra124
SOCTHERM device tree node.

Signed-off-by: Mikko Perttunen 
---
 .../devicetree/bindings/thermal/tegra-soctherm.txt | 32 ++
 include/dt-bindings/thermal/tegra124-soctherm.h| 15 ++
 2 files changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
 create mode 100644 include/dt-bindings/thermal/tegra124-soctherm.h

diff --git a/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt 
b/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
new file mode 100644
index 000..dc5588e
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
@@ -0,0 +1,32 @@
+Tegra124 SOCTHERM thermal management system
+
+Required properties :
+- compatible : "nvidia,tegra124-soctherm".
+- reg : Should contain 1 entry:
+  - SOCTHERM register set
+- interrupts : Defines the interrupt used by SOCTHERM
+- clocks : Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names : Must include the following entries:
+  - tsensor
+  - soctherm
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - soctherm
+- #thermal-sensor-cells : For thermctl sensors. Should be 1.
+
+Example :
+
+   soctherm@0,700e2000 {
+   compatible = "nvidia,tegra124-soctherm";
+   reg = <0x0 0x700e2000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&tegra_car TEGRA124_CLK_TSENSOR>,
+   <&tegra_car TEGRA124_CLK_SOC_THERM>;
+   clock-names = "tsensor", "soctherm";
+   resets = <&tegra_car 78>;
+   reset-names = "soctherm";
+
+   #thermal-sensor-cells = <1>;
+   };
diff --git a/include/dt-bindings/thermal/tegra124-soctherm.h 
b/include/dt-bindings/thermal/tegra124-soctherm.h
new file mode 100644
index 000..cbef15d
--- /dev/null
+++ b/include/dt-bindings/thermal/tegra124-soctherm.h
@@ -0,0 +1,15 @@
+/*
+ * This header provides constants for binding nvidia,tegra124-soctherm.
+ */
+
+#ifndef _DT_BINDINGS_THERMAL_TEGRA124_SOCTHERM_H
+#define _DT_BINDINGS_THERMAL_TEGRA124_SOCTHERM_H
+
+#define TEGRA124_SOCTHERM_SENSOR_CPU 0
+#define TEGRA124_SOCTHERM_SENSOR_MEM 1
+#define TEGRA124_SOCTHERM_SENSOR_GPU 2
+#define TEGRA124_SOCTHERM_SENSOR_PLLX 3
+
+#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 0/5] Improve sequential read throughput v3

[Mel Gorman]

Changelog since V2
o Simply fair zone policy cost reduction
o Drop CFQ patch

Changelog since v1
o Rebase to v3.16-rc2
o Move CFQ patch to end of series where it can be rejected easier if necessary
o Introduce page-reclaim related patch related to kswapd/fairzone interactions
o Rework fast zone policy patch

IO performance since 3.0 has been a mixed bag. In many respects we are
better and in some we are worse and one of those places is sequential
read throughput. This is visible in a number of benchmarks but I looked
at tiobench the closest. This is using ext3 on a mid-range desktop and
the series applied.

  3.16.0-rc23.16.0-rc2
 vanilla lessdirty
MinSeqRead-MB/sec-1 120.92 (  0.00%)  140.73 ( 16.38%)
MinSeqRead-MB/sec-2 100.25 (  0.00%)  117.43 ( 17.14%)
MinSeqRead-MB/sec-4  96.27 (  0.00%)  109.01 ( 13.23%)
MinSeqRead-MB/sec-8  83.55 (  0.00%)   90.86 (  8.75%)
MinSeqRead-MB/sec-16 66.77 (  0.00%)   74.12 ( 11.01%)

Overall system CPU usage is reduced

  3.16.0-rc2  3.16.0-rc2
 vanilla lessdirty-v3
User  390.13  390.20
System404.41  379.08
Elapsed  5412.45 5123.74

This series does not fully restore throughput performance to 3.0 levels
but it brings it close for lower thread counts. Higher thread counts are
known to be worse than 3.0 due to CFQ changes but there is no appetite
for changing the defaults there.

 include/linux/mmzone.h | 210 ++---
 include/linux/writeback.h  |   1 +
 include/trace/events/pagemap.h |  16 ++--
 mm/internal.h  |   1 +
 mm/mm_init.c   |   4 +-
 mm/page-writeback.c|  23 +++--
 mm/page_alloc.c| 173 -
 mm/swap.c  |   4 +-
 mm/vmscan.c|  16 ++--
 mm/vmstat.c|   4 +-
 10 files changed, 258 insertions(+), 194 deletions(-)

-- 
1.8.4.5

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

[PATCH 5/5] mm: page_alloc: Reduce cost of dirty zone balancing

[Mel Gorman]

When allocating a page cache page for writing the allocator makes an attempt
to proportionally distribute dirty pages between populated zones. The call
to zone_dirty_ok is more expensive than expected because of the number of
vmstats it examines. This patch caches some of that information to reduce
the cost. It means the proportional allocation is based on stale data but
the heuristic should not need perfectly accurate information. As before,
the benefit is marginal but cumulative and depends on the size of the
machine. For a very small machine the effect is visible in system CPU time
for a tiobench test but it'll vary between workloads.

  3.16.0-rc2  3.16.0-rc2
fairzone   lessdirty
User  393.76  389.03
System391.50  388.64
Elapsed  5182.86 5186.28

Even though the benefit is small it's generally worthwhile reducing overhead
in the page allocator as it has a tendency to creep up over time.

Signed-off-by: Mel Gorman 
---
 include/linux/mmzone.h|  2 ++
 include/linux/writeback.h |  1 +
 mm/internal.h |  1 +
 mm/page-writeback.c   | 23 +++
 mm/page_alloc.c   | 16 
 5 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index f7f93d4..cd7a3d4 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -480,6 +480,8 @@ struct zone {
/* zone flags, see below */
unsigned long   flags;
 
+   unsigned long   dirty_limit_cached;
+
ZONE_PADDING(_pad2_)
 
/* Write-intensive fields used by page reclaim */
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index 5777c13..90190d4 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -121,6 +121,7 @@ static inline void laptop_sync_completion(void) { }
 #endif
 void throttle_vm_writeout(gfp_t gfp_mask);
 bool zone_dirty_ok(struct zone *zone);
+unsigned long zone_dirty_limit(struct zone *zone);
 
 extern unsigned long global_dirty_limit;
 
diff --git a/mm/internal.h b/mm/internal.h
index 7f22a11f..f31e3b2 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -370,5 +370,6 @@ unsigned long reclaim_clean_pages_from_list(struct zone 
*zone,
 #define ALLOC_CPUSET   0x40 /* check for correct cpuset */
 #define ALLOC_CMA  0x80 /* allow allocations from CMA areas */
 #define ALLOC_FAIR 0x100 /* fair zone allocation */
+#define ALLOC_DIRTY0x200 /* spread GFP_WRITE allocations */
 
 #endif /* __MM_INTERNAL_H */
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 518e2c3..a7d11b1 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -256,8 +256,6 @@ static unsigned long global_dirtyable_memory(void)
  * Calculate the dirty thresholds based on sysctl parameters
  * - vm.dirty_background_ratio  or  vm.dirty_background_bytes
  * - vm.dirty_ratio or  vm.dirty_bytes
- * The dirty limits will be lifted by 1/4 for PF_LESS_THROTTLE (ie. nfsd) and
- * real-time tasks.
  */
 void global_dirty_limits(unsigned long *pbackground, unsigned long *pdirty)
 {
@@ -298,10 +296,9 @@ void global_dirty_limits(unsigned long *pbackground, 
unsigned long *pdirty)
  * Returns the maximum number of dirty pages allowed in a zone, based
  * on the zone's dirtyable memory.
  */
-static unsigned long zone_dirty_limit(struct zone *zone)
+unsigned long zone_dirty_limit(struct zone *zone)
 {
unsigned long zone_memory = zone_dirtyable_memory(zone);
-   struct task_struct *tsk = current;
unsigned long dirty;
 
if (vm_dirty_bytes)
@@ -310,9 +307,6 @@ static unsigned long zone_dirty_limit(struct zone *zone)
else
dirty = vm_dirty_ratio * zone_memory / 100;
 
-   if (tsk->flags & PF_LESS_THROTTLE || rt_task(tsk))
-   dirty += dirty / 4;
-
return dirty;
 }
 
@@ -325,7 +319,20 @@ static unsigned long zone_dirty_limit(struct zone *zone)
  */
 bool zone_dirty_ok(struct zone *zone)
 {
-   unsigned long limit = zone_dirty_limit(zone);
+   unsigned long limit = zone->dirty_limit_cached;
+   struct task_struct *tsk = current;
+
+   /*
+* The dirty limits are lifted by 1/4 for PF_LESS_THROTTLE (ie. nfsd)
+* and real-time tasks to prioritise their allocations.
+* PF_LESS_THROTTLE tasks may be cleaning memory and rt tasks may be
+* blocking tasks that can clean pages.
+*/
+   if (tsk->flags & PF_LESS_THROTTLE || rt_task(tsk)) {
+   limit = zone_dirty_limit(zone);
+   zone->dirty_limit_cached = limit;
+   limit += limit / 4;
+   }
 
return zone_page_state(zone, NR_FILE_DIRTY) +
   zone_page_state(zone, NR_UNSTABLE_NFS) +
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d2ed2e0..cf8e858 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1941,9 +1941,7 @@ get_page_from_freelist(gfp_t gfp_mask, nodemask

Get a loan in 24 hours at 2% interest rate

[Liu Chang]

I am Liu Chang, can you work with me on a business proposal that worth 
$15Million Dollars? for
 more info contact me with my email: liuchan...@foxmail.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 4/5] mm: page_alloc: Reduce cost of the fair zone allocation policy

[Mel Gorman]

The fair zone allocation policy round-robins allocations between zones
within a node to avoid age inversion problems during reclaim. If the
first allocation fails, the batch counts is reset and a second attempt
made before entering the slow path.

One assumption made with this scheme is that batches expire at roughly the
same time and the resets each time are justified. This assumption does not
hold when zones reach their low watermark as the batches will be consumed
at uneven rates.  Allocation failure due to watermark depletion result in
additional zonelist scans for the reset and another watermark check before
hitting the slowpath.

This patch makes a number of changes that should reduce the overall cost

o Do not apply the fair zone policy to small zones such as DMA
o Abort the fair zone allocation policy once remote or small zones are
  encountered
o Use a simplier scan when resetting NR_ALLOC_BATCH
o Use a simple flag to identify depleted zones instead of accessing a
  potentially write-intensive cache line for counters
o Track zones who met the watermark but failed the NR_ALLOC_BATCH check
  to avoid doing a rescan of the zonelist when the counters are reset

On UMA machines, the effect is marginal. Even judging from system CPU
usage it's small for the tiobench test

  3.16.0-rc2  3.16.0-rc2
checklowfairzone
User  396.24  396.23
System395.23  391.50
Elapsed  5182.65 5165.49

And the number of pages allocated from each zone is comparable

3.16.0-rc2  3.16.0-rc2
  checklowfairzone
DMA allocs   0   0
DMA32 allocs   7374217 7920241
Normal allocs999277551   996568115

On NUMA machines, the scanning overhead is higher as zones are scanned
that are ineligible for use by zone allocation policy. This patch fixes
the zone-order zonelist policy and reduces the numbers of zones scanned
by the allocator.

Signed-off-by: Mel Gorman 
---
 include/linux/mmzone.h |   7 +++
 mm/mm_init.c   |   4 +-
 mm/page_alloc.c| 146 +
 3 files changed, 96 insertions(+), 61 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index a2f6443..f7f93d4 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -534,6 +534,7 @@ typedef enum {
ZONE_WRITEBACK, /* reclaim scanning has recently found
 * many pages under writeback
 */
+   ZONE_FAIR_DEPLETED, /* fair zone policy batch depleted */
 } zone_flags_t;
 
 static inline void zone_set_flag(struct zone *zone, zone_flags_t flag)
@@ -571,6 +572,11 @@ static inline int zone_is_reclaim_locked(const struct zone 
*zone)
return test_bit(ZONE_RECLAIM_LOCKED, &zone->flags);
 }
 
+static inline int zone_is_fair_depleted(const struct zone *zone)
+{
+   return test_bit(ZONE_FAIR_DEPLETED, &zone->flags);
+}
+
 static inline int zone_is_oom_locked(const struct zone *zone)
 {
return test_bit(ZONE_OOM_LOCKED, &zone->flags);
@@ -716,6 +722,7 @@ struct zoneref {
 struct zonelist {
struct zonelist_cache *zlcache_ptr;  // NULL or &zlcache
struct zoneref _zonerefs[MAX_ZONES_PER_ZONELIST + 1];
+   bool fair_enabled;  /* eligible for fair zone policy */
 #ifdef CONFIG_NUMA
struct zonelist_cache zlcache;   // optional ...
 #endif
diff --git a/mm/mm_init.c b/mm/mm_init.c
index 4074caf..27ef4fa 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -47,9 +47,9 @@ void mminit_verify_zonelist(void)
continue;
 
/* Print information about the zonelist */
-   printk(KERN_DEBUG "mminit::zonelist %s %d:%s = ",
+   printk(KERN_DEBUG "mminit::zonelist %s %d:%s(%s) = ",
listid > 0 ? "thisnode" : "general", nid,
-   zone->name);
+   zone->name, zonelist->fair_enabled ? "F" : "");
 
/* Iterate the zonelist */
for_each_zone_zonelist(zone, z, zonelist, zoneid) {
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ebbdbcd..d2ed2e0 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1544,7 +1544,7 @@ int split_free_page(struct page *page)
 static inline
 struct page *buffered_rmqueue(struct zone *preferred_zone,
struct zone *zone, unsigned int order,
-   gfp_t gfp_flags, int migratetype)
+   gfp_t gfp_flags, int migratetype, bool acct_fair)
 {
unsigned long flags;
struct page *page;
@@ -1596,7 +1596,11 @@ again:
  get_freepage_migratetype(page));
}
 
-   __mod_zone_page_state(zone, NR_ALLOC_BA

Re: [RFC 04/10] memory: Add Tegra124 memory controller support

[Thierry Reding]

On Fri, Jun 27, 2014 at 03:41:20PM +0800, Joseph Lo wrote:
> Hi Thierry,
> 
> On 06/27/2014 04:49 AM, Thierry Reding wrote:
> [snip]
> >+
> >+#define MC_INTSTATUS 0x000
> >+#define  MC_INT_DECERR_MTS (1 << 16)
> >+#define  MC_INT_SECERR_SEC (1 << 13)
> >+#define  MC_INT_DECERR_VPR (1 << 12)
> >+#define  MC_INT_INVALID_APB_ASID_UPDATE (1 << 11)
> >+#define  MC_INT_INVALID_SMMU_PAGE (1 << 10)
> >+#define  MC_INT_ARBITRATION_EMEM (1 << 9)
> >+#define  MC_INT_SECURITY_VIOLATION (1 << 8)
> >+#define  MC_INT_DECERR_EMEM (1 << 6)
> >+#define MC_INTMASK 0x004
> >+#define MC_ERR_STATUS 0x08
> >+#define MC_ERR_ADR 0x0c
> >+
> [snip]
> >+
> >+#define SMMU_PDE_ATTR  (SMMU_PDE_READABLE | SMMU_PDE_WRITABLE | \
> >+SMMU_PDE_NONSECURE)
> >+#define SMMU_PTE_ATTR  (SMMU_PTE_READABLE | SMMU_PTE_WRITABLE | \
> >+SMMU_PTE_NONSECURE)
> >+
> >+#define SMMU_PDE_VACANT(n) (((n) << 10) | SMMU_PDE_ATTR)
> >+#define SMMU_PTE_VACANT(n) (((n) << 12) | SMMU_PTE_ATTR)
> 
> There is an ISR to catch the invalid SMMU translation. Do you want to modify
> the identity mapping with read/write attribute of the unused SMMU pages?

I'm not sure I understand what you mean by "identity mapping". None of
the public documentation seems to describe the exact layout of PDEs or
PTEs, so it's somewhat hard to tell what to set them to when pages are
unmapped.

> This can make sure we capture the invalid SMMU translation. And helps for
> driver to capture issues when using SMMU.

That certainly sounds like a useful thing to have. Like I said this is
an RFC and I'm not even sure if it's acceptable in the current form, so
I wanted to get feedback early on to avoid wasting effort on something
that turn out to be a wild-goose chase.

Thierry


pgptxXgo1eel4.pgp
Description: PGP signature

[PATCH 3/5] mm: vmscan: Do not reclaim from lower zones if they are balanced

[Mel Gorman]

Historically kswapd scanned from DMA->Movable in the opposite direction
to the page allocator to avoid allocating behind kswapd direction of
progress. The fair zone allocation policy altered this in a non-obvious
manner.

Traditionally, the page allocator prefers to use the highest eligible zone
until the watermark is depleted, woke kswapd and moved onto the next zone.
kswapd scans zones in the opposite direction so the scanning lists on
64-bit look like this;

Page alloc  Kswapd
--  --
Movable DMA
Normal  DMA32
DMA32   Normal
DMA Movable

If kswapd scanned in the same direction as the page allocator then it is
possible that kswapd would proportionally reclaim the lower zones that
were never used as the page allocator was always allocating behind the
reclaim. This would work as follows

pgalloc hits Normal low wmark
kswapd reclaims Normal
kswapd reclaims DMA32
pgalloc hits Normal low wmark
kswapd reclaims Normal
kswapd reclaims DMA32

The introduction of the fair zone allocation policy fundamentally altered
this problem by interleaving between zones until the low watermark is
reached. There are at least two issues with this

o The page allocator can allocate behind kswapds progress (scans/reclaims
  lower zone and fair zone allocation policy then uses those pages)
o When the low watermark of the high zone is reached there may recently
  allocated pages allocated from the lower zone but as kswapd scans
  dma->highmem to the highest zone needing balancing it'll reclaim the
  lower zone even if it was balanced.

Let N = high_wmark(Normal) + high_wmark(DMA32). Of the last N allocations,
some percentage will be allocated from Normal and some from DMA32. The
percentage depends on the ratio of the zone sizes and when their watermarks
were hit. If Normal is unbalanced, DMA32 will be shrunk by kswapd. If DMA32
is unbalanced only DMA32 will be shrunk. This leads to a difference of
ages between DMA32 and Normal. Relatively young pages are then continually
rotated and reclaimed from DMA32 due to the higher zone being unbalanced.
Some of these pages may be recently read-ahead pages requiring that the page
be re-read from disk and impacting overall performance.

The problem is fundamental to the fact we have per-zone LRU and allocation
policies and ideally we would only have per-node allocation and LRU lists.
This would avoid the need for the fair zone allocation policy but the
low-memory-starvation issue would have to be addressed again from scratch.

This patch will only scan/reclaim from lower zones if they have not
reached their watermark. This should not break the normal page aging
as the proportional allocations due to the fair zone allocation policy
should compensate.

tiobench was used to evaluate this because it includes a simple
sequential reader which is the most obvious regression. It also has threaded
readers that produce reasonably steady figures.

  3.16.0-rc23.16.0-rc2  
   3.0.0
 vanillachecklow-v2r14  
 vanilla
MinSeqRead-MB/sec-1 120.96 (  0.00%)  140.63 ( 16.26%)  
134.04 ( 10.81%)
MinSeqRead-MB/sec-2 100.73 (  0.00%)  117.95 ( 17.10%)  
120.76 ( 19.88%)
MinSeqRead-MB/sec-4  96.05 (  0.00%)  109.54 ( 14.04%)  
114.49 ( 19.20%)
MinSeqRead-MB/sec-8  82.46 (  0.00%)   88.22 (  6.99%)   
98.04 ( 18.89%)
MinSeqRead-MB/sec-16 66.37 (  0.00%)   69.14 (  4.17%)   
79.49 ( 19.77%)
Mean   RandWrite-MB/sec-161.34 (  0.00%)1.34 (  0.00%)
1.34 (  0.25%)

It was also tested against xfs and there are similar gains. There are
still regressions for higher number of threads but this is related to
changes in the CFQ IO scheduler.

Signed-off-by: Mel Gorman 
---
 mm/vmscan.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 0f16ffe..40c3af8 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3124,12 +3124,13 @@ static unsigned long balance_pgdat(pg_data_t *pgdat, 
int order,
 
/*
 * Now scan the zone in the dma->highmem direction, stopping
-* at the last zone which needs scanning.
-*
-* We do this because the page allocator works in the opposite
-* direction.  This prevents the page allocator from allocating
-* pages behind kswapd's direction of progress, which would
-* cause too much scanning of the lower zones.
+* at the last zone which needs scanning. We do this because
+* the page al

Re: [PATCH] mfd: cros_ec_spi: set wakeup capability

[Lee Jones]

On Thu, 26 Jun 2014, Olof Johansson wrote:

> On Mon, Jun 23, 2014 at 2:26 AM, Lee Jones  wrote:
> >> Lee (-others),
> >
> > Re-CC'ing the list.
> >
> >> On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones  wrote:
> >> >> From: Prathyush K 
> >> >>
> >> >> Set the device as wakeup capable and register the wakeup source.
> >> >>
> >> >> Note: Though it makes more sense to have the SPI framework do this,
> >> >> (either via device tree or by board_info)
> >> >> this change is as per an existing mail chain:
> >> >> https://lkml.org/lkml/2009/8/27/291
> >> >>
> >> >> Signed-off-by: Prathyush K 
> >> >> Signed-off-by: Doug Anderson 
> >> >> ---
> >> >> Note that I don't have suspend/resume actually working upstream, but I
> >> >> see that /sys/bus/spi/drivers/cros-ec-spi/spi2.0/power/wakeup exists
> >> >> with this patch and doesn't exist without it.
> >> >
> >> > Very well.  Applied, thanks.
> >>
> >> Thanks for applying!  ...did this go in some non-standard branch?  I
> >> see another of my patches got committed to your "for-mfd-next" tree on
> >> the 19th but I don't see this one...
> >
> > Patience Grasshopper.  When I say that it's applied, it means that I
> > have done so locally only.  After I've collected a few local patches
> > I'll usually then fix them all with with my SoB and push them out to
> > the public MFD tree.
> >
> > BTW, it's always best to leave the ML in as CC, so others can see the
> > answer to these types of questions.  It may save a few emails a year,
> > but every little helps. :)
> 
> It's great to see this on the list, because I find your workflow as a
> maintainer to be hard to follow as a developer.
> 
> You applying patches but taking several days to push out makes it
> completely opaque for someone to know if you just accidentally missed
> to apply the patch after all (it happens, I've done that myself). It's
> pretty common to expect a "thanks, applied" patch to show up in
> linux-next within one day or so depending on timing.
> 
> The fact that you had already pushed out a patch that you had replied
> to even later makes for extra confusion. So I'm sorry Lee, but I don't
> think Doug was unreasonable in asking for status here. Sometimes
> maintainers forget to push, which is why it's a good idea to ping a
> few days later if the patch hasn't showed up in -next.

I completely understand and even empathise with the predicament of a
diligent developer.  What you see above isn't me being cantankerous,
but rather an explanation how things are handed in the MFD tree.

Taking into consideration my current workload and time constraints,
the work-flow used is the best I can muster currently.  Lest we forget,
this isn't the role for what I'm employed, I do this on-top of my
daily tasks using time accumulated by starting early and finishing
late _every day_.

Building, testing and pushing after every patch, hell even on a daily
basis would be difficult to sustain without it impacting my _proper_
work.  What I need to do is write some more scripts which will help to
relieve some of the burden, but again time is notable factor here.

>From a personal point of view, I prefer to be on top of the patches
as they come in and have some lead time from when they are applied
locally to finding their way into -next (bearing in mind that this
lead time is seldom more than 24-48hrs), rather than do what others do
and leave patches hanging on the list for weeks, then gather enough
time to review, collect, test and push all in one session. 

A quick aside; given the state of maintainership in some of the other
subsystems, I'm surprised that we're even having this conversation
considering how responsive we are in MFD.

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

Re: [PATCH v2 1/3] cgroup: fix mount failure in a corner case

[Li Zefan]

Oh sorry the cut&paste was incomplete. Here's the complete one:



From: Li Zefan 
Date: Thu, 12 Jun 2014 09:11:00 +0800
Subject: [PATCH v2 1/3] cgroup: fix mount failure in a corner case

  # cat test.sh
  #! /bin/bash

  mount -t cgroup -o cpu xxx /cgroup
  umount /cgroup

  mount -t cgroup -o cpu,cpuacct xxx /cgroup
  umount /cgroup
  # ./test.sh
  mount: xxx already mounted or /cgroup busy
  mount: according to mtab, xxx is already mounted on /cgroup

It's because the cgroupfs_root of the first mount was under destruction
asynchronously.

Fix this by delaying and then retrying mount for this case.

v2:
- use percpu_ref_tryget_live() rather that introducing
  percpu_ref_alive(). (Tejun)
- adjust comment.

Signed-off-by: Li Zefan 
---
 kernel/cgroup.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 1c65f24..6826227 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1648,10 +1648,12 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
 int flags, const char *unused_dev_name,
 void *data)
 {
+   struct cgroup_subsys *ss;
struct cgroup_root *root;
struct cgroup_sb_opts opts;
struct dentry *dentry;
int ret;
+   int i, j = -1;
bool new_sb;
 
/*
@@ -1677,6 +1679,25 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
goto out_unlock;
}
 
+   /*
+* Destruction of cgroup root is asynchronous, so we may fail to
+* mount a cgroupfs if it immediately follows a umount. Let's wait
+* a little bit and retry.
+*/
+   for_each_subsys(ss, i) {
+   if (!(opts.subsys_mask & (1 << i)) ||
+   ss->root === &cgrp_dfl_root)
+   continue;
+
+   if (!percpu_ref_tryget_live(&ss->root->cgrp.self.refcnt)) {
+   mutex_unlock(&cgroup_mutex);
+   msleep(10);
+   ret = restart_syscall();
+   goto out_free;
+   }
+   j = i;
+   }
+
for_each_root(root) {
bool name_match = false;
 
@@ -1763,6 +1784,14 @@ out_free:
kfree(opts.release_agent);
kfree(opts.name);
 
+   for_each_subsys(ss, i) {
+   if (i > j)
+   break;
+   if (!(opts.subsys_mask & (1 << i)))
+   continue;
+   cgroup_put(&ss->root->cgrp);
+   }
+
if (ret)
return ERR_PTR(ret);
 
-- 
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/

[PATCH 1/5] mm: pagemap: Avoid unnecessary overhead when tracepoints are deactivated

[Mel Gorman]

The LRU insertion and activate tracepoints take PFN as a parameter forcing
the overhead to the caller.  Move the overhead to the tracepoint fast-assign
method to ensure the cost is only incurred when the tracepoint is active.

Signed-off-by: Mel Gorman 
---
 include/trace/events/pagemap.h | 16 +++-
 mm/swap.c  |  4 ++--
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/include/trace/events/pagemap.h b/include/trace/events/pagemap.h
index 1c9fabd..ce0803b 100644
--- a/include/trace/events/pagemap.h
+++ b/include/trace/events/pagemap.h
@@ -28,12 +28,10 @@ TRACE_EVENT(mm_lru_insertion,
 
TP_PROTO(
struct page *page,
-   unsigned long pfn,
-   int lru,
-   unsigned long flags
+   int lru
),
 
-   TP_ARGS(page, pfn, lru, flags),
+   TP_ARGS(page, lru),
 
TP_STRUCT__entry(
__field(struct page *,  page)
@@ -44,9 +42,9 @@ TRACE_EVENT(mm_lru_insertion,
 
TP_fast_assign(
__entry->page   = page;
-   __entry->pfn= pfn;
+   __entry->pfn= page_to_pfn(page);
__entry->lru= lru;
-   __entry->flags  = flags;
+   __entry->flags  = trace_pagemap_flags(page);
),
 
/* Flag format is based on page-types.c formatting for pagemap */
@@ -64,9 +62,9 @@ TRACE_EVENT(mm_lru_insertion,
 
 TRACE_EVENT(mm_lru_activate,
 
-   TP_PROTO(struct page *page, unsigned long pfn),
+   TP_PROTO(struct page *page),
 
-   TP_ARGS(page, pfn),
+   TP_ARGS(page),
 
TP_STRUCT__entry(
__field(struct page *,  page)
@@ -75,7 +73,7 @@ TRACE_EVENT(mm_lru_activate,
 
TP_fast_assign(
__entry->page   = page;
-   __entry->pfn= pfn;
+   __entry->pfn= page_to_pfn(page);
),
 
/* Flag format is based on page-types.c formatting for pagemap */
diff --git a/mm/swap.c b/mm/swap.c
index 9e8e347..d10be45 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -501,7 +501,7 @@ static void __activate_page(struct page *page, struct 
lruvec *lruvec,
SetPageActive(page);
lru += LRU_ACTIVE;
add_page_to_lru_list(page, lruvec, lru);
-   trace_mm_lru_activate(page, page_to_pfn(page));
+   trace_mm_lru_activate(page);
 
__count_vm_event(PGACTIVATE);
update_page_reclaim_stat(lruvec, file, 1);
@@ -996,7 +996,7 @@ static void __pagevec_lru_add_fn(struct page *page, struct 
lruvec *lruvec,
SetPageLRU(page);
add_page_to_lru_list(page, lruvec, lru);
update_page_reclaim_stat(lruvec, file, active);
-   trace_mm_lru_insertion(page, page_to_pfn(page), lru, 
trace_pagemap_flags(page));
+   trace_mm_lru_insertion(page, lru);
 }
 
 /*
-- 
1.8.4.5

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

Re: [PATCH] iommu: Constify struct iommu_ops

[Thierry Reding]

On Thu, Jun 26, 2014 at 09:04:54PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> This structure is read-only data and should never be modified.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/iommu/amd_iommu.c   |  4 ++--
>  drivers/iommu/arm-smmu.c|  2 +-
>  drivers/iommu/exynos-iommu.c|  2 +-
>  drivers/iommu/fsl_pamu_domain.c |  2 +-
>  drivers/iommu/intel-iommu.c |  4 ++--
>  drivers/iommu/iommu.c   | 19 ++-
>  drivers/iommu/ipmmu-vmsa.c  |  2 +-
>  drivers/iommu/msm_iommu.c   |  2 +-
>  drivers/iommu/omap-iommu.c  |  2 +-
>  drivers/iommu/shmobile-iommu.c  |  2 +-
>  drivers/iommu/tegra-gart.c  |  2 +-
>  drivers/iommu/tegra-smmu.c  |  2 +-
>  include/linux/iommu.h   |  4 ++--
>  13 files changed, 29 insertions(+), 20 deletions(-)

I noticed that this patch is missing a hunk to include/linux/device.h
and I've sent a v2 to address this. Apologies for the noise.

Thierry


pgpTSrNejTWYk.pgp
Description: PGP signature

[PATCH 2/5] mm: Rearrange zone fields into read-only, page alloc, statistics and page reclaim lines

[Mel Gorman]

The arrangement of struct zone has changed over time and now it has reached the
point where there is some inappropriate sharing going on. On x86-64 for example

o The zone->node field is shared with the zone lock and zone->node is accessed
  frequently from the page allocator due to the fair zone allocation policy.
o span_seqlock is almost never used by shares a line with free_area
o Some zone statistics share a cache line with the LRU lock so reclaim-intensive
  and allocator-intensive workloads can bounce the cache line on a stat update

This patch rearranges struct zone to put read-only and read-mostly fields
together and then splits the page allocator intensive fields, the zone
statistics and the page reclaim intensive fields into their own cache
lines. Note that arguably the biggest change is reducing the size of the
lowmem_reserve type. It should still be large enough but by shrinking it
the fields used by the page allocator fast path all fit in one cache line.

On the test configuration I used the overall size of struct zone shrunk
by one cache line.

Signed-off-by: Mel Gorman 
---
 include/linux/mmzone.h | 201 +
 mm/page_alloc.c|  13 ++--
 mm/vmstat.c|   4 +-
 3 files changed, 113 insertions(+), 105 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 6cbd1b6..a2f6443 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -324,19 +324,12 @@ enum zone_type {
 #ifndef __GENERATING_BOUNDS_H
 
 struct zone {
-   /* Fields commonly accessed by the page allocator */
+   /* Read-mostly fields */
 
/* zone watermarks, access with *_wmark_pages(zone) macros */
unsigned long watermark[NR_WMARK];
 
/*
-* When free pages are below this point, additional steps are taken
-* when reading the number of free pages to avoid per-cpu counter
-* drift allowing watermarks to be breached
-*/
-   unsigned long percpu_drift_mark;
-
-   /*
 * We don't know if the memory that we're going to allocate will be 
freeable
 * or/and it will be released eventually, so to avoid totally wasting 
several
 * GB of ram we must reserve some of the lower zone memory (otherwise 
we risk
@@ -344,41 +337,17 @@ struct zone {
 * on the higher zones). This array is recalculated at runtime if the
 * sysctl_lowmem_reserve_ratio sysctl changes.
 */
-   unsigned long   lowmem_reserve[MAX_NR_ZONES];
-
-   /*
-* This is a per-zone reserve of pages that should not be
-* considered dirtyable memory.
-*/
-   unsigned long   dirty_balance_reserve;
+   unsigned int lowmem_reserve[MAX_NR_ZONES];
 
+   struct per_cpu_pageset __percpu *pageset;
 #ifdef CONFIG_NUMA
int node;
-   /*
-* zone reclaim becomes active if more unmapped pages exist.
-*/
-   unsigned long   min_unmapped_pages;
-   unsigned long   min_slab_pages;
 #endif
-   struct per_cpu_pageset __percpu *pageset;
/*
-* free areas of different sizes
+* The target ratio of ACTIVE_ANON to INACTIVE_ANON pages on
+* this zone's LRU.  Maintained by the pageout code.
 */
-   spinlock_t  lock;
-#if defined CONFIG_COMPACTION || defined CONFIG_CMA
-   /* Set to true when the PG_migrate_skip bits should be cleared */
-   boolcompact_blockskip_flush;
-
-   /* pfn where compaction free scanner should start */
-   unsigned long   compact_cached_free_pfn;
-   /* pfn where async and sync compaction migration scanner should start */
-   unsigned long   compact_cached_migrate_pfn[2];
-#endif
-#ifdef CONFIG_MEMORY_HOTPLUG
-   /* see spanned/present_pages for more description */
-   seqlock_t   span_seqlock;
-#endif
-   struct free_areafree_area[MAX_ORDER];
+   unsigned int inactive_ratio;
 
 #ifndef CONFIG_SPARSEMEM
/*
@@ -388,74 +357,37 @@ struct zone {
unsigned long   *pageblock_flags;
 #endif /* CONFIG_SPARSEMEM */
 
-#ifdef CONFIG_COMPACTION
/*
-* On compaction failure, 1> PAGE_SHIFT */
unsigned long   zone_start_pfn;
 
@@ -504,16 +436,89 @@ struct zone {
unsigned long   present_pages;
unsigned long   managed_pages;
 
+#ifdef CONFIG_MEMORY_HOTPLUG
+   /* see spanned/present_pages for more description */
+   seqlock_t   span_seqlock;
+#endif
+
/*
-* Number of MIGRATE_RESEVE page block. To maintain for just
-* optimization. Protected by zone->lock.
+* wait_table   -- the array holding the hash table
+* wai

RE: [PATCH v2] USB: ehci-pci: USB host controller support for Intel Quark X1000

[Chen, Alvin]

> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Friday, June 27, 2014 4:08 PM
> ...
> > /* The maximal threshold value is 0x80, which means 512 bytes */
> > #define EHCI_THRESHOLD_512BYTES 0x80
> > #define EHCI_THRESHOLD_508BYTES 0x79
> 
> It would be better to define these using expressions. So:
> #define EHCI_THRESHOLD_512BYTES   (512u / 8u)
> #define EHCI_THRESHOLD_508BYTES   (508u / 8u)
> 
Just to clarify, the threshold value set to register is in dword, so '0x80' 
means 0x80 dwords (512 bytes), and 508 bytes is not 0x79, it is 0x7F.

> Then you might decide to use:
> #define EHCI_THRESHOLD(size) ((size) / 8u)
> 
> Then realise that the names are not generic EHCI, so need some driver-specific
> prefix (for namespace reasons).
> 
How about the following?
#define INTEL_QUARK_X1000_EHCI_THRESHOLD(size) ((size) / 4u)  /* threshold 
value is in dword*/

> And that the defines are probably limit values, and should be named as such.
> 
>   David
> 
> 

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

Re: [PATCH v2 7/9] regulator: palmas: Add palmas_pmic_driver_data structure

[Lee Jones]

On Wed, 18 Jun 2014, Keerthy wrote:

> Add palmas_pmic_driver_data structure.
> 
> Signed-off-by: Keerthy 
> ---
>  include/linux/mfd/palmas.h |   25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
> index 0136e58..1a045ba 100644
> --- a/include/linux/mfd/palmas.h
> +++ b/include/linux/mfd/palmas.h
> @@ -53,6 +53,8 @@ struct palmas_pmic;
>  struct palmas_gpadc;
>  struct palmas_resource;
>  struct palmas_usb;
> +struct palmas_pmic_driver_data;
> +struct palmas_pmic_platform_data;

Are you sure all of these forward declarations are required?  I'd
prefer that you re-ordered the header file, rather than have them all
looming here.

>  enum palmas_usb_state {
>   PALMAS_USB_STATE_DISCONNECT,
> @@ -76,6 +78,8 @@ struct palmas {
>   struct mutex irq_lock;
>   struct regmap_irq_chip_data *irq_data;
>  
> + struct palmas_pmic_driver_data *pmic_ddata;
> +
>   /* Child Devices */
>   struct palmas_pmic *pmic;
>   struct palmas_gpadc *gpadc;
> @@ -107,6 +111,27 @@ struct regs_info {
>   int sleep_id;
>  };
>  
> +struct palmas_pmic_driver_data {
> + int smps_start;
> + int smps_end;
> + int ldo_begin;
> + int ldo_end;
> + int max_reg;
> + struct regs_info *palmas_regs_info;
> + struct of_regulator_match *palmas_matches;
> + struct palmas_sleep_requestor_info *sleep_req_info;
> + int (*smps_register)(struct palmas_pmic *pmic,
> +  struct palmas_pmic_driver_data *ddata,
> +  struct palmas_pmic_platform_data *pdata,
> +  const char *pdev_name,
> +  struct regulator_config config);
> + int (*ldo_register)(struct palmas_pmic *pmic,
> + struct palmas_pmic_driver_data *ddata,
> + struct palmas_pmic_platform_data *pdata,
> + const char *pdev_name,
> + struct regulator_config config);
> +};
> +
>  struct palmas_gpadc_platform_data {
>   /* Channel 3 current source is only enabled during conversion */
>   int ch3_current;

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

Re: [PATCH 07/22] media: Use pci_zalloc_consistent

[Hans Verkuil]

Hi Joe,

For the media subsystem:

Acked-by: Hans Verkuil 

Regards,

Hans

On 06/23/2014 03:41 PM, Joe Perches wrote:

Remove the now unnecessary memset too.

Signed-off-by: Joe Perches 
---
  drivers/media/common/saa7146/saa7146_core.c   | 15 ++-
  drivers/media/common/saa7146/saa7146_fops.c   |  5 +++--
  drivers/media/pci/bt8xx/bt878.c   | 16 
  drivers/media/pci/ngene/ngene-core.c  |  7 +++
  drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c | 11 +++
  drivers/media/usb/ttusb-dec/ttusb_dec.c   | 11 +++
  6 files changed, 22 insertions(+), 43 deletions(-)

diff --git a/drivers/media/common/saa7146/saa7146_core.c 
b/drivers/media/common/saa7146/saa7146_core.c
index 34b0d0d..97afee6 100644
--- a/drivers/media/common/saa7146/saa7146_core.c
+++ b/drivers/media/common/saa7146/saa7146_core.c
@@ -421,23 +421,20 @@ static int saa7146_init_one(struct pci_dev *pci, const 
struct pci_device_id *ent
err = -ENOMEM;

/* get memory for various stuff */
-   dev->d_rps0.cpu_addr = pci_alloc_consistent(pci, SAA7146_RPS_MEM,
-   &dev->d_rps0.dma_handle);
+   dev->d_rps0.cpu_addr = pci_zalloc_consistent(pci, SAA7146_RPS_MEM,
+&dev->d_rps0.dma_handle);
if (!dev->d_rps0.cpu_addr)
goto err_free_irq;
-   memset(dev->d_rps0.cpu_addr, 0x0, SAA7146_RPS_MEM);

-   dev->d_rps1.cpu_addr = pci_alloc_consistent(pci, SAA7146_RPS_MEM,
-   &dev->d_rps1.dma_handle);
+   dev->d_rps1.cpu_addr = pci_zalloc_consistent(pci, SAA7146_RPS_MEM,
+&dev->d_rps1.dma_handle);
if (!dev->d_rps1.cpu_addr)
goto err_free_rps0;
-   memset(dev->d_rps1.cpu_addr, 0x0, SAA7146_RPS_MEM);

-   dev->d_i2c.cpu_addr = pci_alloc_consistent(pci, SAA7146_RPS_MEM,
-  &dev->d_i2c.dma_handle);
+   dev->d_i2c.cpu_addr = pci_zalloc_consistent(pci, SAA7146_RPS_MEM,
+   &dev->d_i2c.dma_handle);
if (!dev->d_i2c.cpu_addr)
goto err_free_rps1;
-   memset(dev->d_i2c.cpu_addr, 0x0, SAA7146_RPS_MEM);

/* the rest + print status message */

diff --git a/drivers/media/common/saa7146/saa7146_fops.c 
b/drivers/media/common/saa7146/saa7146_fops.c
index eda01bc..a776a80 100644
--- a/drivers/media/common/saa7146/saa7146_fops.c
+++ b/drivers/media/common/saa7146/saa7146_fops.c
@@ -520,14 +520,15 @@ int saa7146_vv_init(struct saa7146_dev* dev, struct 
saa7146_ext_vv *ext_vv)
   configuration data) */
dev->ext_vv_data = ext_vv;

-   vv->d_clipping.cpu_addr = pci_alloc_consistent(dev->pci, SAA7146_CLIPPING_MEM, 
&vv->d_clipping.dma_handle);
+   vv->d_clipping.cpu_addr =
+   pci_zalloc_consistent(dev->pci, SAA7146_CLIPPING_MEM,
+ &vv->d_clipping.dma_handle);
if( NULL == vv->d_clipping.cpu_addr ) {
ERR("out of memory. aborting.\n");
kfree(vv);
v4l2_ctrl_handler_free(hdl);
return -1;
}
-   memset(vv->d_clipping.cpu_addr, 0x0, SAA7146_CLIPPING_MEM);

saa7146_video_uops.init(dev,vv);
if (dev->ext_vv_data->capabilities & V4L2_CAP_VBI_CAPTURE)
diff --git a/drivers/media/pci/bt8xx/bt878.c b/drivers/media/pci/bt8xx/bt878.c
index d0c281f..1176583 100644
--- a/drivers/media/pci/bt8xx/bt878.c
+++ b/drivers/media/pci/bt8xx/bt878.c
@@ -101,28 +101,20 @@ static int bt878_mem_alloc(struct bt878 *bt)
if (!bt->buf_cpu) {
bt->buf_size = 128 * 1024;

-   bt->buf_cpu =
-   pci_alloc_consistent(bt->dev, bt->buf_size,
-&bt->buf_dma);
-
+   bt->buf_cpu = pci_zalloc_consistent(bt->dev, bt->buf_size,
+   &bt->buf_dma);
if (!bt->buf_cpu)
return -ENOMEM;
-
-   memset(bt->buf_cpu, 0, bt->buf_size);
}

if (!bt->risc_cpu) {
bt->risc_size = PAGE_SIZE;
-   bt->risc_cpu =
-   pci_alloc_consistent(bt->dev, bt->risc_size,
-&bt->risc_dma);
-
+   bt->risc_cpu = pci_zalloc_consistent(bt->dev, bt->risc_size,
+&bt->risc_dma);
if (!bt->risc_cpu) {
bt878_mem_free(bt);
return -ENOMEM;
}
-
-   memset(bt->risc_cpu, 0, bt->risc_size);
}

return 0;
diff --git a/drivers/media/pci/ngene/ngene-core.c 
b/drivers/media/pci/ngene/ngene-core.c
index 970e833..37dc149 100644
--- a/drivers/media/

Re: [PATCH PING] VFS: mount must return EACCES, not EROFS

[Philippe De Muyter]

PING

Currently, the initial mount of the root file system by the linux
kernel fails with a cryptic message instead of being retried with
the MS_RDONLY flag set,  when the device is read-only and the
combination of block driver and filesystem driver yields EROFS.

I do not know if POSIX mandates that mount(2) must fail with EACCES, nor
if linux aims to strict compliance with POSIX on that point.  Consensus
amongst the messages that I have read so far seems to show that linux
kernel hackers feel that EROFS is a more appropriate error code than
EACCES in that case.

So, do you choose for my first pragmatic and non-intrusive patch, that
lets mount_block_root() retry with MS_RDONLY if the file system
returns EROFS (https://lkml.org/lkml/2014/6/18/468) or for the second
one that forces all file-systems to return EACCES instead of EROFS.
(https://lkml.org/lkml/2014/6/20/98).

Best regards

Philippe

On Fri, Jun 20, 2014 at 10:39:22AM +0200, Philippe De Muyter wrote:
> mount must return EACCES, not EROFS, when one attempts to mount a
> read-only filesystem in read-write mode, but the file-system layer
> only transmits the error given by the block layer, and many block
> drivers return EROFS in that case, so let's fix it in do_mount.
> 
> Actually it is only a small problem for a user using the mount(1)
> command, because EROFS is actually a more explicit answer than
> EACCES, but init/do_mounts.c checks only for EACCES, not EROFS,
> to decide to retry to mount the root file-system in read-only mode,
> and so we are left with an unbootable kernel, and with a cryptic
> error message (*) if the root partition happens to be read-only
> 
> (*): VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2):
> error -30
> 
> Signed-off-by: Philippe De Muyter 
> Cc: Al Viro 
> Cc: Dave Chinner 
> Cc: Andrew Morton 
> Cc: linux-fsde...@vger.kernel.org
> ---
>  fs/namespace.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 182bc41..6291a3f 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2411,6 +2411,8 @@ long do_mount(const char *dev_name, const char 
> *dir_name,
>  
>   retval = security_sb_mount(dev_name, &path,
>  type_page, flags, data_page);
> + if (retval == -EROFS)
> + retval = -EACCES;
>   if (!retval && !may_mount())
>   retval = -EPERM;
>   if (retval)
> -- 
> 1.7.5.3

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: usbhid: quirk for PM1610 and PM1640 Touchscreen.

[John Sung]

These device needs to be added to the quirks list with HID_QUIRK_NOGET,
otherwise they will reset upon receiving the get input report requests.

Signed-off-by: John Sung 
---
 drivers/hid/hid-ids.h   |2 ++
 drivers/hid/usbhid/hid-quirks.c |2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 7370ae3..37af778 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -715,6 +715,8 @@
 
 #define USB_VENDOR_ID_PENMOUNT 0x14e1
 #define USB_DEVICE_ID_PENMOUNT_PCI 0x3500
+#define USB_DEVICE_ID_PENMOUNT_16100x1610
+#define USB_DEVICE_ID_PENMOUNT_16400x1640
 
 #define USB_VENDOR_ID_PETALYNX 0x18b1
 #define USB_DEVICE_ID_PETALYNX_MAXTER_REMOTE   0x0037
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 13ca192..587d3aa 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -76,6 +76,8 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE, 
HID_QUIRK_NO_INIT_REPORTS },
+   { USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1610, HID_QUIRK_NOGET 
},
+   { USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1640, HID_QUIRK_NOGET 
},
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2, 
HID_QUIRK_NO_INIT_REPORTS },
-- 
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: ext4: total breakdown on USB hdd, 3.0 kernel

[Oliver Neukum]

On Thu, 2014-06-26 at 22:20 +0200, Pavel Machek wrote:
> Hi!
> 
> Ok, this ext4 filesystem does _not_ have easy life: it is in usb
> envelope, I wanted
> to use it as a root filesystem, and it is connected to OLPC-1.75,
> running some kind
> of linux-3.0 kernels.
> 
> So power disconnects are common, and even during regular reboot, I
> hear disk doing
> emergency parking.
> 
> I don't know how barriers work over USB...

Just like with other SCSI devices.

HTH
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/9] regulator: palmas: add driver data and modularize the probe

[Lee Jones]

On Wed, 18 Jun 2014, Keerthy wrote:
> add driver data and modularize the probe.

Nit: This is a sentence, it should start with a capital letter.

> Signed-off-by: Keerthy 
> ---
> 
> Changes in V2:
> 
>   * Fixed the order of variable declarations.
> 
>  drivers/mfd/palmas.c |   44 +--
>  drivers/regulator/palmas-regulator.c |  658 
> --
>  2 files changed, 396 insertions(+), 306 deletions(-)
> 
> diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
> index c12759d..28cb048 100644
> --- a/drivers/mfd/palmas.c
> +++ b/drivers/mfd/palmas.c
> @@ -25,42 +25,6 @@
>  #include 
>  #include 
>  
> -#define EXTERNAL_REQUESTOR(_id, _offset, _pos)   \
> - [PALMAS_EXTERNAL_REQSTR_ID_##_id] = {   \
> - .id = PALMAS_EXTERNAL_REQSTR_ID_##_id,  \
> - .reg_offset = _offset,  \
> - .bit_pos = _pos,\
> - }
> -
> -static struct palmas_sleep_requestor_info sleep_req_info[] = {
> - EXTERNAL_REQUESTOR(REGEN1, 0, 0),
> - EXTERNAL_REQUESTOR(REGEN2, 0, 1),
> - EXTERNAL_REQUESTOR(SYSEN1, 0, 2),
> - EXTERNAL_REQUESTOR(SYSEN2, 0, 3),
> - EXTERNAL_REQUESTOR(CLK32KG, 0, 4),
> - EXTERNAL_REQUESTOR(CLK32KGAUDIO, 0, 5),
> - EXTERNAL_REQUESTOR(REGEN3, 0, 6),
> - EXTERNAL_REQUESTOR(SMPS12, 1, 0),
> - EXTERNAL_REQUESTOR(SMPS3, 1, 1),
> - EXTERNAL_REQUESTOR(SMPS45, 1, 2),
> - EXTERNAL_REQUESTOR(SMPS6, 1, 3),
> - EXTERNAL_REQUESTOR(SMPS7, 1, 4),
> - EXTERNAL_REQUESTOR(SMPS8, 1, 5),
> - EXTERNAL_REQUESTOR(SMPS9, 1, 6),
> - EXTERNAL_REQUESTOR(SMPS10, 1, 7),
> - EXTERNAL_REQUESTOR(LDO1, 2, 0),
> - EXTERNAL_REQUESTOR(LDO2, 2, 1),
> - EXTERNAL_REQUESTOR(LDO3, 2, 2),
> - EXTERNAL_REQUESTOR(LDO4, 2, 3),
> - EXTERNAL_REQUESTOR(LDO5, 2, 4),
> - EXTERNAL_REQUESTOR(LDO6, 2, 5),
> - EXTERNAL_REQUESTOR(LDO7, 2, 6),
> - EXTERNAL_REQUESTOR(LDO8, 2, 7),
> - EXTERNAL_REQUESTOR(LDO9, 3, 0),
> - EXTERNAL_REQUESTOR(LDOLN, 3, 1),
> - EXTERNAL_REQUESTOR(LDOUSB, 3, 2),
> -};
> -

Happy with this, good riddance.

>  static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = 
> {
>   {
>   .reg_bits = 8,
> @@ -365,10 +329,10 @@ static struct regmap_irq_chip tps65917_irq_chip = {
>  int palmas_ext_control_req_config(struct palmas *palmas,
>   enum palmas_external_requestor_id id,  int ext_ctrl, bool enable)
>  {
> + struct palmas_pmic_driver_data *pmic_ddata = palmas->pmic_ddata;
>   int preq_mask_bit = 0;
>   int reg_add = 0;
> - int bit_pos;
> - int ret;
> + int bit_pos, ret;

I don't like this change.

[...]

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

Re: [PATCH v5 03/14] clk: max77686: Add DT include for MAX77686 PMIC clock

[Andreas Färber]

Hi Javier,

Am 27.06.2014 09:53, schrieb Javier Martinez Canillas:
> Hello Andreas,
> 
> On 06/27/2014 09:48 AM, Andreas Färber wrote:
>> Am 26.06.2014 20:15, schrieb Javier Martinez Canillas:
>>> This patch adds a dt-binding include for Maxim 77686
>>> PMIC clock IDs that can be to be shared between the
>>
>> "can be shared"?
>>
> 
> As it should be quite clear right now I'm not a native English speaker.

Guessed so, me neither. But since it's v5 already and no native speaker
pointed it out, I took the liberty to do so while verifying that the
LD02 typo didn't propagate into your bindings documentation (it didn't).

> I meant
> that the header file can be included by both Device Tree source files and the
> max77802 driver.

AFAIU "clock IDs to be shared" and "clock IDs that can be shared" would
both be valid, but above a verb is missing (e.g., "can be used to").

Thanks for your upstreaming efforts, and don't let me discourage you.

Best regards,

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] perf trace: add pagefault statistics

[Stanislav Fomichev]

> Where is it?
>  usleep (19155), 151 events, 84.4%, 0:68 faults, 0.000 msec
  ^^^
  maj:min
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sysctl: Add a feature to drop caches selectively

[Matthias Schniedermeyer]

On 26.06.2014 13:57, Luká? Czerner wrote:

> > So if the authors want to sell this new interface (in whatever form) to
> > the kernel community, they should start with providing a solid use-case,
> > with some more details, explore alternatives and show how the
> > alternatives do not work for them.
> 
> Yes please, let's see some solid use-case for this.

Personally i would want it to verify files after copying them:
Especially while moving files:
- Copy a file
- 
- Verify that it really is correct on stable storage
- Remove original file

Currently i choose either of the 3 ways:
- drop_caches
- umount/mount
- Write more data than memory in machine (Which is only an 
approximnation and you have to verify in the same order the files were 
written, so it is likely that any cache was thrashed in the meantime)

But having a way to selectivly "destory" the cache of a file would make 
this task easier.




-- 

Matthias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

[Will Deacon]

On Thu, Jun 26, 2014 at 08:36:24PM +0100, Alex Williamson wrote:
> On Thu, 2014-06-26 at 19:10 +, Chalamarla, Tirumalesh wrote:
> > Thanks for the clarification Alex, That’s exactly my point, why are we
> > relying on  QEMU or something else to emulate the MSI space when we can
> > directly give access to devices using ITS (of course with a small
> > emulation code).  This way we are also benefited from all ITS services
> > like VCPU migration etc.  
> 
> I have no idea what ITS is.

ITS is the MSI doorbell for GICv3 (ARM's latest interrupt controller).

I agree that we will need an ITS emulation if we want to use MSIs in the
guest, and I believe that Marc (CC'd) had already started thinking about
that.

> > What about non QEMU VFIO users, for example, if I wanted to use VFIO to
> > assign a device to a user process I don't need to depend on QEMU.   I
> > thought this is one of the main goals of vfio to make it independent of
> > hypervisors. 
> 
> Where did QEMU become a requirement?  Maybe I'm missing something in the
> ARM part of the conversation that got chopped off, but this is exactly
> why we have the VFIO/QEMU split that we do.  VFIO provides basic
> virtualization for config space and restricts access to other areas that
> users shouldn't be allowed to change.  QEMU is just one example of a
> userspace VFIO driver.  QEMU takes the decomposed device exposed through
> the VFIO ABI and re-creates a PCI device out of it.  VFIO itself has no
> dependency on QEMU.  Thanks,

I also don't understand the QEMU part here. The MSI emulation would be in
the kernel, just like the GICv2 emulation that we already have. For
userspace drivers, wouldn't you just use eventfd rather than bother with
emulating MSIs?

Finally, the interrupt remapping part is about the SMMU preventing MSI
writes to arbitrary portions of the host address space. The ITS is about
routing interrupts to CPUs.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: rtc/hctosys.c Problem during kernel boot

[Alexander Holler]

Am 23.06.2014 23:36, schrieb John Stultz:

On Sat, Jun 21, 2014 at 6:08 AM, Alexander Holler  wrote:

Am 12.06.2014 01:53, schrieb John Stultz:


You can read some of the previous discussion here:
https://lkml.org/lkml/2013/6/17/533

I'd be very interested in patches to resolve this!



And the silence as response to my repost of my already working patches just
proved that isn't true.


You put in your patches the following:
"Besides discussing possible *real* bugs, I don't care what any person
  (including maintainers) will request. I'm fine with these patches (I'm
  using them since a year) and I don't play remote keyboard or
  patch ping-pong. If someone want changes I suggest he gets responsible
  for them himself and just puts a patch on top of my patches. And in any
  case, feel free to completely ignore these patches."

I've pointed out problems with your patchset earlier, and you refuse
to address them. That's totally your prerogative, and that's fine, but
I don't know how I should respond here.


I've written that because I will not add a totally unnecessary lock in a 
code path which does set the system time. If multiple RTCs do race to 
set the system time, the system was configured wrong and is already 
untrustworthy and a lock inside the kernel won't help. Especially 
because it will not remove the race, and just solve it somehow. And 
that's happen without a lock (which might block or even dead lock if 
done wrong) too.


So if you want a lock there, please add such a patch yourself and be 
responsible for it. I will not do such.



I agree that there is an issue here that your patches try to address,
which needs to be fixed, but I'm hoping John Whitmore might be able to
read the discussion and either rework your patches or write his own to
address the issue without the problems in your patch I pointed out.

I've removed the rest of your anti-maintainer rant here, but I will
say that I do very much understand that the upstream kernel community
process can be frustrating at times. I have myself had to start over
many many times on patches when maintainers request, and sometimes my
patches don't ever make it past the bar for acceptance. So I very much
do see this from both sides, and despite my frustration, I appreciate
that folks are looking over my patches carefully for design and
maintenance issues, because without the high standards, the kernel
code would be in much worse shape.


Unfortunately I really think you believe what you are writing.

But my experience is that even totally silly and very small bugfixes 
like oneliners are discussed to death and do need years to end up in a 
mainline kernel, if they end up there at all.


And it doesn't help if maintainers do request silly things. My 
experience here is that they always will request a change, even for 
perfect patches, just to request something. If a patch contains a 
variable named red, they would request to change it to green and if it 
would have a name green, they would request to change it to red.


So I'm sorry, but in my humble opinion that isn't how a high standard 
does look like. Many request from maintainer are just capriciousness or 
despotism and often maintainers are totally wrong. And discussing with 
them just leads to ignored patches/bugfixes.


Regards,

Alexander Holler

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/14] mfd: max77802: Add DT binding documentation

[Javier Martinez Canillas]

Hello Andreas,

Thanks a lot for your feedback.

On 06/27/2014 10:06 AM, Andreas Färber wrote:
> Am 26.06.2014 20:15, schrieb Javier Martinez Canillas:
>> Add Device Tree binding documentation for Maxim 77802 PMIC.
>> 
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>> 
>> Changes since v4: None
>> 
>> Changes since v3: None
>> 
>> Changes since v2:
>>  - Explain better the Dynamic Voltage Scaling (DVS) support in some Buck
>>regulators and the max77802,pmic-buck-{dvs,selb}-gpios properties.
>>Suggested by Mark Brown.
>> 
>>  Documentation/devicetree/bindings/mfd/max77802.txt | 97 
>> ++
>>  1 file changed, 97 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt 
>> b/Documentation/devicetree/bindings/mfd/max77802.txt
>> new file mode 100644
>> index 000..f3b67c5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/max77802.txt
>> @@ -0,0 +1,97 @@
>> +Maxim MAX77802 multi-function device
>> +
>> +MAX77802 is a Mulitifunction device with PMIC, RTC and Charger on chip. It 
>> is
> 
> "Multifunction"?
> 

Yes, another typo. I'll fix it on the next series as well.

>> +interfaced to host controller using i2c interface. PMIC, Charger and RTC
>> +submodules are addressed using same i2c slave address.
>> +
>> +Buck regulators 1, 2, 3, 4 and 6 include Dynamic Voltage Scaling (DVS) that
>> +allows each output voltage to change dynamically. Each Buck output voltage
>> +is selected using a set of external inputs: DVS1-3 and SELB1, 2, 3 and 6.
>> +
>> +There are 8 DVS registers that can be used to configure the output voltage
>> +for each Buck regulator and which one is active is controled by DVSx lines.
>> +
>> +SELBx lines are used to control if individual Buck lines are ON or OFF.
>> +
>> +This document describes the binding for mfd device and PMIC submodule.
>> +
>> +Binding for the built-in 32k clock generator block is defined separately
>> +in bindings/clk/maxim,max77802.txt file.
>> +
>> +Required properties:
>> +- compatible : Must be "maxim,max77802";
>> +- reg : Specifies the i2c slave address of PMIC block.
>> +- interrupts : This i2c device has an IRQ line connected to the main SoC.
>> +- interrupt-parent : The parent interrupt controller.
>> +
>> +Optional properties:
>> +- max77802,pmic-buck-default-dvs-idx: We'll always write this DVS index in 
>> the
>> +  PMIC for Bucks with DVS.
>> +  NOTE: at the moment these bindings don't include enough details for actual
>> +  GPIO-DVS--this just lets you choose which single slot to use.
>> +
>> +- max77802,pmic-buck-dvs-gpios: A GPIO array where each GPIO is connected 
>> to a
>> +  DVS line. We'll try to set these GPIOs to match pmic-buck-default-dvs-idx 
>> at
>> +  probe time if they are defined. If some or all of these GPIOs are not 
>> defined
>> +  it's assumed that the board has any missing GPIOs hardwired to match
>> +  pmic-buck-default-dvs-idx.
>> +
>> +- max77802,pmic-buck-selb-gpios: A GPIO array where each GPIO is connected 
>> to a
>> +  SELBx line. Should be five values: 1, 2, 3, 4, 6. It is strongly 
>> suggested to
>> +  include these GPIOs if there's any chance that changing DVS GPIOs one 
>> line at
>> +  a time might glitch your DVS values.
>> +
>> +Optional node:
>> +- regulators : The regulators of max77802 have to be instantiated
>> +  under subnode named "regulators" using the following format.
>> +
>> +regulator_name {
> 
> The convention, I was told, would be regulator-name as node name.
> 

Ok, I'll change this to regulator-name. It is a symbolic name to refer to the
regulator node name anyways since now that the regulator-compatible property is
deprecated, the regulator node name is used for matching. So the list of valid
regulator node names is properly defined below:

>> +
>> +  The regulator node name should be initialized with a string
>> +to get matched with their hardware counterparts as follow:
>> +
>> +-LDOn   :   for LDOs, where n can lie in range 1 to 35.
>> +example: LDO1, LDO2, LDO35.
>> +-BUCKn  :   for BUCKs, where n can lie in range 1 to 10.
>> +example: BUCK1, BUCK5, BUCK10.
>> +Example:
>> +
>> +max77802@09 {
>> +compatible = "maxim,max77802";
>> +interrupt-parent = <&wakeup_eint>;
>> +interrupts = <26 0>;
>> +reg = <0x09>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +max77802,pmic-buck-default-dvs-idx = <1>;
>> +max77802,pmic-buck-dvs-gpios = <&gpy7 6 0>,
>> +   <&gpj4 2 0>,
>> +   <&gpj4 3 0>;
>> +max77802,pmic-buck-selb-gpios = <&gph0 2 0>,
>> +<&gph0 3 0>,
>> +<&gph0 4 0>,
>> +  

Re: [PATCH v5 03/14] clk: max77686: Add DT include for MAX77686 PMIC clock

[Javier Martinez Canillas]

Hello Andreas,

On 06/27/2014 10:26 AM, Andreas Färber wrote:
> Hi Javier,
> 
> Am 27.06.2014 09:53, schrieb Javier Martinez Canillas:
>> Hello Andreas,
>> 
>> On 06/27/2014 09:48 AM, Andreas Färber wrote:
>>> Am 26.06.2014 20:15, schrieb Javier Martinez Canillas:
 This patch adds a dt-binding include for Maxim 77686
 PMIC clock IDs that can be to be shared between the
>>>
>>> "can be shared"?
>>>
>> 
>> As it should be quite clear right now I'm not a native English speaker.
> 
> Guessed so, me neither. But since it's v5 already and no native speaker
> pointed it out, I took the liberty to do so while verifying that the
> LD02 typo didn't propagate into your bindings documentation (it didn't).
> 
>> I meant
>> that the header file can be included by both Device Tree source files and the
>> max77802 driver.
> 
> AFAIU "clock IDs to be shared" and "clock IDs that can be shared" would
> both be valid, but above a verb is missing (e.g., "can be used to").
> 
> Thanks for your upstreaming efforts, and don't let me discourage you.
> 

No discourage at all, your feedback is highly appreciated and sorry that I
didn't catch all these typos when working on the DT documentation.

> Best regards,
> 
> Andreas
> 

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

Re: [PATCH] sysctl: Add a feature to drop caches selectively

[Bernd Schubert]

On 06/27/2014 04:55 AM, Dave Chinner wrote:

On Thu, Jun 26, 2014 at 02:10:28PM +0200, Bernd Schubert wrote:

On 06/26/2014 01:57 PM, Lukáš Czerner wrote:

On Thu, 26 Jun 2014, Artem Bityutskiy wrote:

On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote:

On 06/26/2014 08:13 AM, Artem Bityutskiy wrote:

On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote:

Your particular use case can be handled by directing your benchmark
at a filesystem mount point and unmounting the filesystem in between
benchmark runs. There is no ned to adding kernel functionality for
somethign that can be so easily acheived by other means, especially
in benchmark environments where *everything* is tightly controlled.


If I was a benchmark writer, I would not be willing running it as root
to be able to mount/unmount, I would not be willing to require the
customer creating special dedicated partitions for the benchmark,
because this is too user-unfriendly. Or do I make incorrect assumptions?


But why a sysctl then? And also don't see a point for that at all, why
can't the benchmark use posix_fadvise(POSIX_FADV_DONTNEED)?


The latter question was answered - people want a way to drop caches for
a file. They need a method which guarantees that the caches are dropped.
They do not need an advisory method which does not give any guarantees.


I'm not sure if a benchmark really needs that so much that
FADV_DONTNEED isn't sufficient.
Personally I would also like to know if FADV_DONTNEED succeeded.
I.e. 'ql-fstest' is to check if the written pattern went to the
block device and currently it does not know if data really had been
dropped from the page cache. As it reads files several times this is
not critical, but only would be a nice to have - nothing worth to
add a new syscall.


ql-test is not a benchmark, it's a data integrity test. The re-read
verification problem is easily solved by using direct IO to read the
files directly without going through the page cache. Indeed, direct
IO will invalidate cached pages over the range it reads before it
does the read, so the guarantee that you are after - no cached pages
when the read is done - is also fulfilled by the direct IO read...

I really don't understand why people keep trying to make cached IO
behave like uncached IO when we already have uncached IO
interfaces



Firstly, direct IO has an entirely different IO pattern, usually much 
simpler than buffered through the page cache. Secondly, going through 
the page cache ensures that page cache buffering is also tested.
I'm not at all opposed to open files randomly with direct IO to also 
test that path and I'm going to add that soon, but only using direct IO 
would limit the use case of ql-fstest.



Bernd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pktgen: Fill the payload optionally with a pattern

[Zoltan Kiss]

On 26/06/14 01:54, David Miller wrote:

From: Zoltan Kiss 
Date: Tue, 24 Jun 2014 21:40:15 +0100


Introduces a new flag called PATTERN, which puts a non-periodic, predicatble
pattern into the payload. This was useful to reproduce an otherwise intermittent
bug in xen-netback [1], where checksum checking doesn't help.
The pattern is a repetition of " %lu", a series of increasing numbers divided by
space. The value of the number is the size of the preceding payload area. E.g.
" 1 3 5"..." 1000 1005 1010"
If the pattern is used, every frag will have its own page, unlike before, so it
needs more memory.

[1] 5837574: xen-netback: Fix grant ref resolution in RX path

Signed-off-by: Zoltan Kiss 

You are changing the page allocation strategy regardless of the pattern
setting, this is undesirable.

It may be significantly faster to use the same page for all the frags,
and this is absolutely critical for pktgen usage where every nanosecond
of performance counts.
If the PATTERN flag is not used, it always using the pages[0] page, so 
it falls back to the original way.


Zoli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] spi: omap-uwire: fix compilation failure

[Mark Brown]

On Thu, Jun 26, 2014 at 11:07:38PM -0700, Olof Johansson wrote:
> Patch 'spi: omap-uwire: use devm_ functions' (b3f6a57506b8) introduced a
> build error due to a missing include file. Add it.

A similar patch was applied a few days ago.


signature.asc
Description: Digital signature

LOAN OFFER

[Stanley Clarke]

I am Stanley Clarke a private lender located in USA.I can help you with a loan 
you are looking for @ 3% interest rate,For Urgent Response Email: 
stanleyloancla...@gmail.com

Stanley Clarke.
Email: stanleyloancla...@gmail.com
Telephone:(781)-369-5127
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sysctl: Add a feature to drop caches selectively

[Lukáš Czerner]

On Fri, 27 Jun 2014, Matthias Schniedermeyer wrote:

> Date: Fri, 27 Jun 2014 10:41:39 +0200
> From: Matthias Schniedermeyer 
> To: Luká? Czerner 
> Cc: Artem Bityutskiy ,
> Bernd Schubert ,
> Dave Chinner , Thomas Knauth ,
> David Rientjes ,
> Maksym Planeta ,
> Alexander Viro , linux-fsde...@vger.kernel.org,
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] sysctl: Add a feature to drop caches selectively
> 
> On 26.06.2014 13:57, Luká? Czerner wrote:
> 
> > > So if the authors want to sell this new interface (in whatever form) to
> > > the kernel community, they should start with providing a solid use-case,
> > > with some more details, explore alternatives and show how the
> > > alternatives do not work for them.
> > 
> > Yes please, let's see some solid use-case for this.
> 
> Personally i would want it to verify files after copying them:
> Especially while moving files:
> - Copy a file
> - 
> - Verify that it really is correct on stable storage
> - Remove original file

I assume you're using cp to copy a file, not your own program. In
that case can we make cp optionally use direct io ? It seems that it
would solve your problem in very elegant way.

-Lukas

> 
> Currently i choose either of the 3 ways:
> - drop_caches
> - umount/mount
> - Write more data than memory in machine (Which is only an 
> approximnation and you have to verify in the same order the files were 
> written, so it is likely that any cache was thrashed in the meantime)
> 
> But having a way to selectivly "destory" the cache of a file would make 
> this task easier.
> 
> 
> 
> 
> 

Re: [PATCH v4 06/13] ARM64 / ACPI: Introduce early_param for "acpi"

[Arnd Bergmann]

On Friday 27 June 2014 11:49:29 Hanjun Guo wrote:
> +
> +static int __init parse_acpi(char *arg)
> +{
> +   if (!arg)
> +   return -EINVAL;
> +
> +   /* "acpi=off" disables both ACPI table parsing and interpreter */
> +   if (strcmp(arg, "off") == 0) {
> +   disable_acpi();
> +   }
> +   /* acpi=strict disables out-of-spec workarounds */
> +   else if (strcmp(arg, "strict") == 0) {
> +   acpi_strict = 1;
> +   } else {
> +   /* Core will printk when we return error */
> +   return -EINVAL;
> +   }
> +
> +   return 0;
> +}
> +early_param("acpi", parse_acpi);

Can you explain in the changelog what happens for the acpi=off case? Does this
mean we fall back to using data from the dtb instead, or will it just not work?

If I understand correctly, this option makes sense on PC systems that will
still be able to boot using the legacy BIOS services and implicit assumptions
about the hardware, but that never works on arm64.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sysctl: Add a feature to drop caches selectively

[Artem Bityutskiy]

On Fri, 2014-06-27 at 10:41 +0200, Matthias Schniedermeyer wrote:
> On 26.06.2014 13:57, Luká? Czerner wrote:
> 
> > > So if the authors want to sell this new interface (in whatever form) to
> > > the kernel community, they should start with providing a solid use-case,
> > > with some more details, explore alternatives and show how the
> > > alternatives do not work for them.
> > 
> > Yes please, let's see some solid use-case for this.
> 
> Personally i would want it to verify files after copying them:
> Especially while moving files:
> - Copy a file
> - 
> - Verify that it really is correct on stable storage
> - Remove original file

To make 100% sure you'd not only need to drop VFS-level caches but also
file-system-level caches. Indeed, file-systems have their own rather
buffers for different indexing data-structures, etc. The unmount/mount
sequence takes care of that.

-- 
Best Regards,
Artem Bityutskiy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Linaro-acpi] [PATCH v4 12/13] ARM64 / ACPI: if we chose to boot from acpi then disable FDT

[Arnd Bergmann]

On Friday 27 June 2014 11:49:35 Hanjun Guo wrote:
> From: Graeme Gregory 
> 
> If the early boot methods of acpi are happy that we have valid ACPI
> tables and acpi=off has not been passed. Then do not unflat devicetree
> effectively disabling further hardware probing from DT.
> 

I guess this answers the question I had on patch 4 ;-)

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sysctl: Add a feature to drop caches selectively

[Bityutskiy, Artem]

On Fri, 2014-06-27 at 12:08 +0300, Artem Bityutskiy wrote:
> To make 100% sure you'd not only need to drop VFS-level caches but also
> file-system-level caches. Indeed, file-systems have their own rather
Sorry, I wanted to say "rather complex" here
> buffers for different indexing data-structures, etc. The unmount/mount
> sequence takes care of that.
> 

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: mfd: sec-core requires regulators

[Lee Jones]

On Tue, 24 Jun 2014, Arnd Bergmann wrote:

> The newly added sec-core mfd module calls the regulator_suspend_prepare()
> function, which is only available if the regulator API is provided. This
> matches the usage of the driver, so we can just add a Kconfig dependency.
> 
> Reported-by: Jim Davis 
> Signed-off-by: Arnd Bergmann 

Thanks for re-sending Arnd, patch applied.

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 207c433..1caa3c5 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -582,7 +582,7 @@ config MFD_RC5T583
>  
>  config MFD_SEC_CORE
> bool "SAMSUNG Electronics PMIC Series Support"
> -   depends on I2C=y
> +   depends on I2C=y && REGULATOR
> select MFD_CORE
> select REGMAP_I2C
> select REGMAP_IRQ

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

Re: [PATCH v2 1/3] cgroup: fix mount failure in a corner case

[Li Zefan]

Made a mistake again.. :(


==

From: Li Zefan 
Subject: [PATCH 1/3] cgroup: fix mount failure in a corner case

  # cat test.sh
  #! /bin/bash

  mount -t cgroup -o cpu xxx /cgroup
  umount /cgroup

  mount -t cgroup -o cpu,cpuacct xxx /cgroup
  umount /cgroup
  # ./test.sh
  mount: xxx already mounted or /cgroup busy
  mount: according to mtab, xxx is already mounted on /cgroup

It's because the cgroupfs_root of the first mount was under destruction
asynchronously.

Fix this by delaying and then retrying mount for this case.

v2:
- use percpu_ref_tryget_live() rather that introducing
  percpu_ref_alive(). (Tejun)
- adjust comment.

Signed-off-by: Li Zefan 
---
 kernel/cgroup.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 1c65f24..b94449f 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1648,10 +1648,12 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
 int flags, const char *unused_dev_name,
 void *data)
 {
+   struct cgroup_subsys *ss;
struct cgroup_root *root;
struct cgroup_sb_opts opts;
struct dentry *dentry;
int ret;
+   int i, j = -1;
bool new_sb;
 
/*
@@ -1677,6 +1679,25 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
goto out_unlock;
}
 
+   /*
+* Destruction of cgroup root is asynchronous, so we may fail to
+* mount a cgroupfs if it immediately follows a umount. Let's wait
+* a little bit and retry.
+*/
+   for_each_subsys(ss, i) {
+   if (!(opts.subsys_mask & (1 << i)) ||
+   ss->root == &cgrp_dfl_root)
+   continue;
+
+   if (!percpu_ref_tryget_live(&ss->root->cgrp.self.refcnt)) {
+   mutex_unlock(&cgroup_mutex);
+   msleep(10);
+   ret = restart_syscall();
+   goto out_free;
+   }
+   j = i;
+   }
+
for_each_root(root) {
bool name_match = false;
 
@@ -1763,6 +1784,14 @@ out_free:
kfree(opts.release_agent);
kfree(opts.name);
 
+   for_each_subsys(ss, i) {
+   if (i > j)
+   break;
+   if (!(opts.subsys_mask & (1 << i)))
+   continue;
+   cgroup_put(&ss->root->cgrp);
+   }
+
if (ret)
return ERR_PTR(ret);
 
-- 
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 2/2] mxc_nand: use our own read_page function

[Michael Grzeschik]

On Thu, Jun 26, 2014 at 10:42:48PM +0200, Michael Grzeschik wrote:
> The current approach of the read_page function is to iterate over all
> subpages and call the correct_data function. The correct_data function
> currently does the same. It iterates over all subpages and checks for
> correctable and uncorrectable data. This redundant call for each
> subpage leads to miscalculations.
> 
> This patch changes the driver to use its own read_page function in which
> we call the correct_data function only once per page. With that we do
> the failure and correct statistics counting inside this function.
> 
> Signed-off-by: Michael Grzeschik 
> ---
>  drivers/mtd/nand/mxc_nand.c | 73 
> ++---
>  1 file changed, 69 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> index 7fd495e..09e3682 100644
> --- a/drivers/mtd/nand/mxc_nand.c
> +++ b/drivers/mtd/nand/mxc_nand.c

[snip]

> @@ -673,15 +728,21 @@ static int mxc_nand_correct_data_v2_v3(struct mtd_info 
> *mtd, u_char *dat,
>   do {
>   err = ecc_stat & ecc_bit_mask;
>   if (err > err_limit) {
> - printk(KERN_WARNING "UnCorrectable RS-ECC Error\n");
> - return -1;
> + broken++;
>   } else {
>   ret += err;
>   }
>   ecc_stat >>= 4;
>   } while (--no_subpages);
>  
> - pr_debug("%d Symbol Correctable RS-ECC Error\n", ret);
> + mtd->ecc_stats.corrected += ret;
> + if (ret)
> + printk("%d Symbol Correctable RS-ECC Error\n", ret);

This was ment to be pr_debug as before.

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regulator: tps65917: Fix SMPS enable/disable/is_enable

[Keerthy]

Hello Nishanth,

On Friday 27 June 2014 12:01 AM, Nishanth Menon wrote:

We use regmap regulator ops to enable/disable and check if regulator
is enabled for various SMPS. However, these depend on valid
enable_reg, enable_mask and enable_value in regulator descriptor.

So, similar to fix we did in commit 318dbb02b50c
("regulator: palmas: Fix SMPS enable/disable/is_enabled"), populate the
same for TPS65917 SMPS registration. LDO definitions are already in place.

Fixes: d6f83370ed97 ("regulator: palmas: Add tps65917 PMIC support")
Signed-off-by: Nishanth Menon 
---

Applies on:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
branch: topic/palmas (4c0c9ca Merge remote-tracking branch 
'regulator/fix/palmas' into regulator-palmas)

Note: Ignored the minor style check from checkpatch --strict as fixing
it would create an 80 char warning

  drivers/regulator/palmas-regulator.c |8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/regulator/palmas-regulator.c 
b/drivers/regulator/palmas-regulator.c
index 7c8b441..c7aa1b1 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1333,6 +1333,14 @@ static int tps65917_smps_registration(struct palmas_pmic 
*pmic,
pmic->current_reg_mode[id] = reg &
PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
  
+		pmic->desc[id].enable_reg =

+   PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE,
+   palmas_regs_info[id].ctrl_addr);


This is wrong. Please change palmas_regs_info[id].ctrl_addr to
ddata->palmas_regs_info[id].ctrl_addr. The palmas_regs_info
should come from the driver data for specific instances as the regmap
is different for the different PMICs we support.

Once you make the above changes please feel free to add
Tested-by: Keerthy .


+   pmic->desc[id].enable_mask =
+   PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
+   /* set_mode overrides this value */
+   pmic->desc[id].enable_val = SMPS_CTRL_MODE_ON;
+
pmic->desc[id].type = REGULATOR_VOLTAGE;
pmic->desc[id].owner = THIS_MODULE;
  


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

[PATCH - RESEND] Bluetooth: Keep master role when SCO or eSCO is active

[Kiran Kumar Raparthy]

From: "hyungseoung.yoo" 

Preserve the master role when SCO or eSCO is active
as this improves compatability with lots of
headset and chipset combinations.

This is one of the number of patches from the Android AOSP
common.git tree, which is used on almost all Android devices.
It looks like it would improve support for compatibility with
lot of headset,so I wanted to submit it for review to see
if it should go upstream.

v3: Fixed formatting issues pointed by Sergei

Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Cc: "David S. Miller" 
Cc: linux-blueto...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Android Kernel Team 
Cc: John Stultz 
Signed-off-by: hyungseoung.yoo 
Signed-off-by: Jaikumar Ganesh 
[kiran: Added context to commit message]
Signed-off-by: Kiran Raparthy 
---
 net/bluetooth/hci_event.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 15010a2..cfb1355 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1915,6 +1915,14 @@ unlock:
hci_conn_check_pending(hdev);
 }
 
+static inline bool is_sco_active(struct hci_dev *hdev)
+{
+   if (hci_conn_hash_lookup_state(hdev, SCO_LINK, BT_CONNECTED) ||
+   hci_conn_hash_lookup_state(hdev, ESCO_LINK, BT_CONNECTED))
+   return true;
+   return false;
+}
+
 static void hci_conn_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
 {
struct hci_ev_conn_request *ev = (void *) skb->data;
@@ -1961,7 +1969,9 @@ static void hci_conn_request_evt(struct hci_dev *hdev, 
struct sk_buff *skb)
 
bacpy(&cp.bdaddr, &ev->bdaddr);
 
-   if (lmp_rswitch_capable(hdev) && (mask & HCI_LM_MASTER))
+   if (lmp_rswitch_capable(hdev) &&
+   ((mask & HCI_LM_MASTER) ||
+   is_sco_active(hdev)))
cp.role = 0x00; /* Become master */
else
cp.role = 0x01; /* Remain slave */
-- 
1.8.2.1

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

Re: [PATCHv5 2/2] arm: Get rid of meminfo

[Laura Abbott]

On 6/24/2014 1:49 AM, Uwe Kleine-König wrote:
> Hi Laura,
> 
> On Mon, Jun 23, 2014 at 01:47:55PM -0700, Laura Abbott wrote:
>> Thanks for the report.
> Thanks for your reply to address it :-)
> Are you already aware of the mail with Message-Id:
> caga+x85h510fngtxjhgyfqybra2fggg2nycgj8rmjj6te7g...@mail.gmail.com ?
> Seems to be another fall-out but I think you were not on Cc.
> 
>> On 6/23/2014 2:17 AM, Uwe Kleine-König wrote:
>>> This patch is in 3.16-rc1 as 1c2f87c22566cd057bc8cde10c37ae9da1a1bb76
>>> now.
>>>
>>> Unfortunately it makes my efm32 machine unbootable.
>>>
>>> With earlyprintk enabled I get the following output:
>>>
>>> [0.00] Booting Linux on physical CPU 0x0
>>> [0.00] Linux version 3.15.0-rc1-00028-g1c2f87c22566-dirty 
>>> (ukleinek@perseus) (gcc version 4.7.2 (OSELAS.Toolchain-2012.12.1) ) #280 
>>> PREEMPT Mon Jun 23 11:05:34 CEST 2014
>>> [0.00] CPU: ARMv7-M [412fc231] revision 1 (ARMv7M), cr=
>>> [0.00] CPU: unknown data cache, unknown instruction cache
>>> [0.00] Machine model: Energy Micro Giant Gecko Development Kit
>>> [0.00] debug: ignoring loglevel setting.
>>> [0.00] bootconsole [earlycon0] enabled
>>> [0.00] On node 0 totalpages: 1024
>>> [0.00] free_area_init_node: node 0, pgdat 880208f4, node_mem_map 
>>> 
>>> [0.00]   Normal zone: 3840 pages exceeds freesize 1024
>>
>> This looks off. The number of pages for the memmap exceeds the available free
>> size. Working backwards, I think the wrong bounds are being calculated in
>> find_limits in arch/arm/mm/init.c . max_low is now calculated via the current
>> limit but nommu never sets a limit unlike the mmu case. Can you try the
>> following patch and see if it fixes the issue? If this doesn't work, can
>> you share working bootup logs so I can do a bit more compare and contrast?
>>
>> Thanks,
>> Laura
>>
>> ---8<
>> From 9b19241d577caf91928e26e55413047d1be90feb Mon Sep 17 00:00:00 2001
>> From: Laura Abbott 
>> Date: Mon, 23 Jun 2014 13:26:56 -0700
>> Subject: [PATCH] arm: Set memblock limit for nommu
>>
>> Commit 1c2f87c (ARM: 8025/1: Get rid of meminfo) changed find_limits
>> to use memblock_get_current_limit for calculating the max_low pfn.
>> nommu targets never actually set a limit on memblock though which
>> means memblock_get_current_limit will just return the default
>> value. Set the memblock_limit to be the end of DDR to make sure
> s/DDR/RAM/ ?
> 
>> bounds are calculated correctly.
> This patch makes my machine boot. Full boot log appended below.
> (Side note: I place my dtb in the SRAM at 0x1000 but don't add this to
> the available memory because it's only 128 KiB in size and so too small
> to be worth to track. Not sure this is allowed?!)
> 
> Thanks
> Uwe
> 
 
I put this in the patch tracker as 8086/1

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 02/14] mfd: max77686: Allow the max77686 rtc to wakeup the system

[Lee Jones]

On Thu, 26 Jun 2014, Javier Martinez Canillas wrote:

> From: Doug Anderson 
> 
> The max77686 includes an RTC that keeps power during suspend.  It's
> convenient to be able to use it as a wakeup source.
> 
> NOTE: due to wakeup ordering problems this patch alone doesn't work so
> well on exynos5250-snow.  You also need something that brings the i2c
> bus up before the max77686 wakeup runs.
> 
> Signed-off-by: Doug Anderson 
> Reviewed-by: Javier Martinez Canillas 
> Reviewed-by: Krzysztof Kozlowski 
> ---
> 
> Changes since v4: None
> 
> Changes since v3:
>  - Keep the note that this patch needs another change due wakeup
>ordering problems.
> 
>  drivers/rtc/rtc-max77686.c | 28 
>  1 file changed, 28 insertions(+)

This patch doesn't actually touch the MFD subsystem directly.  Can you
change the $SUBJECT line accordingly please?

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

Re: [PATCH v3 4/9] ACPI, x86: Extended error log driver for x86 platform

[Borislav Petkov]

On Fri, Jun 27, 2014 at 01:34:45PM +0800, Xie XiuQi wrote:
> The call graph is like this,
> do_machine_check
>  -> mce_log
>   -> atomic_notifier_call_chain(&x86_mce_decoder_chain ...)
>-> ...
> -> extlog_print
>  -> print_extlog_rcd
>   -> __print_extlog_rcd
>-> printk
> 
> There's a logbuf_lock in printk. If logbuf_lock is held by other cpu,
> it'll lead to an infinity spin here. Isn't it?

Yes, but we want to take the risk and print something out before the
machine dies instead of waiting to get into printk-safe context first
and maybe corrupt state.

Besides, there's work currently going on to make printk safe in atomic
context so...

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH v5 10/14] regulator: Add driver for Maxim 77802 PMIC regulators

[Lee Jones]

On Thu, 26 Jun 2014, Javier Martinez Canillas wrote:
> The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout
> (LDO) regulators. This patch adds support for all these regulators
> found on the MAX77802 PMIC and is based on a driver added by Simon
> Glass to the Chrome OS kernel 3.8 tree.
> 
> Signed-off-by: Javier Martinez Canillas 
> Tested-by: Naveen Krishna Chatradhi 
> ---
> 
> Changes since v4: None
> 
> Changes since v3:
>  - Set the supply_name for regulators to lookup their parent supply node.
>Suggested by Mark Brown.
>  - Change Exyno5 for Exynos5420/Exynos5800 in regulator driver Kconfig.
>Suggested by Doug Anderson.
> 
> Changes since v2:
>  - Use dev_warn() instead pr_warn(). Suggested by Mark Brown.
>  - Add a generic function to regmap core to copy registers instead of
>having a driver-specific function. Suggested by Mark Brown.
>  - Remove unnecessary probe debug log. Suggested by Mark Brown.
>  - Set struct regulator_config dev field to MFD instead of the platform dev.
>Suggested by Mark Brown.
>  - Read the regulators operational mode from the hardware registers instead
>of setting to normal as default on probe. Suggested by Mark Brown.
>  - Remove unnecessary cross-subsystem dependencies. Suggested by Lee Jones.
> 
> Changes since v1:
>  - Remove unneeded check if num_regulators != MAX77802_MAX_REGULATORS.
>  - Fix .set_suspend_mode handler comment and split regulators ops for
>regulators that behave differently. Suggested by Mark Brown.
>  - Use module_platform_driver() instead of having init/exit functions.
>Suggested by Mark Brown.
>  - Use the new descriptor-based GPIO interface instead of the deprecated
>integer based GPIO one. Suggested by Mark Brown.
>  - Look for "regulators" child node instead of "voltage-regulators" to be
>consistent with other PMIC drivers. Suggested by Mark Brown.
> 
>  drivers/mfd/max77802.c   |   8 +-
>  drivers/regulator/Kconfig|   9 +
>  drivers/regulator/Makefile   |   1 +
>  drivers/regulator/max77802.c | 694 
> +++
>  include/linux/mfd/max77802-private.h |   3 -
>  5 files changed, 711 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/regulator/max77802.c
> 
> diff --git a/drivers/mfd/max77802.c b/drivers/mfd/max77802.c
> index 3d477fb..79d36b6 100644
> --- a/drivers/mfd/max77802.c
> +++ b/drivers/mfd/max77802.c
> @@ -228,7 +228,7 @@ static int max77802_i2c_probe(struct i2c_client *i2c,
>  
>   max77802 = devm_kzalloc(&i2c->dev, sizeof(struct max77802_dev),
>   GFP_KERNEL);
> - if (max77802 == NULL)
> + if (!max77802)
>   return -ENOMEM;
>  
>   i2c_set_clientdata(i2c, max77802);
> @@ -315,6 +315,12 @@ static int max77802_suspend(struct device *dev)
>   if (device_may_wakeup(dev))
>   enable_irq_wake(max77802->irq);
>  
> + /*
> +  * The IRQ must be disabled during suspend since due wakeup
> +  * ordering issues it may be possible that the I2C controller
> +  * is still suspended when the interrupt happens so the IRQ
> +  * handler will fail to read the I2C bus.
> +  */

Please re-word this, the English is a little off.

>   disable_irq(max77802->irq);
>  
>   return 0;

Please separate the MFD changes out.  There is no need for them to be
munged in with regulator changes.

[...]

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

RE: [PATCH] scsi: pm8001: pm80xx_hwi.c: Cleaning up variable is set more than once

[Suresh Thiagarajan]

On Thu, Jun 26, 2014 at 1:50 PM, Maurizio Lombardi  wrote:
> On 06/26/2014 10:09 AM, Jack Wang wrote:
>> Thanks Rickard,
>>
>> From my point of view, looks good, but I'd like to get review from Anand
>> (cc-ed).
>
> I would like to add that I noticed that this fields is only set and appears 
> to be never used,
> maybe it could be completely removed.

You are correct. The whole forensic_info structure itself is not used or 
referred anywhere. I will remove it and send a patch.

Regards,
Suresh Thiagarajan
>
> Regards,
> Maurizio Lombardi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.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/

Re: [PATCH v5 02/14] mfd: max77686: Allow the max77686 rtc to wakeup the system

[Javier Martinez Canillas]

Hello Lee,

On 06/27/2014 11:21 AM, Lee Jones wrote:
> On Thu, 26 Jun 2014, Javier Martinez Canillas wrote:
> 
>> From: Doug Anderson 
>> 
>> The max77686 includes an RTC that keeps power during suspend.  It's
>> convenient to be able to use it as a wakeup source.
>> 
>> NOTE: due to wakeup ordering problems this patch alone doesn't work so
>> well on exynos5250-snow.  You also need something that brings the i2c
>> bus up before the max77686 wakeup runs.
>> 
>> Signed-off-by: Doug Anderson 
>> Reviewed-by: Javier Martinez Canillas 
>> Reviewed-by: Krzysztof Kozlowski 
>> ---
>> 
>> Changes since v4: None
>> 
>> Changes since v3:
>>  - Keep the note that this patch needs another change due wakeup
>>ordering problems.
>> 
>>  drivers/rtc/rtc-max77686.c | 28 
>>  1 file changed, 28 insertions(+)
> 
> This patch doesn't actually touch the MFD subsystem directly.  Can you
> change the $SUBJECT line accordingly please?
> 

You're right, I'll change the $subject.

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

Re: [PATCH 8/9] ARM: kernel: add support for cpu cache information

[Sudeep Holla]

Hi,

On 26/06/14 19:45, Stephen Boyd wrote:

On 06/26/14 04:36, Sudeep Holla wrote:

Hi Stephen,

On 26/06/14 01:19, Stephen Boyd wrote:

On 06/25/14 10:30, Sudeep Holla wrote:

+
+/*
+ * Which cache CCSIDR represents depends on CSSELR value
+ * Make sure no one else changes CSSELR during this
+ * smp_call_function_single prevents preemption for us
+ */


Where's the smp_call_function_single() or preemption disable happening?



init_cache_level is called using smp_call_function_single in
drivers/base/cacheinfo.c(PATCH 2/9)


Oh that's unexpected. Do other architectures require the use of
smp_call_function_single() to read their cache information? It seems
like an ARM architecture specific detail that has been pushed up into
the generic layer.



Right, since I started with x86 as reference and it requires it, I missed to
see others. So x86,ARM{32,64} requires it while ppc,s390 and ia64 doesn't.
I see how to fix that. Thanks for spotting it.

Regards,
Sudeep

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/9] regulator: palmas: add driver data and modularize the probe

[Keerthy]

Hi Lee Jones,

On Friday 27 June 2014 01:53 PM, Lee Jones wrote:

On Wed, 18 Jun 2014, Keerthy wrote:

add driver data and modularize the probe.

Nit: This is a sentence, it should start with a capital letter.


The series is already pulled by Mark. I Can send fixes on top of
that patch set.


Signed-off-by: Keerthy 
---

Changes in V2:

   * Fixed the order of variable declarations.

  drivers/mfd/palmas.c |   44 +--
  drivers/regulator/palmas-regulator.c |  658 --
  2 files changed, 396 insertions(+), 306 deletions(-)

diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index c12759d..28cb048 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -25,42 +25,6 @@
  #include 
  #include 
  
-#define EXTERNAL_REQUESTOR(_id, _offset, _pos)		\

-   [PALMAS_EXTERNAL_REQSTR_ID_##_id] = {   \
-   .id = PALMAS_EXTERNAL_REQSTR_ID_##_id,  \
-   .reg_offset = _offset,  \
-   .bit_pos = _pos,\
-   }
-
-static struct palmas_sleep_requestor_info sleep_req_info[] = {
-   EXTERNAL_REQUESTOR(REGEN1, 0, 0),
-   EXTERNAL_REQUESTOR(REGEN2, 0, 1),
-   EXTERNAL_REQUESTOR(SYSEN1, 0, 2),
-   EXTERNAL_REQUESTOR(SYSEN2, 0, 3),
-   EXTERNAL_REQUESTOR(CLK32KG, 0, 4),
-   EXTERNAL_REQUESTOR(CLK32KGAUDIO, 0, 5),
-   EXTERNAL_REQUESTOR(REGEN3, 0, 6),
-   EXTERNAL_REQUESTOR(SMPS12, 1, 0),
-   EXTERNAL_REQUESTOR(SMPS3, 1, 1),
-   EXTERNAL_REQUESTOR(SMPS45, 1, 2),
-   EXTERNAL_REQUESTOR(SMPS6, 1, 3),
-   EXTERNAL_REQUESTOR(SMPS7, 1, 4),
-   EXTERNAL_REQUESTOR(SMPS8, 1, 5),
-   EXTERNAL_REQUESTOR(SMPS9, 1, 6),
-   EXTERNAL_REQUESTOR(SMPS10, 1, 7),
-   EXTERNAL_REQUESTOR(LDO1, 2, 0),
-   EXTERNAL_REQUESTOR(LDO2, 2, 1),
-   EXTERNAL_REQUESTOR(LDO3, 2, 2),
-   EXTERNAL_REQUESTOR(LDO4, 2, 3),
-   EXTERNAL_REQUESTOR(LDO5, 2, 4),
-   EXTERNAL_REQUESTOR(LDO6, 2, 5),
-   EXTERNAL_REQUESTOR(LDO7, 2, 6),
-   EXTERNAL_REQUESTOR(LDO8, 2, 7),
-   EXTERNAL_REQUESTOR(LDO9, 3, 0),
-   EXTERNAL_REQUESTOR(LDOLN, 3, 1),
-   EXTERNAL_REQUESTOR(LDOUSB, 3, 2),
-};
-

Happy with this, good riddance.


  static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
{
.reg_bits = 8,
@@ -365,10 +329,10 @@ static struct regmap_irq_chip tps65917_irq_chip = {
  int palmas_ext_control_req_config(struct palmas *palmas,
enum palmas_external_requestor_id id,  int ext_ctrl, bool enable)
  {
+   struct palmas_pmic_driver_data *pmic_ddata = palmas->pmic_ddata;
int preq_mask_bit = 0;
int reg_add = 0;
-   int bit_pos;
-   int ret;
+   int bit_pos, ret;

I don't like this change.

[...]



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

Re: [PATCH - RESEND] Bluetooth: Keep master role when SCO or eSCO is active

[Marcel Holtmann]

Hi Kiran,

> Preserve the master role when SCO or eSCO is active
> as this improves compatability with lots of
> headset and chipset combinations.

this comment is pretty much non-sense. If you have an incoming BR/EDR 
connection, then by default you will be slave. The acceptor is the slave, there 
is no way of preserving the master role. You never had it in the first place.

So lets assume you have an existing connection with a different device, then 
yes it could be beneficial to not enter a scatternet situation. Assume you are 
already master in the existing connection, then sure, staying master here is 
beneficial since you don't want to maintain a second connection and you want to 
drive the piconet. However what happens when you are slave in the existing 
connection. Are you forcing now master role on the new connection or better 
stay slave. Or check if you might be able to become master for both devices and 
thus move them into a single piconet.

> This is one of the number of patches from the Android AOSP
> common.git tree, which is used on almost all Android devices.
> It looks like it would improve support for compatibility with
> lot of headset,so I wanted to submit it for review to see
> if it should go upstream.
> 
> v3: Fixed formatting issues pointed by Sergei
> 
> Cc: Marcel Holtmann 
> Cc: Gustavo Padovan 
> Cc: Johan Hedberg 
> Cc: "David S. Miller" 
> Cc: linux-blueto...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Android Kernel Team 
> Cc: John Stultz 
> Signed-off-by: hyungseoung.yoo 
> Signed-off-by: Jaikumar Ganesh 
> [kiran: Added context to commit message]
> Signed-off-by: Kiran Raparthy 

I am pretty sick of just blasting patches to everybody on the planet. Patches 
concerning Bluetooth subsystem should be send to 
linux-blueto...@vger.kernel.org only. There is no point in spamming everybody 
else.

> ---
> net/bluetooth/hci_event.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 15010a2..cfb1355 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -1915,6 +1915,14 @@ unlock:
>   hci_conn_check_pending(hdev);
> }
> 
> +static inline bool is_sco_active(struct hci_dev *hdev)
> +{
> + if (hci_conn_hash_lookup_state(hdev, SCO_LINK, BT_CONNECTED) ||
> + hci_conn_hash_lookup_state(hdev, ESCO_LINK, BT_CONNECTED))
> + return true;
> + return false;
> +}
> +
> static void hci_conn_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
> {
>   struct hci_ev_conn_request *ev = (void *) skb->data;
> @@ -1961,7 +1969,9 @@ static void hci_conn_request_evt(struct hci_dev *hdev, 
> struct sk_buff *skb)
> 
>   bacpy(&cp.bdaddr, &ev->bdaddr);
> 
> - if (lmp_rswitch_capable(hdev) && (mask & HCI_LM_MASTER))
> + if (lmp_rswitch_capable(hdev) &&
> + ((mask & HCI_LM_MASTER) ||
> + is_sco_active(hdev)))
>   cp.role = 0x00; /* Become master */
>   else
>   cp.role = 0x01; /* Remain slave */

So this is a policy that takes global affect and might not be the what all 
devices want to do. The problem now is that acceptors force slave role on the 
initiator. It might be the case that the initiator can not facilitate the slave 
role here. And that results in connection failures with certain devices. Not a 
good idea.

Where I am standing this should be a policy that the SCO sockets that are 
active can enforce. So on a SCO socket you might set that you want to stay 
master. And that policy, if set, then gets enforced here. That allows other 
profiles to pick whatever policy they want.

Regards

Marcel

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

Re: [PATCH v5 10/14] regulator: Add driver for Maxim 77802 PMIC regulators

[Javier Martinez Canillas]

Hello Lee,

Thanks a lot for your feedback.

On 06/27/2014 11:26 AM, Lee Jones wrote:
> On Thu, 26 Jun 2014, Javier Martinez Canillas wrote:
>> The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout
>> (LDO) regulators. This patch adds support for all these regulators
>> found on the MAX77802 PMIC and is based on a driver added by Simon
>> Glass to the Chrome OS kernel 3.8 tree.
>> 
>> Signed-off-by: Javier Martinez Canillas 
>> Tested-by: Naveen Krishna Chatradhi 
>> ---
>> 
>> Changes since v4: None
>> 
>> Changes since v3:
>>  - Set the supply_name for regulators to lookup their parent supply node.
>>Suggested by Mark Brown.
>>  - Change Exyno5 for Exynos5420/Exynos5800 in regulator driver Kconfig.
>>Suggested by Doug Anderson.
>> 
>> Changes since v2:
>>  - Use dev_warn() instead pr_warn(). Suggested by Mark Brown.
>>  - Add a generic function to regmap core to copy registers instead of
>>having a driver-specific function. Suggested by Mark Brown.
>>  - Remove unnecessary probe debug log. Suggested by Mark Brown.
>>  - Set struct regulator_config dev field to MFD instead of the platform dev.
>>Suggested by Mark Brown.
>>  - Read the regulators operational mode from the hardware registers instead
>>of setting to normal as default on probe. Suggested by Mark Brown.
>>  - Remove unnecessary cross-subsystem dependencies. Suggested by Lee Jones.
>> 
>> Changes since v1:
>>  - Remove unneeded check if num_regulators != MAX77802_MAX_REGULATORS.
>>  - Fix .set_suspend_mode handler comment and split regulators ops for
>>regulators that behave differently. Suggested by Mark Brown.
>>  - Use module_platform_driver() instead of having init/exit functions.
>>Suggested by Mark Brown.
>>  - Use the new descriptor-based GPIO interface instead of the deprecated
>>integer based GPIO one. Suggested by Mark Brown.
>>  - Look for "regulators" child node instead of "voltage-regulators" to be
>>consistent with other PMIC drivers. Suggested by Mark Brown.
>> 
>>  drivers/mfd/max77802.c   |   8 +-
>>  drivers/regulator/Kconfig|   9 +
>>  drivers/regulator/Makefile   |   1 +
>>  drivers/regulator/max77802.c | 694 
>> +++
>>  include/linux/mfd/max77802-private.h |   3 -
>>  5 files changed, 711 insertions(+), 4 deletions(-)
>>  create mode 100644 drivers/regulator/max77802.c
>> 
>> diff --git a/drivers/mfd/max77802.c b/drivers/mfd/max77802.c
>> index 3d477fb..79d36b6 100644
>> --- a/drivers/mfd/max77802.c
>> +++ b/drivers/mfd/max77802.c
>> @@ -228,7 +228,7 @@ static int max77802_i2c_probe(struct i2c_client *i2c,
>>  
>>  max77802 = devm_kzalloc(&i2c->dev, sizeof(struct max77802_dev),
>>  GFP_KERNEL);
>> -if (max77802 == NULL)
>> +if (!max77802)
>>  return -ENOMEM;
>>  
>>  i2c_set_clientdata(i2c, max77802);
>> @@ -315,6 +315,12 @@ static int max77802_suspend(struct device *dev)
>>  if (device_may_wakeup(dev))
>>  enable_irq_wake(max77802->irq);
>>  
>> +/*
>> + * The IRQ must be disabled during suspend since due wakeup
>> + * ordering issues it may be possible that the I2C controller
>> + * is still suspended when the interrupt happens so the IRQ
>> + * handler will fail to read the I2C bus.
>> + */
> 
> Please re-word this, the English is a little off.
> 

Ok, I found that drivers/mfd/max14577.c has a similar comment so I'll just reuse
that one since explains it way better.

>>  disable_irq(max77802->irq);
>>  
>>  return 0;
> 
> Please separate the MFD changes out.  There is no need for them to be
> munged in with regulator changes.
>

Yes, when preparing v5 I squashed the mfd driver changes into the patch adding
the regulator driver by mistake instead with the one adding the mfd driver.
Sorry about that...

I'll wait for your complete review so I can fix all the issues you find and post
a v6.

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

Re: [RFC 09/10] drm/tegra: Add IOMMU support

[Hiroshi DOyu]

Thierry Reding  writes:

> From: Thierry Reding 
>
> When an IOMMU device is available on the platform bus, allocate an IOMMU
> domain and attach the display controllers to it. The display controllers
> can then scan out non-contiguous buffers by mapping them through the
> IOMMU.
>
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/tegra/dc.c  |  21 
>  drivers/gpu/drm/tegra/drm.c |  17 
>  drivers/gpu/drm/tegra/drm.h |   3 +
>  drivers/gpu/drm/tegra/fb.c  |  16 ++-
>  drivers/gpu/drm/tegra/gem.c | 236 
> +++-
>  drivers/gpu/drm/tegra/gem.h |   4 +
>  6 files changed, 273 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index afcca04f5367..0f7452d04811 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -9,6 +9,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include "dc.h"
> @@ -1283,8 +1284,18 @@ static int tegra_dc_init(struct host1x_client *client)
>  {
> struct drm_device *drm = dev_get_drvdata(client->parent);
> struct tegra_dc *dc = host1x_client_to_dc(client);
> +   struct tegra_drm *tegra = drm->dev_private;
> int err;
>
> +   if (tegra->domain) {
> +   err = iommu_attach_device(tegra->domain, dc->dev);

I wanted to keep device drivers iommu-free with the following:

http://patchwork.ozlabs.org/patch/354074/


> +   if (err < 0) {
> +   dev_err(dc->dev, "failed to attach to IOMMU: %d\n",
> +   err);
> +   return err;
> +   }
> +   }
> +
> drm_crtc_init(drm, &dc->base, &tegra_crtc_funcs);
> drm_mode_crtc_set_gamma_size(&dc->base, 256);
> drm_crtc_helper_add(&dc->base, &tegra_crtc_helper_funcs);
> @@ -1318,7 +1329,9 @@ static int tegra_dc_init(struct host1x_client *client)
>
>  static int tegra_dc_exit(struct host1x_client *client)
>  {
> +   struct drm_device *drm = dev_get_drvdata(client->parent);
> struct tegra_dc *dc = host1x_client_to_dc(client);
> +   struct tegra_drm *tegra = drm->dev_private;
> int err;
>
> devm_free_irq(dc->dev, dc->irq, dc);
> @@ -1335,6 +1348,8 @@ static int tegra_dc_exit(struct host1x_client *client)
> return err;
> }
>
> +   iommu_detach_device(tegra->domain, dc->dev);
> +
> return 0;
>  }
>
> @@ -1462,6 +1477,12 @@ static int tegra_dc_probe(struct platform_device *pdev)
> return -ENXIO;
> }
>
> +   err = iommu_attach(&pdev->dev);
> +   if (err < 0) {
> +   dev_err(&pdev->dev, "failed to attach to IOMMU: %d\n", err);
> +   return err;
> +   }
> +
> INIT_LIST_HEAD(&dc->client.list);
> dc->client.ops = &dc_client_ops;
> dc->client.dev = &pdev->dev;
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index 59736bb810cd..1d2bbafad982 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -8,6 +8,7 @@
>   */
>
>  #include 
> +#include 
>
>  #include "drm.h"
>  #include "gem.h"
> @@ -33,6 +34,16 @@ static int tegra_drm_load(struct drm_device *drm, unsigned 
> long flags)
> if (!tegra)
> return -ENOMEM;
>
> +   if (iommu_present(&platform_bus_type)) {
> +   tegra->domain = iommu_domain_alloc(&platform_bus_type);

Can we use "dma_iommu_mapping" instead of domain?

I thought that DMA API is on the top of IOMMU API so that it may be
cleaner to use only DMA API.


> +   if (IS_ERR(tegra->domain)) {
> +   kfree(tegra);
> +   return PTR_ERR(tegra->domain);
> +   }
> +
> +   drm_mm_init(&tegra->mm, 0, SZ_2G);
> +   }
> +
> mutex_init(&tegra->clients_lock);
> INIT_LIST_HEAD(&tegra->clients);
> drm->dev_private = tegra;
> @@ -71,6 +82,7 @@ static int tegra_drm_load(struct drm_device *drm, unsigned 
> long flags)
>  static int tegra_drm_unload(struct drm_device *drm)
>  {
> struct host1x_device *device = to_host1x_device(drm->dev);
> +   struct tegra_drm *tegra = drm->dev_private;
> int err;
>
> drm_kms_helper_poll_fini(drm);
> @@ -82,6 +94,11 @@ static int tegra_drm_unload(struct drm_device *drm)
> if (err < 0)
> return err;
>
> +   if (tegra->domain) {
> +   iommu_domain_free(tegra->domain);
> +   drm_mm_takedown(&tegra->mm);
> +   }
> +
> return 0;
>  }
>
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index 96d754e7b3eb..a07c796b7edc 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -39,6 +39,9 @@ struct tegra_fbdev {
>  struct tegra_drm {
> struct drm_device *drm;
>
> +   struct iommu_domain *domain;
> +   struct drm_mm mm;
> +
> struct mutex clients

Re: [RFC 10/10] mmc: sdhci-tegra: Add IOMMU support

[Hiroshi DOyu]

Thierry Reding  writes:

> From: Thierry Reding 
>
> Attach to the device's master interface of the IOMMU at .probe() time.
> IOMMU support becomes available via the DMA mapping API interoperation
> code, but this explicit attachment is necessary to ensure proper probe
> order.
>
> Signed-off-by: Thierry Reding 
> ---
>  drivers/mmc/host/sdhci-tegra.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index 33100d10d176..b884614fa4e6 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -237,6 +238,11 @@ static int sdhci_tegra_probe(struct platform_device 
> *pdev)
>   match = of_match_device(sdhci_tegra_dt_match, &pdev->dev);
>   if (!match)
>   return -EINVAL;
> +
> + rc = iommu_attach(&pdev->dev);
> + if (rc < 0)
> + return rc;
> +

I thought that, if we consider that ->probe() should include minimal H/W
probing so that DMA API call in ->probe() could be deferred after
->probe() and till it's in use actually, like opening a device node. For
me this decision(minimal h/w probe) seemed logical but it would add a
new restriction. One advantage is that we could still keep all drivers
wihtout any IOMMU code if it doesn't call DMA API in ->probe().

>   soc_data = match->data;
>  
>   host = sdhci_pltfm_init(pdev, soc_data->pdata, 0);
> @@ -310,6 +316,8 @@ static int sdhci_tegra_remove(struct platform_device 
> *pdev)
>   clk_disable_unprepare(pltfm_host->clk);
>   clk_put(pltfm_host->clk);
>  
> + iommu_detach(&pdev->dev);
> +
>   sdhci_pltfm_free(pdev);
>  
>   return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 04/10] memory: Add Tegra124 memory controller support

[Hiroshi DOyu]

Thierry Reding  writes:

> From: Thierry Reding 
>
> The memory controller on NVIDIA Tegra124 exposes various knobs that can
> be used to tune the behaviour of the clients attached to it.
>
> Currently this driver sets up the latency allowance registers to the HW
> defaults. Eventually an API should be exported by this driver (via a
> custom API or a generic subsystem) to allow clients to register latency
> requirements.
>
> This driver also registers an IOMMU (SMMU) that's implemented by the
> memory controller.
>
> Signed-off-by: Thierry Reding 
> ---
>  drivers/memory/Kconfig   |9 +
>  drivers/memory/Makefile  |1 +
>  drivers/memory/tegra124-mc.c | 1945 
> ++
>  include/dt-bindings/memory/tegra124-mc.h |   30 +
>  4 files changed, 1985 insertions(+)
>  create mode 100644 drivers/memory/tegra124-mc.c
>  create mode 100644 include/dt-bindings/memory/tegra124-mc.h

I prefer reusing the existing SMMU and having MC and SMMU separated
since most of SMMU code are not different from functionality POV, and
new MC features are quite independent of SMMU.

If it's really convenient to combine MC and SMMU into one driver, we
could move "drivers/iomm/tegra-smmu.c" here first, and add MC features
on the top of it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] staging: cxt1e1: Remove useless OS_phystov() and OS_vtophys()

[Daeseok Youn]

OS_phystov()/OS_vtophys() are replaced with __va()/__pa().

Signed-off-by: Daeseok Youn 
---
 drivers/staging/cxt1e1/musycc.c  |   16 
 drivers/staging/cxt1e1/pmcc4_drv.c   |   12 ++--
 drivers/staging/cxt1e1/sbecom_inline_linux.h |   19 ---
 3 files changed, 14 insertions(+), 33 deletions(-)

diff --git a/drivers/staging/cxt1e1/musycc.c b/drivers/staging/cxt1e1/musycc.c
index 9495c0b..563076c 100644
--- a/drivers/staging/cxt1e1/musycc.c
+++ b/drivers/staging/cxt1e1/musycc.c
@@ -103,7 +103,7 @@ musycc_dump_rxbuffer_ring_locked(mch_t *ch)
if (m->data)
 #endif
{
-   dp = (u_int32_t *)OS_phystov((void 
*)(le32_to_cpu(m->data)));
+   dp = __va(le32_to_cpu(m->data));
if (len >= 0x10)
pr_info("%x[%x]: %08X %08X 
%08X %08x\n",
(u_int32_t)dp, len,
@@ -173,7 +173,7 @@ musycc_dump_txbuffer_ring_locked(mch_t *ch)
len = status & LENGTH_MASK;
 
if (m->data) {
-   dp = (u_int32_t *)OS_phystov((void 
*)(le32_to_cpu(m->data)));
+   dp = __va(le32_to_cpu(m->data));
if (len >= 0x10)
pr_info("%x[%x]: %08X %08X %08X 
%08x\n",
(u_int32_t) dp, len,
@@ -328,7 +328,7 @@ musycc_update_tx_thp(mch_t *ch)
musycc_bh_tx_eom(ch->up, ch->gchan);
}
md = ch->txd_irq_srv;
-   ch->up->regram->thp[ch->gchan] = cpu_to_le32(OS_vtophys(md));
+   ch->up->regram->thp[ch->gchan] = cpu_to_le32(__pa(md));
FLUSH_MEM_WRITE();
 
if (ch->tx_full) {
@@ -729,7 +729,7 @@ musycc_chan_proto(int proto)
 static void __init
 musycc_init_port(mpi_t *pi)
 {
-   pci_write_32((u_int32_t *) &pi->reg->gbp, OS_vtophys(pi->regram));
+   pci_write_32((u_int32_t *) &pi->reg->gbp, __pa(pi->regram));
 
pi->regram->grcd =
__constant_cpu_to_le32(MUSYCC_GRCD_RX_ENABLE |
@@ -817,7 +817,7 @@ musycc_init(ci_t *ci)
ci->regram = ci->port[0].regram;
musycc_serv_req(&ci->port[0], SR_CHIP_RESET);
 
-   pci_write_32((u_int32_t *) &ci->reg->gbp, OS_vtophys(ci->regram));
+   pci_write_32((u_int32_t *) &ci->reg->gbp, __pa(ci->regram));
pci_flush_write(ci);
 #ifdef CONFIG_SBE_PMCC4_NCOMM
ci->regram->__glcd = __constant_cpu_to_le32(GCD_MAGIC);
@@ -827,7 +827,7 @@ musycc_init(ci_t *ci)
MUSYCC_GCD_INTB_DISABLE);
 #endif
 
-   ci->regram->__iqp = cpu_to_le32(OS_vtophys(&ci->iqd_p[0]));
+   ci->regram->__iqp = cpu_to_le32(__pa(&ci->iqd_p[0]));
ci->regram->__iql = __constant_cpu_to_le32(INT_QUEUE_SIZE - 1);
pci_write_32((u_int32_t *) &ci->reg->dacbp, 0);
FLUSH_MEM_WRITE();
@@ -1045,7 +1045,7 @@ musycc_bh_rx_eom(mpi_t *pi, int gchan)
if (m2) {
/* substitute the mbuf+cluster */
md->mem_token = m2;
-   md->data = cpu_to_le32(OS_vtophys(
+   md->data = cpu_to_le32(__pa(
   
OS_mem_token_data(m2)));
 
/* pass the received mbuf upward */
@@ -1698,7 +1698,7 @@ musycc_start_xmit(ci_t *ci, int channum, void *mem_token)
 */
md->mem_token = len ? NULL : mem_token;
 
-   md->data = cpu_to_le32(OS_vtophys(OS_mem_token_data(m2)));
+   md->data = cpu_to_le32(__pa(OS_mem_token_data(m2)));
FLUSH_MEM_WRITE();
md->status = cpu_to_le32(u);
--ch->txd_free;
diff --git a/drivers/staging/cxt1e1/pmcc4_drv.c 
b/drivers/staging/cxt1e1/pmcc4_drv.c
index 76bebdd..5f4865a 100644
--- a/drivers/staging/cxt1e1/pmcc4_drv.c
+++ b/drivers/staging/cxt1e1/pmcc4_drv.c
@@ -919,7 +919,7 @@ c4_set_port (ci_t *ci, int portnum)
 
 pci_write_32 ((u_int32_t *) &ci->cpldbase->mclk, clck);
 pci_write_32 ((u_int32_t *) &ci->cpldbase->mcsr, PMCC4_CPLD_MCSR_IND);
-pci_write_32 ((u_int32_t *) &pi->reg->gbp, OS_vtophys (pi->regram));
+pci_write_32 ((u_int32_t *) &pi->reg->gbp, __pa(pi->regram));
 
 /*/
 /* ERRATA: If transparent mode is used, do not set OOFMP_DISABLE bit */
@@ -1355,7 +1355,7 @@ c4_chan_up (ci_t *ci, int channum)
 {
 md->snext = &ch->mdr[i + 1];
 }
-md->next = cpu_to_le32 (OS_vtophys (md->snext));
+md->next = cpu_to_le32 (__pa(md->snext));
 
  

[PATCH 3/3] staging: cxt1e1: remove OS_mem_token_xxxx interfaces in sbecom_inline_linux.h

[Daeseok Youn]

OS_mem_token_ interfaces are useless, so just replaced with
sk_buff related fuctions.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/cxt1e1/musycc.c  |   45 +-
 drivers/staging/cxt1e1/pmcc4_drv.c   |   11 ++--
 drivers/staging/cxt1e1/pmcc4_private.h   |2 +-
 drivers/staging/cxt1e1/sbecom_inline_linux.h |   65 --
 4 files changed, 28 insertions(+), 95 deletions(-)

diff --git a/drivers/staging/cxt1e1/musycc.c b/drivers/staging/cxt1e1/musycc.c
index 5fc45a4..d61f7d9 100644
--- a/drivers/staging/cxt1e1/musycc.c
+++ b/drivers/staging/cxt1e1/musycc.c
@@ -935,16 +935,15 @@ musycc_bh_tx_eom(mpi_t *pi, int gchan)
md->data = 0;
if (md->mem_token) {
/* upcount channel */
-   atomic_sub(OS_mem_token_tlen(md->mem_token),
-  &ch->tx_pending);
+   unsigned int total_len = md->mem_token->len;
+   atomic_sub(total_len, &ch->tx_pending);
/* upcount card */
-   atomic_sub(OS_mem_token_tlen(md->mem_token),
-  &pi->up->tx_pending);
+   atomic_sub(total_len, &pi->up->tx_pending);
 #ifdef SBE_WAN256T3_ENABLE
if (!atomic_read(&pi->up->tx_pending))
wan256t3_led(pi->up, LED_TX, 0);
 #endif
-   OS_mem_token_free_irq(md->mem_token);
+   dev_kfree_skb_irq(md->mem_token);
md->mem_token = NULL;
}
md->status = 0;
@@ -1016,7 +1015,7 @@ static void
 musycc_bh_rx_eom(mpi_t *pi, int gchan)
 {
mch_t  *ch;
-   void   *m, *m2;
+   struct sk_buff *m, *m2;
struct mdesc *md;
volatile u_int32_t status;
u_int32_t   error;
@@ -1041,12 +1040,12 @@ musycc_bh_rx_eom(mpi_t *pi, int gchan)
error = (status >> 16) & 0xf;
if (error == 0) {
{
-   m2 = OS_mem_token_alloc(cxt1e1_max_mru);
+   m2 = dev_alloc_skb(cxt1e1_max_mru);
if (m2) {
/* substitute the mbuf+cluster */
md->mem_token = m2;
md->data = cpu_to_le32(__pa(
-  
OS_mem_token_data(m2)));
+  m2->data));
 
/* pass the received mbuf upward */
sd_recv_consume(m, status & LENGTH_MASK,
@@ -1552,11 +1551,11 @@ musycc_chan_down(ci_t *dummy, int channum)
FLUSH_MEM_WRITE();
for (i = 0; i < ch->txd_num; i++)
if (ch->mdt[i].mem_token)
-   OS_mem_token_free(ch->mdt[i].mem_token);
+   dev_kfree_skb_any(ch->mdt[i].mem_token);
 
for (i = 0; i < ch->rxd_num; i++)
if (ch->mdr[i].mem_token)
-   OS_mem_token_free(ch->mdr[i].mem_token);
+   dev_kfree_skb_any(ch->mdr[i].mem_token);
 
kfree(ch->mdr);
ch->mdr = NULL;
@@ -1574,11 +1573,11 @@ musycc_chan_down(ci_t *dummy, int channum)
 #endif
 
 int
-musycc_start_xmit(ci_t *ci, int channum, void *mem_token)
+musycc_start_xmit(ci_t *ci, int channum, struct sk_buff *mem_token)
 {
mch_t  *ch;
struct mdesc *md;
-   void   *m2;
+   struct sk_buff *m2;
int txd_need_cnt = 0;
u_int32_t   len, data_len;
 
@@ -1611,23 +1610,23 @@ musycc_start_xmit(ci_t *ci, int channum, void 
*mem_token)
/** Determine total amount of data to be sent **/
/***/
m2 = mem_token;
-   len = OS_mem_token_tlen(m2);
+   len = m2->len;
 
while (m2 && len > 0) {
-   data_len = OS_mem_token_len(m2);
+   data_len = m2->data_len;
if (data_len) {
len -= data_len;
txd_need_cnt++;
}
 
-   m2 = OS_mem_token_next(m2);
+   m2 = m2->next;
}
 
if (txd_need_cnt == 0) {
if (cxt1e1_log_level >= LOG_MONITOR2)
pr_info("%s channel %d: no TX data in User buffer\n",
ci->devname, channum);
-   OS_mem_token_free(mem_token);
+   dev_kfree_skb_any(mem_token);
return 0;   /* no data to send */
}
/*/
@@ -1639,7 +1638,7 @@ musycc_start_xmit(ci_t *ci, int channum, void *mem_token)
pr_info("start_xmit: discarding buffer, insufficient 
d

[PATCH v2] dma-mapping: Provide write-combine allocations

[Thierry Reding]

From: Thierry Reding 

Provide an implementation for dma_{alloc,free,mmap}_writecombine() when
the architecture supports DMA attributes.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- Add a generic dma_mmap_writecombine() function

 arch/arm/include/asm/dma-mapping.h   | 16 
 include/asm-generic/dma-mapping-common.h |  8 
 include/linux/dma-mapping.h  | 26 ++
 3 files changed, 26 insertions(+), 24 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index c45b61a4b4a5..85738b200023 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -265,22 +265,6 @@ extern int arm_dma_mmap(struct device *dev, struct 
vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
struct dma_attrs *attrs);
 
-static inline void *dma_alloc_writecombine(struct device *dev, size_t size,
-  dma_addr_t *dma_handle, gfp_t flag)
-{
-   DEFINE_DMA_ATTRS(attrs);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
-   return dma_alloc_attrs(dev, size, dma_handle, flag, &attrs);
-}
-
-static inline void dma_free_writecombine(struct device *dev, size_t size,
-void *cpu_addr, dma_addr_t dma_handle)
-{
-   DEFINE_DMA_ATTRS(attrs);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
-   return dma_free_attrs(dev, size, cpu_addr, dma_handle, &attrs);
-}
-
 /*
  * This can be called during early boot to increase the size of the atomic
  * coherent DMA pool above the default value of 256KiB. It must be called
diff --git a/include/asm-generic/dma-mapping-common.h 
b/include/asm-generic/dma-mapping-common.h
index de8bf89940f8..d137431bf26f 100644
--- a/include/asm-generic/dma-mapping-common.h
+++ b/include/asm-generic/dma-mapping-common.h
@@ -205,14 +205,6 @@ dma_mmap_attrs(struct device *dev, struct vm_area_struct 
*vma, void *cpu_addr,
 
 #define dma_mmap_coherent(d, v, c, h, s) dma_mmap_attrs(d, v, c, h, s, NULL)
 
-static inline int dma_mmap_writecombine(struct device *dev, struct 
vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size)
-{
-   DEFINE_DMA_ATTRS(attrs);
-   dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
-   return dma_mmap_attrs(dev, vma, cpu_addr, dma_addr, size, &attrs);
-}
-
 int
 dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
   void *cpu_addr, dma_addr_t dma_addr, size_t size);
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 931b70986272..d5d388160f42 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -263,6 +263,32 @@ struct dma_attrs;
 #define dma_unmap_sg_attrs(dev, sgl, nents, dir, attrs) \
dma_unmap_sg(dev, sgl, nents, dir)
 
+#else
+static inline void *dma_alloc_writecombine(struct device *dev, size_t size,
+  dma_addr_t *dma_addr, gfp_t gfp)
+{
+   DEFINE_DMA_ATTRS(attrs);
+   dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+   return dma_alloc_attrs(dev, size, dma_addr, gfp, &attrs);
+}
+
+static inline void dma_free_writecombine(struct device *dev, size_t size,
+void *cpu_addr, dma_addr_t dma_addr)
+{
+   DEFINE_DMA_ATTRS(attrs);
+   dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+   return dma_free_attrs(dev, size, cpu_addr, dma_addr, &attrs);
+}
+
+static inline int dma_mmap_writecombine(struct device *dev,
+   struct vm_area_struct *vma,
+   void *cpu_addr, dma_addr_t dma_addr,
+   size_t size)
+{
+   DEFINE_DMA_ATTRS(attrs);
+   dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+   return dma_mmap_attrs(dev, vma, cpu_addr, dma_addr, size, &attrs);
+}
 #endif /* CONFIG_HAVE_DMA_ATTRS */
 
 #ifdef CONFIG_NEED_DMA_MAP_STATE
-- 
2.0.0

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

[PATCH 2/3] staging: cxt1e1: count fragmented packet properly.

[Daeseok Youn]

OS_mem_token_tlen() is same return value as OS_mem_token_len().
That means packet count is always 1. So OS_mem_token_tlen()
must be total length of packet and OS_mem_token_len() has a
length of fragmented packet. And then it can count total
count of fragmented packets properly.

And OS_mem_token_next() returns NULL, it will be dereferencing
a NULL pointer. So it must return next fragmented packet buffer as
sk_buff.

Signed-off-by: Daeseok Youn 
---
I'm not sure of this patch and not tested.(just only build test).
Please review for this.
Thanks.

 drivers/staging/cxt1e1/musycc.c  |   52 +++---
 drivers/staging/cxt1e1/sbecom_inline_linux.h |4 +-
 2 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/cxt1e1/musycc.c b/drivers/staging/cxt1e1/musycc.c
index 563076c..5fc45a4 100644
--- a/drivers/staging/cxt1e1/musycc.c
+++ b/drivers/staging/cxt1e1/musycc.c
@@ -1579,8 +1579,8 @@ musycc_start_xmit(ci_t *ci, int channum, void *mem_token)
mch_t  *ch;
struct mdesc *md;
void   *m2;
-   int txd_need_cnt;
-   u_int32_t   len;
+   int txd_need_cnt = 0;
+   u_int32_t   len, data_len;
 
ch = sd_find_chan(ci, channum);
if (!ch)
@@ -1611,13 +1611,16 @@ musycc_start_xmit(ci_t *ci, int channum, void 
*mem_token)
/** Determine total amount of data to be sent **/
/***/
m2 = mem_token;
-   txd_need_cnt = 0;
-   for (len = OS_mem_token_tlen(m2); len > 0;
-m2 = (void *) OS_mem_token_next(m2)) {
-   if (!OS_mem_token_len(m2))
-   continue;
-   txd_need_cnt++;
-   len -= OS_mem_token_len(m2);
+   len = OS_mem_token_tlen(m2);
+
+   while (m2 && len > 0) {
+   data_len = OS_mem_token_len(m2);
+   if (data_len) {
+   len -= data_len;
+   txd_need_cnt++;
+   }
+
+   m2 = OS_mem_token_next(m2);
}
 
if (txd_need_cnt == 0) {
@@ -1658,13 +1661,18 @@ musycc_start_xmit(ci_t *ci, int channum, void 
*mem_token)
/**/
m2 = mem_token;
md = ch->txd_usr_add;   /* get current available descriptor */
+   len = OS_mem_token_tlen(m2);
 
-   for (len = OS_mem_token_tlen(m2); len > 0; m2 = OS_mem_token_next(m2)) {
-   int u = OS_mem_token_len(m2);
+   while (m2 && len > 0) {
+   u_int32_t data_len = OS_mem_token_len(m2);
+   u_int32_t status = 0;
 
-   if (!u)
+   if (!data_len) {
+   m2 = OS_mem_token_next(m2);
continue;
-   len -= u;
+   }
+
+   len -= data_len;
 
/*
 * Enable following chunks, yet wait to enable the FIRST chunk 
until
@@ -1672,25 +1680,24 @@ musycc_start_xmit(ci_t *ci, int channum, void 
*mem_token)
 */
if (md != ch->txd_usr_add)  /* not first chunk */
/* transfer ownership from HOST to MUSYCC */
-   u |= MUSYCC_TX_OWNED;
+   status |= MUSYCC_TX_OWNED;
 
if (len)/* not last chunk */
-   u |= EOBIRQ_ENABLE;
+   status |= EOBIRQ_ENABLE;
else if (ch->p.chan_mode == CFG_CH_PROTO_TRANS) {
/*
 * Per MUSYCC Ref 6.4.9 for Transparent Mode, the host 
must
 * always clear EOMIRQ_ENABLE in every Transmit Buffer 
Descriptor
 * (IE. don't set herein).
 */
-   u |= EOBIRQ_ENABLE;
+   status |= EOBIRQ_ENABLE;
} else
-   u |= EOMIRQ_ENABLE; /* EOM, last HDLC chunk */
-
+   status |= EOMIRQ_ENABLE; /* EOM, last HDLC chunk */
 
/* last chunk in hdlc mode */
-   u |= (ch->p.idlecode << IDLE_CODE);
+   status |= (ch->p.idlecode << IDLE_CODE);
if (ch->p.pad_fill_count) {
-   u |= (PADFILL_ENABLE | (ch->p.pad_fill_count << 
EXTRA_FLAGS));
+   status |= (PADFILL_ENABLE | (ch->p.pad_fill_count << 
EXTRA_FLAGS));
}
/* Fill in mds on last segment, others set ZERO
 * so that entire token is removed ONLY when ALL
@@ -1700,13 +1707,14 @@ musycc_start_xmit(ci_t *ci, int channum, void 
*mem_token)
 
md->data = cpu_to_le32(__pa(OS_mem_token_data(m2)));
FLUSH_MEM_WRITE();
-   md->status = cpu_to_le32(u);
+   md->status = cpu_to_le32(status);
--ch->txd_free;
md = md->snext;
+
+   

Re: [PATCH 00/13] leds: fix attribute-creation races

[Jiri Kosina]

On Thu, 26 Jun 2014, Greg Kroah-Hartman wrote:

> > Thanks a lot for driving this. I will applied this patchset into my
> > -devel branch. After I got the Ack from Input guys, I will apply it to
> > my for-next branch then.
> 
> Series looks good to me, Johan, thanks for doing this work.

Yeah, looks good to me as well, thanks. The lm8323 change should be Acked 
by Dmitry though, as it's in his area.

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

Re: [PATCH] arch/score/include/uapi/asm/ptrace.h: Add prefix 'SCORE_' for related macros

[Chen Gang]

On 06/25/2014 08:28 AM, Chen Gang wrote:
> On 06/24/2014 10:44 PM, Guenter Roeck wrote:
>> On 06/24/2014 06:24 AM, Chen Gang wrote:
>>> On 06/23/2014 11:03 AM, Chen Gang wrote:
 On 06/22/2014 11:02 PM, Guenter Roeck wrote:
> On 06/22/2014 07:53 AM, Guenter Roeck wrote:
>> I did that, and managed to build gcc.
>>
>> However, when trying to compile score defconfig, I get internal
>> compiler errors in cc1
>> when compiling drivers/tty/tty_mutex.o and block/elevator.o.
>>
>>CC  block/elevator.o
>> score-elf-gcc: internal compiler error: Segmentation fault (program
>> cc1)
>> 0x40c073 execute
>>   ../../gcc/gcc/gcc.c:2848
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See  for instructions.
>> make[1]: *** [block/elevator.o] Error 4
>> make: *** [block/elevator.o] Error 2
>>
>> Do you see that as well ?
>>
>> This is with
>>
>> GNU assembler version 2.24.51 (score-elf) using BFD version (GNU
>> Binutils) 2.24.51.20140622
>>
>> and gcc configured with:
>>
>> Configured with: ../gcc/configure --prefix=/opt/kernel/score
>> --program-prefix=score-elf- \
>> --target=score-elf --without-header --disable-nls --enable-languages=c
>> --disable-threads \
>> --disable-shared --enable-werror=no
>> target_configargs=enable_vtable_verify=yes \
>> --enable-obsolete --disable-libssp --disable-libquadmath
>>
>> Tip of gcc source is commit d8686b0aa945a, tip of binutils source is
>> commit d17c74c1d41.
>> Your assembler fix is included in this version of binutils.
>>
>>>
>>> Can we repeated this issue, or it is random?  I have try it use my
>>> current gcc version, it has no issue.
>>>
>>> If it can be repeated in the latest version, I shall use version compine
>>> (and try step by step) to fix it.
>>>
>>> If real random issue, if possible, please help repeated and generate
>>> coredump file, and put it to a place to let me get back for analysing.
>>>
>> I got the same error each time. You should be able to reproduce it by
>> checking out the latest gcc. If that doesn't produce the error, try
>> checking out sha d8686b0aa945a. I didn't keep that compiler after the tip
>> of the gcc 4.9 branch worked, so I'd have to rebuild it myself
>> to reproduce it myself.
>>
>> Note that compilation of libssp failed with d8686b0aa945a, which is why
>> I disabled it. I didn't try to build it with 4.9.
>>

And I guess, I have found the root cause, and sent related information
to gcc mailing list (also cc to you). And one temporary fix below (can
cross compile score defconfig successfully for latest gcc):

  diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
  index def10a2..af49601 100644
  --- a/gcc/c/c-decl.c
  +++ b/gcc/c/c-decl.c
  @@ -2300,15 +2300,6 @@ merge_decls (tree newdecl, tree olddecl, tree newtype, 
tree oldtype)
   
 if (CODE_CONTAINS_STRUCT (TREE_CODE (olddecl), TS_DECL_WITH_VIS))
   {
  -  /* Merge the section attribute.
  -  We want to issue an error if the sections conflict but that
  -  must be done later in decl_attributes since we are called
  -  before attributes are assigned.  */
  -  if ((DECL_EXTERNAL (olddecl) || TREE_PUBLIC (olddecl) || TREE_STATIC 
(olddecl))
  -   && DECL_SECTION_NAME (newdecl) == NULL
  -   && DECL_SECTION_NAME (olddecl))
  - set_decl_section_name (newdecl, DECL_SECTION_NAME (olddecl));
  -
 /* Copy the assembler name.
 Currently, it can only be defined in the prototype.  */
 COPY_DECL_ASSEMBLER_NAME (olddecl, newdecl);

I shall continue for it, and provide the final property fix for it.

Thanks.

> 
> Thank you very much for your work.
> 
> It is my chance to fix gcc issues which I have planed, I shall continue
> based on it, hope I can finish within this month (within 2014-06-30).
> 
> 
> Thanks.
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

weird oops in kernel/sched/core.c

[Arturo Borrero Gonzalez]

Hi there!

It seems I hit a oops in kernel/sched/core.c

This happened in a libvirt/kvm x86_64 virtual machine. I can't get a
complete report, and the virt-manager only let me know the message in
the screenshot [1].

Is a 3.15 based-kernel. No special workload. I was playing with some
Netfilter modules.

Please keep me in CC as i'm not subscribed to the list.

regards.

[1] http://www.anony.ws/i/2014/06/27/oops.png

-- 
Arturo Borrero González
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio_flash: fix the CPLB miss bug for gpio expanded flash

[Aaron Wu]

In this bug, the address operation range may exceed the
window size defined by gpio expanded flash MTD partition.

Signed-off-by: Aaron Wu 
---
 drivers/mtd/maps/gpio-addr-flash.c |   34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/maps/gpio-addr-flash.c 
b/drivers/mtd/maps/gpio-addr-flash.c
index a4c477b..ca9282f 100644
--- a/drivers/mtd/maps/gpio-addr-flash.c
+++ b/drivers/mtd/maps/gpio-addr-flash.c
@@ -108,13 +108,24 @@ static void gf_copy_from(struct map_info *map, void *to, 
unsigned long from, ssi
 {
struct async_state *state = gf_map_info_to_state(map);
 
-   gf_set_gpios(state, from);
+   int this_len;
 
/* BUG if operation crosses the win_size */
BUG_ON(!((from + len) % state->win_size <= (from + len)));
 
-   /* operation does not cross the win_size, so one shot it */
-   memcpy_fromio(to, map->virt + (from % state->win_size), len);
+   while (len) {
+   if ((from % state->win_size) + len > state->win_size)
+   this_len = state->win_size - (from % state->win_size);
+   else
+   this_len = len;
+
+   gf_set_gpios(state, from);
+   memcpy_fromio(to, map->virt + (from % state->win_size)
+   , this_len);
+   len -= this_len;
+   from += this_len;
+   to += this_len;
+   }
 }
 
 /**
@@ -147,13 +158,24 @@ static void gf_copy_to(struct map_info *map, unsigned 
long to,
 {
struct async_state *state = gf_map_info_to_state(map);
 
-   gf_set_gpios(state, to);
+   int this_len;
 
/* BUG if operation crosses the win_size */
BUG_ON(!((to + len) % state->win_size <= (to + len)));
 
-   /* operation does not cross the win_size, so one shot it */
-   memcpy_toio(map->virt + (to % state->win_size), from, len);
+   while (len) {
+   if ((to % state->win_size) + len > state->win_size)
+   this_len = state->win_size - (to % state->win_size);
+   else
+   this_len = len;
+
+   gf_set_gpios(state, to);
+   memcpy_toio(map->virt + (to % state->win_size), from, len);
+
+   len -= this_len;
+   to += this_len;
+   from += this_len;
+   }
 }
 
 static const char * const part_probe_types[] = {
-- 
1.7.9.5

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

Re: [PATCH 2/2] rsi: fix memory leaks and error handling in rsi_91x_usb

[Jonas Gorski]

On Fri, Jun 27, 2014 at 12:51 AM, Alexey Khoroshilov
 wrote:
> The patch fixes a couple of issues:
> - absence of deallocation of rsi_dev->rx_usb_urb[0] in the driver;
> - potential NULL pointer dereference because of lack of checks for memory
>   allocation success in rsi_init_usb_interface().
>
> By the way, it makes rsi_probe() returning error code instead of 1
> and fixes comments regarding returning values.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov 

I count four different issues being fixed, so maybe split this into
four patches?


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: __schedule #DF splat

[Borislav Petkov]

On Wed, Jun 25, 2014 at 10:26:50PM +0200, Borislav Petkov wrote:
> On Wed, Jun 25, 2014 at 05:32:28PM +0200, Borislav Petkov wrote:
> > Hi guys,
> > 
> > so I'm looking at this splat below when booting current linus+tip/master
> > in a kvm guest. Initially I thought this is something related to the
> > PARAVIRT gunk but it happens with and without it.
> 
> Ok, here's a cleaner splat. I went and rebuilt qemu to latest master
> from today to rule out some breakage there but it still fires.

Ok, another observation: I was using qemu from sources from the other day:

v2.0.0-1806-g2b5b7ae917e8

Switching back to the installed one:

$ qemu-system-x86_64 --version
QEMU emulator version 1.7.1 (Debian 1.7.0+dfsg-6), Copyright (c) 2003-2008 
Fabrice Bellard

fixes the issue.

Joerg says I should bisect but I'm busy with other stuff. If people are
interested in chasing this further, I could free up some time to do
so...

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mfd: sec-core requires regulators

[Lee Jones]

On Fri, 27 Jun 2014, Lee Jones wrote:

> On Tue, 24 Jun 2014, Arnd Bergmann wrote:
> 
> > The newly added sec-core mfd module calls the regulator_suspend_prepare()
> > function, which is only available if the regulator API is provided. This
> > matches the usage of the driver, so we can just add a Kconfig dependency.
> > 
> > Reported-by: Jim Davis 
> > Signed-off-by: Arnd Bergmann 
> 
> Thanks for re-sending Arnd, patch applied.

Slight change of plan - this appears to have been fixed by 591123e.

> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index 207c433..1caa3c5 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -582,7 +582,7 @@ config MFD_RC5T583
> >  
> >  config MFD_SEC_CORE
> > bool "SAMSUNG Electronics PMIC Series Support"
> > -   depends on I2C=y
> > +   depends on I2C=y && REGULATOR
> > select MFD_CORE
> > select REGMAP_I2C
> > select REGMAP_IRQ
> 

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

Re: [PATCH v6 net-next 1/4] net: flow_dissector: avoid multiple calls in eBPF

[Daniel Borkmann]

On 06/26/2014 12:00 AM, Chema Gonzalez wrote:
...

There's still the problem of whether we want to obsolete classic BPF
in the kernel before the tools (libpcap mainly) accept eBPF. This can
take a lot.

Finally, what's the user's CLI interface you have in mind? Right now,
tcpdump expressions are very handy: I know I can pass "ip[2:2] ==
1500" or "(tcp[13] & 0x03)" to any libpcap-based application. This is
very handy to log into a machine, and quickly run tcpdump to get the
packets I'm interested on. What would be the model for using C-- eBPF
filters in the same manner?


Yes, imho, it's a valid question to ask. I think there are a couple
of possibilities for libpcap/tcpdump from a user point of view (note,
I don't strictly think it's the _only_ main user though): 1) iff a
llvm and/or gcc backend gets merged from the compiler side, one could
add a cli interface to run the generated opcodes from a file for
advanced filters while perhaps classic BPF continues to be supported
via its high-level filter expressions; 2) there could be a Linux-only
compiler in libpcap that translates and makes use of full eBPF (though
significantly more effort to implement); 3) libpcap continues to use
classic BPF as it's currently doing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/