[PATCH 2/2] perf/x86: Ivy Bridge-EP uncore support

[Yan, Zheng]

From: "Yan, Zheng" 

The uncore subsystem in Ivy Bridge-EP is similar to Sandy Bridge-EP.
There are some differences in config register encoding and pci device
IDs. The Ivy Bridge-EP uncore also supports a few new events.

Signed-off-by: Yan, Zheng 
---
 arch/x86/kernel/cpu/perf_event_intel_uncore.c | 520 --
 arch/x86/kernel/cpu/perf_event_intel_uncore.h |  51 ++-
 2 files changed, 543 insertions(+), 28 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c 
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 979f81f..54ddede 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -34,9 +34,13 @@ DEFINE_UNCORE_FORMAT_ATTR(occ_sel, occ_sel, "config:14-15");
 DEFINE_UNCORE_FORMAT_ATTR(occ_invert, occ_invert, "config:30");
 DEFINE_UNCORE_FORMAT_ATTR(occ_edge, occ_edge, "config:14-51");
 DEFINE_UNCORE_FORMAT_ATTR(filter_tid, filter_tid, "config1:0-4");
+DEFINE_UNCORE_FORMAT_ATTR(filter_link, filter_link, "config1:5-8");
 DEFINE_UNCORE_FORMAT_ATTR(filter_nid, filter_nid, "config1:10-17");
+DEFINE_UNCORE_FORMAT_ATTR(filter_nid2, filter_nid, "config1:32-47");
 DEFINE_UNCORE_FORMAT_ATTR(filter_state, filter_state, "config1:18-22");
+DEFINE_UNCORE_FORMAT_ATTR(filter_state2, filter_state, "config1:17-22");
 DEFINE_UNCORE_FORMAT_ATTR(filter_opc, filter_opc, "config1:23-31");
+DEFINE_UNCORE_FORMAT_ATTR(filter_opc2, filter_opc, "config1:52-60");
 DEFINE_UNCORE_FORMAT_ATTR(filter_band0, filter_band0, "config1:0-7");
 DEFINE_UNCORE_FORMAT_ATTR(filter_band1, filter_band1, "config1:8-15");
 DEFINE_UNCORE_FORMAT_ATTR(filter_band2, filter_band2, "config1:16-23");
@@ -367,6 +371,7 @@ static struct event_constraint 
snbep_uncore_cbox_constraints[] = {
UNCORE_EVENT_CONSTRAINT(0x04, 0x3),
UNCORE_EVENT_CONSTRAINT(0x05, 0x3),
UNCORE_EVENT_CONSTRAINT(0x07, 0x3),
+   UNCORE_EVENT_CONSTRAINT(0x09, 0x3),
UNCORE_EVENT_CONSTRAINT(0x11, 0x1),
UNCORE_EVENT_CONSTRAINT(0x12, 0x3),
UNCORE_EVENT_CONSTRAINT(0x13, 0x3),
@@ -416,6 +421,14 @@ static struct event_constraint 
snbep_uncore_r3qpi_constraints[] = {
UNCORE_EVENT_CONSTRAINT(0x24, 0x3),
UNCORE_EVENT_CONSTRAINT(0x25, 0x3),
UNCORE_EVENT_CONSTRAINT(0x26, 0x3),
+   UNCORE_EVENT_CONSTRAINT(0x28, 0x3),
+   UNCORE_EVENT_CONSTRAINT(0x29, 0x3),
+   UNCORE_EVENT_CONSTRAINT(0x2a, 0x3),
+   UNCORE_EVENT_CONSTRAINT(0x2b, 0x3),
+   UNCORE_EVENT_CONSTRAINT(0x2c, 0x3),
+   UNCORE_EVENT_CONSTRAINT(0x2d, 0x3),
+   UNCORE_EVENT_CONSTRAINT(0x2e, 0x3),
+   UNCORE_EVENT_CONSTRAINT(0x2f, 0x3),
UNCORE_EVENT_CONSTRAINT(0x30, 0x3),
UNCORE_EVENT_CONSTRAINT(0x31, 0x3),
UNCORE_EVENT_CONSTRAINT(0x32, 0x3),
@@ -423,6 +436,8 @@ static struct event_constraint 
snbep_uncore_r3qpi_constraints[] = {
UNCORE_EVENT_CONSTRAINT(0x34, 0x3),
UNCORE_EVENT_CONSTRAINT(0x36, 0x3),
UNCORE_EVENT_CONSTRAINT(0x37, 0x3),
+   UNCORE_EVENT_CONSTRAINT(0x38, 0x3),
+   UNCORE_EVENT_CONSTRAINT(0x39, 0x3),
EVENT_CONSTRAINT_END
 };
 
@@ -772,55 +787,63 @@ static struct intel_uncore_type snbep_uncore_r3qpi = {
SNBEP_UNCORE_PCI_COMMON_INIT(),
 };
 
+enum {
+   SNBEP_PCI_UNCORE_HA,
+   SNBEP_PCI_UNCORE_IMC,
+   SNBEP_PCI_UNCORE_QPI,
+   SNBEP_PCI_UNCORE_R2PCIE,
+   SNBEP_PCI_UNCORE_R3QPI,
+};
+
 static struct intel_uncore_type *snbep_pci_uncores[] = {
-   _uncore_ha,
-   _uncore_imc,
-   _uncore_qpi,
-   _uncore_r2pcie,
-   _uncore_r3qpi,
+   [SNBEP_PCI_UNCORE_HA]   = _uncore_ha,
+   [SNBEP_PCI_UNCORE_IMC]  = _uncore_imc,
+   [SNBEP_PCI_UNCORE_QPI]  = _uncore_qpi,
+   [SNBEP_PCI_UNCORE_R2PCIE]   = _uncore_r2pcie,
+   [SNBEP_PCI_UNCORE_R3QPI]= _uncore_r3qpi,
NULL,
 };
 
 static DEFINE_PCI_DEVICE_TABLE(snbep_uncore_pci_ids) = {
{ /* Home Agent */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_UNC_HA),
-   .driver_data = (unsigned long)_uncore_ha,
+   .driver_data = SNBEP_PCI_UNCORE_HA,
},
{ /* MC Channel 0 */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_UNC_IMC0),
-   .driver_data = (unsigned long)_uncore_imc,
+   .driver_data = SNBEP_PCI_UNCORE_IMC,
},
{ /* MC Channel 1 */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_UNC_IMC1),
-   .driver_data = (unsigned long)_uncore_imc,
+   .driver_data = SNBEP_PCI_UNCORE_IMC,
},
{ /* MC Channel 2 */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_UNC_IMC2),
-   .driver_data = (unsigned long)_uncore_imc,
+   .driver_data = SNBEP_PCI_UNCORE_IMC,
},
{ /* MC Channel 3 */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_UNC_IMC3),
-   .driver_data = 

[PATCH 1/2] perf/x86: fix SNB-EP CBO and PCU uncore PMU filter management

[Yan, Zheng]

From: "Yan, Zheng" 

The existing code assumes all Cbox and PCU events are using
filter, but actually the filter is event specific. Furthermore
the filter is sub-divided into multiple fields which are used
by different events.

Signed-off-by: Yan, Zheng 
Reported-by: Stephane Eranian 
---
 arch/x86/kernel/cpu/perf_event_intel_uncore.c | 326 +-
 arch/x86/kernel/cpu/perf_event_intel_uncore.h |  13 +-
 2 files changed, 280 insertions(+), 59 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c 
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index b43200d..979f81f 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -17,6 +17,9 @@ static struct event_constraint constraint_fixed =
 static struct event_constraint constraint_empty =
EVENT_CONSTRAINT(0, 0, 0);
 
+#define __BITS_VALUE(x, i, n)  ((typeof(x))(((x) >> ((i) * (n))) & \
+   ((1ULL << (n)) - 1)))
+
 DEFINE_UNCORE_FORMAT_ATTR(event, event, "config:0-7");
 DEFINE_UNCORE_FORMAT_ATTR(event_ext, event, "config:0-7,21");
 DEFINE_UNCORE_FORMAT_ATTR(umask, umask, "config:8-15");
@@ -110,6 +113,21 @@ static void uncore_put_constraint(struct intel_uncore_box 
*box, struct perf_even
reg1->alloc = 0;
 }
 
+static u64 uncore_shared_reg_config(struct intel_uncore_box *box, int idx)
+{
+   struct intel_uncore_extra_reg *er;
+   unsigned long flags;
+   u64 config;
+
+   er = >shared_regs[idx];
+
+   raw_spin_lock_irqsave(>lock, flags);
+   config = er->config;
+   raw_spin_unlock_irqrestore(>lock, flags);
+
+   return config;
+}
+
 /* Sandy Bridge-EP uncore support */
 static struct intel_uncore_type snbep_uncore_cbox;
 static struct intel_uncore_type snbep_uncore_pcu;
@@ -205,7 +223,7 @@ static void snbep_uncore_msr_enable_event(struct 
intel_uncore_box *box, struct p
struct hw_perf_event_extra *reg1 = >extra_reg;
 
if (reg1->idx != EXTRA_REG_NONE)
-   wrmsrl(reg1->reg, reg1->config);
+   wrmsrl(reg1->reg, uncore_shared_reg_config(box, 0));
 
wrmsrl(hwc->config_base, hwc->config | SNBEP_PMON_CTL_EN);
 }
@@ -226,29 +244,6 @@ static void snbep_uncore_msr_init_box(struct 
intel_uncore_box *box)
wrmsrl(msr, SNBEP_PMON_BOX_CTL_INT);
 }
 
-static int snbep_uncore_hw_config(struct intel_uncore_box *box, struct 
perf_event *event)
-{
-   struct hw_perf_event *hwc = >hw;
-   struct hw_perf_event_extra *reg1 = >extra_reg;
-
-   if (box->pmu->type == _uncore_cbox) {
-   reg1->reg = SNBEP_C0_MSR_PMON_BOX_FILTER +
-   SNBEP_CBO_MSR_OFFSET * box->pmu->pmu_idx;
-   reg1->config = event->attr.config1 &
-   SNBEP_CB0_MSR_PMON_BOX_FILTER_MASK;
-   } else {
-   if (box->pmu->type == _uncore_pcu) {
-   reg1->reg = SNBEP_PCU_MSR_PMON_BOX_FILTER;
-   reg1->config = event->attr.config1 & 
SNBEP_PCU_MSR_PMON_BOX_FILTER_MASK;
-   } else {
-   return 0;
-   }
-   }
-   reg1->idx = 0;
-
-   return 0;
-}
-
 static struct attribute *snbep_uncore_formats_attr[] = {
_attr_event.attr,
_attr_umask.attr,
@@ -345,16 +340,16 @@ static struct attribute_group 
snbep_uncore_qpi_format_group = {
.attrs = snbep_uncore_qpi_formats_attr,
 };
 
+#define SNBEP_UNCORE_MSR_OPS_COMMON_INIT() \
+   .init_box   = snbep_uncore_msr_init_box,\
+   .disable_box= snbep_uncore_msr_disable_box, \
+   .enable_box = snbep_uncore_msr_enable_box,  \
+   .disable_event  = snbep_uncore_msr_disable_event,   \
+   .enable_event   = snbep_uncore_msr_enable_event,\
+   .read_counter   = uncore_msr_read_counter
+
 static struct intel_uncore_ops snbep_uncore_msr_ops = {
-   .init_box   = snbep_uncore_msr_init_box,
-   .disable_box= snbep_uncore_msr_disable_box,
-   .enable_box = snbep_uncore_msr_enable_box,
-   .disable_event  = snbep_uncore_msr_disable_event,
-   .enable_event   = snbep_uncore_msr_enable_event,
-   .read_counter   = uncore_msr_read_counter,
-   .get_constraint = uncore_get_constraint,
-   .put_constraint = uncore_put_constraint,
-   .hw_config  = snbep_uncore_hw_config,
+   SNBEP_UNCORE_MSR_OPS_COMMON_INIT(),
 };
 
 static struct intel_uncore_ops snbep_uncore_pci_ops = {
@@ -446,6 +441,145 @@ static struct intel_uncore_type snbep_uncore_ubox = {
.format_group   = _uncore_ubox_format_group,
 };
 
+static struct extra_reg snbep_uncore_cbox_extra_regs[] = {
+   SNBEP_CBO_EVENT_EXTRA_REG(SNBEP_CBO_PMON_CTL_TID_EN,
+ SNBEP_CBO_PMON_CTL_TID_EN, 0x1),
+   SNBEP_CBO_EVENT_EXTRA_REG(0x0334, 0x, 0x4),
+   SNBEP_CBO_EVENT_EXTRA_REG(0x0534, 0x, 0x4),
+   

linux-next: manual merge of the akpm tree with the block tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
block/blk-core.c between commit f79ea4161434 ("block: Refactor
blk_update_request()") from the block tree and commit "block, aio: batch
completion for bios/kiocbs" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc block/blk-core.c
index f224d17,186603b..000
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@@ -2280,9 -2251,11 +2281,10 @@@ EXPORT_SYMBOL(blk_fetch_request)
   * %false - this request doesn't have any more data
   * %true  - this request has more data
   **/
- bool blk_update_request(struct request *req, int error, unsigned int nr_bytes)
+ bool blk_update_request(struct request *req, int error, unsigned int nr_bytes,
+   struct batch_complete *batch)
  {
 -  int total_bytes, bio_nbytes, next_idx = 0;
 -  struct bio *bio;
 +  int total_bytes;
  
if (!req->bio)
return false;
@@@ -2328,21 -2301,56 +2330,21 @@@
  
blk_account_io_completion(req, nr_bytes);
  
 -  total_bytes = bio_nbytes = 0;
 -  while ((bio = req->bio) != NULL) {
 -  int nbytes;
 +  total_bytes = 0;
 +  while (req->bio) {
 +  struct bio *bio = req->bio;
 +  unsigned bio_bytes = min(bio->bi_size, nr_bytes);
  
 -  if (nr_bytes >= bio->bi_size) {
 +  if (bio_bytes == bio->bi_size)
req->bio = bio->bi_next;
 -  nbytes = bio->bi_size;
 -  req_bio_endio(req, bio, nbytes, error, batch);
 -  next_idx = 0;
 -  bio_nbytes = 0;
 -  } else {
 -  int idx = bio->bi_idx + next_idx;
  
-   req_bio_endio(req, bio, bio_bytes, error);
 -  if (unlikely(idx >= bio->bi_vcnt)) {
 -  blk_dump_rq_flags(req, "__end_that");
 -  printk(KERN_ERR "%s: bio idx %d >= vcnt %d\n",
 - __func__, idx, bio->bi_vcnt);
 -  break;
 -  }
++  req_bio_endio(req, bio, bio_bytes, error, batch);
  
 -  nbytes = bio_iovec_idx(bio, idx)->bv_len;
 -  BIO_BUG_ON(nbytes > bio->bi_size);
 +  total_bytes += bio_bytes;
 +  nr_bytes -= bio_bytes;
  
 -  /*
 -   * not a complete bvec done
 -   */
 -  if (unlikely(nbytes > nr_bytes)) {
 -  bio_nbytes += nr_bytes;
 -  total_bytes += nr_bytes;
 -  break;
 -  }
 -
 -  /*
 -   * advance to the next vector
 -   */
 -  next_idx++;
 -  bio_nbytes += nbytes;
 -  }
 -
 -  total_bytes += nbytes;
 -  nr_bytes -= nbytes;
 -
 -  bio = req->bio;
 -  if (bio) {
 -  /*
 -   * end more in this run, or just return 'not-done'
 -   */
 -  if (unlikely(nr_bytes <= 0))
 -  break;
 -  }
 +  if (!nr_bytes)
 +  break;
}
  
/*


pgpVwBKddM2Jq.pgp
Description: PGP signature

linux-next: manual merge of the akpm tree with the block tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got conflicts in
drivers/md/raid1.c and drivers/md/raid10.c between commit 9e882242c619
("block: Add submit_bio_wait(), remove from md") from the block tree and
commit "block: prep work for batch completion" from the akpm tree.

I fixed it up (by removing the functions from the files as in the block
tree patch) and can carry the fix as necessary (no action is required).

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


pgpxPFEbmoB8Q.pgp
Description: PGP signature

Re: [PATCH 05/10] migrate: add hugepage migration code to migrate_pages()

[Naoya Horiguchi]

On Mon, Mar 25, 2013 at 02:04:16PM +0100, Michal Hocko wrote:
> On Fri 22-03-13 16:23:50, Naoya Horiguchi wrote:
> [...]
> > @@ -523,6 +544,11 @@ static inline int check_pmd_range(struct 
> > vm_area_struct *vma, pud_t *pud,
> > pmd = pmd_offset(pud, addr);
> > do {
> > next = pmd_addr_end(addr, end);
> > +   if (pmd_huge(*pmd) && is_vm_hugetlb_page(vma)) {
> > +   check_hugetlb_pmd_range(vma, pmd, nodes,
> > +   flags, private);
> 
> I am afraid this has the same issue with other huge page sizes I have
> mentioned earlier.

So we need arch-dependent helper functions. I'll try that, but it
might be better to start with enabling only x86_64 if it takes time
to implement this.

> > +   continue;
> > +   }
> > split_huge_page_pmd(vma, addr, pmd);
> > if (pmd_none_or_trans_huge_or_clear_bad(pmd))
> > continue;
> [...]
> > @@ -1012,14 +1040,8 @@ static int migrate_to_node(struct mm_struct *mm, int 
> > source, int dest,
> > check_range(mm, mm->mmap->vm_start, mm->task_size, ,
> > flags | MPOL_MF_DISCONTIG_OK, );
> >  
> > -   if (!list_empty()) {
> > -   err = migrate_pages(, new_node_page, dest,
> > +   return migrate_movable_pages(, new_node_page, dest,
> > MIGRATE_SYNC, MR_SYSCALL);
> > -   if (err)
> > -   putback_lru_pages();
> > -   }
> > -
> > -   return err;
> 
> This is really confusing. Why migrate_pages doesn't do putback cleanup
> on its own but migrate_movable_pages does?

I consider migrate_movable_pages() as a wrapper of migrate_pages(),
not the variant of migrate_pages().
We can find the same pattern in the callers like

  if (!list_empty()) {
err = migrate_pages(...);
if (err)
putback_lru_pages();
  }

, so it can be simplified by migrate_movable_pages().

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

linux-next: manual merge of the akpm tree with the block tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
include/linux/blk_types.h between commit a38352e0ac02 ("block: Add an
explicit bio flag for bios that own their bvec") from the block tree and
commit "mm: make snapshotting pages for stable writes a per-bio
operation" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc include/linux/blk_types.h
index e8de670,22990cf..000
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@@ -116,8 -117,7 +117,8 @@@ struct bio 
   * Flags starting here get preserved by bio_reset() - this includes
   * BIO_POOL_IDX()
   */
- #define BIO_RESET_BITS12
- #define BIO_OWNS_VEC  12  /* bio_free() should free bvec */
+ #define BIO_RESET_BITS13
++#define BIO_OWNS_VEC  13  /* bio_free() should free bvec */
  
  #define bio_flagged(bio, flag)((bio)->bi_flags & (1 << (flag)))
  


pgpOTgIDvUY5x.pgp
Description: PGP signature

Re: [PATCH] drivers: virtio: Use PTR_RET function

[Andrew Morton]

On Tue, 26 Mar 2013 13:57:09 +1030 Rusty Russell  wrote:

> Alexandru Gheorghiu  writes:
> 
> > Used PTR_RET function instead of IS_ERR and PTR_ERR.
> > Patch found using coccinelle.
> 
> WTF is PTR_RET?  PTR_RET doesn't return anything.  Why is it called
> that?  It doesn't even make sense.
> 
> ZERO_OR_PTR_ERR() maybe.
> 
> But what problem are we solving?  Insufficient churn in the tree?  Code
> being too readable?  This isn't some hard-to-get right corner case, or a
> missed optimization.
> 
> Andrew, what am I missing here?

It seemed like a good idea at the time.  Merged it two years ago and
have since been keenly awaiting an opportunity to use it.

It seems that people _have_ been using it, but mainly netfilter people
and we know they're all crazy ;)

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

Re: [PATCH] drivers: virtio: Use PTR_RET function

[Rusty Russell]

Alexandru Gheorghiu  writes:

> Used PTR_RET function instead of IS_ERR and PTR_ERR.
> Patch found using coccinelle.

WTF is PTR_RET?  PTR_RET doesn't return anything.  Why is it called
that?  It doesn't even make sense.

ZERO_OR_PTR_ERR() maybe.

But what problem are we solving?  Insufficient churn in the tree?  Code
being too readable?  This isn't some hard-to-get right corner case, or a
missed optimization.

Andrew, what am I missing here?

Grumpy,
Rusty.

> Signed-off-by: Alexandru Gheorghiu 
> ---
>  drivers/virtio/virtio_mmio.c |5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
> index 1ba0d68..d1e664f 100644
> --- a/drivers/virtio/virtio_mmio.c
> +++ b/drivers/virtio/virtio_mmio.c
> @@ -567,10 +567,7 @@ static int vm_cmdline_set(const char *device,
>   pdev = platform_device_register_resndata(_cmdline_parent,
>   "virtio-mmio", vm_cmdline_id++,
>   resources, ARRAY_SIZE(resources), NULL, 0);
> - if (IS_ERR(pdev))
> - return PTR_ERR(pdev);
> -
> - return 0;
> + return PTR_RET(pdev);
>  }
>  
>  static int vm_cmdline_get_device(struct device *dev, void *data)
> -- 
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] mfd: max77686: Use NULL instead of 0

[Sachin Kamat]

'data' is a pointer and hence use NULL instead of 0.
Silences the following warning:
drivers/mfd/max77686.c:49:50: warning: Using plain integer as NULL pointer

Signed-off-by: Sachin Kamat 
Cc: Jonghwa Lee 
---
 drivers/mfd/max77686.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
index 4d73963..1cbb176 100644
--- a/drivers/mfd/max77686.c
+++ b/drivers/mfd/max77686.c
@@ -46,7 +46,7 @@ static struct regmap_config max77686_regmap_config = {
 
 #ifdef CONFIG_OF
 static struct of_device_id max77686_pmic_dt_match[] = {
-   {.compatible = "maxim,max77686",.data = 0},
+   {.compatible = "maxim,max77686", .data = NULL},
{},
 };
 
-- 
1.7.4.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/

signal: Define __ARCH_HAS_SA_RESTORER so we know whether to clear sa_restorer

[Ben Hutchings]

On Thu, 2013-03-21 at 01:41 +, Ben Hutchings wrote:
> On Wed, 2013-03-20 at 21:43 +0100, Sebastian Gottschall (DD-WRT) wrote:
> > Am 20.03.2013 20:02, schrieb Sebastian Gottschall (DD-WRT):
> > > Hello
> > >
> > > The patch for sa_restorer will break mips builds, since sa_restorer 
> > > isnt defined as field within the struct, but the MACRO is.
> > > so use the __ARCH_HAS_SA_RESTORER way which is implemented in that way 
> > > in linux 3.9 or simply revert the patch
> 
> This also appears to break blackfin, ia64, parisc and tile.
> 
> I think for earlier 3.x.y series we can use one of the attached
> (untested) patches to define __ARCH_HAS_SA_RESTORER appropriately, and
> then apply the upstream change:
> 
> commit 522cff142d7d2f9230839c9e1f21a4d8bcc22a4a
> Author: Andrew Morton 
> Date:   Wed Mar 13 14:59:34 2013 -0700
> 
> kernel/signal.c: use __ARCH_HAS_SA_RESTORER instead of SA_RESTORER
> 
> Ben.

The Debian package of 3.2.41, which included these two patches, built on
mips and ia64.  (Actually it failed on ia64, but *compilation* was
successful.)

(This does not, of course, prove that I didn't un-fix the information
leak.)

Here is the first patch again (separate versions for 3.8.y and for
earlier series), now with a more accurate subject line.  I'm going to
include this in 3.2.42.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.

From: Ben Hutchings 
Date: Sun, 25 Nov 2012 22:24:19 -0500
Subject: signal: Define __ARCH_HAS_SA_RESTORER so we know whether to clear sa_restorer

flush_signal_handlers() needs to know whether sigaction::sa_restorer
is defined, not whether SA_RESTORER is defined.  Define the
__ARCH_HAS_SA_RESTORER macro to indicate this.

Vaguely based on upstream commit 574c4866e33d 'consolidate kernel-side
struct sigaction declarations'.

Signed-off-by: Ben Hutchings 
Cc: Al Viro 
---
--- a/arch/arm/include/asm/signal.h
+++ b/arch/arm/include/asm/signal.h
@@ -127,6 +127,7 @@ struct sigaction {
 	__sigrestore_t sa_restorer;
 	sigset_t sa_mask;		/* mask last for extensibility */
 };
+#define __ARCH_HAS_SA_RESTORER
 
 struct k_sigaction {
 	struct sigaction sa;
--- a/arch/avr32/include/asm/signal.h
+++ b/arch/avr32/include/asm/signal.h
@@ -128,6 +128,7 @@ struct sigaction {
 	__sigrestore_t sa_restorer;
 	sigset_t sa_mask;		/* mask last for extensibility */
 };
+#define __ARCH_HAS_SA_RESTORER
 
 struct k_sigaction {
 	struct sigaction sa;
--- a/arch/cris/include/asm/signal.h
+++ b/arch/cris/include/asm/signal.h
@@ -122,6 +122,7 @@ struct sigaction {
 	void (*sa_restorer)(void);
 	sigset_t sa_mask;		/* mask last for extensibility */
 };
+#define __ARCH_HAS_SA_RESTORER
 
 struct k_sigaction {
 	struct sigaction sa;
--- a/arch/h8300/include/asm/signal.h
+++ b/arch/h8300/include/asm/signal.h
@@ -121,6 +121,7 @@ struct sigaction {
 	void (*sa_restorer)(void);
 	sigset_t sa_mask;		/* mask last for extensibility */
 };
+#define __ARCH_HAS_SA_RESTORER
 
 struct k_sigaction {
 	struct sigaction sa;
--- a/arch/m32r/include/asm/signal.h
+++ b/arch/m32r/include/asm/signal.h
@@ -123,6 +123,7 @@ struct sigaction {
 	__sigrestore_t sa_restorer;
 	sigset_t sa_mask;		/* mask last for extensibility */
 };
+#define __ARCH_HAS_SA_RESTORER
 
 struct k_sigaction {
 	struct sigaction sa;
--- a/arch/m68k/include/asm/signal.h
+++ b/arch/m68k/include/asm/signal.h
@@ -119,6 +119,7 @@ struct sigaction {
 	__sigrestore_t sa_restorer;
 	sigset_t sa_mask;		/* mask last for extensibility */
 };
+#define __ARCH_HAS_SA_RESTORER
 
 struct k_sigaction {
 	struct sigaction sa;
--- a/arch/mn10300/include/asm/signal.h
+++ b/arch/mn10300/include/asm/signal.h
@@ -131,6 +131,7 @@ struct sigaction {
 	__sigrestore_t sa_restorer;
 	sigset_t sa_mask;		/* mask last for extensibility */
 };
+#define __ARCH_HAS_SA_RESTORER
 
 struct k_sigaction {
 	struct sigaction sa;
--- a/arch/powerpc/include/asm/signal.h
+++ b/arch/powerpc/include/asm/signal.h
@@ -109,6 +109,7 @@ struct sigaction {
 	__sigrestore_t sa_restorer;
 	sigset_t sa_mask;		/* mask last for extensibility */
 };
+#define __ARCH_HAS_SA_RESTORER
 
 struct k_sigaction {
 	struct sigaction sa;
--- a/arch/s390/include/asm/signal.h
+++ b/arch/s390/include/asm/signal.h
@@ -131,6 +131,7 @@ struct sigaction {
 void (*sa_restorer)(void);
 sigset_t sa_mask;   /* mask last for extensibility */
 };
+#define __ARCH_HAS_SA_RESTORER
 
 struct k_sigaction {
 struct sigaction sa;
--- a/arch/sparc/include/asm/signal.h
+++ b/arch/sparc/include/asm/signal.h
@@ -191,6 +191,7 @@ struct __old_sigaction {
 	unsigned long		sa_flags;
 	void			(*sa_restorer)(void);  /* not used by Linux/SPARC yet */
 };
+#define __ARCH_HAS_SA_RESTORER
 
 typedef struct sigaltstack {
 	void			__user *ss_sp;
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -125,6 +125,8 @@ typedef unsigned long sigset_t;
 extern void do_notify_resume(struct pt_regs *, void *, __u32);
 # endif /* __KERNEL__ */
 
+#define 

Re: [PATCH v2] X.509: Support parse long form of length octets in Authority Key Identifier

[joeyli]

Hi experts, 

I didn't this patch merged to any git tree or maybe I missed.
Where is the right place for send X.509 patch?


Thanks a lot!
Joey Lee

於 四，2013-03-14 於 15:34 +0800，Lee, Chun-Yi 提到：
> From: Chun-Yi Lee 
> 
> Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
> Identifier Extension is:
> 
>AuthorityKeyIdentifier ::= SEQUENCE {
>   keyIdentifier [0] KeyIdentifier   OPTIONAL,
>   authorityCertIssuer   [1] GeneralNamesOPTIONAL,
>   authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
> 
>KeyIdentifier ::= OCTET STRING
> 
> When a certificate also provides
> authorityCertIssuer and authorityCertSerialNumber then the length of
> AuthorityKeyIdentifier SEQUENCE is likely to long form format.
> e.g.
>The example certificate demos/tunala/A-server.pem in openssl source:
> 
> X509v3 Authority Key Identifier:
> keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
> DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority 
> (RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
> serial:00
> 
> Current parsing rule of OID_authorityKeyIdentifier only take care the
> short form format, it causes load certificate to modsign_keyring fail:
> 
> [   12.061147] X.509: Extension: 47
> [   12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)
> 
> So, this patch add the parsing rule for support long form format against
> Authority Key Identifier.
> 
> v2:
>  - Removed comma from author's name.
>  - Moved 'Short Form length' comment inside the if-body.
>  - Changed the type of sub to size_t.
>  - Use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
>  - Moved the key_len's value assignment before alter v.
>  - Fixed the typo of octets.
>  - Add 2 to v before entering the loop for calculate the length.
>  - Removed the comment of check vlen.
> 
> Cc: Rusty Russell 
> Cc: Josh Boyer 
> Cc: Randy Dunlap 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Acked-by: David Howells 
> Signed-off-by: Chun-Yi Lee 
> ---
>  crypto/asymmetric_keys/x509_cert_parser.c |   55 
>  1 files changed, 47 insertions(+), 8 deletions(-)
> 
> diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
> b/crypto/asymmetric_keys/x509_cert_parser.c
> index 7fabc4c..59ab6d2 100644
> --- a/crypto/asymmetric_keys/x509_cert_parser.c
> +++ b/crypto/asymmetric_keys/x509_cert_parser.c
> @@ -373,6 +373,9 @@ int rsa_extract_mpi(void *context, size_t hdrlen,
>   return 0;
>  }
>  
> +/* The keyIdentifier in AuthorityKeyIdentifier SEQUENCE is tag(CONT,PRIM,0) 
> */
> +#define SEQ_TAG_KEYID (ASN1_CONT << 6)
> +
>  /*
>   * Process certificate extensions that are used to qualify the certificate.
>   */
> @@ -407,21 +410,57 @@ int x509_process_extension(void *context, size_t hdrlen,
>   }
>  
>   if (ctx->last_oid == OID_authorityKeyIdentifier) {
> + size_t key_len;
> +
>   /* Get hold of the CA key fingerprint */
>   if (vlen < 5)
>   return -EBADMSG;
> - if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)) ||
> - v[1] != vlen - 2 ||
> - v[2] != (ASN1_CONT << 6) ||
> - v[3] != vlen - 4)
> +
> + /* Authority Key Identifier must be a Constructed SEQUENCE */
> + if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)))
>   return -EBADMSG;
> - v += 4;
> - vlen -= 4;
>  
> - f = kmalloc(vlen * 2 + 1, GFP_KERNEL);
> + /* Authority Key Identifier is not indefinite length */
> + if (unlikely(vlen == ASN1_INDEFINITE_LENGTH))
> + return -EBADMSG;
> +
> + if (vlen < ASN1_INDEFINITE_LENGTH) {
> + /* Short Form length */
> + if (v[1] != vlen - 2 ||
> + v[2] != SEQ_TAG_KEYID ||
> + v[3] != vlen - 4)
> + return -EBADMSG;
> +
> + key_len = v[3];
> + v += 4;
> + } else {
> + /* Long Form length */
> + size_t seq_len = 0;
> + size_t sub = v[1] - ASN1_INDEFINITE_LENGTH;
> +
> + if (sub > 2)
> + return -EBADMSG;
> +
> + /* calculate the length from subsequent octets */
> + v += 2;
> + for (i = 0; i < sub; i++) {
> + seq_len <<= 8;
> + seq_len |= v[i];
> + }
> +
> + if (seq_len != vlen - 2 - sub ||
> + v[sub] != SEQ_TAG_KEYID ||
> + v[sub + 1] > vlen - 4 - sub)
> + return -EBADMSG;
> +
> + key_len = v[sub + 1];
> +   

Re: [PATCH] vfs: dcache: cond_resched in shrink_dentry_list

[Greg Thelen]

On Mon, Mar 25 2013, Dave Chinner wrote:

> On Mon, Mar 25, 2013 at 05:39:13PM -0700, Greg Thelen wrote:
>> On Mon, Mar 25 2013, Dave Chinner wrote:
>> > On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
>> >> Call cond_resched() from shrink_dentry_list() to preserve
>> >> shrink_dcache_parent() interactivity.
>> >> 
>> >> void shrink_dcache_parent(struct dentry * parent)
>> >> {
>> >>   while ((found = select_parent(parent, )) != 0)
>> >>   shrink_dentry_list();
>> >> }
>> >> 
>> >> select_parent() populates the dispose list with dentries which
>> >> shrink_dentry_list() then deletes.  select_parent() carefully uses
>> >> need_resched() to avoid doing too much work at once.  But neither
>> >> shrink_dcache_parent() nor its called functions call cond_resched().
>> >> So once need_resched() is set select_parent() will return single
>> >> dentry dispose list which is then deleted by shrink_dentry_list().
>> >> This is inefficient when there are a lot of dentry to process.  This
>> >> can cause softlockup and hurts interactivity on non preemptable
>> >> kernels.
>> >
>> > Hi Greg,
>> >
>> > I can see how this coul dcause problems, but isn't the problem then
>> > that shrink_dcache_parent()/select_parent() itself is mishandling
>> > the need for rescheduling rather than being a problem with
>> > the shrink_dentry_list() implementation?  i.e. select_parent() is
>> > aborting batching based on a need for rescheduling, but then not
>> > doing that itself and assuming that someone else will do the
>> > reschedule for it?
>> >
>> > Perhaps this is a better approach:
>> >
>> > -  while ((found = select_parent(parent, )) != 0)
>> > +  while ((found = select_parent(parent, )) != 0) {
>> > shrink_dentry_list();
>> > +  cond_resched();
>> > +  }
>> >
>> > With this, select_parent() stops batching when a resched is needed,
>> > we dispose of the list as a single batch and only then resched if it
>> > was needed before we go and grab the next batch. That should fix the
>> > "small batch" problem without the potential for changing the
>> > shrink_dentry_list() behaviour adversely for other users
>> 
>> I considered only modifying shrink_dcache_parent() as you show above.
>> Either approach fixes the problem I've seen.  My initial approach adds
>> cond_resched() deeper into shrink_dentry_list() because I thought that
>> there might a secondary benefit: shrink_dentry_list() would be willing
>> to give up the processor when working on a huge number of dentry.  This
>> could improve interactivity during shrinker and umount.  I don't feel
>> strongly on this and would be willing to test and post the
>> add-cond_resched-to-shrink_dcache_parent approach.
>
> The shrinker has interactivity problems because of the global
> dcache_lru_lock, not because of ithe size of the list passed to
> shrink_dentry_list(). The amount of work that shrink_dentry_list()
> does here is already bound by the shrinker batch size. Hence in the
> absence of the RT folk complaining about significant holdoffs I
> don't think there is an interactivity problem through the shrinker
> path.

No arguments from me.

> As for the unmount path - shrink_dcache_for_umount_subtree() - that
> doesn't use shrink_dentry_list() and so would need it's own internal
> calls to cond_resched().  Perhaps it's shrink_dcache_sb() that you
> are concerned about?  Either way, And there are lots more similar
> issues in the unmount path such as evict_inodes(), so unless you are
> going to give every possible path through unmount/remount/bdev
> invalidation the same treatment then changing shrink_dentry_list()
> won't significantly improve the interactivity of the system
> situation in these paths...

Ok.  As stated, I wasn't sure if the cond_resched() in
shrink_dentry_list() had any appeal.  Apparently it doesn't.  I'll drop
this approach in favor of the following:

--->8---

From: Greg Thelen 
Date: Sat, 23 Mar 2013 18:25:02 -0700
Subject: [PATCH] vfs: dcache: cond_resched in shrink_dcache_parent

Call cond_resched() in shrink_dcache_parent() to maintain
interactivity.

Before this patch:

void shrink_dcache_parent(struct dentry * parent)
{
while ((found = select_parent(parent, )) != 0)
shrink_dentry_list();
}

select_parent() populates the dispose list with dentries which
shrink_dentry_list() then deletes.  select_parent() carefully uses
need_resched() to avoid doing too much work at once.  But neither
shrink_dcache_parent() nor its called functions call cond_resched().
So once need_resched() is set select_parent() will return single
dentry dispose list which is then deleted by shrink_dentry_list().
This is inefficient when there are a lot of dentry to process.  This
can cause softlockup and hurts interactivity on non preemptable
kernels.

This change adds cond_resched() in shrink_dcache_parent().  The
benefit of this is that need_resched() is quickly cleared so that
future calls to select_parent() are able 

Re: [PATCH 03/10] soft-offline: use migrate_pages() instead of migrate_huge_page()

[Naoya Horiguchi]

On Mon, Mar 25, 2013 at 01:31:28PM +0100, Michal Hocko wrote:
> On Fri 22-03-13 16:23:48, Naoya Horiguchi wrote:
> > Currently migrate_huge_page() takes a pointer to a hugepage to be
> > migrated as an argument, instead of taking a pointer to the list of
> > hugepages to be migrated. This behavior was introduced in commit
> > 189ebff28 ("hugetlb: simplify migrate_huge_page()"), and was OK
> > because until now hugepage migration is enabled only for soft-offlining
> > which takes only one hugepage in a single call.
> > 
> > But the situation will change in the later patches in this series
> > which enable other users of page migration to support hugepage migration.
> > They can kick migration for both of normal pages and hugepages
> > in a single call, so we need to go back to original implementation
> > of using linked lists to collect the hugepages to be migrated.
> 
> If the purpose of this patch is to reduce code duplication then you
> should remove migrate_huge_page as it doesn't have any caller anymore.

Yes, that makes sense. I'll do this.

> [...]
> > @@ -1482,12 +1483,20 @@ static int soft_offline_huge_page(struct page 
> > *page, int flags)
> > unlock_page(hpage);
> >  
> > /* Keep page count to indicate a given hugepage is isolated. */
> > -   ret = migrate_huge_page(hpage, new_page, MPOL_MF_MOVE_ALL,
> > -   MIGRATE_SYNC);
> > -   put_page(hpage);
> > +   list_move(>lru, );
> > +   ret = migrate_pages(, new_page, MPOL_MF_MOVE_ALL,
> > +   MIGRATE_SYNC, MR_MEMORY_FAILURE);
> > if (ret) {
> > pr_info("soft offline: %#lx: migration failed %d, type %lx\n",
> > pfn, ret, page->flags);
> > +   /*
> > +* We know that soft_offline_huge_page() tries to migrate
> > +* only one hugepage pointed to by hpage, so we need not
> > +* run through the pagelist here.
> > +*/
> > +   putback_active_hugepage(hpage);
> 
> Maybe I am missing something but why we didn't need to call this before
> when using migrate_huge_page?

migrate_huge_page() does not need list handling before/after the call,
because it's defined to migrate only one hugepage, and it has a page as
an argument, not list_head.

> > +   if (ret > 0)
> > +   ret = -EIO;
> > } else {
> > set_page_hwpoison_huge_page(hpage);
> > dequeue_hwpoisoned_huge_page(hpage);
> > diff --git v3.9-rc3.orig/mm/migrate.c v3.9-rc3/mm/migrate.c
> > index f69f354..66030b6 100644
> > --- v3.9-rc3.orig/mm/migrate.c
> > +++ v3.9-rc3/mm/migrate.c
> > @@ -981,6 +981,8 @@ static int unmap_and_move_huge_page(new_page_t 
> > get_new_page,
> >  
> > unlock_page(hpage);
> >  out:
> > +   if (rc != -EAGAIN)
> > +   putback_active_hugepage(hpage);
> 
> And why do you put it here? If it is called from migrate_pages then the
> caller already does the clean-up (putback_lru_pages).

What the caller of migrate_pages() cleans up is the (huge)pages which failed
to be migrated. And what the above code cleans up is the source hugepage
after the migration succeeds.

The latter clean-up code originally existed, but removed in 189ebff28
("hugetlb: simplify migrate_huge_page()").
This commit cleans up the code based on that there was only one user
of hugepage migration, but that's not true any more.
So the above hunk is a part of revert of the commit.
But it's not a simple revert, because there's one difference between
now and before 189ebff28 that we link hugepages in-use to hugepage_activelist.
Then we finally come to the above change.

Thanks,
Naoya

> > put_page(new_hpage);
> > if (result) {
> > if (rc)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clocksource: Fix build error when !CONFIG_CLKSRC_OF

[Axel Lin]

Fix below build error:

  CC  drivers/clocksource/exynos_mct.o
drivers/clocksource/exynos_mct.c:557:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '__unused'
drivers/clocksource/exynos_mct.c:558:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '__unused'
make[2]: *** [drivers/clocksource/exynos_mct.o] Error 1
make[1]: *** [drivers/clocksource] Error 2
make: *** [drivers] Error 2

This build error is introduced by commit 4d10f054
"clocksource: make CLOCKSOURCE_OF_DECLARE type safe".

Signed-off-by: Axel Lin 
---
 include/linux/clocksource.h |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index ac33184..b84a2f3 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -344,11 +344,7 @@ extern void clocksource_of_init(void);
 .data = (fn == (clocksource_of_init_fn)NULL) ? fn : fn }
 #else
 static inline void clocksource_of_init(void) {}
-#define CLOCKSOURCE_OF_DECLARE(name, compat, fn)   \
-   static const struct of_device_id __clksrc_of_table_##name   \
-   __unused __section(__clksrc_of_table)   \
-= { .compatible = compat,  \
-.data = (fn == (clocksource_of_init_fn)NULL) ? fn : fn }
+#define CLOCKSOURCE_OF_DECLARE(name, compat, fn)
 #endif
 
 #endif /* _LINUX_CLOCKSOURCE_H */
-- 
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 02/10] migrate: make core migration code aware of hugepage

[Naoya Horiguchi]

On Mon, Mar 25, 2013 at 11:57:01AM +0100, Michal Hocko wrote:
> On Fri 22-03-13 16:23:47, Naoya Horiguchi wrote:
...
> > diff --git v3.9-rc3.orig/mm/hugetlb.c v3.9-rc3/mm/hugetlb.c
> > index 98a478e..a787c44 100644
> > --- v3.9-rc3.orig/mm/hugetlb.c
> > +++ v3.9-rc3/mm/hugetlb.c
> > @@ -48,7 +48,8 @@ static unsigned long __initdata 
> > default_hstate_max_huge_pages;
> >  static unsigned long __initdata default_hstate_size;
> >
> >  /*
> > - * Protects updates to hugepage_freelists, nr_huge_pages, and 
> > free_huge_pages
> > + * Protects updates to hugepage_freelists, hugepage_activelist, 
> > nr_huge_pages,
> > + * free_huge_pages, and surplus_huge_pages.
> >   */
>
> Could you get this out into a separate patch and add lockdep assertions
> to functions which do not lock it directly but they rely on it so that
> the locking is more clear?
> e.g. dequeue_huge_page_node, update_and_free_page, try_to_free_low, ...

OK, I'll try it.

> It would a nice cleanup and a lead for future when somebody tries to
> make the locking a bit saner.
>
...
> > @@ -1056,6 +1064,20 @@ int migrate_pages(struct list_head *from, new_page_t 
> > get_new_page,
> > return rc;
> >  }
> >
> > +int migrate_movable_pages(struct list_head *from, new_page_t get_new_page,
> > +   unsigned long private,
> > +   enum migrate_mode mode, int reason)
> > +{
> > +   int err = 0;
> > +
> > +   if (!list_empty(from)) {
> > +   err = migrate_pages(from, get_new_page, private, mode, reason);
> > +   if (err)
> > +   putback_movable_pages(from);
> > +   }
> > +   return err;
> > +}
> > +
>
> There doesn't seem to be any caller for this function. Please move it to
> the patch which uses it.

I would do like that if there's only one user of this function, but I thought
that it's better to separate this part as changes of common code
because this function is commonly used by multiple users which are added by
multiple patches later in this series.

I mean doing like

  Patch 1: core change
  Patch 2: user A (depend on patch 1)
  Patch 3: user B (depend on patch 1)
  Patch 4: user C (depend on patch 1)

is a bit cleaner and easier in bisecting than doing like

  Patch 1: core change + user A
  Patch 2: user B (depend on patch 1)
  Patch 3: user C (depend on patch 1)

. I'm not sure which is standard or well-accepted way.

Thanks,
Naoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ia64 idle: delete (*idle)()

[Len Brown]

From: Len Brown 

3e7fc708eb (ia64 idle: delete pm_idle) in 3.9-rc1
didn't finish the job, leaving an un-initialized
reference to (*idle)().

Reported-by: Lars-Peter Clausen 
Signed-off-by: Len Brown 
---
 arch/ia64/kernel/process.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index e34f565..6f7dc8b 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -291,7 +291,6 @@ cpu_idle (void)
}
 
if (!need_resched()) {
-   void (*idle)(void);
 #ifdef CONFIG_SMP
min_xtp();
 #endif
@@ -299,9 +298,7 @@ cpu_idle (void)
if (mark_idle)
(*mark_idle)(1);
 
-   if (!idle)
-   idle = default_idle;
-   (*idle)();
+   default_idle();
if (mark_idle)
(*mark_idle)(0);
 #ifdef CONFIG_SMP
-- 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/10] migrate: add migrate_entry_wait_huge()

[Naoya Horiguchi]

On Mon, Mar 25, 2013 at 11:13:40AM +0100, Michal Hocko wrote:
> On Fri 22-03-13 16:23:46, Naoya Horiguchi wrote:
> > When we have a page fault for the address which is backed by a hugepage
> > under migration, the kernel can't wait correctly until the migration
> > finishes. This is because pte_offset_map_lock() can't get a correct
> > migration entry for hugepage. This patch adds migration_entry_wait_huge()
> > to separate code path between normal pages and hugepages.
> 
> The changelog is missing a description what is the effect of the bug. I
> assume that we end up busy looping on the huge page page fault until
> migration finishes, right?

Right. I'll add it in the description.

> Should this be applied to the stable tree or the current usage of the huge
> page migration (HWPOISON) is not spread enough?

Yes, it's better to also send it to stable.

> I like how you got rid of the duplication but I think this still doesn't
> work for all archs/huge page sizes.
> 
> [...]
> > diff --git v3.9-rc3.orig/mm/hugetlb.c v3.9-rc3/mm/hugetlb.c
> > index 0a0be33..98a478e 100644
> > --- v3.9-rc3.orig/mm/hugetlb.c
> > +++ v3.9-rc3/mm/hugetlb.c
> > @@ -2819,7 +2819,7 @@ int hugetlb_fault(struct mm_struct *mm, struct 
> > vm_area_struct *vma,
> > if (ptep) {
> > entry = huge_ptep_get(ptep);
> > if (unlikely(is_hugetlb_entry_migration(entry))) {
> > -   migration_entry_wait(mm, (pmd_t *)ptep, address);
> > +   migration_entry_wait_huge(mm, (pmd_t *)ptep, address);
> 
> e.g. ia64 returns pte_t *

We need arch-independent fix.

> [...]
> > +void migration_entry_wait_huge(struct mm_struct *mm, pmd_t *pmd,
> > +   unsigned long address)
> > +{
> > +   spinlock_t *ptl = pte_lockptr(mm, pmd);
> > +   __migration_entry_wait(mm, (pte_t *)pmd, ptl);
> 
> So you are trying to get lockptr from pmd but you have pte in fact. No
> biggy for !USE_SPLIT_PTLOCKS but doesn't work otherwise. So you probably
> need a arch specific huge_pte_lockptr callback for USE_SPLIT_PTLOCKS.

I must fix it, thanks.
And it might be good to generalize the idea of USE_SPLIT_PTLOCKS to pud and pmd.

> Or am I missing something here? All the pte usage in hugetlb is one
> giant mess and I wouldn't be surprised if there were more places
> hardcoded to pmd there.

Yes, that's a big problem on hugetlb and we need many clean-ups.

Thanks,
Naoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] spark: cpufreq: move cpufreq driver to drivers/cpufreq

[Viresh Kumar]

On 26 March 2013 07:30, Viresh Kumar  wrote:
> On 25 March 2013 22:37, David Miller  wrote:
>> From: Viresh Kumar 
>> Date: Mon, 25 Mar 2013 22:24:44 +0530
>>
>>> This patch moves cpufreq driver of SPARK architecture to drivers/cpufreq.
>>
>> I don't know what spark is.
>
> :(
>
> s/spark/sparc ...
>
> I will fix patch in V2..

Mistake was done in code too and not only log :)

Here is re-spin of this patch (attached too in case you want to test):

From: Viresh Kumar 
Date: Mon, 25 Mar 2013 11:20:23 +0530
Subject: [PATCH] sparc: cpufreq:  move cpufreq driver to drivers/cpufreq

This patch moves cpufreq driver of SPARC architecture to drivers/cpufreq.

Cc: David S. Miller 
Cc: sparcli...@vger.kernel.org
Signed-off-by: Viresh Kumar 
---
 arch/sparc/Kconfig | 23 --
 arch/sparc/kernel/Makefile |  3 ---
 drivers/cpufreq/Kconfig| 23 ++
 drivers/cpufreq/Makefile   |  2 ++
 .../cpufreq/sparc-us2e-cpufreq.c   |  0
 .../cpufreq/sparc-us3-cpufreq.c|  0
 6 files changed, 25 insertions(+), 26 deletions(-)
 rename arch/sparc/kernel/us2e_cpufreq.c =>
drivers/cpufreq/sparc-us2e-cpufreq.c (100%)
 rename arch/sparc/kernel/us3_cpufreq.c =>
drivers/cpufreq/sparc-us3-cpufreq.c (100%)

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 289127d..52e7680 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -260,29 +260,6 @@ config HOTPLUG_CPU

 if SPARC64
 source "drivers/cpufreq/Kconfig"
-
-config US3_FREQ
-   tristate "UltraSPARC-III CPU Frequency driver"
-   depends on CPU_FREQ
-   select CPU_FREQ_TABLE
-   help
- This adds the CPUFreq driver for UltraSPARC-III processors.
-
- For details, take a look at .
-
- If in doubt, say N.
-
-config US2E_FREQ
-   tristate "UltraSPARC-IIe CPU Frequency driver"
-   depends on CPU_FREQ
-   select CPU_FREQ_TABLE
-   help
- This adds the CPUFreq driver for UltraSPARC-IIe processors.
-
- For details, take a look at .
-
- If in doubt, say N.
-
 endif

 config US3_MC
diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
index 6cf591b..5276fd4 100644
--- a/arch/sparc/kernel/Makefile
+++ b/arch/sparc/kernel/Makefile
@@ -102,9 +102,6 @@ obj-$(CONFIG_PCI_MSI)+= pci_msi.o

 obj-$(CONFIG_COMPAT) += sys32.o sys_sparc32.o signal32.o

-# sparc64 cpufreq
-obj-$(CONFIG_US3_FREQ)  += us3_cpufreq.o
-obj-$(CONFIG_US2E_FREQ) += us2e_cpufreq.o
 obj-$(CONFIG_US3_MC)+= chmc.o

 obj-$(CONFIG_KPROBES)   += kprobes.o
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 602d5db..a1488f5 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -258,6 +258,29 @@ depends on PPC32 || PPC64
 source "drivers/cpufreq/Kconfig.powerpc"
 endmenu

+menu "SPARC CPU frequency scaling drivers"
+depends on SPARC64
+config SPARC_US3_CPUFREQ
+   tristate "UltraSPARC-III CPU Frequency driver"
+   select CPU_FREQ_TABLE
+   help
+ This adds the CPUFreq driver for UltraSPARC-III processors.
+
+ For details, take a look at .
+
+ If in doubt, say N.
+
+config SPARC_US2E_CPUFREQ
+   tristate "UltraSPARC-IIe CPU Frequency driver"
+   select CPU_FREQ_TABLE
+   help
+ This adds the CPUFreq driver for UltraSPARC-IIe processors.
+
+ For details, take a look at .
+
+ If in doubt, say N.
+endmenu
+
 menu "SH CPU Frequency scaling"
 depends on SUPERH
 config SH_CPU_FREQ
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index ab3a054..050bd0c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -85,4 +85,6 @@ obj-$(CONFIG_ETRAXFS) += 
cris-etraxfs-cpufreq.o
 obj-$(CONFIG_IA64_ACPI_CPUFREQ)+= ia64-acpi-cpufreq.o
 obj-$(CONFIG_LOONGSON2_CPUFREQ)+= loongson2_cpufreq.o
 obj-$(CONFIG_SH_CPU_FREQ)  += sh-cpufreq.o
+obj-$(CONFIG_SPARC_US2E_CPUFREQ)   += sparc-us2e-cpufreq.o
+obj-$(CONFIG_SPARC_US3_CPUFREQ)+= sparc-us3-cpufreq.o
 obj-$(CONFIG_UNICORE32)+= unicore2-cpufreq.o
diff --git a/arch/sparc/kernel/us2e_cpufreq.c
b/drivers/cpufreq/sparc-us2e-cpufreq.c
similarity index 100%
rename from arch/sparc/kernel/us2e_cpufreq.c
rename to drivers/cpufreq/sparc-us2e-cpufreq.c
diff --git a/arch/sparc/kernel/us3_cpufreq.c
b/drivers/cpufreq/sparc-us3-cpufreq.c
similarity index 100%
rename from arch/sparc/kernel/us3_cpufreq.c
rename to drivers/cpufreq/sparc-us3-cpufreq.c


0001-sparc-cpufreq-move-cpufreq-driver-to-drivers-cpufreq.patch
Description: Binary data

Re: [PATCH 05/15] KDB: add more exports for supporting KDB modules v2

[Mike Travis]

On 3/25/2013 7:38 PM, Eric W. Biederman wrote:
> Mike Travis  writes:
> 
>> This patch adds some significant KDB functions to be usable by
>> externally built and loadable KDB modules.   All added functions
>> have been marked EXPORT_SYMBOL_GPL as that seems to be the norm.
>> No 'EXPORT_SYMBOL's were changed from previous instances to avoid
>> breaking existing modules.
> 
> I don't have any real objections.  Although the export of kallsyms
> probably is enough to raise an eyebrow or two.
> 
> Are there plans for these external modules to be merged?
> 
> In general the policy is to not export things unless there are in tree
> users.  Otherwise maitenance can be a challenge if you can't update your
> users when you update their helper functions.  Certainly a symbol being
> exported is not a guarantee that the exported function won't be changed.
> 
> Eric

I have a few of the older KDB modules converted to be built as
regular external kernel modules but I wasn't certain if they would be
accepted into the base kernel source tree.  Both kdbm_dereference.c
and kdbm_debugtypes.c are there which support the following kdb cmds:

"print", "", "Type casting as in lcrash"
"px", "", "Print in hex (type casting) (see 'pxhelp')"
"whatis", or symbol>", "Display the type, or the address for a symbol"
"sizeof", "", "Display the size of a structure, typedef, etc."
"pxhelp", "", "Display help for the px command"
"walk", "", "Walk linked structs (see walkhelp)",
"walkhelp", "", "Display help for the walk command"

These essentially use the kernel symtab to print structure members,
and to walk linked structures from within KDB.  That was the primary
motivation for moving the ksymtab stuff to be externally exported.
It currently has a couple of problems but here's an example:

[8]kdb> md8c1 kdb_current_task
0x81c8ed00 88081d714bf0.Kq. 
  
[8]kdb> px *(task_struct *)0x88081d714bf0
struct task_struct {
state = 0x0
stack = 0x88081d71a000
usage = atomic_t {
counter = 0x2
}
flags = 0x10202040
ptrace = 0x0
wake_entry = struct llist_node {
next = (nil)
}   
  
...

(First 'kdb_current_task' should have been taken as the argument to
the px cmd, and second the printout does not stop with 'q' to the
"more>" prompt.)  I will sign up to merge these if there is interest?

Thanks,
Mike

> 
>> Cc: Tim Bird 
>> Cc: Anton Vorontsov 
>> Cc: Sasha Levin 
>> Cc: Rusty Russell 
>> Cc: Greg Kroah-Hartman 
>> Cc: Cong Wang 
>> Cc: Stephen Boyd 
>> Cc: Al Viro 
>> Cc: Oleg Nesterov 
>> Cc: Eric W. Biederman 
>> Cc: Serge Hallyn 
>> Reviewed-by: Dimitri Sivanich 
>> Signed-off-by: Mike Travis 
>> ---
>> v2: change in handling of EXPORT_SYMBOLS.
>> ---
>>  kernel/debug/kdb/kdb_io.c  |3 +++
>>  kernel/debug/kdb/kdb_main.c|   14 ++
>>  kernel/debug/kdb/kdb_support.c |   17 +
>>  kernel/kallsyms.c  |1 +
>>  4 files changed, 35 insertions(+)
>>
>> --- linux.orig/kernel/debug/kdb/kdb_io.c
>> +++ linux/kernel/debug/kdb/kdb_io.c
>> @@ -30,6 +30,7 @@
>>  char kdb_prompt_str[CMD_BUFLEN];
>>  
>>  int kdb_trap_printk;
>> +EXPORT_SYMBOL_GPL(kdb_trap_printk);
>>  
>>  static int kgdb_transition_check(char *buffer)
>>  {
>> @@ -447,6 +448,7 @@ char *kdb_getstr(char *buffer, size_t bu
>>  kdb_nextline = 1;   /* Prompt and input resets line number */
>>  return kdb_read(buffer, bufsize);
>>  }
>> +EXPORT_SYMBOL_GPL(kdb_getstr);
>>  
>>  /*
>>   * kdb_input_flush
>> @@ -839,6 +841,7 @@ kdb_print_out:
>>  preempt_enable();
>>  return retlen;
>>  }
>> +EXPORT_SYMBOL_GPL(vkdb_printf);
>>  
>>  int kdb_printf(const char *fmt, ...)
>>  {
>> --- linux.orig/kernel/debug/kdb/kdb_main.c
>> +++ linux/kernel/debug/kdb/kdb_main.c
>> @@ -53,6 +53,7 @@ int kdb_grep_trailing;
>>   * Kernel debugger state flags
>>   */
>>  int kdb_flags;
>> +EXPORT_SYMBOL_GPL(kdb_flags);
>>  atomic_t kdb_event;
>>  
>>  /*
>> @@ -60,12 +61,14 @@ atomic_t kdb_event;
>>   * single thread processors through the kernel debugger.
>>   */
>>  int kdb_initial_cpu = -1;   /* cpu number that owns kdb */
>> +EXPORT_SYMBOL_GPL(kdb_initial_cpu);
>>  int kdb_nextline = 1;
>>  int kdb_state;  /* General KDB state */
>>  
>>  struct task_struct *kdb_current_task;
>>  EXPORT_SYMBOL(kdb_current_task);
>>  struct pt_regs *kdb_current_regs;
>> +EXPORT_SYMBOL_GPL(kdb_current_regs);
>>  
>>  const char *kdb_diemsg;
>>  static int kdb_go_count;
>> @@ -186,6 +189,7 @@ struct task_struct *kdb_curr_task(int cp
>>  #endif
>>  return p;
>>  }
>> +EXPORT_SYMBOL_GPL(kdb_curr_task);
>>  
>>  /*
>>   * kdbgetenv - This function will return the character string value of
>> @@ -217,6 +221,7 @@ char *kdbgetenv(const char 

linux-next: build failure after merge of the char-misc tree

[Stephen Rothwell]

Hi all,

After merging the char-misc tree, today's linux-next build
(x86_64_allmodconfig) failed like this:

drivers/input/keyboard/pmic8xxx-keypad.c:24:35: fatal error: 
linux/mfd/pm8xxx/gpio.h: No such file or directory

Caused by commit e44b0ceee4cc ("add single-wire serial bus interface
(SSBI) driver") which added the Kconfig symbol MSM_SSBI (later changed to
just SSBI) which did not exist in the tree before.  However,
MFD_PM8921_CORE depended on it and that selects MFD_PM8XXX which allows
the above file to build (and fail).

I have used the char-misc tree from next-20130325 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpiUi9N76tH1.pgp
Description: PGP signature

Re: [PATCH] powerpc: remove two lines of dead code

[Michael Ellerman]

On Mon, Mar 25, 2013 at 11:32:11AM +0100, Paul Bolle wrote:
> Commit c1fb6816fb1b78dd94b673b0fdaa9a7a16e97bd1 ("powerpc: Add
> relocation on exception vector handlers") added two lines of code that
> depend on the macro CONFIG_HVC_SCOM. That macro doesn't exist. Perhaps
> it was intended to use CONFIG_PPC_SCOM here. But since
> "maintence_interrupt" is a typo and there's nothing in arch/powerpc that
> looks like maintenance_interrupt it seems best to just delete these
> lines.

It's cruft from our internal tree that snuck into the patch. I was
meaning to remove it but you beat me to it.

Acked-by: Michael Ellerman 

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

Re: [PATCH 1/1 v1] the recommended crash memory reservation is too small for x86_64.

[WANG Chao]

On 03/25/2013 07:52 PM, 周洲仪 wrote:
> Thanks for reviewing
>   Is it sounds good to add following line into section "Boot into System 
> Kernel":
> 
>   The memory reserved for crash kernel should be no less than the unpacked 
> init ram disk size
> that loaded with dump-capture kernel plus wired memory used by kernel itself.

Sorry, that is just basic knowledge for everyone.

> 
>   #
>   After all, I have been trapped into "hang after capture" problem when 
> sticking strictly to this document.
> Cheers
> Zhouyi  
> 
>>  
>>  On 03/25/2013 06:56 PM, zhouzho...@gmail.com wrote:
>>  > From: root 
>>  > 
>>  > 
>>  >  On Documentation/kdump/kdump.txt, section Boot into  System Kernel: On 
>> x86 and x86_64, use
>>  >  "crashkernel=64M@16M", but some OSes like ubuntu 12.10 use ram fs larger 
>> than 64M, so in these cases the
>>  >  memory reserved for crashkernel should be at least 128M.
>>  
>>  People use different initramfs generators for different purpose. That means
>>  the size of initramfs and also its memory consuming can vary very much from
>>  each other. You just can't list all these generators and their recommended
>>  reserved memory here. Though I have to say crashkernel=128M is good choice.
>>  
>>  I think it would be better to leave this to user or distribution itself to
>>  determine how much memory should be reserved for crash kernel, then export
>>  this value to kernel in some ways.
>>  
>>  Thanks,
>>  WANG Chao
>>  
>>  > 
>>  > 
>>  > Signed-off-by: Zhouyi Zhou 
>>  > ---
>>  >  Documentation/kdump/kdump.txt |4 +++-
>>  >  1 file changed, 3 insertions(+), 1 deletion(-)
>>  > 
>>  > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
>>  > index 13f1aa0..1e850e0 100644
>>  > --- a/Documentation/kdump/kdump.txt
>>  > +++ b/Documentation/kdump/kdump.txt
>>  > @@ -290,7 +290,9 @@ Boot into System Kernel
>>  > "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of 
>> memory
>>  > starting at physical address 0x0100 (16MB) for the dump-capture 
>> kernel.
>>  >  
>>  > -   On x86 and x86_64, use "crashkernel=64M@16M".
>>  > +   On x86 and x86_64, use "crashkernel=64M@16M" (some OSes use init ram 
>> fs larger
>>  > +than 64M, for example ubuntu-12.10, use crashkernel=128M@16M instead, or 
>> dump-capture
>>  > +kernel will out of memory).
>>  >  
>>  > On ppc64, use "crashkernel=128M@32M".
>>  >  
>>  > 
>>  
> 
> 
> 
> 

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

linux-next: manual merge of the usb tree with the tty tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
drivers/usb/serial/usb-serial.c between commit 6aad04f21374 ("TTY: add
tty_port_tty_wakeup helper") from the tty tree and commit d12e211d4484
("USB: serial: clean up debug info") from the usb tree.

I fixed it up (I just used the version of usb_serial_port_work() from the
tty tree - see below) and can carry the fix as necessary (no action is
required).

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

diff --cc drivers/usb/serial/usb-serial.c
index 2f60474,5eb96df..000
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@@ -542,11 -538,19 +538,11 @@@ static void usb_serial_port_work(struc
  {
struct usb_serial_port *port =
container_of(work, struct usb_serial_port, work);
 -  struct tty_struct *tty;
  
 -  tty = tty_port_tty_get(>port);
 -  if (!tty)
 -  return;
 -
 -  dev_dbg(tty->dev, "%s\n", __func__);
 -
 -  tty_wakeup(tty);
 -  tty_kref_put(tty);
 +  tty_port_tty_wakeup(>port);
  }
  
- static void kill_traffic(struct usb_serial_port *port)
+ static void usb_serial_port_poison_urbs(struct usb_serial_port *port)
  {
int i;
  


pgpUCEGNenYTy.pgp
Description: PGP signature

[PATCH] ptp_pch: eliminate a number of sparse warnings

[kpark3469]

From: Sahara 

This fixes a number of sparse warnings like:
  warning: incorrect type in argument 2 (different address spaces)
expected void volatile [noderef] *addr
got unsigned int *

  warning: Using plain integer as NULL pointer

Additionally this fixes a warning from checkpatch.pl like:
  WARNING: sizeof pch_param.station should be sizeof(pch_param.station)

Signed-off-by: Sahara 
---
 drivers/ptp/ptp_pch.c |   27 ++-
 1 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
index 1367655..d1adb19 100644
--- a/drivers/ptp/ptp_pch.c
+++ b/drivers/ptp/ptp_pch.c
@@ -118,7 +118,7 @@ struct pch_ts_regs {
  * struct pch_dev - Driver private data
  */
 struct pch_dev {
-   struct pch_ts_regs *regs;
+   struct pch_ts_regs __iomem *regs;
struct ptp_clock *ptp_clock;
struct ptp_clock_info caps;
int exts0_enabled;
@@ -154,7 +154,7 @@ static inline void pch_eth_enable_set(struct pch_dev *chip)
iowrite32(val, (>regs->ts_sel));
 }
 
-static u64 pch_systime_read(struct pch_ts_regs *regs)
+static u64 pch_systime_read(struct pch_ts_regs __iomem *regs)
 {
u64 ns;
u32 lo, hi;
@@ -169,7 +169,7 @@ static u64 pch_systime_read(struct pch_ts_regs *regs)
return ns;
 }
 
-static void pch_systime_write(struct pch_ts_regs *regs, u64 ns)
+static void pch_systime_write(struct pch_ts_regs __iomem *regs, u64 ns)
 {
u32 hi, lo;
 
@@ -315,7 +315,7 @@ int pch_set_station_address(u8 *addr, struct pci_dev *pdev)
struct pch_dev *chip = pci_get_drvdata(pdev);
 
/* Verify the parameter */
-   if ((chip->regs == 0) || addr == (u8 *)NULL) {
+   if ((chip->regs == NULL) || addr == (u8 *)NULL) {
dev_err(>dev,
"invalid params returning PCH_INVALIDPARAM\n");
return PCH_INVALIDPARAM;
@@ -361,7 +361,7 @@ EXPORT_SYMBOL(pch_set_station_address);
 static irqreturn_t isr(int irq, void *priv)
 {
struct pch_dev *pch_dev = priv;
-   struct pch_ts_regs *regs = pch_dev->regs;
+   struct pch_ts_regs __iomem *regs = pch_dev->regs;
struct ptp_clock_event event;
u32 ack = 0, lo, hi, val;
 
@@ -415,7 +415,7 @@ static int ptp_pch_adjfreq(struct ptp_clock_info *ptp, s32 
ppb)
u32 diff, addend;
int neg_adj = 0;
struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
-   struct pch_ts_regs *regs = pch_dev->regs;
+   struct pch_ts_regs __iomem *regs = pch_dev->regs;
 
if (ppb < 0) {
neg_adj = 1;
@@ -438,7 +438,7 @@ static int ptp_pch_adjtime(struct ptp_clock_info *ptp, s64 
delta)
s64 now;
unsigned long flags;
struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
-   struct pch_ts_regs *regs = pch_dev->regs;
+   struct pch_ts_regs __iomem *regs = pch_dev->regs;
 
spin_lock_irqsave(_dev->register_lock, flags);
now = pch_systime_read(regs);
@@ -455,7 +455,7 @@ static int ptp_pch_gettime(struct ptp_clock_info *ptp, 
struct timespec *ts)
u32 remainder;
unsigned long flags;
struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
-   struct pch_ts_regs *regs = pch_dev->regs;
+   struct pch_ts_regs __iomem *regs = pch_dev->regs;
 
spin_lock_irqsave(_dev->register_lock, flags);
ns = pch_systime_read(regs);
@@ -472,7 +472,7 @@ static int ptp_pch_settime(struct ptp_clock_info *ptp,
u64 ns;
unsigned long flags;
struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
-   struct pch_ts_regs *regs = pch_dev->regs;
+   struct pch_ts_regs __iomem *regs = pch_dev->regs;
 
ns = ts->tv_sec * 10ULL;
ns += ts->tv_nsec;
@@ -567,9 +567,9 @@ static void pch_remove(struct pci_dev *pdev)
free_irq(pdev->irq, chip);
 
/* unmap the virtual IO memory space */
-   if (chip->regs != 0) {
+   if (chip->regs != NULL) {
iounmap(chip->regs);
-   chip->regs = 0;
+   chip->regs = NULL;
}
/* release the reserved IO memory space */
if (chip->mem_base != 0) {
@@ -670,7 +670,7 @@ pch_probe(struct pci_dev *pdev, const struct pci_device_id 
*id)
 err_req_irq:
ptp_clock_unregister(chip->ptp_clock);
iounmap(chip->regs);
-   chip->regs = 0;
+   chip->regs = NULL;
 
 err_ioremap:
release_mem_region(chip->mem_base, chip->mem_size);
@@ -723,7 +723,8 @@ static s32 __init ptp_pch_init(void)
 module_init(ptp_pch_init);
 module_exit(ptp_pch_exit);
 
-module_param_string(station, pch_param.station, sizeof pch_param.station, 
0444);
+module_param_string(station,
+pch_param.station, sizeof(pch_param.station), 0444);
 MODULE_PARM_DESC(station,
 "IEEE 1588 station address to use - column separated hex values");
 
-- 
1.7.1

--
To unsubscribe from this list: send the 

RE: [PATCH 09/16] ia64 idle: delete pm_idle

[Brown, Len]

> > -   idle = pm_idle;
> > if (!idle)
> 
> Hm, if I'm not mistaken idle will uninitialized at this point, so this
> could quite likely lead to a crash.


thanks,
will fix.

-Len

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] include/linux/platform_data: beautify code, 'inline' is better in front of 'void'

[Chen Gang]

On 2013年03月26日 10:47, Nicolas Pitre wrote:
> On Tue, 26 Mar 2013, Chen Gang wrote:
> 
>>   a hacker may find something "valuable" with the aid of compiler   ;-)
>>
>>   maybe, it is a patch which is too minor to apply. I can understand :-)
> 
> You should send such patches to Jiri Kosina .
> 

  ok

> 
> Nicolas
> 
> 


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: remove CONFIG_GENERIC_FIND_NEXT_BIT again

[rkuo]

> CONFIG_GENERIC_FIND_NEXT_BIT was removed in v3.0, but reappeared in two
> architectures. Remove it again.
>
> Signed-off-by: Paul Bolle 
> ---
> 0) Untested.
>
> 1) See commit 63e424c84429903c92a0f1e9654c31ccaf6694d0 ("arch: remove
> CONFIG_GENERIC_FIND_{NEXT_BIT,BIT_LE,LAST_BIT}") for the removal of this
> Kconfig symbol.
>
> 2) Sent as one patch. Feel free to tell me to split it up in two
> patches.
>
>  arch/hexagon/Kconfig  | 3 ---
>  arch/openrisc/Kconfig | 3 ---
>  2 files changed, 6 deletions(-)
>

I'd be fine pulling these into my tree to go with my next batch of
changes, or the OpenRISC folks can if they want.  Ack would be nice.

Just in case:

Acked-by: Richard Kuo 


Thanks,
Richard Kuo



--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


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

Re: [PATCH] include/linux/platform_data: beautify code, 'inline' is better in front of 'void'

[Nicolas Pitre]

On Tue, 26 Mar 2013, Chen Gang wrote:

>   a hacker may find something "valuable" with the aid of compiler   ;-)
> 
>   maybe, it is a patch which is too minor to apply. I can understand :-)

You should send such patches to Jiri Kosina .


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

Re: [RFC PATCH] sched: wake-affine throttle

[Michael Wang]

On 03/25/2013 10:31 PM, Mike Galbraith wrote:
[snip]
>>
>> Do you mean 1ms interval is still too big? and you prefer to have a 0
>> option?
> 
> Not really, I just think a fixed interval may not be good enough without
> some idle time consideration.  Once a single load gets going less
> balancing is more, it's just when load is fluctuating a lot, and mixed
> loads where I can imagine troubles.
> 
> Perhaps ramp up to knob interval after an idle period trigger of.. say
> migration_cost, or whatever.  Something dirt simple that makes it open
> the gates when it's most likely to matter.
> 

So a dynamically adjustment, sounds attractively ;-)

However, IMHO, I don't think we could be able to figure out when to
adjust and how to adjust, actually we even don't have the data to count
on, otherwise, there is no necessary to throttle the wake-affine stuff
at all...

May be do such work in user space will be better?

This knob is nothing but compromise, besides, it's a highlight to notify
us we still have a feature waiting for improve, if later we have the way
to build an accurate wake-affine, remove the knob should be easy.

Regards,
Michael Wang

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

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

[PATCH v5 3/5] PCI/AER: clean all untracked pci_ops_aer when rmmod aer_inject

[Yijing Wang]

When we do hot plug for pci devices that were injected aer errors, some newly 
created child buses'
pci_ops will be assigned to pci_ops_aer. Aer_inject module will not track these 
pci_ops_aer(not
list in pci_bus_ops_list),so we should clean all of these when rmmod aer_inject 
module.

Reviewed-by: Huang Ying 
Signed-off-by: Yijing Wang 

---
 drivers/pci/pcie/aer/aer_inject.c |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pcie/aer/aer_inject.c 
b/drivers/pci/pcie/aer/aer_inject.c
index f499f01..4777c44 100644
--- a/drivers/pci/pcie/aer/aer_inject.c
+++ b/drivers/pci/pcie/aer/aer_inject.c
@@ -285,6 +285,29 @@ static void pci_bus_ops_init(struct pci_bus_ops *bus_ops,
bus_ops->ops = ops;
 }
 
+static void pci_clean_child_aer_ops(struct pci_bus *bus)
+{
+   struct pci_bus *child;
+
+   list_for_each_entry(child, >children, node) {
+   if (child->ops == _ops_aer)
+   pci_bus_set_ops(child, bus->ops);
+   pci_clean_child_aer_ops(child);
+   }
+}
+
+/* find pci_ops_aer from root bus, and replace it by parent bus's pci_ops.
+ * pci_ops of root bus won't be pci_ops_aer here*/
+static void clean_untracked_pci_ops_aer(void)
+{
+   struct pci_bus_ops *bus_ops;
+
+   list_for_each_entry(bus_ops, _bus_ops_list, list) {
+   if (pci_is_root_bus(bus_ops->bus))
+   pci_clean_child_aer_ops(bus_ops->bus);
+   }
+}
+
 static int pci_bus_set_aer_ops(struct pci_bus *bus)
 {
struct pci_ops *ops;
@@ -546,6 +569,7 @@ static void __exit aer_inject_exit(void)
list_for_each_entry(bus_ops, _bus_ops_list, list)
pci_bus_set_ops(bus_ops->bus, bus_ops->ops);
 
+   clean_untracked_pci_ops_aer();
while ((bus_ops = pci_bus_ops_pop()))
kfree(bus_ops);
 
-- 
1.7.1


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

[PATCH v5 5/5] PCI/AER: free pci_bus_ops_list and remove pci_bus_ops_pop

[Yijing Wang]

Rewrite pci_bus_ops_list release code for simplification, and clean
no used function pci_bus_ops_pop().

Reviewed-by: Huang Ying 
Signed-off-by: Yijing Wang 

---
 drivers/pci/pcie/aer/aer_inject.c |   25 ++---
 1 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/drivers/pci/pcie/aer/aer_inject.c 
b/drivers/pci/pcie/aer/aer_inject.c
index c5372dd..14d2c92 100644
--- a/drivers/pci/pcie/aer/aer_inject.c
+++ b/drivers/pci/pcie/aer/aer_inject.c
@@ -143,23 +143,6 @@ static struct pci_ops *__find_pci_bus_ops(struct pci_bus 
*bus)
return __find_pci_bus_ops_parent(bus);
 }
 
-static struct pci_bus_ops *pci_bus_ops_pop(void)
-{
-   unsigned long flags;
-   struct pci_bus_ops *bus_ops = NULL;
-
-   spin_lock_irqsave(_lock, flags);
-   if (list_empty(_bus_ops_list))
-   bus_ops = NULL;
-   else {
-   struct list_head *lh = pci_bus_ops_list.next;
-   list_del(lh);
-   bus_ops = list_entry(lh, struct pci_bus_ops, list);
-   }
-   spin_unlock_irqrestore(_lock, flags);
-   return bus_ops;
-}
-
 static u32 *find_pci_config_dword(struct aer_error *err, int where,
  int *prw1cs)
 {
@@ -608,7 +591,7 @@ static void __exit aer_inject_exit(void)
 {
struct aer_error *err, *err_next;
unsigned long flags;
-   struct pci_bus_ops *bus_ops;
+   struct pci_bus_ops *bus_ops, *tmp_ops;
 
bus_unregister_notifier(_bus_type, _hp_notifier);
misc_deregister(_inject_device);
@@ -617,8 +600,12 @@ static void __exit aer_inject_exit(void)
pci_bus_set_ops(bus_ops->bus, bus_ops->ops);
 
clean_untracked_pci_ops_aer();
-   while ((bus_ops = pci_bus_ops_pop()))
+
+   /* free pci_bus_ops_list */
+   list_for_each_entry_safe(bus_ops, tmp_ops, _bus_ops_list, list) {
+   list_del(_ops->list);
kfree(bus_ops);
+   }
 
spin_lock_irqsave(_lock, flags);
list_for_each_entry_safe(err, err_next, , list) {
-- 
1.7.1


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

[PATCH v5 2/5] PCI/AER: use list_for_each_entry to avoid a small race condition window

[Yijing Wang]

When we rmmod aer_inject module, there is a small race condition window between 
pci_bus_ops_pop()
and pci_bus_set_ops() in aer_inject_exit, eg. pci_read_aer/pci_write_aer was 
called between
them. So keep pci_bus_ops_list until pci_bus_set_ops complete, use 
list_for_each_entry() instead of
pci_bus_ops_pop to get bus_ops.

Signed-off-by: Yijing Wang 
---
 drivers/pci/pcie/aer/aer_inject.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pcie/aer/aer_inject.c 
b/drivers/pci/pcie/aer/aer_inject.c
index fdab3bb..f499f01 100644
--- a/drivers/pci/pcie/aer/aer_inject.c
+++ b/drivers/pci/pcie/aer/aer_inject.c
@@ -543,10 +543,11 @@ static void __exit aer_inject_exit(void)
 
misc_deregister(_inject_device);
 
-   while ((bus_ops = pci_bus_ops_pop())) {
+   list_for_each_entry(bus_ops, _bus_ops_list, list)
pci_bus_set_ops(bus_ops->bus, bus_ops->ops);
+
+   while ((bus_ops = pci_bus_ops_pop()))
kfree(bus_ops);
-   }
 
spin_lock_irqsave(_lock, flags);
list_for_each_entry_safe(err, err_next, , list) {
-- 
1.7.1


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

[PATCH v5 1/5] PCI/AER: Fix pci_ops return NULL in pci_read/write_aer

[Yijing Wang]

When we injected aer errors to the pcie device by aer_inject module, pci_ops of 
the pci
bus the device on will be assigned to pci_ops_aer.So if the target pci device
is a bridge, once we hot-remove and hot-add the bridge, the newly created child 
bus's pci_ops
will be assigned to pci_ops_aer too.Now every access to the child bus's device 
will cause the
system panic, because it will get a NULL pci_ops in pci_read_aer/pci_write_aer.

Reviewed-by: Huang Ying 
Signed-off-by: Yijing Wang 
Signed-off-by: Jiang Liu 
Reviewed-by: Sven Dietrich 
---
 drivers/pci/pcie/aer/aer_inject.c |   26 +-
 1 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/pcie/aer/aer_inject.c 
b/drivers/pci/pcie/aer/aer_inject.c
index 4e24cb8..fdab3bb 100644
--- a/drivers/pci/pcie/aer/aer_inject.c
+++ b/drivers/pci/pcie/aer/aer_inject.c
@@ -109,6 +109,26 @@ static struct aer_error *__find_aer_error_by_dev(struct 
pci_dev *dev)
return __find_aer_error((u16)domain, dev->bus->number, dev->devfn);
 }
 
+/* find pci_ops of the nearest parent bus */
+static struct pci_ops *__find_pci_bus_ops_parent(struct pci_bus *bus)
+{
+   struct pci_bus_ops *bus_ops;
+   struct pci_bus *pbus = bus->parent;
+
+   if (!pbus)
+   return NULL;
+
+   while (pbus) {
+   list_for_each_entry(bus_ops, _bus_ops_list, list)
+   if (bus_ops->bus == pbus)
+   return bus_ops->ops;
+
+   pbus = pbus->parent;
+   }
+
+   return NULL;
+}
+
 /* inject_lock must be held before calling */
 static struct pci_ops *__find_pci_bus_ops(struct pci_bus *bus)
 {
@@ -118,7 +138,9 @@ static struct pci_ops *__find_pci_bus_ops(struct pci_bus 
*bus)
if (bus_ops->bus == bus)
return bus_ops->ops;
}
-   return NULL;
+
+   /* can't find bus_ops, fall back to get bus_ops of parent bus */
+   return __find_pci_bus_ops_parent(bus);
 }
 
 static struct pci_bus_ops *pci_bus_ops_pop(void)
@@ -208,6 +230,7 @@ static int pci_read_aer(struct pci_bus *bus, unsigned int 
devfn, int where,
}
 out:
ops = __find_pci_bus_ops(bus);
+   BUG_ON(!ops);
spin_unlock_irqrestore(_lock, flags);
return ops->read(bus, devfn, where, size, val);
 }
@@ -243,6 +266,7 @@ int pci_write_aer(struct pci_bus *bus, unsigned int devfn, 
int where, int size,
}
 out:
ops = __find_pci_bus_ops(bus);
+   BUG_ON(!ops);
spin_unlock_irqrestore(_lock, flags);
return ops->write(bus, devfn, where, size, val);
 }
-- 
1.7.1


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

[PATCH v5 4/5] PCI/AER: clean pci_bus_ops when related pci bus was removed

[Yijing Wang]

When Inject aer errors to the target pci device, a pci_bus_ops will
be allocated for the pci device's pci bus.When the pci bus was removed,
we should also release the pci_bus_ops.

Signed-off-by: Yijing Wang 
Reviewed-by: Sven Dietrich 
---
 drivers/pci/pcie/aer/aer_inject.c |   49 -
 1 files changed, 48 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/pcie/aer/aer_inject.c 
b/drivers/pci/pcie/aer/aer_inject.c
index 4777c44..c5372dd 100644
--- a/drivers/pci/pcie/aer/aer_inject.c
+++ b/drivers/pci/pcie/aer/aer_inject.c
@@ -553,9 +553,55 @@ static struct miscdevice aer_inject_device = {
.fops = _inject_fops,
 };
 
+static void aer_clean_pci_bus_ops(struct pci_dev *dev)
+{
+   unsigned long flags;
+   struct pci_bus_ops *bus_ops, *tmp_ops;
+   struct pci_bus *bus;
+   bus = dev->subordinate;
+   if (!bus)
+   return;
+
+   spin_lock_irqsave(_lock, flags);
+   list_for_each_entry_safe(bus_ops, tmp_ops, _bus_ops_list, list)
+   if (bus_ops->bus == bus) {
+   list_del(_ops->list);
+   kfree(bus_ops);
+   break;
+   }
+   spin_unlock_irqrestore(_lock, flags);
+}
+
+static int aer_hp_notify_fn(struct notifier_block *nb,
+   unsigned long event, void *data)
+{
+   switch (event) {
+   case BUS_NOTIFY_DEL_DEVICE:
+   aer_clean_pci_bus_ops(to_pci_dev(data));
+   break;
+   default:
+   return NOTIFY_DONE;
+   }
+
+   return NOTIFY_OK;
+}
+
+static struct notifier_block aerinj_hp_notifier = {
+   .notifier_call = _hp_notify_fn,
+};
+
 static int __init aer_inject_init(void)
 {
-   return misc_register(_inject_device);
+   int ret;
+   ret = misc_register(_inject_device);
+   if (ret)
+   goto out;
+
+   ret = bus_register_notifier(_bus_type, _hp_notifier);
+   if (ret)
+   misc_deregister(_inject_device);
+out:
+   return ret;
 }
 
 static void __exit aer_inject_exit(void)
@@ -564,6 +610,7 @@ static void __exit aer_inject_exit(void)
unsigned long flags;
struct pci_bus_ops *bus_ops;
 
+   bus_unregister_notifier(_bus_type, _hp_notifier);
misc_deregister(_inject_device);
 
list_for_each_entry(bus_ops, _bus_ops_list, list)
-- 
1.7.1


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

[PATCH v5 0/5] Fix aer_inject tool bug

[Yijing Wang]

Hi Tony,
   Can you pick up these bug fix patches into your ras tree? I sent them to PCI 
subsystem maillist, but Bjorn does not seem 
very interested in these aer_inject tool bug fix patches. Huang Ying 
 is the author of aer_inject tool.
And I had a long discussion with Huang Ying about these patches, and got his 
reviewed-by. I do not know what people are really 
interested in these patches, So I try to send them to you. Thank you very much!

This series of patch mainly to fix the aer_inject bug described as below:

-+-[:40]-+-00.0-[:41]--
 |   +-01.0-[:42]--+-00.0  Intel Corporation 82576 Gigabit Network 
Connection
 |   | \-00.1  Intel Corporation 82576 Gigabit Network 
Connection
 |   +-03.0-[:43]00.0  LSI Logic / Symbios Logic SAS1064ET 
PCI-Express Fusion-MPT SAS
 |   +-04.0-[:44]--
 |   +-05.0-[:45]--
 |   +-07.0-[:46-49]00.0-[:47-49]--+-02.0-[:48]--+-00.0 
 Intel Corporation 82576 Gigabit Network Connection
 |   | | \-00.1 
 Intel Corporation 82576 Gigabit Network Connection
 |   | \-04.0-[:49]--+-00.0 
 Intel Corporation 82576 Gigabit Network Connection
 |   |   \-00.1 
 Intel Corporation 82576 Gigabit Network Connection

my steps:
1)modprobe aer_inject
2)inject aer errors to pcie device :48:00.0
3)modprobe pciehp
4)hot remove Network Card in slot(port :40:07.0)
5)hot add Network Card in slot(port :40:07.0)
6)system panic

in step 2) the pci_ops of bus :48 and bus :40 will be assigned to 
pci_ops_aer
in step 5) the pci_ops of the newly created bus :46 will be assigned to 
pci_ops_aer(inherited by parent pci_ops),
but this pci_ops(:46) is not tracked in pci_bus_ops_list in aer_inject 
module. So every access to pci_config space
by pci_ops of :46 will cause system panic, Since pci_ops_aer cannot find 
its original pci_ops, thus , a NULL pci_ops return;

The first patch fix this bug by finding parent pci_ops(tracked in pci_ops_list) 
instead of returning NULL in step 5);
The second patch fix a small race condition window in aer_inject_exit;
The Third patch to find and clean all untracked pci_ops_aer in system when 
aer_inject module exit
The rest two patch mainly about to clean bus_ops;

Yijing Wang (5):
  PCI/AER: Fix pci_ops return NULL in pci_read/write_aer
  PCI/AER: use list_for_each_entry to avoid a small race condition
window
  PCI/AER: clean all untracked pci_ops_aer when rmmod aer_inject
  PCI/AER: clean pci_bus_ops when related pci bus was removed
  PCI/AER: free pci_bus_ops_list and remove pci_bus_ops_pop

 drivers/pci/pcie/aer/aer_inject.c |  123 +++--
 1 files changed, 103 insertions(+), 20 deletions(-)


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

Re: [PATCH] vfs: dcache: cond_resched in shrink_dentry_list

[Dave Chinner]

On Mon, Mar 25, 2013 at 05:39:13PM -0700, Greg Thelen wrote:
> On Mon, Mar 25 2013, Dave Chinner wrote:
> > On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
> >> Call cond_resched() from shrink_dentry_list() to preserve
> >> shrink_dcache_parent() interactivity.
> >> 
> >> void shrink_dcache_parent(struct dentry * parent)
> >> {
> >>while ((found = select_parent(parent, )) != 0)
> >>shrink_dentry_list();
> >> }
> >> 
> >> select_parent() populates the dispose list with dentries which
> >> shrink_dentry_list() then deletes.  select_parent() carefully uses
> >> need_resched() to avoid doing too much work at once.  But neither
> >> shrink_dcache_parent() nor its called functions call cond_resched().
> >> So once need_resched() is set select_parent() will return single
> >> dentry dispose list which is then deleted by shrink_dentry_list().
> >> This is inefficient when there are a lot of dentry to process.  This
> >> can cause softlockup and hurts interactivity on non preemptable
> >> kernels.
> >
> > Hi Greg,
> >
> > I can see how this coul dcause problems, but isn't the problem then
> > that shrink_dcache_parent()/select_parent() itself is mishandling
> > the need for rescheduling rather than being a problem with
> > the shrink_dentry_list() implementation?  i.e. select_parent() is
> > aborting batching based on a need for rescheduling, but then not
> > doing that itself and assuming that someone else will do the
> > reschedule for it?
> >
> > Perhaps this is a better approach:
> >
> > -   while ((found = select_parent(parent, )) != 0)
> > +   while ((found = select_parent(parent, )) != 0) {
> > shrink_dentry_list();
> > +   cond_resched();
> > +   }
> >
> > With this, select_parent() stops batching when a resched is needed,
> > we dispose of the list as a single batch and only then resched if it
> > was needed before we go and grab the next batch. That should fix the
> > "small batch" problem without the potential for changing the
> > shrink_dentry_list() behaviour adversely for other users
> 
> I considered only modifying shrink_dcache_parent() as you show above.
> Either approach fixes the problem I've seen.  My initial approach adds
> cond_resched() deeper into shrink_dentry_list() because I thought that
> there might a secondary benefit: shrink_dentry_list() would be willing
> to give up the processor when working on a huge number of dentry.  This
> could improve interactivity during shrinker and umount.  I don't feel
> strongly on this and would be willing to test and post the
> add-cond_resched-to-shrink_dcache_parent approach.

The shrinker has interactivity problems because of the global
dcache_lru_lock, not because of ithe size of the list passed to
shrink_dentry_list(). The amount of work that shrink_dentry_list()
does here is already bound by the shrinker batch size. Hence in the
absence of the RT folk complaining about significant holdoffs I
don't think there is an interactivity problem through the shrinker
path.

As for the unmount path - shrink_dcache_for_umount_subtree() - that
doesn't use shrink_dentry_list() and so would need it's own internal
calls to cond_resched().  Perhaps it's shrink_dcache_sb() that you
are concerned about?  Either way, And there are lots more similar
issues in the unmount path such as evict_inodes(), so unless you are
going to give every possible path through unmount/remount/bdev
invalidation the same treatment then changing shrink_dentry_list()
won't significantly improve the interactivity of the system
situation in these paths...

Cheers,

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

Re: [PATCH 05/15] KDB: add more exports for supporting KDB modules v2

[Eric W. Biederman]

Mike Travis  writes:

> This patch adds some significant KDB functions to be usable by
> externally built and loadable KDB modules.   All added functions
> have been marked EXPORT_SYMBOL_GPL as that seems to be the norm.
> No 'EXPORT_SYMBOL's were changed from previous instances to avoid
> breaking existing modules.

I don't have any real objections.  Although the export of kallsyms
probably is enough to raise an eyebrow or two.

Are there plans for these external modules to be merged?

In general the policy is to not export things unless there are in tree
users.  Otherwise maitenance can be a challenge if you can't update your
users when you update their helper functions.  Certainly a symbol being
exported is not a guarantee that the exported function won't be changed.

Eric

> Cc: Tim Bird 
> Cc: Anton Vorontsov 
> Cc: Sasha Levin 
> Cc: Rusty Russell 
> Cc: Greg Kroah-Hartman 
> Cc: Cong Wang 
> Cc: Stephen Boyd 
> Cc: Al Viro 
> Cc: Oleg Nesterov 
> Cc: Eric W. Biederman 
> Cc: Serge Hallyn 
> Reviewed-by: Dimitri Sivanich 
> Signed-off-by: Mike Travis 
> ---
> v2: change in handling of EXPORT_SYMBOLS.
> ---
>  kernel/debug/kdb/kdb_io.c  |3 +++
>  kernel/debug/kdb/kdb_main.c|   14 ++
>  kernel/debug/kdb/kdb_support.c |   17 +
>  kernel/kallsyms.c  |1 +
>  4 files changed, 35 insertions(+)
>
> --- linux.orig/kernel/debug/kdb/kdb_io.c
> +++ linux/kernel/debug/kdb/kdb_io.c
> @@ -30,6 +30,7 @@
>  char kdb_prompt_str[CMD_BUFLEN];
>  
>  int kdb_trap_printk;
> +EXPORT_SYMBOL_GPL(kdb_trap_printk);
>  
>  static int kgdb_transition_check(char *buffer)
>  {
> @@ -447,6 +448,7 @@ char *kdb_getstr(char *buffer, size_t bu
>   kdb_nextline = 1;   /* Prompt and input resets line number */
>   return kdb_read(buffer, bufsize);
>  }
> +EXPORT_SYMBOL_GPL(kdb_getstr);
>  
>  /*
>   * kdb_input_flush
> @@ -839,6 +841,7 @@ kdb_print_out:
>   preempt_enable();
>   return retlen;
>  }
> +EXPORT_SYMBOL_GPL(vkdb_printf);
>  
>  int kdb_printf(const char *fmt, ...)
>  {
> --- linux.orig/kernel/debug/kdb/kdb_main.c
> +++ linux/kernel/debug/kdb/kdb_main.c
> @@ -53,6 +53,7 @@ int kdb_grep_trailing;
>   * Kernel debugger state flags
>   */
>  int kdb_flags;
> +EXPORT_SYMBOL_GPL(kdb_flags);
>  atomic_t kdb_event;
>  
>  /*
> @@ -60,12 +61,14 @@ atomic_t kdb_event;
>   * single thread processors through the kernel debugger.
>   */
>  int kdb_initial_cpu = -1;/* cpu number that owns kdb */
> +EXPORT_SYMBOL_GPL(kdb_initial_cpu);
>  int kdb_nextline = 1;
>  int kdb_state;   /* General KDB state */
>  
>  struct task_struct *kdb_current_task;
>  EXPORT_SYMBOL(kdb_current_task);
>  struct pt_regs *kdb_current_regs;
> +EXPORT_SYMBOL_GPL(kdb_current_regs);
>  
>  const char *kdb_diemsg;
>  static int kdb_go_count;
> @@ -186,6 +189,7 @@ struct task_struct *kdb_curr_task(int cp
>  #endif
>   return p;
>  }
> +EXPORT_SYMBOL_GPL(kdb_curr_task);
>  
>  /*
>   * kdbgetenv - This function will return the character string value of
> @@ -217,6 +221,7 @@ char *kdbgetenv(const char *match)
>   }
>   return NULL;
>  }
> +EXPORT_SYMBOL_GPL(kdbgetenv);
>  
>  /*
>   * kdballocenv - This function is used to allocate bytes for
> @@ -293,6 +298,7 @@ int kdbgetintenv(const char *match, int
>   *value = (int) val;
>   return diag;
>  }
> +EXPORT_SYMBOL_GPL(kdbgetintenv);
>  
>  /*
>   * kdbgetularg - This function will convert a numeric string into an
> @@ -325,6 +331,7 @@ int kdbgetularg(const char *arg, unsigne
>  
>   return 0;
>  }
> +EXPORT_SYMBOL_GPL(kdbgetularg);
>  
>  int kdbgetu64arg(const char *arg, u64 *value)
>  {
> @@ -344,6 +351,7 @@ int kdbgetu64arg(const char *arg, u64 *v
>  
>   return 0;
>  }
> +EXPORT_SYMBOL_GPL(kdbgetu64arg);
>  
>  /*
>   * kdb_set - This function implements the 'set' command.  Alter an
> @@ -425,6 +433,7 @@ int kdb_set(int argc, const char **argv)
>  
>   return KDB_ENVFULL;
>  }
> +EXPORT_SYMBOL_GPL(kdb_set);
>  
>  static int kdb_check_regs(void)
>  {
> @@ -585,6 +594,7 @@ int kdbgetaddrarg(int argc, const char *
>  
>   return 0;
>  }
> +EXPORT_SYMBOL_GPL(kdbgetaddrarg);
>  
>  static void kdb_cmderror(int diag)
>  {
> @@ -1049,6 +1059,7 @@ int kdb_parse(const char *cmdstr)
>   return 0;
>   }
>  }
> +EXPORT_SYMBOL_GPL(kdb_parse);
>  
>  
>  static int handle_ctrl_cmd(char *cmd)
> @@ -1109,6 +1120,7 @@ void kdb_set_current_task(struct task_st
>   }
>   kdb_current_regs = NULL;
>  }
> +EXPORT_SYMBOL_GPL(kdb_set_current_task);
>  
>  /*
>   * kdb_local - The main code for kdb.  This routine is invoked on a
> @@ -2249,6 +2261,7 @@ void kdb_ps_suppressed(void)
>   kdb_printf(" suppressed,\nuse 'ps A' to see all.\n");
>   }
>  }
> +EXPORT_SYMBOL_GPL(kdb_ps_suppressed);
>  
>  /*
>   * kdb_ps - This function implements the 'ps' command which shows a
> @@ -2281,6 +2294,7 @@ void kdb_ps1(const struct task_struct *p
>   }
>   }

Re:

[Mrs Akilah Saeedi]

-- 
I am Akilah Saeedi, i have 7.100,000.00 USD for you contact me on my provide
email for more details.

- Vidarebefordrat

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] include/linux/platform_data: beautify code, 'inline' is better in front of 'void'

[Chen Gang]

On 2013年03月26日 09:48, Greg KH wrote:
> On Tue, Mar 26, 2013 at 09:22:57AM +0800, Chen Gang wrote:
>> On 2013年03月26日 07:32, Greg KH wrote:
>>> On Mon, Mar 25, 2013 at 10:36:22AM +0800, Chen Gang wrote:

   better to let 'inline' in front of 'void'
>>>
>>> Why?  What does this fix?
>>>
>>>
>>>
>>
>>   when I am compiling with "EXTRA_FLAGS=-W", I get a warning:
> 
> That's not anything I really care about, sorry.  No one sane builds the
> kernel like that :)

  a hacker may find something "valuable" with the aid of compiler   ;-)

  maybe, it is a patch which is too minor to apply. I can understand :-)

  thanks.

> 
> greg k-h
> 
> 


-- 
Chen Gang

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

[REPOST Patch v1 3/3] power: power_supply_core: Add support for supplied_from

[Rhyland Klein]

Adding support for supplied_from char * array. This is meant to store the
list of suppliers for a given supply, i.e. chargers for a battery. This
list can be populated through devicetree readily as well as passed
directly from the driver.

Signed-off-by: Rhyland Klein 
---
v1:
 - Changed from RFC v2 -> patch v1
 - removed list logic, added logic to first verify all supplies are
   present and defer probe until they are.
 - after all devices are registered, populate the char ** supplied_from
   array which simulates the case of dt not being used.
 - added of_node element to struct power_supply

v2 (RFC):
  - Simplified and renamed the logic to parse dt for the charger list.
  - Tied the dt parsing directly to power_supply_register to make fewer
changes required for converting existing chargers/supplies.

 drivers/power/power_supply_core.c |  138 +
 include/linux/power_supply.h  |3 +
 2 files changed, 141 insertions(+)

diff --git a/drivers/power/power_supply_core.c 
b/drivers/power/power_supply_core.c
index dd675ae..c1c 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -90,6 +90,133 @@ void power_supply_changed(struct power_supply *psy)
 }
 EXPORT_SYMBOL_GPL(power_supply_changed);
 
+#ifdef CONFIG_OF
+#include 
+
+static int __power_supply_populate_supplied_from(struct device *dev,
+void *data)
+{
+   struct power_supply *psy = (struct power_supply *)data;
+   struct power_supply *epsy = dev_get_drvdata(dev);
+   struct device_node *np;
+   int i = 0;
+
+   do {
+   np = of_parse_phandle(psy->of_node, "power-supplies", i++);
+   if (!np)
+   continue;
+
+   if (np == epsy->of_node) {
+   dev_info(psy->dev, "%s: Found supply : %s\n",
+   psy->name, epsy->name);
+   psy->supplied_from[i-1] = (char *)epsy->name;
+   psy->num_supplies++;
+   break;
+   }
+   } while (np);
+
+   return 0;
+}
+
+int power_supply_populate_supplied_from(struct power_supply *psy)
+{
+   int error;
+
+   error = class_for_each_device(power_supply_class, NULL, psy,
+ __power_supply_populate_supplied_from);
+
+   dev_dbg(psy->dev, "%s %d\n", __func__, error);
+
+   return error;
+}
+
+static int  __power_supply_find_supply_from_node(struct device *dev,
+void *data)
+{
+   struct device_node *np = (struct device_node *)data;
+   struct power_supply *epsy = dev_get_drvdata(dev);
+
+   /* return error breaks out of class_for_each_device loop */
+   if (epsy->of_node == np)
+   return -EINVAL;
+
+   return 0;
+}
+
+int power_supply_find_supply_from_node(struct device_node *supply_node)
+{
+   int error;
+   struct device *dev;
+   struct class_dev_iter iter;
+
+   /* Use iterator to see if any other device is registered.
+* This is required since class_for_each_device returns 0
+* if there are no devices registered.
+*/
+   class_dev_iter_init(, power_supply_class, NULL, NULL);
+   dev = class_dev_iter_next();
+
+   if (!dev)
+   return -EPROBE_DEFER;
+
+   /* we have to treat the return value as inverted, because if
+* we return error on not found, then it won't continue looking.
+* So we trick it by returning error on success to stop looking
+* once the matching device is found.
+*/
+   error = class_for_each_device(power_supply_class, NULL, supply_node,
+  __power_supply_find_supply_from_node);
+
+   return error ? 0 : -EPROBE_DEFER;
+}
+
+int power_supply_check_supplies(struct power_supply *psy)
+{
+   struct device_node *np;
+   int cnt = 0;
+   int ret = 0;
+
+   /* If there is already a list honor it */
+   if (psy->supplied_from && psy->num_supplies > 0)
+   return 0;
+
+   /* No device node found, nothing to do */
+   if (!psy->of_node)
+   return 0;
+
+   do {
+   np = of_parse_phandle(psy->of_node, "power-supplies", cnt++);
+   if (!np)
+   continue;
+
+   ret = power_supply_find_supply_from_node(np);
+   if (ret) {
+   dev_dbg(psy->dev, "Failed to find supply, defer!\n");
+   return -EPROBE_DEFER;
+   }
+   } while (np);
+
+   /* All supplies found, allocate char ** array for filling */
+   psy->supplied_from = devm_kzalloc(psy->dev, sizeof(psy->supplied_from),
+ GFP_KERNEL);
+   if (!psy->supplied_from) {
+   dev_err(psy->dev, "Couldn't allocate memory for supply list\n");
+ 

[REPOST Patch v1 1/3] power_supply: Define Binding for power-supplies

[Rhyland Klein]

This property is meant to be used in device nodes which represent
power_supply devices that wish to provide a list of supplies which
provide them power, such as a battery listing its chargers.

Signed-off-by: Rhyland Klein 
---
v1:
 - changed from RFC v2 -> patch v1
 - made poropery plural as it can be a list
 - update example with plural & changed once charger address

v2 (RFC):
 - changed property to "power-supply" which should be contained in the
   battery rather than the charger. Also updated example to match

 .../bindings/power_supply/power_supply.txt |   23 
 1 file changed, 23 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/power_supply.txt

diff --git a/Documentation/devicetree/bindings/power_supply/power_supply.txt 
b/Documentation/devicetree/bindings/power_supply/power_supply.txt
new file mode 100644
index 000..8391bfa
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/power_supply.txt
@@ -0,0 +1,23 @@
+Power Supply Core Support
+
+Optional Properties:
+ - power-supplies : This property is added to a supply in order to list the
+   devices which supply it power, referenced by their phandles.
+
+Example:
+
+   usb-charger: power@e {
+   compatible = "some,usb-charger";
+   ...
+   };
+
+   ac-charger: power@c {
+   compatible = "some,ac-charger";
+   ...
+   };
+
+   battery@b {
+   compatible = "some,battery";
+   ...
+   power-supplies = <>, <>;
+   };
-- 
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/

[REPOST Patch v1 2/3] power: power_supply: Add core support for supplied_from

[Rhyland Klein]

This patch adds support for supplies to register a list of char *'s
which represent the list of supplies which supply them. This is the
opposite as the supplied_to list.

This change maintains support for supplied_to until all drivers which
make use of it already are converted.

Signed-off-by: Rhyland Klein 
---
v1:
 - changed from RFC v2 -> patch v1
 - removed list logic and instead added supplied_from char ** array and
   num_supplies field

v2 (RFC):
 - changed from struct device_node * contained in suppliers to a list
   stored in the supplies.
 - changed logic for the is_supplied_by check to handle the entire loop
   as the array structure is difference between the 2 paths.

 drivers/power/power_supply_core.c |   49 +++--
 include/linux/power_supply.h  |3 +++
 2 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/drivers/power/power_supply_core.c 
b/drivers/power/power_supply_core.c
index 5deac43..dd675ae 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -26,17 +26,44 @@ EXPORT_SYMBOL_GPL(power_supply_class);
 
 static struct device_type power_supply_dev_type;
 
+static int __power_supply_is_supplied_by(struct power_supply *supplier,
+struct power_supply *supply)
+{
+   int i;
+
+   if (!supply->supplied_from && !supplier->supplied_to)
+   return -EINVAL;
+
+   /* Support both supplied_to and supplied_from modes */
+   if (supply->supplied_from) {
+   for (i = 0; i < supply->num_supplies; i++) {
+   if (!supplier->name)
+   continue;
+   if (!strcmp(supplier->name, supply->supplied_from[i]))
+   return 0;
+   }
+   } else {
+   for (i = 0; i < supplier->num_supplicants; i++) {
+   if (!supply->name)
+   continue;
+   if (!strcmp(supplier->supplied_to[i], supply->name))
+   return 0;
+   }
+   }
+
+   return -EINVAL;
+}
+
 static int __power_supply_changed_work(struct device *dev, void *data)
 {
struct power_supply *psy = (struct power_supply *)data;
struct power_supply *pst = dev_get_drvdata(dev);
-   int i;
 
-   for (i = 0; i < psy->num_supplicants; i++)
-   if (!strcmp(psy->supplied_to[i], pst->name)) {
-   if (pst->external_power_changed)
-   pst->external_power_changed(pst);
-   }
+   if (__power_supply_is_supplied_by(psy, pst)) {
+   if (pst->external_power_changed)
+   pst->external_power_changed(pst);
+   }
+
return 0;
 }
 
@@ -68,17 +95,13 @@ static int __power_supply_am_i_supplied(struct device *dev, 
void *data)
union power_supply_propval ret = {0,};
struct power_supply *psy = (struct power_supply *)data;
struct power_supply *epsy = dev_get_drvdata(dev);
-   int i;
 
-   for (i = 0; i < epsy->num_supplicants; i++) {
-   if (!strcmp(epsy->supplied_to[i], psy->name)) {
-   if (epsy->get_property(epsy,
- POWER_SUPPLY_PROP_ONLINE, ))
-   continue;
+   if (__power_supply_is_supplied_by(epsy, psy))
+   if (!epsy->get_property(epsy, POWER_SUPPLY_PROP_ONLINE, )) {
if (ret.intval)
return ret.intval;
}
-   }
+
return 0;
 }
 
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 002a99f..c1cbd5e 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -171,6 +171,9 @@ struct power_supply {
char **supplied_to;
size_t num_supplicants;
 
+   char **supplied_from;
+   size_t num_supplies;
+
int (*get_property)(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val);
-- 
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/

[REPOST Patch v1 0/3] Add DT Binding for Power-Supply power-supplies property

[Rhyland Klein]

This series defines a common way for devicetree initialized
power_supplies to define their relationships between chargers and
supplicants.

This series adds a supplied_from array to complement the supplied_to
array and to allow supplies to define the list of supplies which
supply them.

Then once this property is supported, we can use a new property for
devicetree to define the relationships between nodes, and read in this
property to generate the supplied_from list.

With this logic in place, all drivers need to do to add support for
this mechanism, is to store their device tree node in the power_supply
struct. They should also handle EPROBE_DEFER properly.

Changes since:
RFC v2:
 - Changed to official Patch set rather than RFC
 - defined supplied_from char ** array rather than complicated
   struct device_node related array

RFC v1:
 - Inverted the logic so that supplies (batteries) contain a list of
   the supplies (chargers) which supply them.

Rhyland Klein (3):
  power_supply: Define Binding for power-supplies
  power: power_supply: Add core support for supplied_from
  power: power_supply_core: Add support for supplied_from

 .../bindings/power_supply/power_supply.txt |   23 +++
 drivers/power/power_supply_core.c  |  187 ++--
 include/linux/power_supply.h   |6 +
 3 files changed, 203 insertions(+), 13 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/power_supply.txt

-- 
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] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init

[Rob Herring]

On 03/25/2013 05:53 PM, John Stultz wrote:
> On 03/25/2013 03:36 PM, Arnd Bergmann wrote:
>> On Monday 25 March 2013, Rob Herring wrote:
>>> I count integrator-cp, realview, versatile and non-DT VExpress that do
>>> this (not surprisingly) and 25 platforms or timer implementations plus
>>> arm64 that do sched_clock setup in time_init. What's broken by not
>>> moving these earlier?
>> timekeeping_init() will leave the persistent_clock_exist variable as
>> "false",
>> which is read in rtc_suspend() and timekeeping_inject_sleeptime().
> 
> Are you mixing up the persistent_clock and sched_clock here? From a
> generic stand-point they have different requirements.

Yes. We're talking about sched_clock here. What would be the benefit of
having it setup before sched_init vs. later in time_init?

Rob

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv3 01/10] clocksource: add generic dummy timer driver

[Stephen Boyd]

On 03/25/13 11:00, Mark Rutland wrote:
>
>>> I've spent the last few hours trying to get the dummy_timer driver working 
>>> on
>>> tc2 with the sp804 as the broadcast source (with architected timer support
>>> disabled). It turns out that having dummy timer's rating so low means that 
>>> it
>>> won't be selected as the tick device on cpu0 in preference to the sp804, and
>>> thus won't push the sp804 out of that spot (allowing it to become the 
>>> broadcast
>>> source). This leads to boot stalling.
>> I'm not following here. Why would we want to remove sp804 from the tick
>> duty?
> To run an SMP system without local timers, we need the sp804 to be the
> broadcast timer. Unfortunately the tick device and broadcast timer are 
> mutually
> exclusive positions, so we need to have a dummy timer knock the sp804 out of
> tick device duty to enable broadcast.
>
> When the dummy timer's rating was 400 (against the sp804's 350), this worked.
> The sp804 would be registered, and would become cpu0's tick device. Later the
> dummy would get registered, knocking the sp804 out (whereupon it would get
> cycled back through tick_check_new_device and become the broadcast timer).
>
> With the dummy timer's rating lower, the sp804 stays as cpu0's tick device, 
> all
> other cpus get dummy timers, but there's no broadcast source, so the system
> locks up waiting for secondary cpus.

Ok. Thanks for clearing up my confusion.

Like you say, increasing the dummy timer rating seems like a hack. But
it also sounds like you want to keep the dummy timer driver fully self
contained. I'm not opposed to calling dummy_timer_register() at the
bottom of tick_init() if we have to, but it sounds like you don't like that.

An alternative would be to push the dummy timer logic into the core
clockevents layer under the ifdef for arch has broadcast. This is
probably the correct approach because most devices don't want to have a
dummy timer sitting around unused. I might be able to take a look at
this tomorrow.

One final question, if you remove all other CPUs besides the CPU that is
servicing the sp804 interrupt do we end up in a situation where the
sp804 is broadcasting to the dummy tick device? I haven't read through
all the code yet for that one. I would think tick_switch_to_oneshot()
would complain on your device?

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

[git pull] Please pull some powerpc build fixes

[Stephen Rothwell]

The following changes since commit 3912a677f68f6084e0a7b6a1a29310ac1b083713:

  Merge tag 'pinctrl-fixes-for-v3.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl (2013-03-24 
10:11:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes.git 
tags/for-linus

for you to fetch changes up to f9294e989fa6f2990da155242db03cea1550cac8:

  powerpc: define the conditions where the ePAPR idle hcall can be supported 
(2013-03-26 08:47:27 +1100)


Just a couple of build fixes for powerpc all{mod,yes}config.

Submitted by me since BenH is on vacation.


Chen Gang (1):
  powerpc: make additional room in exception vector area

Stuart Yoder (1):
  powerpc: define the conditions where the ePAPR idle hcall can be supported

 arch/powerpc/kernel/epapr_paravirt.c |   6 ++
 arch/powerpc/kernel/exceptions-64s.S | 144 +--
 2 files changed, 78 insertions(+), 72 deletions(-)

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


pgpxnAqBmjUZM.pgp
Description: PGP signature

RE: [PATCH -next v2] mailbox: fix invalid use of sizeof in mailbox_msg_send()

[Anna, Suman]

> From: Wei Yongjun 
> 
> sizeof() when applied to a pointer typed expression gives the size of the 
> pointer,
> not that of the pointed data.
> 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/mailbox/mailbox.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c index
> 5fea5c2..78e52c0 100644
> --- a/drivers/mailbox/mailbox.c
> +++ b/drivers/mailbox/mailbox.c
> @@ -83,7 +83,7 @@ int mailbox_msg_send(struct mailbox *mbox, struct
> mailbox_msg *msg)
> 
>   mutex_lock(>mlock);
> 
> - if (kfifo_avail(>fifo) < (sizeof(msg) + msg->size)) {
> + if (kfifo_avail(>fifo) < (sizeof(*msg) + msg->size)) {
>   ret = -ENOMEM;
>   goto out;
>   }
> @@ -93,8 +93,8 @@ int mailbox_msg_send(struct mailbox *mbox, struct
> mailbox_msg *msg)
>   goto out;
>   }
> 
> - len = kfifo_in(>fifo, (unsigned char *)msg, sizeof(msg));
> - WARN_ON(len != sizeof(msg));
> + len = kfifo_in(>fifo, (unsigned char *)msg, sizeof(*msg));
> + WARN_ON(len != sizeof(*msg));
> 
>   if (msg->size && msg->pdata) {
>   len = kfifo_in(>fifo, (unsigned char *)msg->pdata,
>

Looks good, thanks. I have added this patch to my branch on github.

Regards
Suman
 

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

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/md/raid5.c between commit e3620a3ad526 ("MD RAID5: Avoid
accessing gendisk or queue structs when not available") from Linus' tree
and commit 2f6db2a70734 ("raid5: use bio_reset()") from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/md/raid5.c
index 24909eb,7bbd285..000
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@@ -666,16 -665,11 +665,13 @@@ static void ops_run_io(struct stripe_he
bi->bi_io_vec[0].bv_len = STRIPE_SIZE;
bi->bi_io_vec[0].bv_offset = 0;
bi->bi_size = STRIPE_SIZE;
-   bi->bi_next = NULL;
if (rrdev)
set_bit(R5_DOUBLE_LOCKED, >dev[i].flags);
 -  trace_block_bio_remap(bdev_get_queue(bi->bi_bdev),
 -bi, 
disk_devt(conf->mddev->gendisk),
 -sh->dev[i].sector);
 +
 +  if (conf->mddev->gendisk)
 +  
trace_block_bio_remap(bdev_get_queue(bi->bi_bdev),
 +bi, 
disk_devt(conf->mddev->gendisk),
 +sh->dev[i].sector);
generic_make_request(bi);
}
if (rrdev) {
@@@ -700,13 -700,9 +702,10 @@@
rbi->bi_io_vec[0].bv_len = STRIPE_SIZE;
rbi->bi_io_vec[0].bv_offset = 0;
rbi->bi_size = STRIPE_SIZE;
-   rbi->bi_next = NULL;
 -  trace_block_bio_remap(bdev_get_queue(rbi->bi_bdev),
 -rbi, 
disk_devt(conf->mddev->gendisk),
 -sh->dev[i].sector);
 +  if (conf->mddev->gendisk)
 +  
trace_block_bio_remap(bdev_get_queue(rbi->bi_bdev),
 +rbi, 
disk_devt(conf->mddev->gendisk),
 +sh->dev[i].sector);
generic_make_request(rbi);
}
if (!rdev && !rrdev) {


pgp3v5ypUH8Mw.pgp
Description: PGP signature

Re: [PATCH 8/9] spark: cpufreq: move cpufreq driver to drivers/cpufreq

[Viresh Kumar]

On 25 March 2013 22:37, David Miller  wrote:
> From: Viresh Kumar 
> Date: Mon, 25 Mar 2013 22:24:44 +0530
>
>> This patch moves cpufreq driver of SPARK architecture to drivers/cpufreq.
>
> I don't know what spark is.

:(

s/spark/sparc ...

I will fix patch in V2..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [TRIVIAL] Fix typo "CONFIG_CGROUP_CGROUP_MEMCG_SWAP"

[Rob Landley]

On 03/25/2013 05:59:16 PM, Paul Bolle wrote:

Signed-off-by: Paul Bolle 
---
 Documentation/cgroups/memory.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


Acked-by: Rob Landley 

Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] alpha: makefile: don't enforce small data model for kernel builds

[Rob Landley]

On 03/25/2013 03:55:28 PM, Matt Turner wrote:
On Mon, Mar 25, 2013 at 1:06 PM, Michael Cree   
wrote:

> On 26/03/2013, at 4:09 AM, Tobias Klausmann wrote:
>>
>> On Mon, 25 Mar 2013, Will Deacon wrote:
>>>
>>> Any news on these? I've included an updated version of the first  
patch,

>>> with
>>> the Tested-by-tag and a tweaked commit message below.
>>
>>
>> As a data point, I tried vanilla 3.8.4 on the weekend. With my
>> usual config on a UP1500, it will fail at build time with
>> relocation errors. If I remove -msmall-data (or replace it with
>> ~big~), the machine hangs hard immediatly after aboot telling me
>> it's starting it.
>
>
> You probably want the "alpha: Add irongate_io to to PCI bus  
resources" patch
> posted by Matt Turner in the linux-alpha forum.  Looks like it has  
not been

> sent to Linus.
>
> If Matt does not respond in the next day or two I'll collect  
patches and

> send them on to Linus.

Yes, please do. I haven't powered on an alpha in a few months.


What would it take to add Alpha system support to qemu? (It's got  
userspace, but not the system management mode instructions, mmu, or a  
board emulation.)


Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] include/linux/platform_data: beautify code, 'inline' is better in front of 'void'

[Greg KH]

On Tue, Mar 26, 2013 at 09:22:57AM +0800, Chen Gang wrote:
> On 2013年03月26日 07:32, Greg KH wrote:
> > On Mon, Mar 25, 2013 at 10:36:22AM +0800, Chen Gang wrote:
> >>
> >>   better to let 'inline' in front of 'void'
> > 
> > Why?  What does this fix?
> > 
> > 
> > 
> 
>   when I am compiling with "EXTRA_FLAGS=-W", I get a warning:

That's not anything I really care about, sorry.  No one sane builds the
kernel like that :)

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

Re: [PATCH] drivers: uio: Fix UIO device registration failure

[Greg KH]

On Tue, Mar 26, 2013 at 10:31:22AM +0900, Damian Hobson-Garcia wrote:
> Until recently uio_get_minor() returned 0 for success and
> a negative value on failure.  This became non-negative for suceess and
> negative for failure.  Restore the original return value spec so that we can
> successfully initialize UIO devices with a non-zero minor device
> number.
> 
> Signed-off-by: Damian Hobson-Garcia 
> ---
>  drivers/uio/uio.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

Hans, don't you have a bunch of uio patches queued up for me?  I've been
ignoring them, thinking you are collecting them, is this not true?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers: uio: Fix UIO device registration failure

[Damian Hobson-Garcia]

Until recently uio_get_minor() returned 0 for success and
a negative value on failure.  This became non-negative for suceess and
negative for failure.  Restore the original return value spec so that we can
successfully initialize UIO devices with a non-zero minor device
number.

Signed-off-by: Damian Hobson-Garcia 
---
 drivers/uio/uio.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index c8b9262..b645c47 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -374,6 +374,7 @@ static int uio_get_minor(struct uio_device *idev)
retval = idr_alloc(_idr, idev, 0, UIO_MAX_DEVICES, GFP_KERNEL);
if (retval >= 0) {
idev->minor = retval;
+   retval = 0;
} else if (retval == -ENOSPC) {
dev_err(idev->dev, "too many uio devices\n");
retval = -EINVAL;
-- 
1.7.5.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] include/linux/platform_data: beautify code, 'inline' is better in front of 'void'

[Chen Gang]

On 2013年03月26日 07:32, Greg KH wrote:
> On Mon, Mar 25, 2013 at 10:36:22AM +0800, Chen Gang wrote:
>>
>>   better to let 'inline' in front of 'void'
> 
> Why?  What does this fix?
> 
> 
> 

  when I am compiling with "EXTRA_FLAGS=-W", I get a warning:
make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig
make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
  choose arm-linux-gnu- for cross chain prefix.
  choose S5pv210 for processor type
make V=1 EXTRA_CFLAGS=-W ARCH=arm

  the warning is:
include/linux/platform_data/usb-ohci-s3c2410.h:34:1: warning: ‘inline’ is 
not at beginning of declaration [-Wold-style-declaration]


  it is only for beautify code, not fix a bug.



  :-)


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] block: removes dynamic allocation on stack

[Jens Axboe]

On Mon, Mar 25 2013, Philip J. Kelleher wrote:
> From: Philip J Kelleher 
> 
> This patch removes dynamic allocation on the stack error.
> 
> Signed-off-by: Philip J Kelleher 
> ---
> 
> 
> diff -uprN -X linux-block/Documentation/dontdiff 
> linux-block-vanilla/drivers/block/rsxx/dma.c 
> linux-block/drivers/block/rsxx/dma.c
> --- linux-block-vanilla/drivers/block/rsxx/dma.c  2013-03-25 
> 14:44:40.898978713 -0500
> +++ linux-block/drivers/block/rsxx/dma.c  2013-03-25 14:50:48.054969658 
> -0500
> @@ -986,7 +986,10 @@ void rsxx_eeh_save_issued_dmas(struct rs
>   int j;
>   int cnt;
>   struct rsxx_dma *dma;
> - struct list_head issued_dmas[card->n_targets];
> + struct list_head *issued_dmas;

Ahem - thanks, applied :-)

-- 
Jens Axboe

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

linux-next: manual merge of the wireless-next tree with the wireless tree

[Stephen Rothwell]

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
net/mac80211/sta_info.c between commit 27a737ff7cb0 ("mac80211: always
synchronize_net() during station removal") from the wireless tree and
commits 3b8d9c290364 ("mac80211: remove underscores from some key
functions") and 6d10e46be5ac ("mac80211: batch key free synchronize_net()")
from the wireless-next tree.

The latter seems to supercede the former, so I just used the latter and
can carry the fix as necessary (no action is required).

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


pgpjxj7m3z9a3.pgp
Description: PGP signature

[PATCH] Fix child thread's introspection of /proc/self/exe

[Ben Woodard]

Allow threads other than the main thread to do introspection of files in 
proc without relying on read permissions. proc_pid_follow_link() calls 
proc_fd_access_allowed() which ultimately calls __ptrace_may_access().


Though this allows additional access to some proc files, we do not 
believe that this has any unintended security implications. However it 
probably needs to be looked at carefully.


The original problem was a thread of a process whose permissions were 
111 couldn't open its own /proc/self/exe This was interfering with a 
special purpose debugging tool. A simple reproducer is below.:


#include 
#include 
#include 
#include 
#include 
#include 

#define BUFSIZE 2048

void *thread_main(void *arg){
  char *str=(char*)arg;
  char buf[BUFSIZE];
  ssize_t len=readlink("/proc/self/exe", buf, BUFSIZE);
  if(len==-1)
printf("/proc/self/exe in %s: %s\n", str,sys_errlist[errno]);
  else
printf("/proc/self/exe in %s: OK\n", str);

  return 0;
}

int main(){
  pthread_t thread;

  int retval=pthread_create( , NULL, thread_main, "thread");
  if(retval!=0)
exit(1);

  thread_main("main");
  pthread_join(thread, NULL);

  exit(0);
}

Signed-off-by: Ben Woodard 
Signed-off-by: Mark Grondona 
---
 kernel/ptrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index acbd284..347c4c7 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -234,7 +234,7 @@ static int __ptrace_may_access(struct task_struct 
*task, unsigned int mode)

 */
int dumpable = 0;
/* Don't let security modules deny introspection */
-   if (task == current)
+   if (same_thread_group(task, current))
return 0;
rcu_read_lock();
tcred = __task_cred(task);
--
1.8.1.4

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

linux-next: manual merge of the net-next tree with the wireless tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/wireless/core.h between commit f9f475292dbb ("cfg80211: always check
for scan end on P2P device") from the wireless tree and commit
812569699119 ("cfg80211/mac80211: disconnect on suspend") from the
net-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Stephen Rothwell 

diff --cc net/wireless/core.h
index 5845c2b,d5d06fd..000
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@@ -503,9 -500,9 +500,12 @@@ int cfg80211_validate_beacon_int(struc
  void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
   enum nl80211_iftype iftype, int num);
  
 +void cfg80211_stop_p2p_device(struct cfg80211_registered_device *rdev,
 +struct wireless_dev *wdev);
 +
+ void cfg80211_leave(struct cfg80211_registered_device *rdev,
+   struct wireless_dev *wdev);
+ 
  #define CFG80211_MAX_NUM_DIFFERENT_CHANNELS 10
  
  #ifdef CONFIG_CFG80211_DEVELOPER_WARNINGS


pgpYevjQdbnBx.pgp
Description: PGP signature

Re: RFC v2: Zynq Clock Controller

[Sören Brinkmann]

On Mon, Mar 25, 2013 at 07:10:35PM +0100, Lars-Peter Clausen wrote:
> On 03/25/2013 06:59 PM, Sören Brinkmann wrote:
> > Hi,
> > 
> > On Mon, Mar 25, 2013 at 06:19:11PM +0100, Lars-Peter Clausen wrote:
> >> On 03/25/2013 06:08 PM, Sören Brinkmann wrote:
> >>> Hi Lars,
> >>>
> >>> On Mon, Mar 25, 2013 at 03:46:35PM +0100, Lars-Peter Clausen wrote:
>  Hi,
> 
>  On 03/22/2013 11:41 PM, Sören Brinkmann wrote:
> > Hi Lars,
> >
> > On Thu, Mar 21, 2013 at 07:32:52PM +0100, Lars-Peter Clausen wrote:
> >> On 03/21/2013 12:56 AM, Sören Brinkmann wrote:
> >>> Hi,
> >>>
> >>> I spent some time working on this and incorporating feedback. Here's 
> >>> an updated proposal for a clock controller for Zynq:
> >>>
> >>> Required properties:
> >>>  - #clock-cells : Must be 1
> >>>  - compatible : "xlnx,ps7-clkc"  (this may become 'xlnx,zynq-clkc' 
> >>> terminology differs a bit between Xilinx internal and mainline)
> >>>  - ps-clk-frequency : Frequency of the oscillator providing ps_clk in 
> >>> HZ
> >>>  (usually 33 MHz oscillators are used for Zynq 
> >>> platforms)
> >>>  - clock-output-names : List of strings used to name the clock 
> >>> outputs. Shall be a list of the outputs given below.
> >>>
> >>> Optional properties:
> >>>  - clocks : as described in the clock bindings
> >>>  - clock-names : as described in the clock bindings
> >>>
> >>> Clock inputs:
> >>> The following strings are optional parameters to the 'clock-names' 
> >>> property in
> >>> order to provide optional (E)MIO clock sources.
> >>>  - swdt_ext_clk
> >>>  - gem0_emio_clk
> >>>  - gem1_emio_clk
> >>>  - mio_clk_XX  # with XX = 00..53
> >>>
> >>> Example:
> >>> clkc: clkc {
> >>> #clock-cells = <1>;
> >>> compatible = "xlnx,ps7-clkc";
> >>> ps-clk-frequency = <>;
> >>
> >> The input frequency should be a clock as well.
> > Again, monolithic vs split. I don't see a reason not to just internally
> > call clk_register_fixed_rate(). That way its children do not have to
> > cope with a variable name for the xtal.
> > Also, with my proposal 'clocks' and 'clock-names' would be purely
> > optional properties, only required if optional external inputs are
> > present. Having the xtal defined externally would add mandatory entries 
> > for
> > those props.
> 
> 
> 
> >
> >>
> >>> clock-output-names = "armpll", "ddrpll", "iopll", 
> >>> "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x", 
> >>> "dci", "lqspi", "smc", "pcap", "gem0", "gem1", "fclk0", "fclk1", 
> >>> "fclk2", "fclk3", "can0", "can1", "sdio0", "sdio1", "uart0", "uart1", 
> >>> "spi0", "spi1", "dma", "usb0_aper", "usb1_aper", "gem0_aper", 
> >>> "gem1_aper", "sdio0_aper", "sdio1_aper", "spi0_aper", "spi1_aper", 
> >>> "can0_aper", "can1_aper", "i2c0_aper", "i2c1_aper", "uart0_aper", 
> >>> "uart1_aper", "gpio_aper", "lqspi_aper", "smc_aper", "swdt", 
> >>> "dbg_trc", "dbg_apb";  /* long list... explanation below */
> >>> /* optional props */
> >>> clocks = < 16>, <_foo>;
> >>> clock-names = "gem1_emio_clk", "can_mio_clk_23";
> >>> };
> >>>
> >>> With this revised bindings arbitrary upstream and downstream clock 
> >>> providers should be supported and it's also possible to loop back an 
> >>> output as input. The downside of supporting this is, that I don't see 
> >>> a way around explicitly listing the clock output names in the DT.
> >>> The reason for this is, that a downstream clock provider should use 
> >>> of_clk_get_parent_name() to obtain its parent clock name. For a block 
> >>> with multiple outputs of_clk_get_parent_name() can return a valid 
> >>> clock name only when 'clock-output-names' is present.
> >>> Probably the fclks are the only realistic use case to become parent 
> >>> of downstream clock providers, but I could imagine that e.g. a device 
> >>> driver like UART wants to use the CCF to model its internal clocks, 
> >>> hence it would require its parent clock name. Even though a device 
> >>> driver could use clk_get_parent() and __clk_get_name(), 
> >>> of_clk_get_parent_name() should probably work as well. I simply have 
> >>> a bad feeling about breaking of_clk_get_parent_name() for any clock.
> >>> But after all, I'm open for finding a better solution for this.
> >>>
> >>>
> >>> Similar, inputs for optional clock sources through (E)MIO pins can be 
> >>> defined as described in the clock bindings using the 'clocks' and 
> >>> 'clock-names' properties, with 'clock-names' being an arbitrary 
> >>> subset of the documented names. The 

Re: [PATCH 3/4] f2fs: remain nat cache entries for further free nid allocation

[Namjae Jeon]

2013/3/25, Jaegeuk Kim :
> In the checkpoint flow, the f2fs investigates the total nat cache entries.
> Previously, if an entry has NULL_ADDR, f2fs drops the entry and adds the
> obsolete nid to the free nid list.
> However, this free nid will be reused sooner, resulting in its nat entry
> miss.
> In order to avoid this, we don't need to drop the nat cache entry at this
> moment.
>
> Signed-off-by: Jaegeuk Kim 
Looks good to me.
Reviewed-by: Namjae Jeon 

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

linux-next: manual merge of the net-next tree with the wireless tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/mac80211/sta_info.c between commit 27a737ff7cb0 ("mac80211: always
synchronize_net() during station removal") from the wireless tree and
commit 8d1f7ecd2af5 ("mac80211: defer tailroom counter manipulation when
roaming") from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc net/mac80211/sta_info.c
index 238a0cc,3644ad7..000
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@@ -794,19 -798,14 +799,21 @@@ int __must_check __sta_info_destroy(str
list_del_rcu(>list);
  
mutex_lock(>key_mtx);
 -  for (i = 0; i < NUM_DEFAULT_KEYS; i++)
 +  for (i = 0; i < NUM_DEFAULT_KEYS; i++) {
-   __ieee80211_key_free(key_mtx_dereference(local, sta->gtk[i]));
+   __ieee80211_key_free(key_mtx_dereference(local, sta->gtk[i]),
+true);
 -  if (sta->ptk)
 +  have_key = true;
 +  }
 +  if (sta->ptk) {
-   __ieee80211_key_free(key_mtx_dereference(local, sta->ptk));
+   __ieee80211_key_free(key_mtx_dereference(local, sta->ptk),
+true);
 +  have_key = true;
 +  }
mutex_unlock(>key_mtx);
  
 +  if (!have_key)
 +  synchronize_net();
 +
sta->dead = true;
  
local->num_sta--;


pgpueaDnDE75T.pgp
Description: PGP signature

Re: [PATCH 2/4] f2fs: do not skip writing file meta during fsync

[Namjae Jeon]

2013/3/25, Jaegeuk Kim :
> This patch removes data_version check flow during the fsync call.
> The original purpose for the use of data_version was to avoid writng inode
> pages redundantly by the fsync calls repeatedly.
Hi Jaegeuk.
> However, when user can modify file meta and then call fsync, we should not
> skip fsync procedure.
I have a question.
Which case does user can directly modify meta ? Recovery tool ?

Thanks.

> So, let's remove this condition check and hope that user triggers in right
> manner.
>
> Signed-off-by: Jaegeuk Kim 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] vfs: dcache: cond_resched in shrink_dentry_list

[Greg Thelen]

On Mon, Mar 25 2013, Dave Chinner wrote:

> On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
>> Call cond_resched() from shrink_dentry_list() to preserve
>> shrink_dcache_parent() interactivity.
>> 
>> void shrink_dcache_parent(struct dentry * parent)
>> {
>>  while ((found = select_parent(parent, )) != 0)
>>  shrink_dentry_list();
>> }
>> 
>> select_parent() populates the dispose list with dentries which
>> shrink_dentry_list() then deletes.  select_parent() carefully uses
>> need_resched() to avoid doing too much work at once.  But neither
>> shrink_dcache_parent() nor its called functions call cond_resched().
>> So once need_resched() is set select_parent() will return single
>> dentry dispose list which is then deleted by shrink_dentry_list().
>> This is inefficient when there are a lot of dentry to process.  This
>> can cause softlockup and hurts interactivity on non preemptable
>> kernels.
>
> Hi Greg,
>
> I can see how this coul dcause problems, but isn't the problem then
> that shrink_dcache_parent()/select_parent() itself is mishandling
> the need for rescheduling rather than being a problem with
> the shrink_dentry_list() implementation?  i.e. select_parent() is
> aborting batching based on a need for rescheduling, but then not
> doing that itself and assuming that someone else will do the
> reschedule for it?
>
> Perhaps this is a better approach:
>
> - while ((found = select_parent(parent, )) != 0)
> + while ((found = select_parent(parent, )) != 0) {
> shrink_dentry_list();
> + cond_resched();
> + }
>
> With this, select_parent() stops batching when a resched is needed,
> we dispose of the list as a single batch and only then resched if it
> was needed before we go and grab the next batch. That should fix the
> "small batch" problem without the potential for changing the
> shrink_dentry_list() behaviour adversely for other users

I considered only modifying shrink_dcache_parent() as you show above.
Either approach fixes the problem I've seen.  My initial approach adds
cond_resched() deeper into shrink_dentry_list() because I thought that
there might a secondary benefit: shrink_dentry_list() would be willing
to give up the processor when working on a huge number of dentry.  This
could improve interactivity during shrinker and umount.  I don't feel
strongly on this and would be willing to test and post the
add-cond_resched-to-shrink_dcache_parent approach.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] f2fs: fix the recovery flow to handle errors correctly

[Namjae Jeon]

2013/3/25, Jaegeuk Kim :
> 2013-03-25 (월), 15:30 +0900, Namjae Jeon:
>> 2013/3/25, Jaegeuk Kim :
>> > We should handle errors during the recovery flow correctly.
>> > For example, if we get -ENOMEM, we should report a mount failure instead
>> > of
>> > conducting the remained mount procedure.
>> >
>> > Signed-off-by: Jaegeuk Kim 
>> > ---
>> >  fs/f2fs/f2fs.h |  2 +-
>> >  fs/f2fs/recovery.c | 46 --
>> >  fs/f2fs/super.c|  9 +++--
>> >  3 files changed, 36 insertions(+), 21 deletions(-)
>> >
>> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>> > index 5bb87e0..109e12d 100644
>> > --- a/fs/f2fs/f2fs.h
>> > +++ b/fs/f2fs/f2fs.h
>> > @@ -1027,7 +1027,7 @@ void destroy_gc_caches(void);
>> >  /*
>> >   * recovery.c
>> >   */
>> > -void recover_fsync_data(struct f2fs_sb_info *);
>> > +int recover_fsync_data(struct f2fs_sb_info *);
>> >  bool space_for_roll_forward(struct f2fs_sb_info *);
>> >
>> >  /*
>> > diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
>> > index 2d86eb2..61bdaa7 100644
>> > --- a/fs/f2fs/recovery.c
>> > +++ b/fs/f2fs/recovery.c
>> > @@ -118,10 +118,8 @@ static int find_fsync_dnodes(struct f2fs_sb_info
>> > *sbi,
>> > struct list_head *head)
>> >
>> >lock_page(page);
>> >
>> Hi Jaegeuk.
>> I have a question.
>> > -  if (cp_ver != cpver_of_node(page)) {
>> > -  err = -EINVAL;
>> > +  if (cp_ver != cpver_of_node(page))
>> >goto unlock_out;
>> > -  }
>> err = 0 is initialized to zero in the start of function
>> Why have you remove err = -EINVAL; code when mismatching cp_ver ?
>
> This ending condition is used to find the latest node pages that we have
> to recover, not to detect an error to exit the recovery routine.
> For example, the error conditions include -ENOMEM or -EIO, something
> like such the obvious errors.
> Thanks,
Yes, Right. It does make sense.
Thanks for explanation :)

You can add:
Reviewed-by: Namjae Jeon 
>
>>
>> Thanks.
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> Jaegeuk Kim
> Samsung
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] doc: change example to existing Makefile fragment

[Rob Landley]

On 03/25/2013 05:16:24 AM, Paul Bolle wrote:

Signed-off-by: Paul Bolle 
---
 Documentation/kbuild/makefiles.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)


Acked-by: Rob Landley 

Please send through the kbuild tree.

Rob

diff --git a/Documentation/kbuild/makefiles.txt  
b/Documentation/kbuild/makefiles.txt

index 5198b74..020bb67 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -921,8 +921,9 @@ When kbuild executes, the following steps are  
followed (roughly):

Often, the KBUILD_CFLAGS variable depends on the configuration.

Example:
-   #arch/x86/Makefile
-   cflags-$(CONFIG_M386) += -march=i386
+   #arch/x86/boot/compressed/Makefile
+   cflags-$(CONFIG_X86_32) := -march=i386
+   cflags-$(CONFIG_X86_64) := -mcmodel=small
KBUILD_CFLAGS += $(cflags-y)

Many arch Makefiles dynamically run the target C compiler to
--
1.7.11.7






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

Re: [PATCH 1/4] ARM: context tracking: add exception support

[Kevin Hilman]

Hi Russell,

Russell King - ARM Linux  writes:

> On Wed, Mar 20, 2013 at 05:01:58PM -0700, Kevin Hilman wrote:
>> Add ARM support for the context tracking subsystem by instrumenting
>> exception entry/exit points.
>> 
>> Special thanks to Mats Liljegren for testing, collaboration and adding
>> support for exceptions/faults that were missing in early test versions.

[...]

>> @@ -405,7 +406,9 @@ asmlinkage void __exception do_undefinstr(struct pt_regs 
>> *regs)
>>  unsigned int instr;
>>  siginfo_t info;
>>  void __user *pc;
>> +enum ctx_state prev_state;
>>  
>> +prev_state = exception_enter();
>>  pc = (void __user *)instruction_pointer(regs);
>>  
>>  if (processor_mode(regs) == SVC_MODE) {
>> @@ -433,8 +436,10 @@ asmlinkage void __exception do_undefinstr(struct 
>> pt_regs *regs)
>>  goto die_sig;
>>  }
>>  
>> -if (call_undef_hook(regs, instr) == 0)
>> +if (call_undef_hook(regs, instr) == 0) {
>> +exception_exit(prev_state);
>>  return;
>> +}
>>  
>>  die_sig:
>>  #ifdef CONFIG_DEBUG_USER
>> @@ -451,12 +456,17 @@ die_sig:
>>  info.si_addr  = pc;
>>  
>>  arm_notify_die("Oops - undefined instruction", regs, , 0, 6);
>> +exception_exit(prev_state);
>
> So, FP emulation and VFP support happens via a separate path.  Does this
> also need to be instrumented?

Looking a little closer at how FP/VFP support are handled along with the
rest of the exceptions, I wondered if it might be simpler to do
something like the patch below.  It instruments the assembly directly
using the existing usr_entry macro, and the ret_to_user path.

Doing that would replace instrumenting the various handlers
(do_DataAbort/do_PrefetchAbort), and would handle the FP emulation VFP
support as well.

If this looks OK, I can probably rework the syscall support as well.
This approach covers the slow syscall return path already.  Instead of
forcing the slowpath on all syscalls, I would just need to instrument
the syscall entry and fast syscall return.

Kevin


diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 0f82098..050472c 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -396,6 +396,9 @@ ENDPROC(__pabt_svc)
 #ifdef CONFIG_IRQSOFF_TRACER
bl  trace_hardirqs_off
 #endif
+#ifdef CONFIG_CONTEXT_TRACKING
+   bl  user_exit
+#endif 
.endm
 
.macro  kuser_cmpxchg_check
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 3248cde..3bef99b 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -74,6 +74,9 @@ no_work_pending:
 #if defined(CONFIG_IRQSOFF_TRACER)
asm_trace_hardirqs_on
 #endif
+#if defined(CONFIG_CONTEXT_TRACKING)
+   bl user_enter
+#endif 
/* perform architecture specific actions before user return */
arch_ret_to_user r1, lr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2 09/12] staging: ti-soc-thermal: fix several kernel-doc warnings and error

[Eduardo Valentin]

On 25-03-2013 14:22, Greg KH wrote:

On Tue, Mar 19, 2013 at 10:54:25AM -0400, Eduardo Valentin wrote:

This patch updates the documentation to remove
all warnings and errors reported by scripts/kernel-doc.
Most are missing arguments due to wrong format.

Cc: Nishanth Menon 

Signed-off-by: Eduardo Valentin 


In the future, don't put empty lines between the Cc: and signed-off-by:
lines please, I had to hand-edit all of these to fix that...


Ok. Sure.. My bad..



greg k-h




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

[Randy Dunlap]

On 03/22/13 07:07, Thomas Meyer wrote:
> Am Samstag, den 16.03.2013, 10:38 -0700 schrieb Randy Dunlap:
>> On 03/16/13 08:08, Thomas Meyer wrote:
>>> Am Mittwoch, den 13.03.2013, 12:56 -0700 schrieb Randy Dunlap:
>>> Yes,
>>>
>>> so why not do this? As the text to EARLY_PRINTK explains?
>>
>> Yes, the default should match the help text.
>> Acked-by: Randy Dunlap 
>>
>> Please resend your patch with Signed-off-by: line.
>>
>> Thanks.
> 
> Align EARLY_PRINTK default value with help text value.
> 
> Signed-off-by: Thomas Meyer 

Acked-by: Randy Dunlap 

Thanks.

tip??

> ---
> 
> diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> index b322f12..852d51c 100644
> --- a/arch/x86/Kconfig.debug
> +++ b/arch/x86/Kconfig.debug
> @@ -32,7 +32,6 @@ config X86_VERBOSE_BOOTUP
>  
>  config EARLY_PRINTK
> bool "Early printk" if EXPERT
> -   default y
> ---help---
>   Write kernel log output directly into the VGA buffer or to a serial
>   port.
> 
> 
> --


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] init/Kconfig: make EXPERT as config instead of menuconfig

[Randy Dunlap]

On 03/21/13 19:02, zhangwei(Jovi) wrote:
> There don't have any EXPERT menu guard, and no config item is
> included in EXPERT menu, so change it as a config, not menu.
> 
> This will make user more clear when they use 'make menuconfig'
> or 'make nconfig'.
> 
> Signed-off-by: zhangwei(Jovi) 
> Cc: Randy Dunlap 
> Cc: Michal Marek 

Makes sense to me.

Acked-by: Randy Dunlap 


Thanks.

> ---
>  init/Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 5341d72..0495453 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1177,7 +1177,7 @@ config SYSCTL
>  config ANON_INODES
>   bool
> 
> -menuconfig EXPERT
> +config EXPERT
>   bool "Configure standard kernel features (expert users)"
>   # Unhide debug options, to make the on-by-default options visible
>   select DEBUG_KERNEL
> 


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Renesas R-Car GPIO driver V3

[Magnus Damm]

From: Magnus Damm 

This patch is V3 of a GPIO driver for the R-Car series of
SoCs from Renesas. This driver is designed to be reusable
between multiple SoCs that share the same basic building block,
but so far it has only been used on R-Car H1 (r8a7779).

Each driver instance handles 32 GPIOs with individually
maskable IRQs. The driver operates on a single I/O memory 
range and the 32 GPIOs are hooked up a single interrupt.

In the case of R-Car H1 either external IRQ pins or GPIOs
with interrupts can be used for on-board interupts. For
external IRQs 4 pins are supported, and in the case of GPIO
there are 202 GPIOS as 202 interrupts hooked up via 6 driver
instances and to the GIC and the Cortex-A9 Quad.

At this point this driver is interfacing as a regular
platform device driver. In the future DT support will be
submitted as an incremental feature patch.

Signed-off-by: Magnus Damm 
---

 Changes since V2:
 - Simple merge of [PATCH 00/03] gpio: Renesas R-Car GPIO driver update
 
 Changes since V1:
 - Update based on most suggestions from review by Laurent, thanks!

 drivers/gpio/Kconfig|6 
 drivers/gpio/Makefile   |1 
 drivers/gpio/gpio-rcar.c|  373 +++
 include/linux/platform_data/gpio-rcar.h |   25 ++
 4 files changed, 405 insertions(+)

--- 0001/drivers/gpio/Kconfig
+++ work/drivers/gpio/Kconfig   2013-03-26 09:15:56.0 +0900
@@ -204,6 +204,12 @@ config GPIO_PXA
help
  Say yes here to support the PXA GPIO device
 
+config GPIO_RCAR
+   tristate "Renesas R-Car GPIO"
+   depends on ARM
+   help
+ Say yes here to support GPIO on Renesas R-Car SoCs.
+
 config GPIO_SPEAR_SPICS
bool "ST SPEAr13xx SPI Chip Select as GPIO support"
depends on PLAT_SPEAR
--- 0001/drivers/gpio/Makefile
+++ work/drivers/gpio/Makefile  2013-03-26 09:15:56.0 +0900
@@ -57,6 +57,7 @@ obj-$(CONFIG_GPIO_PL061)  += gpio-pl061.o
 obj-$(CONFIG_GPIO_PXA) += gpio-pxa.o
 obj-$(CONFIG_GPIO_RC5T583) += gpio-rc5t583.o
 obj-$(CONFIG_GPIO_RDC321X) += gpio-rdc321x.o
+obj-$(CONFIG_GPIO_RCAR)+= gpio-rcar.o
 obj-$(CONFIG_PLAT_SAMSUNG) += gpio-samsung.o
 obj-$(CONFIG_ARCH_SA1100)  += gpio-sa1100.o
 obj-$(CONFIG_GPIO_SCH) += gpio-sch.o
--- /dev/null
+++ work/drivers/gpio/gpio-rcar.c   2013-03-26 09:16:09.0 +0900
@@ -0,0 +1,373 @@
+/*
+ * Renesas R-Car GPIO Support
+ *
+ *  Copyright (C) 2013 Magnus Damm
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License
+ *
+ * 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 
+#include 
+#include 
+
+struct gpio_rcar_priv {
+   void __iomem *base;
+   spinlock_t lock;
+   struct gpio_rcar_config config;
+   struct platform_device *pdev;
+   struct gpio_chip gpio_chip;
+   struct irq_chip irq_chip;
+   struct irq_domain *irq_domain;
+};
+
+#define IOINTSEL 0x00
+#define INOUTSEL 0x04
+#define OUTDT 0x08
+#define INDT 0x0c
+#define INTDT 0x10
+#define INTCLR 0x14
+#define INTMSK 0x18
+#define MSKCLR 0x1c
+#define POSNEG 0x20
+#define EDGLEVEL 0x24
+#define FILONOFF 0x28
+
+static inline u32 gpio_rcar_read(struct gpio_rcar_priv *p, int offs)
+{
+   return ioread32(p->base + offs);
+}
+
+static inline void gpio_rcar_write(struct gpio_rcar_priv *p, int offs,
+  u32 value)
+{
+   iowrite32(value, p->base + offs);
+}
+
+static void gpio_rcar_modify_bit(struct gpio_rcar_priv *p, int offs,
+int bit, bool value)
+{
+   u32 tmp = gpio_rcar_read(p, offs);
+
+   if (value)
+   tmp |= BIT(bit);
+   else
+   tmp &= ~BIT(bit);
+
+   gpio_rcar_write(p, offs, tmp);
+}
+
+static void gpio_rcar_irq_disable(struct irq_data *d)
+{
+   struct gpio_rcar_priv *p = irq_data_get_irq_chip_data(d);
+
+   gpio_rcar_write(p, INTMSK, ~BIT(irqd_to_hwirq(d)));
+}
+
+static void gpio_rcar_irq_enable(struct irq_data *d)
+{
+   struct gpio_rcar_priv *p = irq_data_get_irq_chip_data(d);
+
+   gpio_rcar_write(p, MSKCLR, BIT(irqd_to_hwirq(d)));
+}
+
+static void gpio_rcar_config_interrupt_input_mode(struct gpio_rcar_priv *p,
+ unsigned int hwirq,
+ bool active_high_rising_edge,
+ bool level_trigger)
+{
+   unsigned long flags;
+
+   /* follow steps in the GPIO 

Re: [PATCH] seccomp: allow BPF_XOR based ALU instructions.

[James Morris]

On Fri, 15 Mar 2013, Nicolas Schichan wrote:

> 
> Signed-off-by: Nicolas Schichan 
> ---
>  kernel/seccomp.c |2 ++
>  1 file changed, 2 insertions(+)

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next


-- 
James Morris

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

[PATCH 3/6] workqueue: protect wq->nr_drainers and ->flags with wq->mutex

[Tejun Heo]

From: Lai Jiangshan 

We're expanding wq->mutex to cover all fields specific to each
workqueue with the end goal of replacing pwq_lock which will make
locking simpler and easier to understand.

wq->nr_drainers and ->flags are specific to each workqueue.  Protect
->nr_drainers and ->flags with wq->mutex instead of pool_mutex.

tj: Rebased on top of the current dev branch.  Updated description.

Signed-off-by: Lai Jiangshan 
Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index d448eda..3ac2c4d 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -226,7 +226,7 @@ struct wq_device;
  * the appropriate worker_pool through its pool_workqueues.
  */
 struct workqueue_struct {
-   unsigned intflags;  /* PL: WQ_* flags */
+   unsigned intflags;  /* WQ: WQ_* flags */
struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwq's */
struct list_headpwqs;   /* WR: all pwqs of this wq */
struct list_headlist;   /* PL: list of all workqueues */
@@ -242,7 +242,7 @@ struct workqueue_struct {
struct list_headmaydays;/* MD: pwqs requesting rescue */
struct worker   *rescuer;   /* I: rescue worker */
 
-   int nr_drainers;/* PL: drain in progress */
+   int nr_drainers;/* WQ: drain in progress */
int saved_max_active; /* PW: saved pwq max_active */
 
 #ifdef CONFIG_SYSFS
@@ -2684,10 +2684,10 @@ void drain_workqueue(struct workqueue_struct *wq)
 * hotter than drain_workqueue() and already looks at @wq->flags.
 * Use __WQ_DRAINING so that queue doesn't have to check nr_drainers.
 */
-   mutex_lock(_pool_mutex);
+   mutex_lock(>mutex);
if (!wq->nr_drainers++)
wq->flags |= __WQ_DRAINING;
-   mutex_unlock(_pool_mutex);
+   mutex_unlock(>mutex);
 reflush:
flush_workqueue(wq);
 
@@ -2714,10 +2714,10 @@ reflush:
 
local_irq_enable();
 
-   mutex_lock(_pool_mutex);
+   mutex_lock(>mutex);
if (!--wq->nr_drainers)
wq->flags &= ~__WQ_DRAINING;
-   mutex_unlock(_pool_mutex);
+   mutex_unlock(>mutex);
 }
 EXPORT_SYMBOL_GPL(drain_workqueue);
 
-- 
1.8.1.4

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

[PATCH 4/6] workqueue: protect wq->pwqs and iteration with wq->mutex

[Tejun Heo]

From: Lai Jiangshan 

We're expanding wq->mutex to cover all fields specific to each
workqueue with the end goal of replacing pwq_lock which will make
locking simpler and easier to understand.

init_and_link_pwq() and pwq_unbound_release_workfn() already grab
wq->mutex when adding or removing a pwq from wq->pwqs list.  This
patch makes it official that the list is wq->mutex protected for
writes and updates readers accoridingly.  Explicit IRQ toggles for
sched-RCU read-locking in flush_workqueue_prep_pwqs() and
drain_workqueues() are removed as the surrounding wq->mutex can
provide sufficient synchronization.

Also, assert_rcu_or_pwq_lock() is renamed to assert_rcu_or_wq_mutex()
and checks for wq->mutex too.

pwq_lock locking and assertion are not removed by this patch and a
couple of for_each_pwq() iterations are still protected by it.
They'll be removed by future patches.

tj: Rebased on top of the current dev branch.  Updated description.
Folded in assert_rcu_or_wq_mutex() renaming from a later patch
along with associated comment updates.

Signed-off-by: Lai Jiangshan 
Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 42 ++
 1 file changed, 18 insertions(+), 24 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 3ac2c4d..9c32fd1 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -204,7 +204,7 @@ struct pool_workqueue {
 * Release of unbound pwq is punted to system_wq.  See put_pwq()
 * and pwq_unbound_release_workfn() for details.  pool_workqueue
 * itself is also sched-RCU protected so that the first pwq can be
-* determined without grabbing pwq_lock.
+* determined without grabbing wq->mutex.
 */
struct work_struct  unbound_release_work;
struct rcu_head rcu;
@@ -298,10 +298,11 @@ static void copy_workqueue_attrs(struct workqueue_attrs 
*to,
   lockdep_is_held(_pool_mutex), \
   "sched RCU or wq_pool_mutex should be held")
 
-#define assert_rcu_or_pwq_lock()   \
+#define assert_rcu_or_wq_mutex(wq) \
rcu_lockdep_assert(rcu_read_lock_sched_held() ||\
+  lockdep_is_held(>mutex) ||   \
   lockdep_is_held(_lock),  \
-  "sched RCU or pwq_lock should be held")
+  "sched RCU or wq->mutex should be held")
 
 #ifdef CONFIG_LOCKDEP
 #define assert_manager_or_pool_lock(pool)  \
@@ -356,7 +357,7 @@ static void copy_workqueue_attrs(struct workqueue_attrs *to,
  * @pwq: iteration cursor
  * @wq: the target workqueue
  *
- * This must be called either with pwq_lock held or sched RCU read locked.
+ * This must be called either with wq->mutex held or sched RCU read locked.
  * If the pwq needs to be used beyond the locking in effect, the caller is
  * responsible for guaranteeing that the pwq stays online.
  *
@@ -365,7 +366,7 @@ static void copy_workqueue_attrs(struct workqueue_attrs *to,
  */
 #define for_each_pwq(pwq, wq)  \
list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node)  \
-   if (({ assert_rcu_or_pwq_lock(); false; })) { } \
+   if (({ assert_rcu_or_wq_mutex(wq); false; })) { }   \
else
 
 #ifdef CONFIG_DEBUG_OBJECTS_WORK
@@ -504,13 +505,13 @@ static int worker_pool_assign_id(struct worker_pool *pool)
  * first_pwq - return the first pool_workqueue of the specified workqueue
  * @wq: the target workqueue
  *
- * This must be called either with pwq_lock held or sched RCU read locked.
+ * This must be called either with wq->mutex held or sched RCU read locked.
  * If the pwq needs to be used beyond the locking in effect, the caller is
  * responsible for guaranteeing that the pwq stays online.
  */
 static struct pool_workqueue *first_pwq(struct workqueue_struct *wq)
 {
-   assert_rcu_or_pwq_lock();
+   assert_rcu_or_wq_mutex(wq);
return list_first_or_null_rcu(>pwqs, struct pool_workqueue,
  pwqs_node);
 }
@@ -2477,12 +2478,10 @@ static bool flush_workqueue_prep_pwqs(struct 
workqueue_struct *wq,
atomic_set(>nr_pwqs_to_flush, 1);
}
 
-   local_irq_disable();
-
for_each_pwq(pwq, wq) {
struct worker_pool *pool = pwq->pool;
 
-   spin_lock(>lock);
+   spin_lock_irq(>lock);
 
if (flush_color >= 0) {
WARN_ON_ONCE(pwq->flush_color != -1);
@@ -2499,11 +2498,9 @@ static bool flush_workqueue_prep_pwqs(struct 
workqueue_struct *wq,
pwq->work_color = work_color;
}
 
-   spin_unlock(>lock);
+   spin_unlock_irq(>lock);
}
 
-   

[PATCH 6/6] workqueue: remove pwq_lock which is no longer used

[Tejun Heo]

From: Lai Jiangshan 

To simplify locking, the previous patches expanded wq->mutex to
protect all fields of each workqueue instance including the pwqs list
leaving pwq_lock without any user.  Remove the unused pwq_lock.

tj: Rebased on top of the current dev branch.  Updated description.

Signed-off-by: Lai Jiangshan 
Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index af6087a..04a8b98 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -125,12 +125,9 @@ enum {
  *
  * PR: wq_pool_mutex protected for writes.  Sched-RCU protected for reads.
  *
- * PW: pwq_lock protected.
- *
  * WQ: wq->mutex protected.
  *
- * WR: wq->mutex and pwq_lock protected for writes.  Sched-RCU protected
- * for reads.
+ * WR: wq->mutex protected for writes.  Sched-RCU protected for reads.
  *
  * MD: wq_mayday_lock protected.
  */
@@ -257,7 +254,6 @@ struct workqueue_struct {
 static struct kmem_cache *pwq_cache;
 
 static DEFINE_MUTEX(wq_pool_mutex);/* protects pools and workqueues list */
-static DEFINE_SPINLOCK(pwq_lock);  /* protects pool_workqueues */
 static DEFINE_SPINLOCK(wq_mayday_lock);/* protects wq->maydays list */
 
 static LIST_HEAD(workqueues);  /* PL: list of all workqueues */
@@ -300,8 +296,7 @@ static void copy_workqueue_attrs(struct workqueue_attrs *to,
 
 #define assert_rcu_or_wq_mutex(wq) \
rcu_lockdep_assert(rcu_read_lock_sched_held() ||\
-  lockdep_is_held(>mutex) ||   \
-  lockdep_is_held(_lock),  \
+  lockdep_is_held(>mutex), \
   "sched RCU or wq->mutex should be held")
 
 #ifdef CONFIG_LOCKDEP
@@ -3549,9 +3544,7 @@ static void pwq_unbound_release_workfn(struct work_struct 
*work)
 * and consistent with the linking path.
 */
mutex_lock(>mutex);
-   spin_lock_irq(_lock);
list_del_rcu(>pwqs_node);
-   spin_unlock_irq(_lock);
mutex_unlock(>mutex);
 
put_unbound_pool(pool);
@@ -3635,9 +3628,7 @@ static void init_and_link_pwq(struct pool_workqueue *pwq,
pwq_adjust_max_active(pwq);
 
/* link in @pwq */
-   spin_lock_irq(_lock);
list_add_rcu(>pwqs_node, >pwqs);
-   spin_unlock_irq(_lock);
 
mutex_unlock(>mutex);
 }
-- 
1.8.1.4

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

[PATCH 5/6] workqueue: protect wq->saved_max_active with wq->mutex

[Tejun Heo]

From: Lai Jiangshan 

We're expanding wq->mutex to cover all fields specific to each
workqueue with the end goal of replacing pwq_lock which will make
locking simpler and easier to understand.

This patch makes wq->saved_max_active protected by wq->mutex instead
of pwq_lock.  As pwq_lock locking around pwq_adjust_mac_active() is no
longer necessary, this patch also replaces pwq_lock lockings of
for_each_pwq() around pwq_adjust_max_active() to wq->mutex.

tj: Rebased on top of the current dev branch.  Updated description.

Signed-off-by: Lai Jiangshan 
Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 9c32fd1..af6087a 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -243,7 +243,7 @@ struct workqueue_struct {
struct worker   *rescuer;   /* I: rescue worker */
 
int nr_drainers;/* WQ: drain in progress */
-   int saved_max_active; /* PW: saved pwq max_active */
+   int saved_max_active; /* WQ: saved pwq max_active */
 
 #ifdef CONFIG_SYSFS
struct wq_device*wq_dev;/* I: for sysfs interface */
@@ -3579,13 +3579,13 @@ static void pwq_adjust_max_active(struct pool_workqueue 
*pwq)
bool freezable = wq->flags & WQ_FREEZABLE;
 
/* for @wq->saved_max_active */
-   lockdep_assert_held(_lock);
+   lockdep_assert_held(>mutex);
 
/* fast exit for non-freezable wqs */
if (!freezable && pwq->max_active == wq->saved_max_active)
return;
 
-   spin_lock(>pool->lock);
+   spin_lock_irq(>pool->lock);
 
if (!freezable || !(pwq->pool->flags & POOL_FREEZING)) {
pwq->max_active = wq->saved_max_active;
@@ -3603,7 +3603,7 @@ static void pwq_adjust_max_active(struct pool_workqueue 
*pwq)
pwq->max_active = 0;
}
 
-   spin_unlock(>pool->lock);
+   spin_unlock_irq(>pool->lock);
 }
 
 static void init_and_link_pwq(struct pool_workqueue *pwq,
@@ -3622,7 +3622,6 @@ static void init_and_link_pwq(struct pool_workqueue *pwq,
INIT_WORK(>unbound_release_work, pwq_unbound_release_workfn);
 
mutex_lock(>mutex);
-   spin_lock_irq(_lock);
 
/*
 * Set the matching work_color.  This is synchronized with
@@ -3636,9 +3635,10 @@ static void init_and_link_pwq(struct pool_workqueue *pwq,
pwq_adjust_max_active(pwq);
 
/* link in @pwq */
+   spin_lock_irq(_lock);
list_add_rcu(>pwqs_node, >pwqs);
-
spin_unlock_irq(_lock);
+
mutex_unlock(>mutex);
 }
 
@@ -3803,10 +3803,10 @@ struct workqueue_struct *__alloc_workqueue_key(const 
char *fmt,
 */
mutex_lock(_pool_mutex);
 
-   spin_lock_irq(_lock);
+   mutex_lock(>mutex);
for_each_pwq(pwq, wq)
pwq_adjust_max_active(pwq);
-   spin_unlock_irq(_lock);
+   mutex_unlock(>mutex);
 
list_add(>list, );
 
@@ -3917,14 +3917,14 @@ void workqueue_set_max_active(struct workqueue_struct 
*wq, int max_active)
 
max_active = wq_clamp_max_active(max_active, wq->flags, wq->name);
 
-   spin_lock_irq(_lock);
+   mutex_lock(>mutex);
 
wq->saved_max_active = max_active;
 
for_each_pwq(pwq, wq)
pwq_adjust_max_active(pwq);
 
-   spin_unlock_irq(_lock);
+   mutex_unlock(>mutex);
 }
 EXPORT_SYMBOL_GPL(workqueue_set_max_active);
 
@@ -4287,7 +4287,7 @@ EXPORT_SYMBOL_GPL(work_on_cpu);
  * pool->worklist.
  *
  * CONTEXT:
- * Grabs and releases wq_pool_mutex, pwq_lock and pool->lock's.
+ * Grabs and releases wq_pool_mutex, wq->mutex and pool->lock's.
  */
 void freeze_workqueues_begin(void)
 {
@@ -4309,13 +4309,12 @@ void freeze_workqueues_begin(void)
spin_unlock_irq(>lock);
}
 
-   /* suppress further executions by setting max_active to zero */
-   spin_lock_irq(_lock);
list_for_each_entry(wq, , list) {
+   mutex_lock(>mutex);
for_each_pwq(pwq, wq)
pwq_adjust_max_active(pwq);
+   mutex_unlock(>mutex);
}
-   spin_unlock_irq(_lock);
 
mutex_unlock(_pool_mutex);
 }
@@ -4373,7 +4372,7 @@ out_unlock:
  * frozen works are transferred to their respective pool worklists.
  *
  * CONTEXT:
- * Grabs and releases wq_pool_mutex, pwq_lock and pool->lock's.
+ * Grabs and releases wq_pool_mutex, wq->mutex and pool->lock's.
  */
 void thaw_workqueues(void)
 {
@@ -4396,12 +4395,12 @@ void thaw_workqueues(void)
}
 
/* restore max_active and repopulate worklist */
-   spin_lock_irq(_lock);
list_for_each_entry(wq, , list) {
+   mutex_lock(>mutex);
for_each_pwq(pwq, wq)
pwq_adjust_max_active(pwq);
+   mutex_unlock(>mutex);
}
-   

[PATCH 1/6] workqueue: rename wq_mutex to wq_pool_mutex

[Tejun Heo]

From: Lai Jiangshan 

wq->flush_mutex will be renamed to wq->mutex and cover all fields
specific to each workqueue and eventually replace pwq_lock, which will
make locking simpler and easier to understand.

Rename wq_mutex to wq_pool_mutex to avoid confusion with wq->mutex.
After the scheduled changes, wq_pool_mutex won't be protecting
anything specific to each workqueue instance anyway.

This patch is pure rename.

tj: s/wqs_mutex/wq_pool_mutex/.  Rewrote description.

Signed-off-by: Tejun Heo 
Cc: Lai Jiangshan 
---
 kernel/workqueue.c | 109 +++--
 1 file changed, 55 insertions(+), 54 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 47f2587..064157e 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -123,9 +123,9 @@ enum {
  * MG: pool->manager_mutex and pool->lock protected.  Writes require both
  * locks.  Reads can happen under either lock.
  *
- * WQ: wq_mutex protected.
+ * PL: wq_pool_mutex protected.
  *
- * WR: wq_mutex protected for writes.  Sched-RCU protected for reads.
+ * PR: wq_pool_mutex protected for writes.  Sched-RCU protected for reads.
  *
  * PW: pwq_lock protected.
  *
@@ -163,8 +163,8 @@ struct worker_pool {
struct idr  worker_idr; /* MG: worker IDs and iteration 
*/
 
struct workqueue_attrs  *attrs; /* I: worker attributes */
-   struct hlist_node   hash_node;  /* WQ: unbound_pool_hash node */
-   int refcnt; /* WQ: refcnt for unbound pools 
*/
+   struct hlist_node   hash_node;  /* PL: unbound_pool_hash node */
+   int refcnt; /* PL: refcnt for unbound pools 
*/
 
/*
 * The current concurrency level.  As it's likely to be accessed
@@ -226,10 +226,10 @@ struct wq_device;
  * the appropriate worker_pool through its pool_workqueues.
  */
 struct workqueue_struct {
-   unsigned intflags;  /* WQ: WQ_* flags */
+   unsigned intflags;  /* PL: WQ_* flags */
struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwq's */
struct list_headpwqs;   /* FR: all pwqs of this wq */
-   struct list_headlist;   /* WQ: list of all workqueues */
+   struct list_headlist;   /* PL: list of all workqueues */
 
struct mutexflush_mutex;/* protects wq flushing */
int work_color; /* F: current work color */
@@ -242,7 +242,7 @@ struct workqueue_struct {
struct list_headmaydays;/* MD: pwqs requesting rescue */
struct worker   *rescuer;   /* I: rescue worker */
 
-   int nr_drainers;/* WQ: drain in progress */
+   int nr_drainers;/* PL: drain in progress */
int saved_max_active; /* PW: saved pwq max_active */
 
 #ifdef CONFIG_SYSFS
@@ -256,20 +256,20 @@ struct workqueue_struct {
 
 static struct kmem_cache *pwq_cache;
 
-static DEFINE_MUTEX(wq_mutex); /* protects workqueues and pools */
+static DEFINE_MUTEX(wq_pool_mutex);/* protects pools and workqueues list */
 static DEFINE_SPINLOCK(pwq_lock);  /* protects pool_workqueues */
 static DEFINE_SPINLOCK(wq_mayday_lock);/* protects wq->maydays list */
 
-static LIST_HEAD(workqueues);  /* WQ: list of all workqueues */
-static bool workqueue_freezing;/* WQ: have wqs started 
freezing? */
+static LIST_HEAD(workqueues);  /* PL: list of all workqueues */
+static bool workqueue_freezing;/* PL: have wqs started 
freezing? */
 
 /* the per-cpu worker pools */
 static DEFINE_PER_CPU_SHARED_ALIGNED(struct worker_pool [NR_STD_WORKER_POOLS],
 cpu_worker_pools);
 
-static DEFINE_IDR(worker_pool_idr);/* WR: idr of all pools */
+static DEFINE_IDR(worker_pool_idr);/* PR: idr of all pools */
 
-/* WQ: hash of all unbound pools keyed by pool->attrs */
+/* PL: hash of all unbound pools keyed by pool->attrs */
 static DEFINE_HASHTABLE(unbound_pool_hash, UNBOUND_POOL_HASH_ORDER);
 
 /* I: attributes used when instantiating standard unbound pools on demand */
@@ -293,10 +293,10 @@ static void copy_workqueue_attrs(struct workqueue_attrs 
*to,
 #define CREATE_TRACE_POINTS
 #include 
 
-#define assert_rcu_or_wq_mutex()   \
+#define assert_rcu_or_pool_mutex() \
rcu_lockdep_assert(rcu_read_lock_sched_held() ||\
-  lockdep_is_held(_mutex),  \
-  "sched RCU or wq_mutex should be held")
+  lockdep_is_held(_pool_mutex), \
+  "sched RCU or wq_pool_mutex should be held")
 
 #define assert_rcu_or_pwq_lock() 

[PATCHSET wq/for-3.10] workqueue: replace pwq_lock with wq->mutex

[Tejun Heo]

Hello,

This patchset renames wq->flush_mutex to wq->mutex and expands it to
protect most fields which are specific to each workqueue instance.
This simplifies the locking and makes it easier to understand.  The
mutex was already half there with multiple pool_workqueues support for
unbound workqueues anyway.

The patchese in this series are reshuffled / slightly updated versions
of the relevant patches in Lai's "workqueue: cleanups and better
locking for recent changes" patchset [1].  It contains the following
six patches.  The descriptions are mostly rewritten.

 0001-workqueue-rename-wq_mutex-to-wq_pool_mutex.patch
 0002-workqueue-rename-wq-flush_mutex-to-wq-mutex.patch
 0003-workqueue-protect-wq-nr_drainers-and-flags-with-wq-m.patch
 0004-workqueue-protect-wq-pwqs-and-iteration-with-wq-mute.patch
 0005-workqueue-protect-wq-saved_max_active-with-wq-mutex.patch
 0006-workqueue-remove-pwq_lock-which-is-no-longer-used.patch

0001 is 0007 in the original set.  s/wqs_mutex/wq_pool_mutex/
0002 is 0008.
0003 is 0009.
0004 is 0011.
0005 is 0012.
0006 is 0013.

These patches have been applied to wq/for-3.10.

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-3.10

So, I changes things a bit but nothing fundamental.  Other than some
renaming and reshuffling, these patches do exact the same things as
your original versions.  With these applied, your and my changes
shouldn't collide too much, so let's base everything on top of this.

Thanks.

diffstat follows.

 kernel/workqueue.c |  225 -
 1 file changed, 105 insertions(+), 120 deletions(-)

--
tejun

[1] http://thread.gmane.org/gmane.linux.kernel/1459923
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] workqueue: rename wq->flush_mutex to wq->mutex

[Tejun Heo]

From: Lai Jiangshan 

Currently pwq->flush_mutex protects many fields of a workqueue
including, especially, the pwqs list.  We're going to expand this
mutex to protect most of a workqueue and eventually replace pwq_lock,
which will make locking simpler and easier to understand.

Drop the "flush_" prefix in preparation.

This patch is pure rename.

tj: Rebased on top of the current dev branch.  Updated description.
Use WQ: and WR: instead of Q: and QR: for synchronization labels.

Signed-off-by: Lai Jiangshan 
Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 52 ++--
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 064157e..d448eda 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -118,8 +118,6 @@ enum {
  *cpu or grabbing pool->lock is enough for read access.  If
  *POOL_DISASSOCIATED is set, it's identical to L.
  *
- * F: wq->flush_mutex protected.
- *
  * MG: pool->manager_mutex and pool->lock protected.  Writes require both
  * locks.  Reads can happen under either lock.
  *
@@ -129,8 +127,10 @@ enum {
  *
  * PW: pwq_lock protected.
  *
- * FR: wq->flush_mutex and pwq_lock protected for writes.  Sched-RCU
- * protected for reads.
+ * WQ: wq->mutex protected.
+ *
+ * WR: wq->mutex and pwq_lock protected for writes.  Sched-RCU protected
+ * for reads.
  *
  * MD: wq_mayday_lock protected.
  */
@@ -197,7 +197,7 @@ struct pool_workqueue {
int nr_active;  /* L: nr of active works */
int max_active; /* L: max active works */
struct list_headdelayed_works;  /* L: delayed works */
-   struct list_headpwqs_node;  /* FR: node on wq->pwqs */
+   struct list_headpwqs_node;  /* WR: node on wq->pwqs */
struct list_headmayday_node;/* MD: node on wq->maydays */
 
/*
@@ -214,8 +214,8 @@ struct pool_workqueue {
  * Structure used to wait for workqueue flush.
  */
 struct wq_flusher {
-   struct list_headlist;   /* F: list of flushers */
-   int flush_color;/* F: flush color waiting for */
+   struct list_headlist;   /* WQ: list of flushers */
+   int flush_color;/* WQ: flush color waiting for 
*/
struct completion   done;   /* flush completion */
 };
 
@@ -228,16 +228,16 @@ struct wq_device;
 struct workqueue_struct {
unsigned intflags;  /* PL: WQ_* flags */
struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwq's */
-   struct list_headpwqs;   /* FR: all pwqs of this wq */
+   struct list_headpwqs;   /* WR: all pwqs of this wq */
struct list_headlist;   /* PL: list of all workqueues */
 
-   struct mutexflush_mutex;/* protects wq flushing */
-   int work_color; /* F: current work color */
-   int flush_color;/* F: current flush color */
+   struct mutexmutex;  /* protects this wq */
+   int work_color; /* WQ: current work color */
+   int flush_color;/* WQ: current flush color */
atomic_tnr_pwqs_to_flush; /* flush in progress */
-   struct wq_flusher   *first_flusher; /* F: first flusher */
-   struct list_headflusher_queue;  /* F: flush waiters */
-   struct list_headflusher_overflow; /* F: flush overflow list */
+   struct wq_flusher   *first_flusher; /* WQ: first flusher */
+   struct list_headflusher_queue;  /* WQ: flush waiters */
+   struct list_headflusher_overflow; /* WQ: flush overflow list */
 
struct list_headmaydays;/* MD: pwqs requesting rescue */
struct worker   *rescuer;   /* I: rescue worker */
@@ -2460,7 +2460,7 @@ static void insert_wq_barrier(struct pool_workqueue *pwq,
  * advanced to @work_color.
  *
  * CONTEXT:
- * mutex_lock(wq->flush_mutex).
+ * mutex_lock(wq->mutex).
  *
  * RETURNS:
  * %true if @flush_color >= 0 and there's something to flush.  %false
@@ -2529,7 +2529,7 @@ void flush_workqueue(struct workqueue_struct *wq)
lock_map_acquire(>lockdep_map);
lock_map_release(>lockdep_map);
 
-   mutex_lock(>flush_mutex);
+   mutex_lock(>mutex);
 
/*
 * Start-to-wait phase
@@ -2574,7 +2574,7 @@ void flush_workqueue(struct workqueue_struct *wq)
list_add_tail(_flusher.list, >flusher_overflow);
}
 
-   mutex_unlock(>flush_mutex);
+   mutex_unlock(>mutex);
 
wait_for_completion(_flusher.done);
 
@@ -2587,7 +2587,7 @@ void flush_workqueue(struct workqueue_struct *wq)
if (wq->first_flusher != _flusher)
return;
 
-   

Re: RFC v2: Zynq Clock Controller

[Sören Brinkmann]

On Mon, Mar 25, 2013 at 05:29:33PM -0600, Stephen Warren wrote:
> On 03/22/2013 04:41 PM, Sören Brinkmann wrote:
> > Hi Lars,
> > 
> > On Thu, Mar 21, 2013 at 07:32:52PM +0100, Lars-Peter Clausen wrote:
> >> On 03/21/2013 12:56 AM, Sören Brinkmann wrote:
> >>> Hi,
> >>>
> >>> I spent some time working on this and incorporating feedback. Here's an 
> >>> updated proposal for a clock controller for Zynq:
> >>>
> >>> Required properties:
> >>>  - #clock-cells : Must be 1
> >>>  - compatible : "xlnx,ps7-clkc"  (this may become 'xlnx,zynq-clkc' 
> >>> terminology differs a bit between Xilinx internal and mainline)
> >>>  - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ
> >>>  (usually 33 MHz oscillators are used for Zynq 
> >>> platforms)
> >>>  - clock-output-names : List of strings used to name the clock outputs. 
> >>> Shall be a list of the outputs given below.
> >>>
> >>> Optional properties:
> >>>  - clocks : as described in the clock bindings
> >>>  - clock-names : as described in the clock bindings
> >>>
> >>> Clock inputs:
> >>> The following strings are optional parameters to the 'clock-names' 
> >>> property in
> >>> order to provide optional (E)MIO clock sources.
> >>>  - swdt_ext_clk
> >>>  - gem0_emio_clk
> >>>  - gem1_emio_clk
> >>>  - mio_clk_XX  # with XX = 00..53
> >>>
> >>> Example:
> >>> clkc: clkc {
> >>> #clock-cells = <1>;
> >>> compatible = "xlnx,ps7-clkc";
> >>> ps-clk-frequency = <>;
> >>
> >> The input frequency should be a clock as well.
> >
> > Again, monolithic vs split. I don't see a reason not to just internally
> > call clk_register_fixed_rate(). That way its children do not have to
> > cope with a variable name for the xtal.
> > Also, with my proposal 'clocks' and 'clock-names' would be purely
> > optional properties, only required if optional external inputs are
> > present. Having the xtal defined externally would add mandatory entries for
> > those props.
> 
> But isn't the clock source board-specific? It's a completely separate
> object from Zynq's own clock controller HW, and as such should be
> represented by a separate DT node, right?
Well, the ps-clk-frequency property would be board specific right. But
the same would apply for a fixed-rate clock. This is how it's currently
done in mainline. The zynq dtsi file defines the fixed-rate clock and
every board dts file overrides the fixed rate clock's frequency
property.
In my approach the fixed rate clock is within the clkc block and every
board dts has to provide this property accordingly.


> 
> The issue with parent clock names is simply a red herring. A solution is
> needed to registered clock with a parent clock object, rather than a
> parent clock name. Then, the parent names are completely irrelevant.
But we'd trade the naming problems with issues regarding the order of
how clocks are probed.
And it may not be as easy as just probe from the root towards the leafs
of the clock tree.
In Zynq I can route clocks generated in the processor part into the FPGA
and back using them as an input for the clock-controller. Ant the IP in
the FPGA could add another layer of clock providers in that loop.
With such circular dependencies a clock object based
registration/probing does not seem too easy to me.

Sören


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

Re: RFC v2: Zynq Clock Controller

[Sören Brinkmann]

On Mon, Mar 25, 2013 at 05:33:10PM -0600, Stephen Warren wrote:
> On 03/25/2013 12:27 PM, Sören Brinkmann wrote:
> > Hi Stephen,
> > 
> > On Mon, Mar 25, 2013 at 12:13:08PM -0600, Stephen Warren wrote:
> >> On 03/20/2013 05:56 PM, Sören Brinkmann wrote:
> >>> Hi,
> >>>
> >>> I spent some time working on this and incorporating feedback. Here's an 
> >>> updated proposal for a clock controller for Zynq:
> >>>
> >>> Required properties:
> >>>  - #clock-cells : Must be 1
> >>>  - compatible : "xlnx,ps7-clkc"  (this may become 'xlnx,zynq-clkc' 
> >>> terminology differs a bit between Xilinx internal and mainline)
> >>>  - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ
> >>>  (usually 33 MHz oscillators are used for Zynq 
> >>> platforms)
> >>
> >> This may have been mentioned before, but shouldn't the input clock be
> >> represented as an actual clock in DT, and hence as an entry in this
> >> node's clocks property? The crystal/... itself can be represented in DT
> >> as a fixed-clock.
> > Lars-Peter brought that up, too. Please refer to my answer to him.
> > 
> >>
> >>>  - clock-output-names : List of strings used to name the clock outputs. 
> >>> Shall be a list of the outputs given below.
> >>
> >> That shouldn't be required.
> >
> > When I want to support of_clk_get_parent_name() for my clocks, I think
> > it is. And I'm inclined to not brake this functionality.
> 
> The solution here is to make clock parent names irrelevant.
> 
> Also note that device tree is supposed to describe HW. As such, this
> kind of internal implementation detail of the Linux clock driver should
> have basically zero effect on the DT binding definition.
> 
> >>> Optional properties:
> >>>  - clocks : as described in the clock bindings
> >>>  - clock-names : as described in the clock bindings
> >>
> >> I think clocks should be required, with at least the main crystal clock
> >> input always present, but perhaps having some optional entries for the
> >> (E)MIO feature you mention.
> >
> > This is why I have the xtal separate. This way these props are purely
> > optional and the xtal frequency is obtained separately. It also makes it
> > a little easier internally, because I don't have to cope with a variable
> > name for the xtal this way.
> > 
> > Describing the xtal as fixed clock in DT means a mandatory entry for
> > 'clocks' and 'clock-names' and a variable name for the xtal clock. I
> > wanted to avoid this.
> 
> I don't see any benefit with some properties being purely optional.
> Having optional entries in a property seems just fine to me.
> 
> The name of the crystal clock should be irrelevant; that issue simply
> needs to be fixed. It's driving too much of this discussion, and it will
> be irrelevant once it's fixed.
> 
> >>> Example:
> >>> clkc: clkc {
> >>> #clock-cells = <1>;
> >>> compatible = "xlnx,ps7-clkc";
> >>> ps-clk-frequency = <>;
> >>> clock-output-names = "armpll", "ddrpll", "iopll", 
> >>> "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x", "dci", 
> >>> "lqspi", "smc", "pcap", "gem0", "gem1", "fclk0", "fclk1", "fclk2", 
> >>> "fclk3", "can0", "can1", "sdio0", "sdio1", "uart0", "uart1", "spi0", 
> >>> "spi1", "dma", "usb0_aper", "usb1_aper", "gem0_aper", "gem1_aper", 
> >>> "sdio0_aper", "sdio1_aper", "spi0_aper", "spi1_aper", "can0_aper", 
> >>> "can1_aper", "i2c0_aper", "i2c1_aper", "uart0_aper", "uart1_aper", 
> >>> "gpio_aper", "lqspi_aper", "smc_aper", "swdt", "dbg_trc", "dbg_apb";  /* 
> >>> long list... explanation below */
> >>> /* optional props */
> >>> clocks = < 16>, <_foo>;
> >>> clock-names = "gem1_emio_clk", "can_mio_clk_23";
> >>> };
> >>>
> >>> The downside of supporting this is, that I don't see a way around 
> >>> explicitly listing the clock output names in the DT.
> >>
> >> (Please wrap your emails to ~74 characters or so)
> > I changed my settings.
> > 
> >>
> >> As Mike mentioned off-list, one can create a new clk registration API
> >> that takes a struct clk* as parent rather than a char *clk_name.
> >
> > Then we also have to make sure clocks are probed in a specific order. To
> > obtain a 'struct clk *' through clk_get() the requested clock has to be
> > already been probed. Currently clock probing relies purely on data present
> > in DT. This makes this proposal not that trivial, IMHO.
> 
> Simply use deferred probe.
This would require major changes to the whole clock probing mechanism.
Currently, clocks can not defer probing. And in case of circular
dependencies in the clock tree, it would rather require a multiple steps
probe. Simply deferring won't be enough.

Sören


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

Re: [PATCH v3 2/2] ACPI,acpi_memhotplug: Remove acpi_memory_info->failed bit

[Yasuaki Ishimatsu]

2013/03/23 5:24, Toshi Kani wrote:

On Fri, 2013-03-22 at 10:53 +0900, Yasuaki Ishimatsu wrote:

acpi_memory_info has enabled bit and failed bit for controlling memory
hotplug. But we don't need to keep both bits.

The patch removes acpi_memory_info->failed bit.

Signed-off-by: yasuaki ishimatsu 


Thanks for the update.  It looks good.  For the series:

Acked-by: Toshi Kani 


Thanks!



-Toshi



---

v3 : Continue to memory hot remove when (!info->enabled) case.
v2 : Changed a based kernel from linux-3.9-rc2 to linux-pm.git/bleeding-edge.

---
   drivers/acpi/acpi_memhotplug.c |   15 ++-
   1 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index ea78988..5e6301e 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -73,7 +73,6 @@ struct acpi_memory_info {
unsigned short caching; /* memory cache attribute */
unsigned short write_protect;   /* memory read/write attribute */
unsigned int enabled:1;
-   unsigned int failed:1;
   };

   struct acpi_memory_device {
@@ -201,10 +200,8 @@ static int acpi_memory_enable_device(struct 
acpi_memory_device *mem_device)
 * returns -EEXIST. If add_memory() returns the other error, it
 * means that this memory block is not used by the kernel.
 */
-   if (result && result != -EEXIST) {
-   info->failed = 1;
+   if (result && result != -EEXIST)
continue;
-   }

info->enabled = 1;

@@ -238,16 +235,8 @@ static int acpi_memory_remove_memory(struct 
acpi_memory_device *mem_device)
nid = acpi_get_node(mem_device->device->handle);

list_for_each_entry_safe(info, n, _device->res_list, list) {
-   if (info->failed)
-   /* The kernel does not use this memory block */
-   continue;
-
if (!info->enabled)
-   /*
-* The kernel uses this memory block, but it may be not
-* managed by us.
-*/
-   return -EBUSY;
+   continue;

if (nid < 0)
nid = memory_add_physaddr_to_nid(info->start_addr);







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

[PATCH v2] dm cache: fix writes to cache device in writethrough mode

[Mike Snitzer]

From: Darrick J. Wong 

The dm-cache writethrough strategy introduced by commit e2e74d617eadc15
("dm cache: fix race in writethrough implementation") issues a bio to
the origin device, remaps and then issues the bio to the cache device.
This more conservative in-series approach was selected to favor
correctness over performance (of the previous parallel writethrough).
However, this in-series implementation that reuses the same bio to write
both the origin and cache device didn't take into account that the block
layer's req_bio_endio() modifies a completing bio's bi_sector and
bi_size.  So the new writethrough strategy needs to preserve these bio
fields, and restore them before submission to the cache device,
otherwise nothing gets written to the cache (because bi_size is 0).

This patch adds a struct dm_bio_details field to struct per_bio_data,
and uses dm_bio_record() and dm_bio_restore() to ensure the bio is
restored before reissuing to the cache device.  Adding such a large
structure to the per_bio_data is not ideal but we can improve this
later, for now correctness is the important thing.

This problem initially went unnoticed because the dm-cache test-suite
uses a linear DM device for the dm-cache device's origin device.
Writethrough worked as expected because DM submits a *clone* of the
original bio, so the original bio which was reused for the cache was
never touched.

Signed-off-by: Darrick J. Wong 
Signed-off-by: Joe Thornber 
Signed-off-by: Mike Snitzer 
---
 drivers/md/dm-cache-target.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

v2: revised patch header on Darrick and Joe's behalf

diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index cf24a46..873f495 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -6,6 +6,7 @@
 
 #include "dm.h"
 #include "dm-bio-prison.h"
+#include "dm-bio-record.h"
 #include "dm-cache-metadata.h"
 
 #include 
@@ -205,6 +206,7 @@ struct per_bio_data {
struct cache *cache;
dm_cblock_t cblock;
bio_end_io_t *saved_bi_end_io;
+   struct dm_bio_details bio_details;
 };
 
 struct dm_cache_migration {
@@ -642,6 +644,7 @@ static void writethrough_endio(struct bio *bio, int err)
return;
}
 
+   dm_bio_restore(>bio_details, bio);
remap_to_cache(pb->cache, bio, pb->cblock);
 
/*
@@ -665,6 +668,7 @@ static void remap_to_origin_then_cache(struct cache *cache, 
struct bio *bio,
pb->cache = cache;
pb->cblock = cblock;
pb->saved_bi_end_io = bio->bi_end_io;
+   dm_bio_record(>bio_details, bio);
bio->bi_end_io = writethrough_endio;
 
remap_to_origin_clear_discard(pb->cache, bio, oblock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vfs: dcache: cond_resched in shrink_dentry_list

[Dave Chinner]

On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
> Call cond_resched() from shrink_dentry_list() to preserve
> shrink_dcache_parent() interactivity.
> 
> void shrink_dcache_parent(struct dentry * parent)
> {
>   while ((found = select_parent(parent, )) != 0)
>   shrink_dentry_list();
> }
> 
> select_parent() populates the dispose list with dentries which
> shrink_dentry_list() then deletes.  select_parent() carefully uses
> need_resched() to avoid doing too much work at once.  But neither
> shrink_dcache_parent() nor its called functions call cond_resched().
> So once need_resched() is set select_parent() will return single
> dentry dispose list which is then deleted by shrink_dentry_list().
> This is inefficient when there are a lot of dentry to process.  This
> can cause softlockup and hurts interactivity on non preemptable
> kernels.

Hi Greg,

I can see how this coul dcause problems, but isn't the problem then
that shrink_dcache_parent()/select_parent() itself is mishandling
the need for rescheduling rather than being a problem with
the shrink_dentry_list() implementation?  i.e. select_parent() is
aborting batching based on a need for rescheduling, but then not
doing that itself and assuming that someone else will do the
reschedule for it?

Perhaps this is a better approach:

-   while ((found = select_parent(parent, )) != 0)
+   while ((found = select_parent(parent, )) != 0) {
shrink_dentry_list();
+   cond_resched();
+   }

With this, select_parent() stops batching when a resched is needed,
we dispose of the list as a single batch and only then resched if it
was needed before we go and grab the next batch. That should fix the
"small batch" problem without the potential for changing the
shrink_dentry_list() behaviour adversely for other users

Cheers,

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

Re: Regression: Screen turns off when booting in EFI mode

[Matthew Garrett]

On Tue, Mar 26, 2013 at 09:52:14AM +1000, Dave Airlie wrote:
> >>> Because it's the only way to get the PCI ROM in some cases, like on
> >>> pretty much all Apples with Radeons. Only using it if we have no other
> >>> options probably makes sense, though. Something like this (entirely
> >>> untested)?
> >>
> >> This looks reasonable. Mantas?
> >
> > It compiles, boots, and even makes the graphics card work again.
> > So it looks good to me.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=927451
> 
> popped up sounds like a regression caused by this.

Sigh. I guess we need to figure out where it thinks it's getting that 
image from. The alternative is basically to go back to what Linus 
suggested, remove this from pci_map_rom() and add an explicit lookup to 
the video drivers.

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

Re: Regression: Screen turns off when booting in EFI mode

[Dave Airlie]

>>> Because it's the only way to get the PCI ROM in some cases, like on
>>> pretty much all Apples with Radeons. Only using it if we have no other
>>> options probably makes sense, though. Something like this (entirely
>>> untested)?
>>
>> This looks reasonable. Mantas?
>
> It compiles, boots, and even makes the graphics card work again.
> So it looks good to me.

https://bugzilla.redhat.com/show_bug.cgi?id=927451

popped up sounds like a regression caused by this.

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

Re: [PATCH V3] clk: Add composite clock type

[Mike Turquette]

Quoting Prashant Gaikwad (2013-03-20 05:00:34)
> Not all clocks are required to be decomposed into basic clock
> types but at the same time want to use the functionality
> provided by these basic clock types instead of duplicating.
> 
> For example, Tegra SoC has ~100 clocks which can be decomposed
> into Mux -> Div -> Gate clock types making the clock count to
> ~300. Also, parent change operation can not be performed on gate
> clock which forces to use mux clock in driver if want to change
> the parent.
> 
> Instead aggregate the basic clock types functionality into one
> clock and just use this clock for all operations. This clock
> type re-uses the functionality of basic clock types and not
> limited to basic clock types but any hardware-specific
> implementation.
> 
> Signed-off-by: Prashant Gaikwad 

This version looks cleaner.  Thanks for the respin.  Taken into
clk-next.

Regards,
Mike

> ---
> 
> Changes from V2:
> - Move clk_ops inside clk_composite instead of dynamically allocation.
> 
> ---
>  drivers/clk/Makefile |1 +
>  drivers/clk/clk-composite.c  |  201 
> ++
>  include/linux/clk-provider.h |   31 +++
>  3 files changed, 233 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/clk/clk-composite.c
> 
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 0147022..097ed01 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-fixed-factor.o
>  obj-$(CONFIG_COMMON_CLK)   += clk-fixed-rate.o
>  obj-$(CONFIG_COMMON_CLK)   += clk-gate.o
>  obj-$(CONFIG_COMMON_CLK)   += clk-mux.o
> +obj-$(CONFIG_COMMON_CLK)   += clk-composite.o
>  
>  # SoCs specific
>  obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> new file mode 100644
> index 000..097dee4
> --- /dev/null
> +++ b/drivers/clk/clk-composite.c
> @@ -0,0 +1,201 @@
> +/*
> + * Copyright (c) 2013 NVIDIA CORPORATION.  All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define to_clk_composite(_hw) container_of(_hw, struct clk_composite, hw)
> +
> +static u8 clk_composite_get_parent(struct clk_hw *hw)
> +{
> +   struct clk_composite *composite = to_clk_composite(hw);
> +   const struct clk_ops *mux_ops = composite->mux_ops;
> +   struct clk_hw *mux_hw = composite->mux_hw;
> +
> +   mux_hw->clk = hw->clk;
> +
> +   return mux_ops->get_parent(mux_hw);
> +}
> +
> +static int clk_composite_set_parent(struct clk_hw *hw, u8 index)
> +{
> +   struct clk_composite *composite = to_clk_composite(hw);
> +   const struct clk_ops *mux_ops = composite->mux_ops;
> +   struct clk_hw *mux_hw = composite->mux_hw;
> +
> +   mux_hw->clk = hw->clk;
> +
> +   return mux_ops->set_parent(mux_hw, index);
> +}
> +
> +static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
> +   unsigned long parent_rate)
> +{
> +   struct clk_composite *composite = to_clk_composite(hw);
> +   const struct clk_ops *div_ops = composite->div_ops;
> +   struct clk_hw *div_hw = composite->div_hw;
> +
> +   div_hw->clk = hw->clk;
> +
> +   return div_ops->recalc_rate(div_hw, parent_rate);
> +}
> +
> +static long clk_composite_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate)
> +{
> +   struct clk_composite *composite = to_clk_composite(hw);
> +   const struct clk_ops *div_ops = composite->div_ops;
> +   struct clk_hw *div_hw = composite->div_hw;
> +
> +   div_hw->clk = hw->clk;
> +
> +   return div_ops->round_rate(div_hw, rate, prate);
> +}
> +
> +static int clk_composite_set_rate(struct clk_hw *hw, unsigned long rate,
> +  unsigned long parent_rate)
> +{
> +   struct clk_composite *composite = to_clk_composite(hw);
> +   const struct clk_ops *div_ops = composite->div_ops;
> +   struct clk_hw *div_hw = composite->div_hw;
> +
> +   div_hw->clk = hw->clk;
> +
> +   return div_ops->set_rate(div_hw, rate, parent_rate);
> +}
> +
> +static int clk_composite_is_enabled(struct clk_hw *hw)
> +{
> +   struct clk_composite *composite = to_clk_composite(hw);
> +   const struct 

Re: [PATCH v3 3/3] backlight: as3711: add OF support

[Jingoo Han]

On Monday, March 25, 2013 7:15 PM, Mark Brown wrote:
> 
> On Mon, Mar 25, 2013 at 02:12:21PM +0900, Jingoo Han wrote:
> > On Saturday, March 23, 2013 1:16 AM, Guennadi Liakhovetski wrote:
> 
> > But, there is a typo in comment.
> > > +  * At least one su2-auto-curr* must be specified iff
> > s/iff/if
> 
> Are you sure that's a typo?  "Iff" is a bit of mathematical jargon
> which means "if and only if" that's fairly often used in a computing
> context.

Oh, it's my mistake.

'xor' is used; thus, it is not a typo.
 Thank you for your comment.

Best regards,
Jingoo Han

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

Re: RFC v2: Zynq Clock Controller

[Stephen Warren]

On 03/25/2013 12:27 PM, Sören Brinkmann wrote:
> Hi Stephen,
> 
> On Mon, Mar 25, 2013 at 12:13:08PM -0600, Stephen Warren wrote:
>> On 03/20/2013 05:56 PM, Sören Brinkmann wrote:
>>> Hi,
>>>
>>> I spent some time working on this and incorporating feedback. Here's an 
>>> updated proposal for a clock controller for Zynq:
>>>
>>> Required properties:
>>>  - #clock-cells : Must be 1
>>>  - compatible : "xlnx,ps7-clkc"  (this may become 'xlnx,zynq-clkc' 
>>> terminology differs a bit between Xilinx internal and mainline)
>>>  - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ
>>>  (usually 33 MHz oscillators are used for Zynq 
>>> platforms)
>>
>> This may have been mentioned before, but shouldn't the input clock be
>> represented as an actual clock in DT, and hence as an entry in this
>> node's clocks property? The crystal/... itself can be represented in DT
>> as a fixed-clock.
> Lars-Peter brought that up, too. Please refer to my answer to him.
> 
>>
>>>  - clock-output-names : List of strings used to name the clock outputs. 
>>> Shall be a list of the outputs given below.
>>
>> That shouldn't be required.
>
> When I want to support of_clk_get_parent_name() for my clocks, I think
> it is. And I'm inclined to not brake this functionality.

The solution here is to make clock parent names irrelevant.

Also note that device tree is supposed to describe HW. As such, this
kind of internal implementation detail of the Linux clock driver should
have basically zero effect on the DT binding definition.

>>> Optional properties:
>>>  - clocks : as described in the clock bindings
>>>  - clock-names : as described in the clock bindings
>>
>> I think clocks should be required, with at least the main crystal clock
>> input always present, but perhaps having some optional entries for the
>> (E)MIO feature you mention.
>
> This is why I have the xtal separate. This way these props are purely
> optional and the xtal frequency is obtained separately. It also makes it
> a little easier internally, because I don't have to cope with a variable
> name for the xtal this way.
> 
> Describing the xtal as fixed clock in DT means a mandatory entry for
> 'clocks' and 'clock-names' and a variable name for the xtal clock. I
> wanted to avoid this.

I don't see any benefit with some properties being purely optional.
Having optional entries in a property seems just fine to me.

The name of the crystal clock should be irrelevant; that issue simply
needs to be fixed. It's driving too much of this discussion, and it will
be irrelevant once it's fixed.

>>> Example:
>>> clkc: clkc {
>>> #clock-cells = <1>;
>>> compatible = "xlnx,ps7-clkc";
>>> ps-clk-frequency = <>;
>>> clock-output-names = "armpll", "ddrpll", "iopll", 
>>> "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x", "dci", 
>>> "lqspi", "smc", "pcap", "gem0", "gem1", "fclk0", "fclk1", "fclk2", "fclk3", 
>>> "can0", "can1", "sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1", "dma", 
>>> "usb0_aper", "usb1_aper", "gem0_aper", "gem1_aper", "sdio0_aper", 
>>> "sdio1_aper", "spi0_aper", "spi1_aper", "can0_aper", "can1_aper", 
>>> "i2c0_aper", "i2c1_aper", "uart0_aper", "uart1_aper", "gpio_aper", 
>>> "lqspi_aper", "smc_aper", "swdt", "dbg_trc", "dbg_apb";  /* long list... 
>>> explanation below */
>>> /* optional props */
>>> clocks = < 16>, <_foo>;
>>> clock-names = "gem1_emio_clk", "can_mio_clk_23";
>>> };
>>>
>>> The downside of supporting this is, that I don't see a way around 
>>> explicitly listing the clock output names in the DT.
>>
>> (Please wrap your emails to ~74 characters or so)
> I changed my settings.
> 
>>
>> As Mike mentioned off-list, one can create a new clk registration API
>> that takes a struct clk* as parent rather than a char *clk_name.
>
> Then we also have to make sure clocks are probed in a specific order. To
> obtain a 'struct clk *' through clk_get() the requested clock has to be
> already been probed. Currently clock probing relies purely on data present
> in DT. This makes this proposal not that trivial, IMHO.

Simply use deferred probe.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] include/linux/platform_data: beautify code, 'inline' is better in front of 'void'

[Greg KH]

On Mon, Mar 25, 2013 at 10:36:22AM +0800, Chen Gang wrote:
> 
>   better to let 'inline' in front of 'void'

Why?  What does this fix?

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

[Paul Bolle]

Commit 90173882ed15a8034d6d162da5f343a2c7d87587 ("omap: add dsp platform
device") used CONFIG_BRIDGE_DVFS were it obviously meant
CONFIG_TIDSPBRIDGE_DVFS. Fix that.

Signed-off-by: Paul Bolle 
---
Untested. As this typo has been in the tree since v2.6.37, this really
needs some testing.

 arch/arm/mach-omap2/dsp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
index b155500..b8208b4 100644
--- a/arch/arm/mach-omap2/dsp.c
+++ b/arch/arm/mach-omap2/dsp.c
@@ -26,7 +26,7 @@
 #include "control.h"
 #include "cm2xxx_3xxx.h"
 #include "prm2xxx_3xxx.h"
-#ifdef CONFIG_BRIDGE_DVFS
+#ifdef CONFIG_TIDSPBRIDGE_DVFS
 #include "omap-pm.h"
 #endif
 
@@ -35,7 +35,7 @@
 static struct platform_device *omap_dsp_pdev;
 
 static struct omap_dsp_platform_data omap_dsp_pdata __initdata = {
-#ifdef CONFIG_BRIDGE_DVFS
+#ifdef CONFIG_TIDSPBRIDGE_DVFS
.dsp_set_min_opp = omap_pm_dsp_set_min_opp,
.dsp_get_opp = omap_pm_dsp_get_opp,
.cpu_set_freq = omap_pm_cpu_set_freq,
-- 
1.7.11.7

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

Re: RFC v2: Zynq Clock Controller

[Stephen Warren]

On 03/22/2013 04:41 PM, Sören Brinkmann wrote:
> Hi Lars,
> 
> On Thu, Mar 21, 2013 at 07:32:52PM +0100, Lars-Peter Clausen wrote:
>> On 03/21/2013 12:56 AM, Sören Brinkmann wrote:
>>> Hi,
>>>
>>> I spent some time working on this and incorporating feedback. Here's an 
>>> updated proposal for a clock controller for Zynq:
>>>
>>> Required properties:
>>>  - #clock-cells : Must be 1
>>>  - compatible : "xlnx,ps7-clkc"  (this may become 'xlnx,zynq-clkc' 
>>> terminology differs a bit between Xilinx internal and mainline)
>>>  - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ
>>>  (usually 33 MHz oscillators are used for Zynq 
>>> platforms)
>>>  - clock-output-names : List of strings used to name the clock outputs. 
>>> Shall be a list of the outputs given below.
>>>
>>> Optional properties:
>>>  - clocks : as described in the clock bindings
>>>  - clock-names : as described in the clock bindings
>>>
>>> Clock inputs:
>>> The following strings are optional parameters to the 'clock-names' property 
>>> in
>>> order to provide optional (E)MIO clock sources.
>>>  - swdt_ext_clk
>>>  - gem0_emio_clk
>>>  - gem1_emio_clk
>>>  - mio_clk_XX  # with XX = 00..53
>>>
>>> Example:
>>> clkc: clkc {
>>> #clock-cells = <1>;
>>> compatible = "xlnx,ps7-clkc";
>>> ps-clk-frequency = <>;
>>
>> The input frequency should be a clock as well.
>
> Again, monolithic vs split. I don't see a reason not to just internally
> call clk_register_fixed_rate(). That way its children do not have to
> cope with a variable name for the xtal.
> Also, with my proposal 'clocks' and 'clock-names' would be purely
> optional properties, only required if optional external inputs are
> present. Having the xtal defined externally would add mandatory entries for
> those props.

But isn't the clock source board-specific? It's a completely separate
object from Zynq's own clock controller HW, and as such should be
represented by a separate DT node, right?

The issue with parent clock names is simply a red herring. A solution is
needed to registered clock with a parent clock object, rather than a
parent clock name. Then, the parent names are completely irrelevant.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: failed to fetch the osd tree

[Stephen Rothwell]

Hi Boaz,

Fetching the osd tree
(git://git.open-osd.org/linux-open-osd.git#linux-next) produces a time
out and this error:

fatal: read error: Connection reset by peer

I will continue to use the last osd tree I fetched.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpJqiGi92Otd.pgp
Description: PGP signature

Re: BUG: soft lockup when recording audio on MX28EVK with ASoC sgtl5000

[Fabio Estevam]

Hector,

On Mon, Mar 25, 2013 at 4:31 PM, Fabio Estevam  wrote:
> Hi Hector,
>
> On Mon, Mar 25, 2013 at 7:52 AM, Hector Palacios
>  wrote:
>> Hello,
>>
>> I just tried recording audio on Freescale's MX28EVK that uses ASoC sgtl5000
>> (kernel v3.8) with:
>>
>> arecord -M -f cd sound.wav --duration 10
>>
>> and got a scheduler message:
>>
>> [  789.041847] [sched_delayed] sched: RT throttling activated
>
> I have just tested arecord on 3.8,4 and I haven't seen the 'soft lockup' bug.
>
> However, I see that mxs saif gets busy after the record and any
> attempt to do an 'aplay' after the first arecord fails.
>
> With the attached patch applied I am able to do arecord/aplay sequence
> several times.
>
> I don't have a cable handy here to actually test if the sound is
> recorded properly or not.
>
> Could you please test it against 3.8.4?

I managed to test arecord and it works with the following as follows:

1. Run alsamixer and select LINE_IN in the Capture element

2. Record with the following command line:

arecord -D hw:0,1 -d 10 -f S16_LE -r 44100 -c  test.wav

3. Then listen test.wav on your PC or in your board itself.

The sequence above works fine.

Anyway, I will submit the patch I sent earlier as it prevents the
system to get unresponsive.

Regards,

Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/3] backlight: as3711: add OF support

[Ryan Mallon]

On 26/03/13 09:40, Andrew Morton wrote:
> On Fri, 22 Mar 2013 17:15:49 +0100 Guennadi Liakhovetski 
>  wrote:
> 
>> Add support for configuring AS3711 backlight driver from DT.
>>
>> Signed-off-by: Guennadi Liakhovetski 
>> Reviwed-by: Mark Brown 
>> ---
>>  drivers/video/backlight/as3711_bl.c |  118 
>> ++-
>>  1 files changed, 117 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/video/backlight/as3711_bl.c 
>> b/drivers/video/backlight/as3711_bl.c
>> index 41d52fe..123887c 100644
>> --- a/drivers/video/backlight/as3711_bl.c
>> +++ b/drivers/video/backlight/as3711_bl.c
>> @@ -258,6 +258,109 @@ static int as3711_bl_register(struct platform_device 
>> *pdev,
>>  return 0;
>>  }
>>  
>> +static int as3711_backlight_parse_dt(struct device *dev)
>> +{
>> +struct as3711_bl_pdata *pdata = dev_get_platdata(dev);
>> +struct device_node *bl =
>> +of_find_node_by_name(dev->parent->of_node, "backlight"), *fb;
>> +int ret;
> 
> It's tidier to do
> 
>   struct device_node *bl;
>   
>   bl = of_find_node_by_name(dev->parent->of_node, "backlight"), *fb;
> 
> and avoid the 80-col trickery.

The other reason being that it now becomes much more apparent that *fb
is not an argument to of_find_node_by_name(), but a second variable of
type struct device_node :-).

~Ryan

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

Re: [Update 4][PATCH 2/7] ACPI / scan: Introduce common code for ACPI-based device hotplug

[Toshi Kani]

On Mon, 2013-03-25 at 23:29 +0100, Rafael J. Wysocki wrote:
> On Monday, March 25, 2013 02:45:36 PM Toshi Kani wrote:
> > On Fri, 2013-03-15 at 11:47 +0100, Vasilis Liaskovitis wrote:
> > > Hi,
> > > 
> > > On Thu, Mar 14, 2013 at 06:16:30PM +0100, Rafael J. Wysocki wrote:
> > > > Sorry for the sluggish response, I've been travelling recently. ->
> > > [...]
> > > > > > > So, I'd suggest the following changes.
> > > > > > >  - Remove the "uevents" attribute.  KOBJ_ONLINE/OFFLINE are not 
> > > > > > > used for
> > > > > > > ACPI device objects.
> > > > > > >  - Make the !autoeject case as an exception for now, and emit
> > > > > > > KOBJ_OFFLINE as a way to request off-lining to user.  This uevent 
> > > > > > > is
> > > > > > > tied with the !autoeject case.  We can then revisit if this 
> > > > > > > use-case
> > > > > > > needs to be supported going forward.  If so, we may want to 
> > > > > > > consider a
> > > > > > > different event type.
> > > > > > 
> > > > > > Well, what about avoiding to expose uevents and autoeject for now 
> > > > > > and
> > > > > > exposing enabled only?  Drivers would still be able to set the 
> > > > > > other flags on
> > > > > > init on init to enforce the backwards-compatible behavior.
> > > > > 
> > > > > Now that we don't define uevents and autoeject in v2 of this series, 
> > > > > could you
> > > > > explain how we get safe ejection from userspace e.g. for memory 
> > > > > hot-remove? What
> > > > > are the other flags drivers can use (on init?) to avoid autoeject and 
> > > > > only issue
> > > > > KOBJ_OFFLINE?
> > > > > 
> > > > > > 
> > > > > > I agree that it would be sufficient to use one additional flag 
> > > > > > then, to start
> > > > > > with, but its meaning would be something like "keep backwards 
> > > > > > compatibility
> > > > > > with the old container driver", so perhaps "autoeject" is not a 
> > > > > > good name.
> > > > > > 
> > > > > > What about "user_eject" (that won't be exposed to user space) 
> > > > > > instead?  Where,
> > > > > > if set, it would meand "do not autoeject and emit 
> > > > > > KOBJ_OFFLINE/ONLINE uevents
> > > > > > like the old container driver did"?
> > > > > 
> > > > > I don't see user_eject in v2. Is it unnecessary for userspace 
> > > > > ejection control
> > > > > or planned for later? Also why shouldn't it be exposed to userpace?
> > > > 
> > > > -> At this point we are not sure if it is necessary to have an 
> > > > attribute for
> > > > direct ejection control.  Since the plan is to have a separate 
> > > > offline/online
> > > > attribute anyway (and a check preventing us from ejecting things that 
> > > > haven't
> > > > been put offline), it is not clear how useful it is going to be to 
> > > > control
> > > > ejection directly from user space.
> > > 
> > > ok.
> > > Regarding the offline/online attribute and ejection prevention checking, 
> > > do you
> > > mean the offline/online framework from Toshi:
> > > http://thread.gmane.org/gmane.linux.kernel/1420262
> > > or something else? I assume this is the long-term plan.
> > 
> > Unfortunately, the idea of adding a new set of common hotplug framework
> > was not well-received.  Since the driver-core does not allow any eject
> > failure case, integrating into the driver-core framework seems also
> > impractical.
> > 
> > > Is there any other short-term solution planned? If i understand 
> > > correctly, until
> > > this framework is accepted, memory hot-remove is broken (=unsafe). 
> > 
> > That is correct.  The alternative plan is to go with an ACPI-specific
> > approach that user has to off-line a target device and its children
> > beforehand from sysfs before initiating a hot-delete request.  This
> > hot-delete request will fail if any of the devices are still on-line.
> > The sysfs online/offline interfaces may fail, and user (or user tool)
> > has to take care of the rollback as necessary.  It would move all the
> > error handling & rollback stuff into the user space, and make the kernel
> > part very simple & straightforward -- just delete target device
> > objects.  
> > 
> > After looking further, however, I think this isn't the case...  In case
> > of memory hot-delete, for example, off-lining is only a part of the job
> > done in remove_memory().  So, ACPI-core still needs to call
> > device-specific handlers to perform device-specific hot-delete
> > operations, such as calling remove_memory() or its sub-set function,
> > which can fail when a device is online.  In order to make sure all
> > devices stay off-line, we need to delete their sysfs interfaces.
> 
> No, we don't need to.
> 
> > Since we do not have a way to serialize all online/offline & hot-plug
> > operations (the above patchset had such serialization, but did not get
> > thru), we cannot change all devices at once but delete sysfs interface
> > for each device one by one.  If it failed on one of the devices, we need
> > to rollback to put them back into the original state.  Other 

Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init

[Catalin Marinas]

On Mon, Mar 25, 2013 at 09:28:10PM +, Rob Herring wrote:
> On 03/25/2013 12:26 PM, Russell King - ARM Linux wrote:
> > On Thu, Mar 21, 2013 at 11:06:47AM +, Mark Rutland wrote:
> >> On TC2 this series leads to using the vexpress 24MHz clock as the sched 
> >> clock
> >> in preference to the architected timer:
> >>
> >>   Architected local timer running at 24.00MHz (virt).
> >>   Switching to timer-based delay loop
> >>   Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source
> >>   sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
> >>   Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source
> >>
> >> As they both have the same frequency, neither overrides the other, and
> >> whichever gets registered last is used as the sched_clock. As accesses
> >> to the architected timer are going to have a much lower overhead, this
> >> isn't very nice (and it could be better to use it even if it had a lower
> >> frequency).
> > 
> > I'll remind people that sched_clock() is supposed to be functional at
> > the point in the boot sequence where the call to sched_init() is called.
> > That is after setup_arch() and *before* time_init() is called.
> 
> I count integrator-cp, realview, versatile and non-DT VExpress that do
> this (not surprisingly) and 25 platforms or timer implementations plus
> arm64 that do sched_clock setup in time_init.

Before time_init(), sched_clock() currently returns 0 with the
architected timers (though I don't particularly like this for arm64).
Marc Rutland has patches to make arch_timer_read_counter() a function
which always returns the virtual counter. It requires the CNTVOFF
register to be set to 0 on AArch32 during boot. But this way
sched_clock() on arm64 would always return meaningful values as we have
the architected timers.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ADP1653 board code for Nokia RX-51

[Laurent Pinchart]

Hi Sakari,

On Sunday 24 March 2013 23:46:01 Sakari Ailus wrote:
> Pali Rohár wrote:
> > On Thursday 07 March 2013 23:18:27 Sakari Ailus wrote:
> >> On Wed, Mar 06, 2013 at 10:44:41PM +0100, Sebastian Reichel wrote:
> >>> On Wed, Mar 06, 2013 at 09:20:16PM +0100, Pali Rohár wrote:
>  On Wednesday 06 March 2013 21:12:06 Pali Rohár wrote:
> > On Sunday 17 February 2013 20:03:03 Aaro Koskinen wrote:
> >> On Sun, Feb 17, 2013 at 04:16:49PM +0100, Pali Rohár wrote:
> >>> +/*
> >>> + * arch/arm/mach-omap2/board-rx51-camera.c
> >>> + *
> >>> + * Copyright (C) 2008 Nokia Corporation
> >>> + *
> >>> + * Contact: Sakari Ailus 
> >>> + *  Tuukka Toivonen 
> >> 
> >> You should put these people to CC... Just to see if the addresses are
> >> still valid (which I doubt).
> > 
> > Ok, trying :-)
>  
>  I got "Delivery Status Notification (Failure)" for both addresses.
> >> 
> >> This is expected.
> >> 
> >>> Sakari Ailus hosts some code on github [0], which has the following
> >>> email address:
> >>> sakari.ailus+gitori...@retiisi.org.uk
> >>> 
> >>> I added it to this mail's CC.
> >>> 
> >>> [0] https://gitorious.org/~sailus
> >> 
> >> Nice to hear people are interested in this. ;-)
> >> 
> >> The primary reason I haven't tried submitting this to mainline is that
> >> ARM board code has a bad reputation these days. The N900 does not have
> >> yet support for device tree (AFAIK), which also would require a few bits
> >> and pieces on the flash driver to work.
> >> 
> >> Also the sensor and lens drivers would need at least some work before
> >> being ready for submission to mainline for camera to be usable.
> >> Unfortunately I haven't had recently time to work on this. N9(50) support
> >> has higher priority for myself. That, too, is pending the DT support for
> >> the device.
> >> 
> >> There's indeed more up-to-date code in my repository. Even if it's not
> >> too close to mainline anymore it should be a better starting point than
> >> the old kernel from MeeGo.
> >> 
> >> https://gitorious.org/omap3camera/pages/Home>
> > 
> > Hi,
> > 
> > this board code is same in your git repository and on meego obs.
> > 
> > Patch only adding support for adp1653 driver which is already in upstream
> > kernel.
> > 
> > Are there any other problems with this patch to go for upstream?
> 
> A few more things comes to mind. We depend a little bit on actual board
> code; it's not only static data. That's the configuration of the external
> clock from the ISP to the sensor. That should move to the common clock
> framework so that the ISP registers the clock and the sensor driver can then
> use it. AFAIR Laurent has done some work on that.

Yes. I hope to get the patches in v3.10.

> The peculiar detail of the rx51 is that there's a switch on the camera CCP2
> bus that selects either sensor (primary or secondary). Both sensors are
> connected to the same receiver. That isn't properly modelled currently at
> all, so that's why we have rx51_camera_set_xshutdown(). I guess it'd still
> work if you only power (i.e. open) either of the devices at a time, though.

Have you thought about how we could model that ?

> That should be all.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] spi: spi-omap2-mcspi.c: Add dts for slave device configuration.

[Matthias Brugger]

TI omap2 mcspi allows the slave devices to configure the behavior of
the SPI master. This patch adds device tree support to the existing
options.

Signed-off-by: Matthias Brugger 
---
 Documentation/devicetree/bindings/spi/omap-spi.txt | 23 
 drivers/spi/spi-omap2-mcspi.c  | 41 ++
 2 files changed, 64 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt 
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..fef16bf 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,8 +10,20 @@ Required properties:
  input. The default is D0 as input and
  D1 as output.
 
+SPI Controller specific data in SPI slave nodes:
+
+- The spi slave nodes can provide the following information which is used
+  by the spi controller.
+
+- ti,spi-cs-per-word: Set chipselect to be toggled on every word send.
+
+- ti,spi-turbo-mode: Set turbo mode for this device.
+
+
 Example:
 
+- SoC Specific Portion:
+
 mcspi1: mcspi@1 {
 #address-cells = <1>;
 #size-cells = <0>;
@@ -20,3 +32,14 @@ mcspi1: mcspi@1 {
 ti,spi-num-cs = <4>;
 };
 
+- Board Specific Portion:
+
+   spi-device@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   controller-data {
+   ti,spi-cs-per-word = <1>;
+   ti,spi-turbo-mode = <0>;
+   };
+   };
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 893c3d7..1ae5009 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -731,11 +731,47 @@ static u32 omap2_mcspi_calc_divisor(u32 speed_hz)
return 15;
 }
 
+static struct omap2_mcspi_device_config *omap2_mcspi_get_slave_ctrldata(
+   struct spi_device *spi)
+{
+   struct omap2_mcspi_device_config *cd;
+   struct device_node *slave_np, *data_np = NULL;
+
+   slave_np = spi->dev.of_node;
+   if (!slave_np) {
+   dev_err(>dev, "device node not found\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   data_np = of_get_child_by_name(slave_np, "controller-data");
+   if (!data_np) {
+   dev_err(>dev, "child node 'controller-data' not found\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   cd = kzalloc(sizeof(*cd), GFP_KERNEL);
+   if (!cd) {
+   dev_err(>dev, "could not allocate memory for controller 
data\n");
+   of_node_put(data_np);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   if (of_get_property(data_np, "ti,spi-cs-per-word", NULL))
+   cd->cs_per_word = 1;
+
+   if (of_get_property(data_np, "ti,spi-turbo-mode", NULL))
+   cd->turbo_mode = 1;
+
+   of_node_put(data_np);
+   return cd;
+}
+
 /* called only when no transfer is active to this device */
 static int omap2_mcspi_setup_transfer(struct spi_device *spi,
struct spi_transfer *t)
 {
struct omap2_mcspi_cs *cs = spi->controller_state;
+   struct omap2_mcspi_device_config *cd = spi->controller_data;
struct omap2_mcspi *mcspi;
struct spi_master *spi_cntrl;
u32 l = 0, div = 0;
@@ -745,6 +781,11 @@ static int omap2_mcspi_setup_transfer(struct spi_device 
*spi,
mcspi = spi_master_get_devdata(spi->master);
spi_cntrl = mcspi->master;
 
+   if (!cd && spi->dev.of_node) {
+   cd = omap2_mcspi_get_slave_ctrldata(spi);
+   spi->controller_data = cd;
+   }
+
if (t != NULL && t->bits_per_word)
word_len = t->bits_per_word;
 
-- 
1.7.11.7

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

Re: [PATCH -next] rpmsg: fix error return code in rpmsg_probe()

[Rusty Russell]

Wei Yongjun  writes:
> From: Wei Yongjun 
>
> Fix to return a negative error code from the error handling
> case instead of 0, as returned elsewhere in this function.
>
> Signed-off-by: Wei Yongjun 

Thanks, I've taken this for the moment in my pending queue.

Which brings the questionL Ohad, did you want to keep pushing your own
tree or want to send rpmsg stuff via my virtio-next tree?

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