Re: [PATCH] arm:extend the reserved mrmory for initrd to be page aligned

2014-09-17 Thread Uwe Kleine-König
Hello,

just some commit log nit picking:

$Subject ~= s/mrmory/memory/

And also "ARM: " is the more typical prefix. Don't know if there is a
best practice for patches touching both arm and arm64. (But assuming
this will go through Russell's patch tracker this doesn't matter much.)

On Thu, Sep 18, 2014 at 09:58:10AM +0800, Wang, Yalin wrote:
> this patch extend the start and end address of initrd to be page aligned,
This patch extends ...

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/3] f2fs: update i_size when __allocate_data_block

2014-09-17 Thread Jaegeuk Kim
The f2fs_direct_IO uses __allocate_data_block, but inside the allocation path,
we should update i_size at the changed time to update its inode page.
Otherwise, we can get wrong i_size after roll-forward recovery.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7749f30..aaf22a9 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -572,9 +572,11 @@ put_err:
 static int __allocate_data_block(struct dnode_of_data *dn)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(dn->inode);
+   struct f2fs_inode_info *fi = F2FS_I(dn->inode);
struct f2fs_summary sum;
block_t new_blkaddr;
struct node_info ni;
+   pgoff_t fofs;
int type;
 
if (unlikely(is_inode_flag_set(F2FS_I(dn->inode), FI_NO_ALLOC)))
@@ -597,6 +599,12 @@ static int __allocate_data_block(struct dnode_of_data *dn)
update_extent_cache(new_blkaddr, dn);
clear_inode_flag(F2FS_I(dn->inode), FI_NO_EXTENT);
 
+   /* update i_size */
+   fofs = start_bidx_of_node(ofs_of_node(dn->node_page), fi) +
+   dn->ofs_in_node;
+   if (i_size_read(dn->inode) < ((fofs + 1) << PAGE_CACHE_SHIFT))
+   i_size_write(dn->inode, ((fofs + 1) << PAGE_CACHE_SHIFT));
+
dn->data_blkaddr = new_blkaddr;
return 0;
 }
-- 
1.8.5.2 (Apple Git-48)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] f2fs: use more free segments until SSR is activated

2014-09-17 Thread Jaegeuk Kim
Previously, f2fs activates SSR if the # of free segments reaches to the # of
overprovisioned segments.
In this case, SSR starts to use dirty segments only, so that the overprovisoned
space cannot be selected for new data.
This means that we have no chance to utilizae the overprovisioned space at all.

This patch fixes that by allowing LFS allocations until the # of free segments
reaches to the last threshold, reserved space.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/segment.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index d317b61..a0e9207 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -437,8 +437,9 @@ static inline int reserved_sections(struct f2fs_sb_info 
*sbi)
 
 static inline bool need_SSR(struct f2fs_sb_info *sbi)
 {
-   return (prefree_segments(sbi) / sbi->segs_per_sec)
-   + free_sections(sbi) < overprovision_sections(sbi);
+   int node_secs = get_blocktype_secs(sbi, F2FS_DIRTY_NODES);
+   return (prefree_segments(sbi) / sbi->segs_per_sec) +
+   free_sections(sbi) < (reserved_sections(sbi) + node_secs);
 }
 
 static inline bool has_not_enough_free_secs(struct f2fs_sb_info *sbi, int 
freed)
-- 
1.8.5.2 (Apple Git-48)

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


[PATCH 2/3] f2fs: change the ipu_policy option to enable combinations

2014-09-17 Thread Jaegeuk Kim
This patch changes the ipu_policy setting to use any combination of orthogonal 
policies.

Signed-off-by: Changman Lee 
Signed-off-by: Jaegeuk Kim 
---
 Documentation/filesystems/f2fs.txt |  6 +++---
 fs/f2fs/segment.c  |  2 +-
 fs/f2fs/segment.h  | 39 --
 3 files changed, 20 insertions(+), 27 deletions(-)

diff --git a/Documentation/filesystems/f2fs.txt 
b/Documentation/filesystems/f2fs.txt
index d010da8..2cca5a2 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -192,9 +192,9 @@ Files in /sys/fs/f2fs/
 
  ipu_policy   This parameter controls the policy of in-place
   updates in f2fs. There are five policies:
-   0: F2FS_IPU_FORCE, 1: F2FS_IPU_SSR,
-   2: F2FS_IPU_UTIL,  3: F2FS_IPU_SSR_UTIL,
-   4: F2FS_IPU_FSYNC, 5: F2FS_IPU_DISABLE.
+   0x01: F2FS_IPU_FORCE, 0x02: F2FS_IPU_SSR,
+   0x04: F2FS_IPU_UTIL,  0x08: F2FS_IPU_SSR_UTIL,
+   0x10: F2FS_IPU_FSYNC.
 
  min_ipu_util This parameter controls the threshold to trigger
   in-place-updates. The number indicates percentage
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 24b768a..3125a3d 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1928,7 +1928,7 @@ int build_segment_manager(struct f2fs_sb_info *sbi)
sm_info->ssa_blkaddr = le32_to_cpu(raw_super->ssa_blkaddr);
sm_info->rec_prefree_segments = sm_info->main_segments *
DEF_RECLAIM_PREFREE_SEGMENTS / 100;
-   sm_info->ipu_policy = F2FS_IPU_FSYNC;
+   sm_info->ipu_policy = 1 << F2FS_IPU_FSYNC;
sm_info->min_ipu_util = DEF_MIN_IPU_UTIL;
sm_info->min_fsync_blocks = DEF_MIN_FSYNC_BLOCKS;
 
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 032c090..d317b61 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -487,40 +487,33 @@ enum {
F2FS_IPU_UTIL,
F2FS_IPU_SSR_UTIL,
F2FS_IPU_FSYNC,
-   F2FS_IPU_DISABLE,
 };
 
 static inline bool need_inplace_update(struct inode *inode)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+   unsigned int policy = SM_I(sbi)->ipu_policy;
 
/* IPU can be done only for the user data */
if (S_ISDIR(inode->i_mode))
return false;
 
-   switch (SM_I(sbi)->ipu_policy) {
-   case F2FS_IPU_FORCE:
+   if (policy & (0x1 << F2FS_IPU_FORCE))
return true;
-   case F2FS_IPU_SSR:
-   if (need_SSR(sbi))
-   return true;
-   break;
-   case F2FS_IPU_UTIL:
-   if (utilization(sbi) > SM_I(sbi)->min_ipu_util)
-   return true;
-   break;
-   case F2FS_IPU_SSR_UTIL:
-   if (need_SSR(sbi) && utilization(sbi) > SM_I(sbi)->min_ipu_util)
-   return true;
-   break;
-   case F2FS_IPU_FSYNC:
-   /* this is only set during fdatasync */
-   if (is_inode_flag_set(F2FS_I(inode), FI_NEED_IPU))
-   return true;
-   break;
-   case F2FS_IPU_DISABLE:
-   break;
-   }
+   if (policy & (0x1 << F2FS_IPU_SSR) && need_SSR(sbi))
+   return true;
+   if (policy & (0x1 << F2FS_IPU_UTIL) &&
+   utilization(sbi) > SM_I(sbi)->min_ipu_util)
+   return true;
+   if (policy & (0x1 << F2FS_IPU_SSR_UTIL) && need_SSR(sbi) &&
+   utilization(sbi) > SM_I(sbi)->min_ipu_util)
+   return true;
+
+   /* this is only set during fdatasync */
+   if (policy & (0x1 << F2FS_IPU_FSYNC) &&
+   is_inode_flag_set(F2FS_I(inode), FI_NEED_IPU))
+   return true;
+
return false;
 }
 
-- 
1.8.5.2 (Apple Git-48)

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


[PATCH 1/3] f2fs: introduce a flag to represent each nat entry information

2014-09-17 Thread Jaegeuk Kim
This patch introduces a flag in the nat entry structure to merge various
information such as checkpointed and fsync_done marks.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/node.c | 13 +++--
 fs/f2fs/node.h | 28 
 2 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index b32eb56..d19d6b1 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -131,7 +131,7 @@ int is_checkpointed_node(struct f2fs_sb_info *sbi, nid_t 
nid)
 
read_lock(_i->nat_tree_lock);
e = __lookup_nat_cache(nm_i, nid);
-   if (e && !e->checkpointed)
+   if (e && !get_nat_flag(e, IS_CHECKPOINTED))
is_cp = 0;
read_unlock(_i->nat_tree_lock);
return is_cp;
@@ -146,7 +146,7 @@ bool fsync_mark_done(struct f2fs_sb_info *sbi, nid_t nid)
read_lock(_i->nat_tree_lock);
e = __lookup_nat_cache(nm_i, nid);
if (e)
-   fsync_done = e->fsync_done;
+   fsync_done = get_nat_flag(e, HAS_FSYNC_MARK);
read_unlock(_i->nat_tree_lock);
return fsync_done;
 }
@@ -159,7 +159,7 @@ void fsync_mark_clear(struct f2fs_sb_info *sbi, nid_t nid)
write_lock(_i->nat_tree_lock);
e = __lookup_nat_cache(nm_i, nid);
if (e)
-   e->fsync_done = false;
+   set_nat_flag(e, HAS_FSYNC_MARK, false);
write_unlock(_i->nat_tree_lock);
 }
 
@@ -176,7 +176,7 @@ static struct nat_entry *grab_nat_entry(struct f2fs_nm_info 
*nm_i, nid_t nid)
}
memset(new, 0, sizeof(struct nat_entry));
nat_set_nid(new, nid);
-   new->checkpointed = true;
+   set_nat_flag(new, IS_CHECKPOINTED, true);
list_add_tail(>list, _i->nat_entries);
nm_i->nat_cnt++;
return new;
@@ -249,7 +249,7 @@ retry:
/* update fsync_mark if its inode nat entry is still alive */
e = __lookup_nat_cache(nm_i, ni->ino);
if (e)
-   e->fsync_done = fsync_done;
+   set_nat_flag(e, HAS_FSYNC_MARK, fsync_done);
write_unlock(_i->nat_tree_lock);
 }
 
@@ -1349,7 +1349,8 @@ static int add_free_nid(struct f2fs_sb_info *sbi, nid_t 
nid, bool build)
read_lock(_i->nat_tree_lock);
ne = __lookup_nat_cache(nm_i, nid);
if (ne &&
-   (!ne->checkpointed || nat_get_blkaddr(ne) != NULL_ADDR))
+   (!get_nat_flag(ne, IS_CHECKPOINTED) ||
+   nat_get_blkaddr(ne) != NULL_ADDR))
allocated = true;
read_unlock(_i->nat_tree_lock);
if (allocated)
diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
index 324917d..3043778 100644
--- a/fs/f2fs/node.h
+++ b/fs/f2fs/node.h
@@ -39,10 +39,14 @@ struct node_info {
unsigned char version;  /* version of the node */
 };
 
+enum {
+   IS_CHECKPOINTED,/* is it checkpointed before? */
+   HAS_FSYNC_MARK, /* has the latest node fsync mark? */
+};
+
 struct nat_entry {
struct list_head list;  /* for clean or dirty nat list */
-   bool checkpointed;  /* whether it is checkpointed or not */
-   bool fsync_done;/* whether the latest node has fsync mark */
+   unsigned char flag; /* for node information bits */
struct node_info ni;/* in-memory node information */
 };
 
@@ -57,16 +61,32 @@ struct nat_entry {
 
 #define __set_nat_cache_dirty(nm_i, ne)
\
do {\
-   ne->checkpointed = false;   \
+   set_nat_flag(ne, IS_CHECKPOINTED, false);   \
list_move_tail(>list, _i->dirty_nat_entries);\
} while (0)
 #define __clear_nat_cache_dirty(nm_i, ne)  \
do {\
-   ne->checkpointed = true;\
+   set_nat_flag(ne, IS_CHECKPOINTED, true);\
list_move_tail(>list, _i->nat_entries);  \
} while (0)
 #define inc_node_version(version)  (++version)
 
+static inline void set_nat_flag(struct nat_entry *ne,
+   unsigned int type, bool set)
+{
+   unsigned char mask = 0x01 << type;
+   if (set)
+   ne->flag |= mask;
+   else
+   ne->flag &= ~mask;
+}
+
+static inline bool get_nat_flag(struct nat_entry *ne, unsigned int type)
+{
+   unsigned char mask = 0x01 << type;
+   return ne->flag & mask;
+}
+
 static inline void node_info_from_raw_nat(struct node_info *ni,
struct f2fs_nat_entry *raw_ne)
 {
-- 
1.8.5.2 (Apple Git-48)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More 

Re: [PATCH] mfd: rtsx: fix PM suspend for 5227 & 5249

2014-09-17 Thread micky

On 09/18/2014 12:53 PM, Lee Jones wrote:

On Thu, 18 Sep 2014, micky_ch...@realsil.com.cn wrote:


From: Micky Ching 

Fix rts5227&5249 failed send buffer cmd after suspend,
PM_CTRL3 should reset before send any buffer cmd after suspend.
Otherwise, buffer cmd will failed, this will lead resume fail.

Signed-off-by: Micky Ching 
---
  drivers/mfd/rts5227.c|   19 +++
  drivers/mfd/rts5249.c|4 
  drivers/mfd/rtsx_pcr.h   |1 +
  include/linux/mfd/rtsx_pci.h |   12 
  4 files changed, 36 insertions(+)

I think you'll find you just broke the build.

What happens when you compile these as modules?

I build as modules with no warning or error, did you find anything wrong?

diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 9c8eec8..8222a31 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -128,8 +128,27 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
return rtsx_pci_send_cmd(pcr, 100);
  }
  
+int rts5227_pm_reset(struct rtsx_pcr *pcr)

+{
+   int err;
+
+   /* init aspm */
+   err = rtsx_pci_update_cfg_byte(pcr, LCTLR, 0xFC, 0);
+   if (err < 0)
+   return err;
+
+   /* reset PM_CTRL3 before send buffer cmd */
+   return rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x00);
+}
+
  static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
  {
+   int err;
+
+   err = rts5227_pm_reset(pcr);
+   if (err < 0)
+   return err;
+
/* Optimize RX sensitivity */
return rtsx_pci_write_phy_register(pcr, 0x00, 0xBA42);
  }
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 573de7b..0f1b0e6 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -130,6 +130,10 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
  {
int err;
  
+	err = rts5227_pm_reset(pcr);

+   if (err < 0)
+   return err;

I don't like this.  Place rts52xx_pm_reset() somewhere more central.
Perhaps an inline function in the header would be better?

Thanks, I will fix later.

err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 07e4c2e..acc7a1e 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -72,4 +72,5 @@ do {  
\
pcr->ms_pull_ctl_disable_tbl = __device##_ms_pull_ctl_disable_tbl; \
  } while (0)
  
+int rts5227_pm_reset(struct rtsx_pcr *pcr);

  #endif
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..b34fec8 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -967,4 +967,16 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr 
*pcr)
return (u8 *)(pcr->host_cmds_ptr);
  }
  
+static inline int rtsx_pci_update_cfg_byte(struct rtsx_pcr *pcr, int addr,

+   u8 mask, u8 append)
+{
+   int err;
+   u8 val;
+
+   err = pci_read_config_byte(pcr->pci, addr, );
+   if (err < 0)
+   return err;
+   return pci_write_config_byte(pcr->pci, addr, (val & mask) | append);
+}
+
  #endif


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/3] phy: exynos-dp-video: Use syscon support to control pmu register

2014-09-17 Thread Kishon Vijay Abraham I


On Thursday 18 September 2014 08:55 AM, Vivek Gautam wrote:
> Hi Kishon,
> 
> 
> On Wed, Sep 17, 2014 at 10:24 PM, Kishon Vijay Abraham I  
> wrote:
>>
>>
>> On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
>>> Currently the DP_PHY_ENABLE register is mapped in the driver,
>>> and accessed to control power to the PHY.
>>> With mfd-syscon and regmap interface available at our disposal,
>>> it's wise to use that instead of using a 'reg' property for the
>>> controller and allocating a memory resource for that.
>>>
>>> To facilitate this, we have added another compatible string
>>> for Exynso5420 SoC to acquire driver data which contains
>>> different DP-PHY-CONTROL register offset.
>>>
>>> Signed-off-by: Vivek Gautam 
>>> Cc: Jingoo Han 
>>> Cc: Kishon Vijay Abraham I 
>>
>> Taking this in linux-phy tree. If someone has already taken this patch, 
>> please
>> let me know.
> 
> Thanks for taking this. But just one check, i think i need to separate
> out the Documentation
> to a separate patch even before this driver patch. Isn't it ?

no.. that's alright.

Thanks
Kishon
> 
>>
>> Thanks
>> Kishon
>>
>>> ---
>>>
>>> Changes since v2:
>>>  - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
>>>since that's available with us in "linux/mfd/syscon/exynos5-pmu.h" file.
>>>
>>> Changes since v1:
>>>  - state->regs should have been "struct regmap *" instead of
>>>"void __iomem *". So corrected the same.
>>>
>>>  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>>>  drivers/phy/phy-exynos-dp-video.c  |   79 
>>> +---
>>>  2 files changed, 59 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
>>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> index 7a6feea..15e0f2c 100644
>>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
>>>  -
>>>
>>>  Required properties:
>>> -- compatible : should be "samsung,exynos5250-dp-video-phy";
>>> -- reg : offset and length of the Display Port PHY register set;
>>> +- compatible : should be one of the following supported values:
>>> +  - "samsung,exynos5250-dp-video-phy"
>>> +  - "samsung,exynos5420-dp-video-phy"
>>> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
>>> +   control pmu registers for power isolation.
>>>  - #phy-cells : from the generic PHY bindings, must be 0;
>>>
>>>  Samsung S5P/EXYNOS SoC series USB PHY
>>> diff --git a/drivers/phy/phy-exynos-dp-video.c 
>>> b/drivers/phy/phy-exynos-dp-video.c
>>> index 8b3026e..53f44a0 100644
>>> --- a/drivers/phy/phy-exynos-dp-video.c
>>> +++ b/drivers/phy/phy-exynos-dp-video.c
>>> @@ -13,44 +13,55 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>> -/* DPTX_PHY_CONTROL register */
>>> -#define EXYNOS_DPTX_PHY_ENABLE   (1 << 0)
>>> +struct exynos_dp_video_phy_drvdata {
>>> + u32 phy_ctrl_offset;
>>> +};
>>>
>>>  struct exynos_dp_video_phy {
>>> - void __iomem *regs;
>>> + struct regmap *regs;
>>> + const struct exynos_dp_video_phy_drvdata *drvdata;
>>>  };
>>>
>>> -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int 
>>> on)
>>> +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
>>> + unsigned int on)
>>>  {
>>> - u32 reg;
>>> + unsigned int val;
>>> +
>>> + if (IS_ERR(state->regs))
>>> + return;
>>>
>>> - reg = readl(state->regs);
>>> - if (on)
>>> - reg |= EXYNOS_DPTX_PHY_ENABLE;
>>> - else
>>> - reg &= ~EXYNOS_DPTX_PHY_ENABLE;
>>> - writel(reg, state->regs);
>>> + val = on ? 0 : EXYNOS5_PHY_ENABLE;
>>>
>>> - return 0;
>>> + regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
>>> +EXYNOS5_PHY_ENABLE, val);
>>>  }
>>>
>>>  static int exynos_dp_video_phy_power_on(struct phy *phy)
>>>  {
>>>   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>>
>>> - return __set_phy_state(state, 1);
>>> + /* Disable power isolation on DP-PHY */
>>> + exynos_dp_video_phy_pwr_isol(state, 0);
>>> +
>>> + return 0;
>>>  }
>>>
>>>  static int exynos_dp_video_phy_power_off(struct phy *phy)
>>>  {
>>>   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>>
>>> - return __set_phy_state(state, 0);
>>> + /* Enable power isolation on DP-PHY */
>>> + exynos_dp_video_phy_pwr_isol(state, 1);
>>> +
>>> + return 0;
>>>  }
>>>
>>>  static struct phy_ops exynos_dp_video_phy_ops = {
>>> @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
>>>   .owner  = 

[PATCH 2/3] f2fs: fix conditions to remain recovery information in f2fs_sync_file

2014-09-17 Thread Jaegeuk Kim
This patch revisited whole the recovery information during the f2fs_sync_file.

In this patch, there are three information to make a decision.

a) IS_CHECKPOINTED, /* is it checkpointed before? */
b) HAS_FSYNCED_INODE,   /* is the inode fsynced before? */
c) HAS_LAST_FSYNC,  /* has the latest node fsync mark? */

And, the scenarios for our rule are based on:

[Term] F: fsync_mark, D: dentry_mark

1. inode(x) | CP | inode(x) | dnode(F)
2. inode(x) | CP | inode(F) | dnode(F)
3. inode(x) | CP | dnode(F) | inode(x) | inode(F)
4. inode(x) | CP | dnode(F) | inode(F)
5. CP | inode(x) | dnode(F) | inode(DF)
6. CP | inode(DF) | dnode(F)
7. CP | dnode(F) | inode(DF)
8. CP | dnode(F) | inode(x) | inode(DF)

For example, #3, the three conditions should be changed as follows.

   inode(x) | CP | dnode(F) | inode(x) | inode(F)
a)x   o  o  o  o
b)x   x  x  x  o
c)x   o  o  x  o

If f2fs_sync_file stops   --^,
 it should write inode(F)--^

So, the need_inode_block_update should return true, since
 c) get_nat_flag(e, HAS_LAST_FSYNC), is false.

For example, #8,
  CP | alloc | dnode(F) | inode(x) | inode(DF)
a)o  xx  x  x
b)x   x  x  o
c)o   o  x  o

If f2fs_sync_file stops   ---^,
 it should write inode(DF)--^

Note that, the roll-forward policy should follow this rule, which means,
if there are any missing blocks, we doesn't need to recover that inode.

Signed-off-by: Huang Ying 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c |  3 ---
 fs/f2fs/f2fs.h |  6 +++---
 fs/f2fs/file.c | 10 ++
 fs/f2fs/node.c | 56 +++-
 fs/f2fs/node.h | 21 -
 5 files changed, 56 insertions(+), 40 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 0e37658..fdc3dbe 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1089,9 +1089,6 @@ static ssize_t f2fs_direct_IO(int rw, struct kiocb *iocb,
if (check_direct_IO(inode, rw, iter, offset))
return 0;
 
-   /* clear fsync mark to recover these blocks */
-   fsync_mark_clear(F2FS_I_SB(inode), inode->i_ino);
-
trace_f2fs_direct_IO_enter(inode, offset, count, rw);
 
err = blockdev_direct_IO(rw, iocb, inode, iter, offset, get_data_block);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 9fc1bcd..fd44083 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1224,9 +1224,9 @@ struct dnode_of_data;
 struct node_info;
 
 bool available_free_memory(struct f2fs_sb_info *, int);
-int is_checkpointed_node(struct f2fs_sb_info *, nid_t);
-bool fsync_mark_done(struct f2fs_sb_info *, nid_t);
-void fsync_mark_clear(struct f2fs_sb_info *, nid_t);
+bool is_checkpointed_node(struct f2fs_sb_info *, nid_t);
+bool has_fsynced_inode(struct f2fs_sb_info *, nid_t);
+bool need_inode_block_update(struct f2fs_sb_info *, nid_t);
 void get_node_info(struct f2fs_sb_info *, nid_t, struct node_info *);
 int get_dnode_of_data(struct dnode_of_data *, pgoff_t, int);
 int truncate_inode_blocks(struct inode *, pgoff_t);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index af06e22..3035c79 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -207,15 +207,17 @@ int f2fs_sync_file(struct file *file, loff_t start, 
loff_t end, int datasync)
up_write(>i_sem);
}
} else {
-   /* if there is no written node page, write its inode page */
-   while (!sync_node_pages(sbi, ino, )) {
-   if (fsync_mark_done(sbi, ino))
-   goto out;
+sync_nodes:
+   sync_node_pages(sbi, ino, );
+
+   if (need_inode_block_update(sbi, ino)) {
mark_inode_dirty_sync(inode);
ret = f2fs_write_inode(inode, NULL);
if (ret)
goto out;
+   goto sync_nodes;
}
+
ret = wait_on_node_pages_writeback(sbi, ino);
if (ret)
goto out;
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index d19d6b1..7a2d9c9 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -123,44 +123,48 @@ static void __del_from_nat_cache(struct f2fs_nm_info 
*nm_i, struct nat_entry *e)
kmem_cache_free(nat_entry_slab, e);
 }
 
-int is_checkpointed_node(struct f2fs_sb_info *sbi, nid_t nid)
+bool is_checkpointed_node(struct f2fs_sb_info *sbi, nid_t nid)
 {
struct f2fs_nm_info *nm_i = NM_I(sbi);
struct nat_entry *e;
-   int is_cp = 1;
+   bool is_cp = true;
 
read_lock(_i->nat_tree_lock);
e = __lookup_nat_cache(nm_i, nid);
if (e && !get_nat_flag(e, IS_CHECKPOINTED))
-   is_cp = 0;
+   is_cp = false;
read_unlock(_i->nat_tree_lock);
return 

[PATCH 3/3] f2fs: fix roll-forward missing scenarios

2014-09-17 Thread Jaegeuk Kim
We can summarize the roll forward recovery scenarios as follows.

[Term] F: fsync_mark, D: dentry_mark

1. inode(x) | CP | inode(x) | dnode(F)
-> Update the latest inode(x).

2. inode(x) | CP | inode(F) | dnode(F)
-> No problem.

3. inode(x) | CP | dnode(F) | inode(x)
-> Recover to the latest dnode(F), and drop the last inode(x)

4. inode(x) | CP | dnode(F) | inode(F)
-> No problem.

5. CP | inode(x) | dnode(F)
-> The inode(DF) was missing. Should drop this dnode(F).

6. CP | inode(DF) | dnode(F)
-> No problem.

7. CP | dnode(F) | inode(DF)
-> If f2fs_iget fails, then goto next to find inode(DF).

8. CP | dnode(F) | inode(x)
-> If f2fs_iget fails, then goto next to find inode(DF).
   But it will fail due to no inode(DF).

So, this patch adds some missing points such as #1, #5, #7, and #8.

Signed-off-by: Huang Ying 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/recovery.c | 71 +-
 1 file changed, 60 insertions(+), 11 deletions(-)

diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 36d4f73..a4eb978 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -14,6 +14,37 @@
 #include "node.h"
 #include "segment.h"
 
+/*
+ * Roll forward recovery scenarios.
+ *
+ * [Term] F: fsync_mark, D: dentry_mark
+ *
+ * 1. inode(x) | CP | inode(x) | dnode(F)
+ * -> Update the latest inode(x).
+ *
+ * 2. inode(x) | CP | inode(F) | dnode(F)
+ * -> No problem.
+ *
+ * 3. inode(x) | CP | dnode(F) | inode(x)
+ * -> Recover to the latest dnode(F), and drop the last inode(x)
+ *
+ * 4. inode(x) | CP | dnode(F) | inode(F)
+ * -> No problem.
+ *
+ * 5. CP | inode(x) | dnode(F)
+ * -> The inode(DF) was missing. Should drop this dnode(F).
+ *
+ * 6. CP | inode(DF) | dnode(F)
+ * -> No problem.
+ *
+ * 7. CP | dnode(F) | inode(DF)
+ * -> If f2fs_iget fails, then goto next to find inode(DF).
+ *
+ * 8. CP | dnode(F) | inode(x)
+ * -> If f2fs_iget fails, then goto next to find inode(DF).
+ *But it will fail due to no inode(DF).
+ */
+
 static struct kmem_cache *fsync_entry_slab;
 
 bool space_for_roll_forward(struct f2fs_sb_info *sbi)
@@ -110,27 +141,32 @@ out:
return err;
 }
 
-static int recover_inode(struct inode *inode, struct page *node_page)
+static void __recover_inode(struct inode *inode, struct page *page)
 {
-   struct f2fs_inode *raw_inode = F2FS_INODE(node_page);
+   struct f2fs_inode *raw = F2FS_INODE(page);
+
+   inode->i_mode = le16_to_cpu(raw->i_mode);
+   i_size_write(inode, le64_to_cpu(raw->i_size));
+   inode->i_atime.tv_sec = le64_to_cpu(raw->i_mtime);
+   inode->i_ctime.tv_sec = le64_to_cpu(raw->i_ctime);
+   inode->i_mtime.tv_sec = le64_to_cpu(raw->i_mtime);
+   inode->i_atime.tv_nsec = le32_to_cpu(raw->i_mtime_nsec);
+   inode->i_ctime.tv_nsec = le32_to_cpu(raw->i_ctime_nsec);
+   inode->i_mtime.tv_nsec = le32_to_cpu(raw->i_mtime_nsec);
+}
 
+static int recover_inode(struct inode *inode, struct page *node_page)
+{
if (!IS_INODE(node_page))
return 0;
 
-   inode->i_mode = le16_to_cpu(raw_inode->i_mode);
-   i_size_write(inode, le64_to_cpu(raw_inode->i_size));
-   inode->i_atime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
-   inode->i_ctime.tv_sec = le64_to_cpu(raw_inode->i_ctime);
-   inode->i_mtime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
-   inode->i_atime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
-   inode->i_ctime.tv_nsec = le32_to_cpu(raw_inode->i_ctime_nsec);
-   inode->i_mtime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
+   __recover_inode(inode, node_page);
 
if (is_dent_dnode(node_page))
return recover_dentry(node_page, inode);
 
f2fs_msg(inode->i_sb, KERN_NOTICE, "recover_inode: ino = %x, name = %s",
-   ino_of_node(node_page), raw_inode->i_name);
+   ino_of_node(node_page), F2FS_INODE(node_page)->i_name);
return 0;
 }
 
@@ -183,10 +219,16 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi, 
struct list_head *head)
break;
}
 
+   /*
+* CP | dnode(F) | inode(DF)
+* For this case, we should not give up now.
+*/
entry->inode = f2fs_iget(sbi->sb, ino_of_node(page));
if (IS_ERR(entry->inode)) {
err = PTR_ERR(entry->inode);
kmem_cache_free(fsync_entry_slab, entry);
+   if (err == -ENOENT)
+   goto next;
break;
}
list_add_tail(>list, head);
@@ -423,6 +465,13 @@ static int recover_data(struct f2fs_sb_info *sbi,
entry = get_fsync_inode(head, ino_of_node(page));
if (!entry)
goto next;
+   /*

Re: [PATCHv5] mtd: nand: atmel_nand: retrieve NFC clock

2014-09-17 Thread Brian Norris
On Sat, Sep 13, 2014 at 01:23:59AM +0200, Alexandre Belloni wrote:
> From: Boris BREZILLON 
> 
> Retrieve the NFC clock to make sure it is enabled. Make that optional to 
> ensure
> compatibility with previous device trees but document it as mandatory so newer
> device trees will include it.
> 
> Signed-off-by: Boris BREZILLON 
> Signed-off-by: Alexandre Belloni 
> Acked-by: Josh Wu 
> ---
> Changes in v5:
>  - Added a proper commit log

Pushed to l2-mtd.git. Thanks!

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] f2fs: Fix recover when nid of non-inode dnode < nid of inode

2014-09-17 Thread Jaegeuk Kim
On Mon, Sep 15, 2014 at 01:14:09PM +0800, Huang Ying wrote:
> On Sun, 2014-09-14 at 00:48 -0700, Jaegeuk Kim wrote:
> > On Sat, Sep 13, 2014 at 10:23:18PM +0800, Huang Ying wrote:
> > > On Fri, 2014-09-12 at 15:34 +0800, Huang Ying wrote:
> > > > On Thu, 2014-09-11 at 22:13 -0700, Jaegeuk Kim wrote:
> > > > > On Thu, Sep 11, 2014 at 08:25:17PM +0800, Huang Ying wrote:
> > > > > > 
> > > > > > On Wed, 2014-09-10 at 22:37 -0700, Jaegeuk Kim wrote:
> > > > > > > On Wed, Sep 10, 2014 at 07:08:32PM +0800, huang ying wrote:
> > > > > > > > On Wed, Sep 10, 2014 at 3:21 PM, Jaegeuk Kim 
> > > > > > > >  wrote:
> > > > > > > > 
> > > > > > > > > On Tue, Sep 09, 2014 at 07:31:49PM +0800, huang ying wrote:
> > > > > > > > > > On Tue, Sep 9, 2014 at 3:09 PM, Jaegeuk Kim 
> > > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Sep 09, 2014 at 01:39:30PM +0800, Huang Ying 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Mon, 2014-09-08 at 22:23 -0700, Jaegeuk Kim wrote:
> > > > > > > > > > > > > Hi Huang,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Sep 08, 2014 at 07:38:26PM +0800, Huang Ying 
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > For fsync, if the nid of a non-inode dnode < nid of 
> > > > > > > > > > > > > > inode and the
> > > > > > > > > > > > > > inode is not checkpointed.  The non-inode dnode may 
> > > > > > > > > > > > > > be written
> > > > > > > > > before
> > > > > > > > > > > > > > inode.  So in find_fsync_dnodes, f2fs_iget will 
> > > > > > > > > > > > > > fail, cause the
> > > > > > > > > > > > > > recovery fail.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Usually, inode will be allocated before non-inode 
> > > > > > > > > > > > > > dnode, so the
> > > > > > > > > nid
> > > > > > > > > > > of
> > > > > > > > > > > > > > inode < nid of non-inode dnode.  But it is possible 
> > > > > > > > > > > > > > for the
> > > > > > > > > reverse.
> > > > > > > > > > > > > > For example, because of alloc_nid_failed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This is fixed via ignoring non-inode dnode before 
> > > > > > > > > > > > > > inode dnode in
> > > > > > > > > > > > > > find_fsync_dnodes.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The patch was tested via allocating nid reversely 
> > > > > > > > > > > > > > via a debugging
> > > > > > > > > > > > > > patch, that is, from big number to small number.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Huang, Ying 
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >  fs/f2fs/recovery.c |7 ---
> > > > > > > > > > > > > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --- a/fs/f2fs/recovery.c
> > > > > > > > > > > > > > +++ b/fs/f2fs/recovery.c
> > > > > > > > > > > > > > @@ -172,8 +172,8 @@ static int 
> > > > > > > > > > > > > > find_fsync_dnodes(struct f2fs
> > > > > > > > > > > > > >   if (IS_INODE(page) && 
> > > > > > > > > > > > > > is_dent_dnode(page))
> > > > > > > > > > > > > >   
> > > > > > > > > > > > > > set_inode_flag(F2FS_I(entry->inode),
> > > > > > > > > > > > > >   
> > > > > > > > > > > > > > FI_INC_LINK);
> > > > > > > > > > > > > > - } else {
> > > > > > > > > > > > > > - if (IS_INODE(page) && 
> > > > > > > > > > > > > > is_dent_dnode(page)) {
> > > > > > > > > > > > >
> > > > > > > > > > > > > If this is not inode block, we should add this inode 
> > > > > > > > > > > > > to recover its
> > > > > > > > > > > data blocks.
> > > > > > > > > > > >
> > > > > > > > > > > > Is it possible that there is only non-inode dnode but 
> > > > > > > > > > > > no inode when
> > > > > > > > > > > > find_fsync_dnodes checking dnodes?  Per my 
> > > > > > > > > > > > understanding, any
> > > > > > > > > changes to
> > > > > > > > > > > > file will cause inode page dirty (for example, mtime 
> > > > > > > > > > > > changed), so
> > > > > > > > > that
> > > > > > > > > > > > we will write inode block.  Is it right?  If so, the 
> > > > > > > > > > > > solution in this
> > > > > > > > > > > > patch should work too.
> > > > > > > > > > >
> > > > > > > > > > > Your description says that f2fs_iget will fail, which 
> > > > > > > > > > > causes the
> > > > > > > > > recovery
> > > > > > > > > > > fail.
> > > > > > > > > > > So, I thought it would be better to handle the f2fs_iget 
> > > > > > > > > > > failure
> > > > > > > > > directly.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Yes.  That is another way to fix the issue.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > In addition, we cannot guarantee the write order of dnode 
> > > > > > > > > > > and inode.
> > > > > > > > > > > For exmaple,
> > > > > > > > > > > 1. the inode is written by flusher or kswapd, then,
> > > > > > 

Re: [PATCH] [trivial] wireless:rtlwifi: Fix typo in rtl wifi drivers

2014-09-17 Thread Larry Finger

On 09/17/2014 10:29 PM, Masanari Iida wrote:

This patch fix spelling typo "sleeped" in printk, found in
multiple rtlwifi drivers.

Signed-off-by: Masanari Iida 
---
  drivers/net/wireless/rtlwifi/rtl8188ee/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8192ce/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8192cu/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8723ae/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8723be/phy.c | 2 +-
  7 files changed, 7 insertions(+), 7 deletions(-)


John,

Please do not apply this patch for two reasons. (1) It would interfere with the 
major changes that I will be sending in the next few days. (2) I have been 
favoring "sleeping" over "slept" as a substitute for "sleeped". If I change my 
mind, I will resubmit this patch with Masanari as the author.


Thanks,

Larry

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


Re: [PATCH v4 1/3] mfd/axp20x: extend axp20x to support axp288 pmic

2014-09-17 Thread Lee Jones
On Tue, 16 Sep 2014, Jacob Pan wrote:

> X-Powers AXP288 is a customized PMIC for Intel Baytrail-CR platforms. Similar
> to AXP202/209, AXP288 comes with USB charger, more LDO and BUCK channels, and
> AD converters. It also provides extended status and interrupt reporting
> capabilities than the devices currently supported in axp20x.c.
> 
> In addition to feature extension, this patch also adds ACPI binding for
> enumeration.
> 
> This consolidated driver should support more X-Powers' PMICs in both device
> tree and ACPI enumerated platforms.
> 
> Signed-off-by: Jacob Pan 
> ---
>  drivers/mfd/Kconfig|   3 +-
>  drivers/mfd/axp20x.c   | 353 
> +
>  include/linux/mfd/axp20x.h |  58 
>  3 files changed, 354 insertions(+), 60 deletions(-)
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index de5abf2..c183edb 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -74,7 +74,8 @@ config MFD_AXP20X
>   select REGMAP_IRQ
>   depends on I2C=y
>   help
> -   If you say Y here you get support for the X-Powers AXP202 and AXP209.
> +   If you say Y here you get support for the X-Powers AXP202, AXP209 and
> +   AXP288 power management IC (PMIC).
> This driver include only the core APIs. You have to select individual
> components like regulators or the PEK (Power Enable Key) under the
> corresponding menus.

[...]

> -static const struct regmap_config axp20x_regmap_config = {

[...]

> +static struct regmap_config axp20x_regmap_config = {

Why have you removed const status?

>   .reg_bits   = 8,
>   .val_bits   = 8,
>   .wr_table   = _writeable_table,
> @@ -70,47 +129,96 @@ static const struct regmap_config axp20x_regmap_config = 
> {
>   .cache_type = REGCACHE_RBTREE,
>  };
>  
> -#define AXP20X_IRQ(_irq, _off, _mask) \
> - [AXP20X_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
> +static struct regmap_config axp288_regmap_config = {

const?

> + .reg_bits   = 8,
> + .val_bits   = 8,
> + .wr_table   = _writeable_table,
> + .volatile_table = _volatile_table,
> + .max_register   = AXP288_FG_TUNE5,
> + .cache_type = REGCACHE_RBTREE,
> +};

[...]

> -static const struct regmap_irq_chip axp20x_regmap_irq_chip = {
> +static struct acpi_device_id axp20x_acpi_match[] = {
> + {
> + .id = "INT33F4",
> + .driver_data = (kernel_ulong_t)AXP288_ID,

Why do you need to cast this?

> + },
> + { },
> +};
> +MODULE_DEVICE_TABLE(acpi, axp20x_acpi_match);
> +
> +/* common irq chip attributes only */
> +static struct regmap_irq_chip axp20x_regmap_irq_chip = {
>   .name   = "axp20x_irq_chip",
>   .status_base= AXP20X_IRQ1_STATE,
>   .ack_base   = AXP20X_IRQ1_STATE,
>   .mask_base  = AXP20X_IRQ1_EN,
> - .num_regs   = 5,
> - .irqs   = axp20x_regmap_irqs,
> - .num_irqs   = ARRAY_SIZE(axp20x_regmap_irqs),
>   .mask_invert= true,
>   .init_ack_masked= true,
>  };
> @@ -161,36 +276,155 @@ static struct mfd_cell axp20x_cells[] = {
>   },
>  };

[...]

> +static int axp20x_match_device(struct axp20x_dev *axp20x, struct device *dev)
> +{
> + const struct acpi_device_id *acpi_id;
> + const struct of_device_id *of_id;
> +
> + of_id = of_match_device(axp20x_of_match, dev);
> + if (of_id)
> + axp20x->variant = (long) of_id->data;
> + else {
> + acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
> + if (!acpi_id || !acpi_id->driver_data) {
> + dev_err(dev, "Unable to determine ID\n");
> + return -ENODEV;
> + }
> + axp20x->variant = (long) acpi_id->driver_data;
> + }

We can do better error handling here and give the user a better sense
of what happened if anything were to go wrong.  Do:

if (dev->of_node)
  of_id = of_match_device()
  if (!of_id)
error()
  variant = of_id->data;
else
  acpi_id = acpi_match_device()
  if (!acpi_id)
error()
  variant = acpi_id->driver_data;

> + switch (axp20x->variant) {
> + case AXP202_ID:
> + case AXP209_ID:
> + axp20x->nr_cells = ARRAY_SIZE(axp20x_cells);
> + axp20x->cells = axp20x_cells;
> + axp20x->regmap_cfg = _regmap_config;
> + axp20x_regmap_irq_chip.num_regs = 5;
> + axp20x_regmap_irq_chip.irqs = axp20x_regmap_irqs;
> + axp20x_regmap_irq_chip.num_irqs =
> + ARRAY_SIZE(axp20x_regmap_irqs);
> + break;
> + case AXP288_ID:
> + axp20x->cells = axp288_cells;
> + axp20x->nr_cells = ARRAY_SIZE(axp288_cells);
> + axp20x->regmap_cfg = _regmap_config;
> + axp20x_regmap_irq_chip.irqs = axp288_regmap_irqs;
> +   

Re: [f2fs-dev] [PATCH 04/10] f2fs: give an option to enable in-place-updates during fsync to users

2014-09-17 Thread Jaegeuk Kim
On Mon, Sep 15, 2014 at 11:13:15AM +0900, Changman Lee wrote:
> Hi JK,
> 
> I think it' nicer if this can be used as 'OR' with other policy
> together. If so, we can also cover the weakness in high utilization.

Agreed.
I'll send another patch for that.
Thanks,

> 
> Regard,
> Changman
> 
> On Sun, Sep 14, 2014 at 03:14:18PM -0700, Jaegeuk Kim wrote:
> > If user wrote F2FS_IPU_FSYNC:4 in /sys/fs/f2fs/ipu_policy, f2fs_sync_file
> > only starts to try in-place-updates.
> > And, if the number of dirty pages is over /sys/fs/f2fs/min_fsync_blocks, it
> > keeps out-of-order manner. Otherwise, it triggers in-place-updates.
> > 
> > This may be used by storage showing very high random write performance.
> > 
> > For example, it can be used when,
> > 
> > Seq. writes (Data) + wait + Seq. writes (Node)
> > 
> > is pretty much slower than,
> > 
> > Rand. writes (Data)
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  Documentation/ABI/testing/sysfs-fs-f2fs |  7 +++
> >  Documentation/filesystems/f2fs.txt  |  9 -
> >  fs/f2fs/f2fs.h  |  1 +
> >  fs/f2fs/file.c  |  7 +++
> >  fs/f2fs/segment.c   |  3 ++-
> >  fs/f2fs/segment.h   | 14 ++
> >  fs/f2fs/super.c |  2 ++
> >  7 files changed, 33 insertions(+), 10 deletions(-)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs 
> > b/Documentation/ABI/testing/sysfs-fs-f2fs
> > index 62dd725..6f9157f 100644
> > --- a/Documentation/ABI/testing/sysfs-fs-f2fs
> > +++ b/Documentation/ABI/testing/sysfs-fs-f2fs
> > @@ -44,6 +44,13 @@ Description:
> >  Controls the FS utilization condition for the in-place-update
> >  policies.
> >  
> > +What:  /sys/fs/f2fs//min_fsync_blocks
> > +Date:  September 2014
> > +Contact:   "Jaegeuk Kim" 
> > +Description:
> > +Controls the dirty page count condition for the in-place-update
> > +policies.
> > +
> >  What:  /sys/fs/f2fs//max_small_discards
> >  Date:  November 2013
> >  Contact:   "Jaegeuk Kim" 
> > diff --git a/Documentation/filesystems/f2fs.txt 
> > b/Documentation/filesystems/f2fs.txt
> > index a2046a7..d010da8 100644
> > --- a/Documentation/filesystems/f2fs.txt
> > +++ b/Documentation/filesystems/f2fs.txt
> > @@ -194,13 +194,20 @@ Files in /sys/fs/f2fs/
> >updates in f2fs. There are five policies:
> > 0: F2FS_IPU_FORCE, 1: F2FS_IPU_SSR,
> > 2: F2FS_IPU_UTIL,  3: F2FS_IPU_SSR_UTIL,
> > -   4: F2FS_IPU_DISABLE.
> > +   4: F2FS_IPU_FSYNC, 5: F2FS_IPU_DISABLE.
> >  
> >   min_ipu_util This parameter controls the threshold to 
> > trigger
> >in-place-updates. The number indicates 
> > percentage
> >of the filesystem utilization, and used by
> >F2FS_IPU_UTIL and F2FS_IPU_SSR_UTIL policies.
> >  
> > + min_fsync_blocks This parameter controls the threshold to 
> > trigger
> > +  in-place-updates when F2FS_IPU_FSYNC mode is 
> > set.
> > + The number indicates the number of dirty pages
> > + when fsync needs to flush on its call path. If
> > + the number is less than this value, it triggers
> > + in-place-updates.
> > +
> >   max_victim_search   This parameter controls the number of trials to
> >   find a victim segment when conducting SSR and
> >   cleaning operations. The default value is 4096
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 2756c16..4f84d2a 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -386,6 +386,7 @@ struct f2fs_sm_info {
> >  
> > unsigned int ipu_policy;/* in-place-update policy */
> > unsigned int min_ipu_util;  /* in-place-update threshold */
> > +   unsigned int min_fsync_blocks;  /* threshold for fsync */
> >  
> > /* for flush command control */
> > struct flush_cmd_control *cmd_control_info;
> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > index 77426c7..af06e22 100644
> > --- a/fs/f2fs/file.c
> > +++ b/fs/f2fs/file.c
> > @@ -154,12 +154,11 @@ int f2fs_sync_file(struct file *file, loff_t start, 
> > loff_t end, int datasync)
> > trace_f2fs_sync_file_enter(inode);
> >  
> > /* if fdatasync is triggered, let's do in-place-update */
> > -   if (datasync)
> > +   if (get_dirty_pages(inode) <= SM_I(sbi)->min_fsync_blocks)
> > set_inode_flag(fi, FI_NEED_IPU);
> > -
> > ret = filemap_write_and_wait_range(inode->i_mapping, start, end);
> > -   if (datasync)
> > -   clear_inode_flag(fi, FI_NEED_IPU);
> > +   clear_inode_flag(fi, FI_NEED_IPU);

Re: [PATCH 09/10] f2fs: use MAX_BIO_BLOCKS(sbi)

2014-09-17 Thread Jaegeuk Kim
Hi,

Thank you for the review.
I changed the return value of MAX_BIO_BLOCKS to int.
IMO, it's the best way that I can do for now.

Thanks,

>From f3bcd1d658d1c4aa8178ddc2d4e6a7e45d8405cd Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Thu, 11 Sep 2014 14:37:35 -0700
Subject: [PATCH] f2fs: use MAX_BIO_BLOCKS(sbi)

Change log from v1:
 o change the return value of MAX_BIO_BLOCKS to int type.

This patch cleans up a simple macro.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 2 +-
 fs/f2fs/node.c | 2 +-
 fs/f2fs/recovery.c | 4 ++--
 fs/f2fs/segment.c  | 2 +-
 fs/f2fs/segment.h  | 8 
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index fdc3dbe..7749f30 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -193,7 +193,7 @@ void f2fs_submit_page_mbio(struct f2fs_sb_info *sbi, struct 
page *page,
__submit_merged_bio(io);
 alloc_new:
if (io->bio == NULL) {
-   int bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   int bio_blocks = MAX_BIO_BLOCKS(sbi);
 
io->bio = __bio_alloc(sbi, blk_addr, bio_blocks, is_read);
io->fio = *fio;
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 7a2d9c9..21ed91b 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1697,7 +1697,7 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
struct f2fs_summary *sum_entry;
struct inode *inode = sbi->sb->s_bdev->bd_inode;
block_t addr;
-   int bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   int bio_blocks = MAX_BIO_BLOCKS(sbi);
struct page *pages[bio_blocks];
int i, idx, last_offset, nrpages, err = 0;
 
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 78ef10c..1ccee36 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -180,7 +180,7 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi, 
struct list_head *head)
page = get_meta_page(sbi, blkaddr);
 
ra_meta_pages(sbi, next_blkaddr_of_node(page),
-   MAX_BIO_BLOCKS(max_hw_blocks(sbi)), META_POR);
+   MAX_BIO_BLOCKS(sbi), META_POR);
 
if (cp_ver != cpver_of_node(page))
break;
@@ -444,7 +444,7 @@ static int recover_data(struct f2fs_sb_info *sbi,
page = get_meta_page(sbi, blkaddr);
 
ra_meta_pages(sbi, next_blkaddr_of_node(page),
-   MAX_BIO_BLOCKS(max_hw_blocks(sbi)), META_POR);
+   MAX_BIO_BLOCKS(sbi), META_POR);
 
if (cp_ver != cpver_of_node(page)) {
f2fs_put_page(page, 1);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index c6f627b..4ea53aa 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1757,7 +1757,7 @@ static void build_sit_entries(struct f2fs_sb_info *sbi)
int sit_blk_cnt = SIT_BLK_CNT(sbi);
unsigned int i, start, end;
unsigned int readed, start_blk = 0;
-   int nrpages = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   int nrpages = MAX_BIO_BLOCKS(sbi);
 
do {
readed = ra_meta_pages(sbi, start_blk, nrpages, META_SIT);
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index c6f37f2..633e822 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -93,8 +93,8 @@
(((sector_t)blk_addr) << (sbi)->log_sectors_per_block)
 #define SECTOR_TO_BLOCK(sbi, sectors)  \
(sectors >> (sbi)->log_sectors_per_block)
-#define MAX_BIO_BLOCKS(max_hw_blocks)  \
-   (min((int)max_hw_blocks, BIO_MAX_PAGES))
+#define MAX_BIO_BLOCKS(sbi)\
+   ((int)min(max_hw_blocks(sbi), BIO_MAX_PAGES))
 
 /*
  * indicate a block allocation direction: RIGHT and LEFT.
@@ -728,7 +728,7 @@ static inline int nr_pages_to_skip(struct f2fs_sb_info 
*sbi, int type)
else if (type == NODE)
return 3 * sbi->blocks_per_seg;
else if (type == META)
-   return MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   return MAX_BIO_BLOCKS(sbi);
else
return 0;
 }
@@ -751,7 +751,7 @@ static inline long nr_pages_to_write(struct f2fs_sb_info 
*sbi, int type,
else if (type == NODE)
desired = 3 * max_hw_blocks(sbi);
else
-   desired = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   desired = MAX_BIO_BLOCKS(sbi);
 
wbc->nr_to_write = desired;
return desired - nr_to_write;
-- 
1.8.5.2 (Apple Git-48)

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


Re: [PATCH 7/9] phy: remove .owner field for drivers using module_platform_driver

2014-09-17 Thread Kishon Vijay Abraham I


On Thursday 18 September 2014 12:34 AM, Peter Griffin wrote:
> Hi Kishon,
> 
> On Wed, 17 Sep 2014, Kishon Vijay Abraham I wrote:
> 
>> Hi,
>>
>> On Friday 15 August 2014 06:10 PM, Peter Griffin wrote:
>>> This patch removes the superflous .owner field for drivers which
>>> use the module_platform_driver or platform_driver_register api,
>>> as this is overriden in __platform_driver_register.
>>>
>>> Signed-off-by: Peter Griffin 
> 
> 
>>>  drivers/phy/phy-twl4030-usb.c   | 1 -
>>
>> twl4030-usb doesn't use module_platform_driver. Care to resend this patch
>> along? I've merged all other patches in this series.
> 
> That is true, but it does use platform_driver_register  whih overrides .owner.
> So the patch is stil good I think (fyi see include/linux/platform_device.h).

Indeed. Will merge this one.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: don't request CD IRQ until mmc_start_host()

2014-09-17 Thread Adrian Hunter
On 09/17/2014 10:57 PM, Stephen Warren wrote:
> On 09/17/2014 01:55 PM, Ulf Hansson wrote:
>> On 12 September 2014 19:18, Stephen Warren  wrote:
>>> From: Stephen Warren 
>>>
>>> As soon as the CD IRQ is requested, it can trigger, since it's an
>>> externally controlled event. If it does, delayed_work host->detect will
>>> be scheduled.
>>>
>>> Many host controller probe()s are roughly structured as:
>>>
>>> *_probe() {
>>>  host = sdhci_pltfm_init();
>>>  mmc_of_parse(host->mmc);
>>>  rc = sdhci_add_host(host);
>>>  if (rc) {
>>>  sdhci_pltfm_free();
>>>  return rc;
>>>  }
>>>
>>> In 3.17, CD IRQs can are enabled quite early via *_probe() ->
>>> mmc_of_parse() -> mmc_gpio_request_cd() -> mmc_gpiod_request_cd_irq().
>>>
>>> Note that in linux-next, mmc_of_parse() calls mmc_gpio*d*_request_cd()
>>> rather than mmc_gpio_request_cd(), and mmc_gpio*d*_request_cd() doesn't
>>> call mmc_gpiod_request_cd_irq(). However, this issue still exists for
>>> any other direct users of mmc_gpio_request_cd().
>>>
>>> sdhci_add_host() may fail part way through (e.g. due to deferred
>>> probe for a vmmc regulator), and sdhci_pltfm_free() does nothing to
>>> unrequest the CD IRQ nor cancel the delayed_work. sdhci_pltfm_free() is
>>> coded to assume that if sdhci_add_host() failed, then the delayed_work
>>> cannot (or should not) have been triggered.
>>>
>>> This can lead to the following with CONFIG_DEBUG_OBJECTS_* enabled, when
>>> kfree(host) is eventually called inside sdhci_pltfm_free():
>>>
>>> WARNING: CPU: 2 PID: 6 at lib/debugobjects.c:263
>>> debug_print_object+0x8c/0xb4()
>>> ODEBUG: free active (active state 0) object type: timer_list hint:
>>> delayed_work_timer_fn+0x0/0x18
>>>
>>> The object being complained about is host->detect.
>>>
>>> There's no need to request the CD IRQ so early; mmc_start_host() already
>>> requests it, and I *assume* that mmc_start_host() is called somehow for
>>> all host controllers. For SDHCI hosts at least, the typical call path
>>> that does this is: *_probe() -> sdhci_add_host() -> mmc_add_host() ->
>>> mmc_start_host(). So, remove the call to mmc_gpiod_request_cd_irq() from
>>> mmc_gpio_request_cd(). This matches mmc_gpio*d*_request_cd(), which
>>> already doesn't call mmc_gpiod_request_cd_irq().
>>>
>>> This solves the problem (eliminates the kernel error message above),
>>> since it guarantees that the IRQ can't trigger before mmc_start_host()
>>> is called.
>>>
>>> The critical point here is that once sdhci_add_host() calls
>>> mmc_add_host() -> mmc_start_host(), sdhci_add_host() is coded not to
>>> fail. In other words, if there's a chance that mmc_start_host() may have
>>> been called, and CD IRQs triggered, and the delayed_work scheduled,
>>> sdhci_add_host() won't fail, and so cleanup is no longer via
>>> sdhci_pltfm_free() (which doesn't free the IRQ or cancel the work queue)
>>> but instead must be via sdhci_remove_host(), which calls mmc_remove_host()
>>> -> mmc_stop_host(), which does free the IRQ and cancel the work queue.
>>>
>>> This fixes what I might conclude to be a mistake in commit 740a221ef0e5
>>> ("mmc: slot-gpio: Add GPIO descriptor based CD GPIO API"), which added the
>>> call from mmc_start_host() to mmc_gpiod_request_cd_irq(), but also added
>>> incorrectly added a call from mmc_gpio_request_cd() to
>>> mmc_gpiod_request_cd_irq().
>>>
>>> CC: Russell King 
>>> Cc: Adrian Hunter 
>>> Cc: Alexandre Courbot 
>>> Cc: Linus Walleij 
>>> Signed-off-by: Stephen Warren 
>>
>> Hi Stephen,
>>
>> Thanks for looking into this. It seems like this issue has been
>> present for quite a while.
>> I believe your patch should have a stable tag for 3.15+ as well,
>> unless you object I will add it.
> 
> Yes, that probably makes sense, thanks.

Doesn't this patch break the drivers that call mmc_gpio_request_cd() after
mmc_add_host() like mmc_spi.c or sdhci-sirf.c or tmio_mmc_pio.c ?

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


[PATCH V2 2/3] x86: iosf: Add better description of IOSF driver in config

2014-09-17 Thread David E. Box
Adds better description of IOSF driver to determinine when it should be enabled.
Also moves the Kconfig option to "Processor type and features" menu from main
configuration menu.

Signed-off-by: David E. Box 
---
 arch/x86/Kconfig | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bcbb57d..b075873 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -480,6 +480,23 @@ config X86_INTEL_LPSS
  things like clock tree (common clock framework) and pincontrol
  which are needed by the LPSS peripheral drivers.
 
+config IOSF_MBI
+   tristate "Intel SoC IOSF Sideband support for SoC platforms"
+   depends on PCI
+   ---help---
+ This option enables sideband register access support for Intel SoC
+ platforms. On these platforms the IOSF sideband is used in lieu of
+ MSR's for some register accesses, mostly but not limited to thermal
+ and power. Drivers may query the availability of this device to
+ determine if they need the sideband in order to work on these
+ platforms. The sideband is available on the following SoC products.
+ This list is not meant to be exclusive.
+  - BayTrail
+  - Braswell
+  - Quark
+
+ You should say Y if you are running a kernel on one of these SoC's.
+
 config X86_RDC321X
bool "RDC R-321x SoC"
depends on X86_32
@@ -2443,21 +2460,6 @@ config X86_DMA_REMAP
bool
depends on STA2X11
 
-config IOSF_MBI
-   tristate "Intel System On Chip IOSF Sideband support"
-   depends on PCI
-   ---help---
- Enables sideband access to mailbox registers on SoC's. The sideband is
- available on the following platforms. This list is not meant to be
- exclusive.
-  - BayTrail
-  - Cherryview
-  - Braswell
-  - Quark
-
- You should say Y if you are running a kernel on one of these
- platforms.
-
 config PMC_ATOM
def_bool y
 depends on PCI
-- 
1.9.1

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


[PATCH V2 1/3] x86: iosf: Add Braswell PCI ID

2014-09-17 Thread David E. Box
Add Braswell PCI ID to list of supported ID's for iosf driver.

Signed-off-by: David E. Box 
---
 arch/x86/kernel/iosf_mbi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/iosf_mbi.c b/arch/x86/kernel/iosf_mbi.c
index 0a2faa3..e01f741 100644
--- a/arch/x86/kernel/iosf_mbi.c
+++ b/arch/x86/kernel/iosf_mbi.c
@@ -28,6 +28,7 @@
 #include 
 
 #define PCI_DEVICE_ID_BAYTRAIL 0x0F00
+#define PCI_DEVICE_ID_BRASWELL 0x2280
 #define PCI_DEVICE_ID_QUARK_X1000  0x0958
 
 static DEFINE_SPINLOCK(iosf_mbi_lock);
@@ -275,6 +276,7 @@ static int iosf_mbi_probe(struct pci_dev *pdev,
 
 static const struct pci_device_id iosf_mbi_pci_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_BAYTRAIL) },
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_BRASWELL) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_QUARK_X1000) },
{ 0, },
 };
-- 
1.9.1

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


[PATCH V2 3/3] x86: iosf: Add debugfs config option for iosf

2014-09-17 Thread David E. Box
Makes the iosf sideband available through debugfs. Allows developers to
experiment with using the sideband to provide debug and analytical tools for
units on the SoC.

Signed-off-by: David E. Box 
---
 arch/x86/Kconfig   | 13 +
 arch/x86/kernel/iosf_mbi.c | 23 +++
 2 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b075873..39489d6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -497,6 +497,19 @@ config IOSF_MBI
 
  You should say Y if you are running a kernel on one of these SoC's.
 
+config IOSF_MBI_DEBUG
+   bool "Enable IOSF sideband access through debugfs"
+   depends on IOSF_MBI && DEBUG_FS
+   ---help---
+ Select this option to expose the IOSF sideband access registers (MCR,
+ MDR, MCRX) through debugfs to write and read register information from
+ different units on the SoC. This is most useful for obtaining device
+ state information for debug and analysis. As this is a general access
+ mechanism, users of this option would have specific knowledge of the
+ device they want to access.
+
+ If you don't require the option or are in doubt, say N.
+
 config X86_RDC321X
bool "RDC R-321x SoC"
depends on X86_32
diff --git a/arch/x86/kernel/iosf_mbi.c b/arch/x86/kernel/iosf_mbi.c
index e01f741..82f8d02 100644
--- a/arch/x86/kernel/iosf_mbi.c
+++ b/arch/x86/kernel/iosf_mbi.c
@@ -190,7 +190,7 @@ bool iosf_mbi_available(void)
 }
 EXPORT_SYMBOL(iosf_mbi_available);
 
-/** debugfs begin /
+#ifdef CONFIG_IOSF_MBI_DEBUG
 static u32 dbg_mdr;
 static u32 dbg_mcr;
 static u32 dbg_mcrx;
@@ -229,6 +229,7 @@ static int mcr_set(void *data, u64 val)
 DEFINE_SIMPLE_ATTRIBUTE(iosf_mcr_fops, mcr_get, mcr_set , "%llx\n");
 
 static struct dentry *iosf_dbg;
+
 static void iosf_sideband_debug_init(void)
 {
struct dentry *d;
@@ -257,7 +258,20 @@ static void iosf_sideband_debug_init(void)
 cleanup:
debugfs_remove_recursive(d);
 }
-/** debugfs end /
+
+static void iosf_debugfs_init(void)
+{
+   iosf_sideband_debug_init();
+}
+
+static void iosf_debugfs_remove(void)
+{
+   debugfs_remove_recursive(iosf_dbg);
+}
+#else
+static inline void iosf_debugfs_init(void) { }
+static inline void iosf_debugfs_remove(void) { }
+#endif /* CONFIG_IOSF_MBI_DEBUG */
 
 static int iosf_mbi_probe(struct pci_dev *pdev,
  const struct pci_device_id *unused)
@@ -290,13 +304,14 @@ static struct pci_driver iosf_mbi_pci_driver = {
 
 static int __init iosf_mbi_init(void)
 {
-   iosf_sideband_debug_init();
+   iosf_debugfs_init();
+
return pci_register_driver(_mbi_pci_driver);
 }
 
 static void __exit iosf_mbi_exit(void)
 {
-   debugfs_remove_recursive(iosf_dbg);
+   iosf_debugfs_remove();
 
pci_unregister_driver(_mbi_pci_driver);
if (mbi_pdev) {
-- 
1.9.1

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


[PATCH V2 0/3] x86: iosf: Additions to iosf patch set

2014-09-17 Thread David E. Box
These changes apply on top of the patches currently in Peter Anvin's tip tree.

V2: More descriptive Kconfig prompt for IOSF_MBI and IOSF_MBI_DEBUG
Cleaned up ifdef use on IOSF_MBI_DEBUG with DUMMY functions

David E. Box (3):
  x86: iosf: Add Braswell PCI ID
  x86: iosf: Add better description of IOSF driver in config
  x86: iosf: Add debugfs config option for iosf

 arch/x86/Kconfig   | 45 ++---
 arch/x86/kernel/iosf_mbi.c | 25 +
 2 files changed, 51 insertions(+), 19 deletions(-)

-- 
1.9.1

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


Re: [PATCH] serial: cadence: Add generic earlycon support

2014-09-17 Thread Michal Simek
On 09/17/2014 10:58 PM, Greg Kroah-Hartman wrote:
> On Wed, Sep 17, 2014 at 03:44:58PM +0200, Michal Simek wrote:
>> Hi Greg,
>>
>> On 09/10/2014 12:43 PM, Michal Simek wrote:
>>> Add earlycon support for the cadence serial port.
>>> This is based on recent patches:
>>> "tty/serial: pl011: add generic earlycon support"
>>> (sha1: 0d3c673e7881e691991b2a4745bd4f149603baa2)
>>> "tty/serial: add arm/arm64 semihosting earlycon"
>>> (sha1: d50d7269ebcb438afa346cdffce0f4e2a1b9e831)
>>>
>>> Signed-off-by: Michal Simek 
>>> ---
>>>
>>>  Documentation/kernel-parameters.txt |  6 ++
>>>  drivers/tty/serial/Kconfig  |  1 +
>>>  drivers/tty/serial/xilinx_uartps.c  | 19 +++
>>>  3 files changed, 26 insertions(+)
>>>
>>> diff --git a/Documentation/kernel-parameters.txt 
>>> b/Documentation/kernel-parameters.txt
>>> index a8eb6afce6a4..97055dc43167 100644
>>> --- a/Documentation/kernel-parameters.txt
>>> +++ b/Documentation/kernel-parameters.txt
>>> @@ -921,6 +921,12 @@ bytes respectively. Such letter suffixes can also be 
>>> entirely omitted.
>>>
>>> earlycon=   [KNL] Output early console device and options.
>>>
>>> +   cdns,
>>> +   Start an early, polled-mode console on a cadence serial
>>> +   port at the specified address. The cadence serial port
>>> +   must already be setup and configured. Options are not
>>> +   yet supported.
>>> +
>>> uart[8250],io,[,options]
>>> uart[8250],mmio,[,options]
>>> uart[8250],mmio32,[,options]
>>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>>> index b4d61e6bf28c..72fd2b6e2241 100644
>>> --- a/drivers/tty/serial/Kconfig
>>> +++ b/drivers/tty/serial/Kconfig
>>> @@ -1411,6 +1411,7 @@ config SERIAL_XILINX_PS_UART_CONSOLE
>>> bool "Cadence UART console support"
>>> depends on SERIAL_XILINX_PS_UART=y
>>> select SERIAL_CORE_CONSOLE
>>> +   select SERIAL_EARLYCON
>>> help
>>>   Enable a Cadence UART port to be the system console.
>>>
>>> diff --git a/drivers/tty/serial/xilinx_uartps.c 
>>> b/drivers/tty/serial/xilinx_uartps.c
>>> index 01951d27cc03..675f3fe068f6 100644
>>> --- a/drivers/tty/serial/xilinx_uartps.c
>>> +++ b/drivers/tty/serial/xilinx_uartps.c
>>> @@ -1051,6 +1051,25 @@ static void cdns_uart_console_putchar(struct 
>>> uart_port *port, int ch)
>>> cdns_uart_writel(ch, CDNS_UART_FIFO_OFFSET);
>>>  }
>>>
>>> +static void cdns_early_write(struct console *con, const char *s, unsigned 
>>> n)
>>> +{
>>> +   struct earlycon_device *dev = con->data;
>>> +
>>> +   uart_console_write(>port, s, n, cdns_uart_console_putchar);
>>> +}
>>> +
>>> +static int __init cdns_early_console_setup(struct earlycon_device *device,
>>> +  const char *opt)
>>> +{
>>> +   if (!device->port.membase)
>>> +   return -ENODEV;
>>> +
>>> +   device->con->write = cdns_early_write;
>>> +
>>> +   return 0;
>>> +}
>>> +EARLYCON_DECLARE(cdns, cdns_early_console_setup);
>>> +
>>>  /**
>>>   * cdns_uart_console_write - perform write operation
>>>   * @co: Console handle
>>> --
>>> 1.8.2.3
>>>
>>
>> Any problem with this patch?
> 
> Don't know, it's in my todo queue which is really long at the moment...
> 

Thanks for confirmation that it is in your todo queue.
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature


Re: [PATCH v3 26/29] nios2: ptrace support

2014-09-17 Thread Ley Foon Tan
On Tue, Sep 16, 2014 at 5:43 PM, Tobias Klauser  wrote:
>
> This could be simplified to:
>
> long arch_ptrace(struct task_struct *child, long request, unsigned long addr,
>  unsigned long data)
> {
> return ptrace_request(child, request, addr, data);
> }
Okay, will change this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/2] devicetree: cadence_ttc: Document binding for timer width

2014-09-17 Thread Michal Simek
On 09/17/2014 06:17 PM, Mark Rutland wrote:
> On Wed, Sep 17, 2014 at 03:30:49PM +0100, Michal Simek wrote:
>> From: Peter Crosthwaite 
>>
>> Modern TTC implementations can extend the timer width to 32 bit. This
>> feature is not self identifying so the driver needs to be made aware
>> via device tree.
>>
>> Signed-off-by: Peter Crosthwaite 
>> Signed-off-by: Michal Simek 
>> ---
>>
>>  Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt 
>> b/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
>> index 993695c659e1..5439976eca6b 100644
>> --- a/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
>> +++ b/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
>> @@ -6,6 +6,9 @@ Required properties:
>>  - interrupts : A list of 3 interrupts; one per timer channel.
>>  - clocks: phandle to the source clock
>>
>> +Optional properties:
>> +- timer-width: Bit width of the timer. Either 16 or 32 (default 16).
> 
> Are we expecting TTC implementations with widths other than 16 or 32?

IRC if you use 32bit timer and setup for example 24bit width it should work
too and you are just ignoring that upper bits.

> 
> This looks sane to me, but we might be able to just have a 32-bit-timer
> property if we don't expect arbitrary widths.

Definitely model different timer width is easily possible to do in qemu
that's why I think having more generic property timer-width is just better than
having property used just for one case.

Thanks,
Michal




signature.asc
Description: OpenPGP digital signature


Re: [PATCH 5/9] eeepc-laptop: tell sysfs that the disp attribute is write-only

2014-09-17 Thread Frans Klaver
On 18 September 2014 00:07:53 CEST, Greg Kroah-Hartman 
 wrote:
>On Wed, Sep 17, 2014 at 11:47:23PM +0200, Frans Klaver wrote:
>> The disp attribute is write-only, but sysfs doesn't know this.
>Currently
>> show_sys_acpi() is mimicking sysfs behavior, if the underlying acpi
>call
>> should fail. This was introduced in 6dff29b63a5bf2eaf3 "eeepc-laptop:
>> disp attribute should be write-only". This is not ideal; behaving
>like
>> sysfs is better left to sysfs.
>> 
>> Introduce EEEPC_CREATE_DEVICE_ATTR_WO() to instantiate a write-only
>> attribute, and declare the disp attribute with it. Sysfs makes sure
>> userspace can only write to disp at all times. This removes the need
>for
>> mimicking the sysfs behavior in show_sys_acpi() and store_sys_acpi(),
>> but we'll stick with -EIO, as changing sysfs return values should not
>be
>> taken lightly.
>> 
>> This change also causes EEEPC_CREATE_DEVICE_ATTR() to be used only
>for
>> R/W attributes. This enables us to drop the _mode argument from the
>> macro and use DEVICE_ATTR_RW() internally while we're at it. Append
>_RW
>> to the name for readability.
>> 
>> Signed-off-by: Frans Klaver 
>> ---
>> Here we're sticking with -EIO as return values. It should be said
>that the
>> commit mentioned above did change the error value from -ENODEV to
>-EIO. I'm
>> still in two minds about whether the show_sys_acpi and store_sys_acpi
>should go
>> back to returning ENODEV. We'll probably stick with -EIO, though, as
>there is
>> no strong reason other than "it was like that before".
>> 
>>  drivers/platform/x86/eeepc-laptop.c | 14 +-
>>  1 file changed, 9 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/platform/x86/eeepc-laptop.c
>b/drivers/platform/x86/eeepc-laptop.c
>> index c6d765f..a85da4f 100644
>> --- a/drivers/platform/x86/eeepc-laptop.c
>> +++ b/drivers/platform/x86/eeepc-laptop.c
>> @@ -311,14 +311,18 @@ static ssize_t show_sys_acpi(struct device
>*dev, int cm, char *buf)
>>  return store_sys_acpi(dev, _cm, buf, count);\
>>  }
>>  
>> -#define EEEPC_CREATE_DEVICE_ATTR(_name, _mode, _cm) \
>> +#define EEEPC_CREATE_DEVICE_ATTR_RW(_name, _cm) 
>> \
>>  EEEPC_ACPI_SHOW_FUNC(_name, _cm)\
>>  EEEPC_ACPI_STORE_FUNC(_name, _cm)   \
>> -static DEVICE_ATTR(_name, _mode, _name##_show, _name##_store)
>> +static DEVICE_ATTR_RW(_name)
>>  
>> -EEEPC_CREATE_DEVICE_ATTR(camera, 0644, CM_ASL_CAMERA);
>> -EEEPC_CREATE_DEVICE_ATTR(cardr, 0644, CM_ASL_CARDREADER);
>> -EEEPC_CREATE_DEVICE_ATTR(disp, 0200, CM_ASL_DISPLAYSWITCH);
>> +#define EEEPC_CREATE_DEVICE_ATTR_WO(_name, _cm) 
>> \
>> +EEEPC_ACPI_STORE_FUNC(_name, _cm)   \
>> +static DEVICE_ATTR_WO(_name)
>> +
>> +EEEPC_CREATE_DEVICE_ATTR_RW(camera, CM_ASL_CAMERA);
>> +EEEPC_CREATE_DEVICE_ATTR_RW(cardr, CM_ASL_CARDREADER);
>> +EEEPC_CREATE_DEVICE_ATTR_WO(disp, CM_ASL_DISPLAYSWITCH);
>>  
>>  struct eeepc_cpufv {
>>  int num;
>
>Ah, you did what I asked on a previous patch here, nevermind :)

Yea, I thought I'd make more sense this way. 

Thanks, 
Frans 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] eeepc-laptop: clean up coding style

2014-09-17 Thread Frans Klaver
On 18 September 2014 00:06:52 CEST, Joe Perches  wrote:
>On Wed, 2014-09-17 at 23:47 +0200, Frans Klaver wrote:
>> Correct indentation and brace usage to comply with
>> Documentation/CodingStyle.
>> 
>> Signed-off-by: Frans Klaver 
>> ---
>>  drivers/platform/x86/eeepc-laptop.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/platform/x86/eeepc-laptop.c
>b/drivers/platform/x86/eeepc-laptop.c
>> index 3095d38..653999e 100644
>> --- a/drivers/platform/x86/eeepc-laptop.c
>> +++ b/drivers/platform/x86/eeepc-laptop.c
>> @@ -544,7 +544,7 @@ static int eeepc_led_init(struct eeepc_laptop
>*eeepc)
>>  eeepc->tpd_led.name = "eeepc::touchpad";
>>  eeepc->tpd_led.brightness_set = tpd_led_set;
>>  if (get_acpi(eeepc, CM_ASL_TPD) >= 0) /* if method is available */
>> -  eeepc->tpd_led.brightness_get = tpd_led_get;
>> +eeepc->tpd_led.brightness_get = tpd_led_get;
>>  eeepc->tpd_led.max_brightness = 1;
>>  
>>  rv = led_classdev_register(>platform_device->dev,
>> @@ -692,8 +692,9 @@ static int eeepc_register_rfkill_notifier(struct
>eeepc_laptop *eeepc,
>>   * changed during setup.
>>   */
>>  eeepc_rfkill_hotplug(eeepc, handle);
>> -} else
>> +} else {
>>  return -ENODEV;
>> +}
>>  
>>  return 0;
>>  }
>
>This sort of code:
>
>   if (foo) {
>   [ do_something ]
>   } else
>   return -ERRVAL;
>
>is generally better rewritten as:
>
>   if (!foo)
>   return -ERRVAL;
>
>   [ do_something ]
>
>This gives immediacy to the error handler and
>as well reduces unnecessary indentation.

I fully agree. 

Darren, do you still take this in one patch? 

Frans

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


Re: [PATCH] mfd: rtsx: fix PM suspend for 5227 & 5249

2014-09-17 Thread Lee Jones
On Thu, 18 Sep 2014, micky_ch...@realsil.com.cn wrote:

> From: Micky Ching 
> 
> Fix rts5227&5249 failed send buffer cmd after suspend,
> PM_CTRL3 should reset before send any buffer cmd after suspend.
> Otherwise, buffer cmd will failed, this will lead resume fail.
> 
> Signed-off-by: Micky Ching 
> ---
>  drivers/mfd/rts5227.c|   19 +++
>  drivers/mfd/rts5249.c|4 
>  drivers/mfd/rtsx_pcr.h   |1 +
>  include/linux/mfd/rtsx_pci.h |   12 
>  4 files changed, 36 insertions(+)

I think you'll find you just broke the build.

What happens when you compile these as modules?

> diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
> index 9c8eec8..8222a31 100644
> --- a/drivers/mfd/rts5227.c
> +++ b/drivers/mfd/rts5227.c
> @@ -128,8 +128,27 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
>   return rtsx_pci_send_cmd(pcr, 100);
>  }
>  
> +int rts5227_pm_reset(struct rtsx_pcr *pcr)
> +{
> + int err;
> +
> + /* init aspm */
> + err = rtsx_pci_update_cfg_byte(pcr, LCTLR, 0xFC, 0);
> + if (err < 0)
> + return err;
> +
> + /* reset PM_CTRL3 before send buffer cmd */
> + return rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x00);
> +}
> +
>  static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
>  {
> + int err;
> +
> + err = rts5227_pm_reset(pcr);
> + if (err < 0)
> + return err;
> +
>   /* Optimize RX sensitivity */
>   return rtsx_pci_write_phy_register(pcr, 0x00, 0xBA42);
>  }
> diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
> index 573de7b..0f1b0e6 100644
> --- a/drivers/mfd/rts5249.c
> +++ b/drivers/mfd/rts5249.c
> @@ -130,6 +130,10 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
>  {
>   int err;
>  
> + err = rts5227_pm_reset(pcr);
> + if (err < 0)
> + return err;

I don't like this.  Place rts52xx_pm_reset() somewhere more central.
Perhaps an inline function in the header would be better?

>   err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
>   PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
>   PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
> diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
> index 07e4c2e..acc7a1e 100644
> --- a/drivers/mfd/rtsx_pcr.h
> +++ b/drivers/mfd/rtsx_pcr.h
> @@ -72,4 +72,5 @@ do {
> \
>   pcr->ms_pull_ctl_disable_tbl = __device##_ms_pull_ctl_disable_tbl; \
>  } while (0)
>  
> +int rts5227_pm_reset(struct rtsx_pcr *pcr);
>  #endif
> diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
> index 74346d5..b34fec8 100644
> --- a/include/linux/mfd/rtsx_pci.h
> +++ b/include/linux/mfd/rtsx_pci.h
> @@ -967,4 +967,16 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr 
> *pcr)
>   return (u8 *)(pcr->host_cmds_ptr);
>  }
>  
> +static inline int rtsx_pci_update_cfg_byte(struct rtsx_pcr *pcr, int addr,
> + u8 mask, u8 append)
> +{
> + int err;
> + u8 val;
> +
> + err = pci_read_config_byte(pcr->pci, addr, );
> + if (err < 0)
> + return err;
> + return pci_write_config_byte(pcr->pci, addr, (val & mask) | append);
> +}
> +
>  #endif

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


Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

2014-09-17 Thread Dave Hansen
On 09/17/2014 08:23 PM, Kevin Easton wrote:
> I was actually thinking that the kernel would take care of the xsave / 
> xrstor (for current), updating tsk->thread.fpu.state (for non-running
> threads) and sending an IPI for threads running on other CPUs.
> 
> Of course userspace can always then manually change the bounds directory
> address itself, but then it's quite clear that they're doing something
> unsupported.  Just an idea, anyway.

What's the benefit of that?

As it stands now, MPX is likely to be enabled well before any threads
are created, and the MPX enabling state will be inherited by the new
thread at clone() time.  The current mechanism allows a thread to
individually enable or disable MPX independently of the other threads.

I think it makes it both more complicated and less flexible.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: correct parameter error for dma_mapping_error

2014-09-17 Thread Liu Hua
dma_mapping_error takes two parameters, but some of examples
in Documentation/DMA-API-HOWTO.txt just takes one. So correct
it.

Signed-off-by: Liu Hua 
---
 Documentation/DMA-API-HOWTO.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index dcbbe36..0f7afb2 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -531,7 +531,7 @@ To map a single region, you do:
size_t size = buffer->len;
 
dma_handle = dma_map_single(dev, addr, size, direction);
-   if (dma_mapping_error(dma_handle)) {
+   if (dma_mapping_error(dev, dma_handle)) {
/*
 * reduce current DMA mapping usage,
 * delay and try again later or
@@ -588,7 +588,7 @@ Specifically:
size_t size = buffer->len;
 
dma_handle = dma_map_page(dev, page, offset, size, direction);
-   if (dma_mapping_error(dma_handle)) {
+   if (dma_mapping_error(dev, dma_handle)) {
/*
 * reduce current DMA mapping usage,
 * delay and try again later or
@@ -689,7 +689,7 @@ to use the dma_sync_*() interfaces.
dma_addr_t mapping;
 
mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE);
-   if (dma_mapping_error(dma_handle)) {
+   if (dma_mapping_error(cp->dev, dma_handle)) {
/*
 * reduce current DMA mapping usage,
 * delay and try again later or
-- 
1.9.0

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


[PATCH v4 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support

2014-09-17 Thread Vivek Gautam
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.

Signed-off-by: Vivek Gautam 
Acked-by: Jingoo Han 
Cc: Alan Stern 
---

Changes since v3:
 - Addressed review comments by Alan:
   -- Skipped renaming 'phy_number' variable,
   -- resorted to just adding minimal change required for phy assignment.
   -- updated patch description to mention EPROBE_DEFER support.

 drivers/usb/host/ohci-exynos.c |   81 ++--
 1 file changed, 20 insertions(+), 61 deletions(-)

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 7c48e3f..e8bf4bb 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,11 +19,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include "ohci.h"
 
@@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
 
 struct exynos_ohci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 static int exynos_ohci_get_phy(struct device *dev,
@@ -49,15 +44,9 @@ static int exynos_ohci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
-   int ret = 0;
+   int ret;
 
-   /*
-* Getting generic phy:
-* We are keeping both types of phys as a part of transiting OHCI
-* to generic phy framework, so as to maintain backward compatibilty
-* with old DTB too.
-* We fallback to older USB-PHYs when we fail to get generic PHYs.
-*/
+   /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", _number);
if (ret) {
@@ -73,31 +62,21 @@ static int exynos_ohci_get_phy(struct device *dev,
}
 
phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ohci->phy[phy_number] = phy;
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ohci->phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ohci->phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ohci->phy)) {
-   ret = PTR_ERR(exynos_ohci->phy);
-   if (ret != -ENXIO && ret != -ENODEV) {
-   dev_err(dev, "no usb2 phy configured\n");
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   dev_err(dev,
+   "Error retrieving usb2 phy: %d\n", ret);
+   return PTR_ERR(phy);
+   }
}
-   dev_dbg(dev, "Failed to get usb2 phy\n");
-   } else {
-   exynos_ohci->otg = exynos_ohci->phy->otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ohci_phy_enable(struct device *dev)
@@ -107,16 +86,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ohci->phy))
-   return usb_phy_init(exynos_ohci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   ret = phy_power_on(exynos_ohci->phy_g[i]);
+   if (!IS_ERR(exynos_ohci->phy[i]))
+   ret = phy_power_on(exynos_ohci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   phy_power_off(exynos_ohci->phy_g[i]);
+   if (!IS_ERR(exynos_ohci->phy[i]))
+   phy_power_off(exynos_ohci->phy[i]);
 
return ret;
 }
@@ -127,14 +103,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ohci->phy)) {
-   usb_phy_shutdown(exynos_ohci->phy);
-   return;
-   }
-
for (i = 0; i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   phy_power_off(exynos_ohci->phy_g[i]);
+  

[PATCH v4 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

2014-09-17 Thread Vivek Gautam
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.

Signed-off-by: Vivek Gautam 
Acked-by: Jingoo Han 
Cc: Alan Stern 
---

Changes since v3:
 - Addressed review comments by Alan:
   -- Skipped renaming 'phy_number' variable,
   -- resorted to just adding minimal change required for phy assignment.
   -- updated patch description to mention EPROBE_DEFER support.

 drivers/usb/host/ehci-exynos.c |   74 +++-
 1 file changed, 20 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..f293453 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include "ehci.h"
 
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
 struct exynos_ehci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
@@ -60,8 +55,9 @@ static int exynos_ehci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
-   int ret = 0;
+   int ret;
 
+   /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", _number);
if (ret) {
@@ -77,31 +73,21 @@ static int exynos_ehci_get_phy(struct device *dev,
}
 
phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ehci->phy[phy_number] = phy;
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ehci->phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ehci->phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ehci->phy)) {
-   ret = PTR_ERR(exynos_ehci->phy);
-   if (ret != -ENXIO && ret != -ENODEV) {
-   dev_err(dev, "no usb2 phy configured\n");
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   dev_err(dev,
+   "Error retrieving usb2 phy: %d\n", ret);
+   return PTR_ERR(phy);
+   }
}
-   dev_dbg(dev, "Failed to get usb2 phy\n");
-   } else {
-   exynos_ehci->otg = exynos_ehci->phy->otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +97,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ehci->phy))
-   return usb_phy_init(exynos_ehci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   ret = phy_power_on(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   ret = phy_power_on(exynos_ehci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   phy_power_off(exynos_ehci->phy[i]);
 
return ret;
 }
@@ -131,14 +114,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ehci->phy)) {
-   usb_phy_shutdown(exynos_ehci->phy);
-   return;
-   }
-
for (i = 0; i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   phy_power_off(exynos_ehci->phy[i]);
 }
 
 static void exynos_setup_vbus_gpio(struct device *dev)
@@ -231,9 +209,6 @@ skip_phy:
goto fail_io;
}
 
-   if (exynos_ehci->otg)
-   

Re: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs

2014-09-17 Thread German Rivera

On 09/15/2014 06:44 PM, Kim Phillips wrote:

On Thu, 11 Sep 2014 12:34:21 -0500
"J. German Rivera"  wrote:


From: "J. German Rivera" 

APIs to access the Management Complex (MC) hardware
module of Freescale LS2 SoCs. This patch includes
APIs to check the MC firmware version and to manipulate
DPRC objects in the MC.

Signed-off-by: J. German Rivera 
Signed-off-by: Stuart Yoder 
---
  drivers/bus/fsl-mc/dpmng.c |   93 +
  drivers/bus/fsl-mc/dprc.c  |  504 +++
  drivers/bus/fsl-mc/fsl_dpmng_cmd.h |   83 
  drivers/bus/fsl-mc/fsl_dprc_cmd.h  |  545 +
  drivers/bus/fsl-mc/fsl_mc_sys.c|  237 +++
  include/linux/fsl_dpmng.h  |  120 ++
  include/linux/fsl_dprc.h   |  790 
  include/linux/fsl_mc_cmd.h |  182 +
  include/linux/fsl_mc_sys.h |   81 
  9 files changed, 2635 insertions(+)
  create mode 100644 drivers/bus/fsl-mc/dpmng.c
  create mode 100644 drivers/bus/fsl-mc/dprc.c
  create mode 100644 drivers/bus/fsl-mc/fsl_dpmng_cmd.h
  create mode 100644 drivers/bus/fsl-mc/fsl_dprc_cmd.h
  create mode 100644 drivers/bus/fsl-mc/fsl_mc_sys.c
  create mode 100644 include/linux/fsl_dpmng.h
  create mode 100644 include/linux/fsl_dprc.h
  create mode 100644 include/linux/fsl_mc_cmd.h
  create mode 100644 include/linux/fsl_mc_sys.h


the fsl prefix in the filename fsl_dpmng_cmd.h is redundant with
its directory name fsl-mc/.  Note that I find dashes ('-') in
filenames make them easier to type: is there a reason we're using
underscores here?


This is a convention that we decided early on '-' for directory names
and '_' for file names.


Also, any reason why these and future include files aren't being put
in include/linux/fsl/, so as to not pollute the top level
include/linux/?  That way, we can also remove the fsl- prefix from
those filenames, too..

I would like to receive opinions from others about this before making 
any change here.



diff --git a/drivers/bus/fsl-mc/dpmng.c b/drivers/bus/fsl-mc/dpmng.c
new file mode 100644
index 000..c6ed27c
--- /dev/null
+++ b/drivers/bus/fsl-mc/dpmng.c
@@ -0,0 +1,93 @@
+/* Copyright 2013-2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY


interesting, normally this text reads:

"THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS"

...does that mean we're excluding non-Freescale copyright holders
and contributors from this warranty statement?  That doesn't seem
appropriate for an upstream kernel submission.

I would like to receive opinions from others about this before making 
any change here.



+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */


This dual BSD-3-clause/GPL license doesn't match that of patch 2's
drivers/bus/fsl-mc/fsl_mc_bus.c, GPLv2:

This is because the MC flib files in patch 1 can also be used in 
user-space code not just in the kernel. I will not make any change to 
the licenses of the MC flib files included in patch 1.



+/*
+ * Freescale Management Complex (MC) bus driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any

Re: About RK3288 i2c scl duty cycle

2014-09-17 Thread Doug Anderson
Addy,

On Wed, Sep 17, 2014 at 6:26 PM, addy ke  wrote:
> Add public list
>
> On 2014/9/17 23:17, Doug Anderson wrote:
>> Addy,
>>
>> On Tue, Sep 16, 2014 at 6:30 PM, addy...@rock-chips.com
>>  wrote:
>>> hi, all
>>
>> Any reason why you didn't add some public lists?  It seems like this
>> is a perfect discussion for linux-i2c.
>>
>>
>>> According to i2c-bus specification(version2.1, page 32, Table5, FAST-MODE):
>>> The minimum LOW period of the scl clock is <1.3us>, and the minimum HIGH
>>> period of the scl clock is <0.6us>.
>>> T(min_low) : T(min_high)  ~= 2 : 1
>>>
>>> If  in fast mode(scl rate = 400Khz)
>>> 1)Under ideal conditions, T(scl_low) = T(scl_high) = <1.25us>
>>> 2)Our measurement, T(scl_low) = <1.3us>, T(scl_high) = <1.25us>
>>>
>>> The low period of the scl clock is critical.
>>>
>>> Do we need set   to increase T(scl_low)?   // T(scl_low )
>>> : T(scl_High) = 2 : 1
>>
>> I can't say I've ever looked at that pat of the i2c spec before, but
>> what you say seems reasonable to me.  ...well for 400kHz, at least.
>> At 100kHz you shouldn't use the same 2:1 ratio.
>
> Yes, in normal-mode(100K) we can be only used 1:1 ratio.
> But in FAST-MODE maybe we must use 2:1 ratio.
> 
> In Table 5(Characteristics of the SDA and SCL bus lines for F/S-mode I2C-bus 
> devices)
>
> 1)FAST-MODE(400K):
>   The minimum LOW period of the scl clock1.3us
>   the minimum HIGH period of the scl clock   0.6us
>   T(min_low) : T(min_high)  ~= 2 : 1
>
>   But I can't see any ratio about In FAST-mode(400k) and Normal-mode(100k).
> 2)Normal-MODE(100K):
>   The minimum LOW period of the scl clock4.7us
>   the minimum HIGH period of the scl clock   4.0us
>   T(min_low) : T(min_high)  ~= 1 : 1

You might as well do the math all the way correctly.  That is for
clock > 100kHz use 47 / 87 and 40 / 87.  For clock <= 100kHz use 13 /
19 and 6 / 19

I think that'll give us a max margin, or (given perfect precision):
* a low of 5.4us (10 * 47 / 87.) and a high of 4.6us (10 * 40 / 87.) for 100kHz
* a low of 1.7us and a high of .8us for 400kHz


> 3) HS-mode(3.4M)
>   ratio of 1 to 2 is required, decribed as follows:
>   Hs-mode master devices generate a serial clock signal with a HIGH to LOW 
> ratio of 1 to 2

You forgot about Fast Mode Plus!  ;)  You should probably think of
that before High Speed (IMHO)...

...seriously, though, I think you should send up a patch to do 400kHz
right first, then worry about fast mode plus and high speed.  I
haven't read through the whole i2c-rk3x.c driver, but I can't quite
believe that HS mode is supported right now.  It requires a whole
bunch of extra negotiation.


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


Hello

2014-09-17 Thread Heather Walker
I am Heather Walker,This is my Third Email to you,I am at the end of the
road, and about to donate a huge amount through you. I promise that your
assistance would be rewarded. Please reply back to me for more
information. Remain Blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


linux-next: manual merge of the kvm-arm tree with the kvm tree

2014-09-17 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/arm/vgic.c between commit c06a841bf363 ("KVM: ARM: vgic:
register kvm_device_ops dynamically") from the kvm tree and commit
de56fb1923ca ("KVM: vgic: declare probe function pointer as const")
from the kvm-arm 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 virt/kvm/arm/vgic.c
index 3ee3ce06bbec,efe6eee2e7eb..
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -1993,81 -2070,3 +1993,81 @@@ static struct kvm_device_ops kvm_arm_vg
.get_attr = vgic_get_attr,
.has_attr = vgic_has_attr,
  };
 +
 +static void vgic_init_maintenance_interrupt(void *info)
 +{
 +  enable_percpu_irq(vgic->maint_irq, 0);
 +}
 +
 +static int vgic_cpu_notify(struct notifier_block *self,
 + unsigned long action, void *cpu)
 +{
 +  switch (action) {
 +  case CPU_STARTING:
 +  case CPU_STARTING_FROZEN:
 +  vgic_init_maintenance_interrupt(NULL);
 +  break;
 +  case CPU_DYING:
 +  case CPU_DYING_FROZEN:
 +  disable_percpu_irq(vgic->maint_irq);
 +  break;
 +  }
 +
 +  return NOTIFY_OK;
 +}
 +
 +static struct notifier_block vgic_cpu_nb = {
 +  .notifier_call = vgic_cpu_notify,
 +};
 +
 +static const struct of_device_id vgic_ids[] = {
 +  { .compatible = "arm,cortex-a15-gic", .data = vgic_v2_probe, },
 +  { .compatible = "arm,gic-v3", .data = vgic_v3_probe, },
 +  {},
 +};
 +
 +int kvm_vgic_hyp_init(void)
 +{
 +  const struct of_device_id *matched_id;
-   int (*vgic_probe)(struct device_node *,const struct vgic_ops **,
++  const int (*vgic_probe)(struct device_node *,const struct vgic_ops **,
 +const struct vgic_params **);
 +  struct device_node *vgic_node;
 +  int ret;
 +
 +  vgic_node = of_find_matching_node_and_match(NULL,
 +  vgic_ids, _id);
 +  if (!vgic_node) {
 +  kvm_err("error: no compatible GIC node found\n");
 +  return -ENODEV;
 +  }
 +
 +  vgic_probe = matched_id->data;
 +  ret = vgic_probe(vgic_node, _ops, );
 +  if (ret)
 +  return ret;
 +
 +  ret = request_percpu_irq(vgic->maint_irq, vgic_maintenance_handler,
 +   "vgic", kvm_get_running_vcpus());
 +  if (ret) {
 +  kvm_err("Cannot register interrupt %d\n", vgic->maint_irq);
 +  return ret;
 +  }
 +
 +  ret = __register_cpu_notifier(_cpu_nb);
 +  if (ret) {
 +  kvm_err("Cannot register vgic CPU notifier\n");
 +  goto out_free_irq;
 +  }
 +
 +  /* Callback into for arch code for setup */
 +  vgic_arch_setup(vgic);
 +
 +  on_each_cpu(vgic_init_maintenance_interrupt, NULL, 1);
 +
 +  return kvm_register_device_ops(_arm_vgic_v2_ops,
 + KVM_DEV_TYPE_ARM_VGIC_V2);
 +
 +out_free_irq:
 +  free_percpu_irq(vgic->maint_irq, kvm_get_running_vcpus());
 +  return ret;
 +}


signature.asc
Description: PGP signature


Re: [PATCH v3 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

2014-09-17 Thread Vivek Gautam
Hi Alan,


On Wed, Sep 17, 2014 at 8:27 PM, Alan Stern  wrote:
> On Wed, 17 Sep 2014, Vivek Gautam wrote:
>
>> Now that we have completely moved from older USB-PHY drivers
>> to newer GENERIC-PHY drivers for PHYs available with USB controllers
>> on Exynos series of SoCs, we can remove the support for the same
>> in our host drivers too.
>>
>> Signed-off-by: Vivek Gautam 
>
> I don't see why you made your changes in this awkward way.  For
> instance...
>
>> @@ -59,49 +54,39 @@ static int exynos_ehci_get_phy(struct device *dev,
>>  {
>>   struct device_node *child;
>>   struct phy *phy;
>> - int phy_number;
>> - int ret = 0;
>> + int phy_num;
>
> Why rename this variable?  Wasn't the original name good enough?

fair enough, don't need to rename the variable.

>
>> + int ret;
>>
>>   for_each_available_child_of_node(dev->of_node, child) {
>> - ret = of_property_read_u32(child, "reg", _number);
>> + ret = of_property_read_u32(child, "reg", _num);
>>   if (ret) {
>>   dev_err(dev, "Failed to parse device tree\n");
>>   of_node_put(child);
>>   return ret;
>>   }
>>
>> - if (phy_number >= PHY_NUMBER) {
>> + if (phy_num >= PHY_NUMBER) {
>>   dev_err(dev, "Invalid number of PHYs\n");
>>   of_node_put(child);
>>   return -EINVAL;
>>   }
>>
>> - phy = devm_of_phy_get(dev, child, NULL);
>> + exynos_ehci->phy[phy_num] = devm_of_phy_get(dev, child, NULL);
>> + phy = exynos_ehci->phy[phy_num];
>
> Why make two changes, resulting in more code, when you could have made
> just one change?
>
> phy = devm_of_phy_get(dev, child, NULL);
> +   exynos_ehci->phy[phy_num] = phy;

Right. i don't know what state of mind i was in while making these changes.
i should have kept the changes to minimal.

>
> Also, the patch description should mention that you are adding support
> for EPROBE_DEFER.

Sure, will add that description.




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


Re: [PATCH 07/24] ARM64:ILP32: Use the same size and layout of the signal structures for ILP32 as for LP64

2014-09-17 Thread zhangjian
On 2014/9/4 5:19, Andrew Pinski wrote:
> Defines the macros which allow the signal structures to be the same between 
> ILP32 and LP64.
> 
> Signed-off-by: Andrew Pinski 
> ---
>  arch/arm64/include/uapi/asm/siginfo.h |   33 
>  arch/arm64/include/uapi/asm/signal.h  |   34 
> +
>  2 files changed, 67 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm64/include/uapi/asm/siginfo.h 
> b/arch/arm64/include/uapi/asm/siginfo.h
> index 5a74a08..c80c612 100644
> --- a/arch/arm64/include/uapi/asm/siginfo.h
> +++ b/arch/arm64/include/uapi/asm/siginfo.h
> @@ -1,5 +1,6 @@
>  /*
>   * Copyright (C) 2012 ARM Ltd.
> + * Copyright (C) 2014 Cavium Inc.
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 as
> @@ -18,6 +19,38 @@
>  
>  #define __ARCH_SI_PREAMBLE_SIZE  (4 * sizeof(int))
>  
> +#ifdef __ILP32__
> +
> +/*
> + * For ILP32, the siginfo structures should share the same layout and
> + * alignement requirements as LP64 ABI.
> + * To do this, use an extra pad field and add aligned attribute
> + * to the structure.
> + */
> +
> +# ifdef __AARCH64EB__
> +#  define __SIGINFO_INNER(type, field)   \
> + int __pad#field;\
> + type field
> +# else
> +#  define __SIGINFO_INNER(type, field)   \
> + type field; \
> + int __pad#field
> +# endif
> +
> +# undef __SIGINFO_VOIDPTR
> +# define __SIGINFO_VOIDPTR(field)\
> + __SIGINFO_INNER(void __user*, field)
> +# undef __SIGINFO_BAND
> +
> +# define __SIGINFO_BAND(field)   \
> + __SIGINFO_INNER(long, field)
> +
> +/* Make the alignment of siginfo always 8 byte aligned. */
> +#define __ARCH_SI_ATTRIBUTES __attribute__((aligned(8)))
> +
> +#endif
> +
>  #include 
>  
>  #endif
> diff --git a/arch/arm64/include/uapi/asm/signal.h 
> b/arch/arm64/include/uapi/asm/signal.h
> index 8d1e723..d33a5f7 100644
> --- a/arch/arm64/include/uapi/asm/signal.h
> +++ b/arch/arm64/include/uapi/asm/signal.h
> @@ -16,9 +16,43 @@
>  #ifndef __ASM_SIGNAL_H
>  #define __ASM_SIGNAL_H
>  
> +#include 
typos here, it should be
#include 
> +
>  /* Required for AArch32 compatibility. */
>  #define SA_RESTORER  0x0400
>  
> +/*
> + * Since sigset is a bitmask, we need the same size fields for ILP32
> + * and LP64.  With big-endian, 32bit bitmask does not match up to
> + * 64bit bitmask (unlike with little-endian).
> + */
> +#ifdef __ILP32__
> +
> +#define __SIGSET_INNER_TYPE __kernel_ulong_t
> +#define _NSIG_BPW 64
> +
> +# ifdef __AARCH64EB__
> +#  define __SIGNAL_INNER(type, field)\
> + int __pad_##field;  \
> + type field;
> +# else
> +#  define __SIGNAL_INNER(type, field)\
> + type field; \
> + int __pad_##field;
> +# endif
> +
> +# define __SIGACTION_HANDLER(field)  \
> + __SIGNAL_INNER(__sighandler_t, field)
> +
> +
> +#define __SIGACTION_FLAGS(field) \
> + __kernel_ulong_t field
> +
> +#define __SIGACTION_RESTORER(field)  \
> + __SIGNAL_INNER(__sigrestore_t, field)
> +
> +#endif
> +
>  #include 
>  
>  #endif
> 


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


Re: [PATCH 1/2] regulator: st-pwm: get voltage and duty table from dts

2014-09-17 Thread Doug Anderson
Chris,

On Wed, Sep 17, 2014 at 6:37 PM, Chris Zhong  wrote:
>> Chris: please change the order and make sure Mark is CCed on the
>> bindings.  Probably anyone CCed on the code change should be on the
>> bindings change (and probably vice versa, but maybe not as critical).
>>
>> -Doug
>>
>>
> Thanks.
> I should not only use patman's script to created cc list.

Yup, patman relies on get_maintainer and that's not perfect.  I tend
to rely heavily on it but it's good to sanity check...


Speaking of which: Lee, do you think it would be a good idea to add
yourself as a MAINTAINER for st-pwm?

  (next-20140917))$ ./scripts/get_maintainer.pl -f drivers/regulator/st-pwm.c
  Liam Girdwood  (supporter:VOLTAGE AND CURRE...)
  Mark Brown  (supporter:VOLTAGE AND CURRE...)
  Grant Likely  (maintainer:OPEN FIRMWARE AND...)
  Rob Herring  (maintainer:OPEN FIRMWARE AND...)
  linux-kernel@vger.kernel.org (open list:VOLTAGE AND CURRE...)
  devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND...)


...ideally whatever rule added would also catch the bindings file when
Chris adds it.


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: syscon: Decouple syscon interface from platform devices

2014-09-17 Thread Dong Aisheng
On Thu, Sep 18, 2014 at 08:59:32AM +0530, Pankaj Dubey wrote:
> +CC: Dong Aisheng 
> 
> Hi Arnd,
> 
> On Wednesday, September 17, 2014, Arnd Bergmann wrote,
> > > V2 of this patchset and related discussion can be found here [1].
> > >
> > > Changes since v2:
> > >  - Added back platform device support from syscon, with one change that
> > >syscon will not be probed for DT based platform.
> > >  - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
> > >users of syscon will not be broken.
> > >  - Removed unwanted change in syscon.h.
> > >  - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
> > >Arnd Bergmann.
> > >  - Added Tested-by of Vivek Gautam for testing on Exynos platform.
> > 
> > Looks fine. Provided you can figure out the problem that Dong Aisheng
> reported,
> > please add my
> > 
> > Acked-by: Arnd Bergmann 
> >
> 
> Thanks. 
> After he reported I have again done code walk-through of regmap_init_mmio
> and 
> could not see any such fatal error.  At the same time I have replied to Dong
> Aisheng,
> asking for more details and waiting for his reply. 
>  

I just replied and gave the log.

Regards
Dong Aisheng

> > > -}
> > > +static struct syscon *of_syscon_register(struct device_node *np);
> > >
> > 
> > One  minor comment: please avoid doing forward declarations of local
> functions. It
> > took me a while to understand what is going on because I expect all
> functions to be
> > ordered such that they only get called by functions below, and don't need
> this.
> > 
> > Just move of_syscon_register() here directly.
> > 
> 
> OK, I will remove forward declaration of "of_syscon_register" and respin
> patch once again.
> 
> > Arnd
> 
> Thanks,
> Pankaj Dubey
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: syscon: Decouple syscon interface from platform devices

2014-09-17 Thread Dong Aisheng
On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
> Hi,
> 
> On Wednesday, September 17, 2014, Dong Aisheng Wrote,
> > >
> > > +static struct syscon *of_syscon_register(struct device_node *np) {
> > > + struct syscon *syscon;
> > > + struct regmap *regmap;
> > > + void __iomem *base;
> > > +
> > > + if (!of_device_is_compatible(np, "syscon"))
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
> > > + if (!syscon)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + base = of_iomap(np, 0);
> > > + if (!base)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + regmap = regmap_init_mmio(NULL, base, _regmap_config);
> > 
> > Does a NULL device pointer work?
> 
> Yes, it is safe, at least we are able to test on Exynos based SoC. 
> I have tested it with kgene/for-next kernel on Exynos3250.
> Also it has been tested on Exynos5250 based Snow board with 3.17-rc5 based
> kernel
> by Vivek Gautam. 
> 
> Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
> 
> 

The kernel i tested was next-20140915 of linux-next.

please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config *config)
{
struct device_node *np = dev->of_node;
enum regmap_endian endian;
...
}
It will crash at the first line of dev->of_node if dev is NULL.

Can you check if you're using the same code as mine?

> > I just tested on MX6SX SDB board and it seemed crashed at here in
> regmap_init
> > function.
> > 
> 
> Can you please provide crash log which can give more information about the
> crash?
> 

My crash log is:

[0.225148] Unable to handle kernel NULL pointer dereference at virtual 
address 01d4
[0.233383] pgd = 80004000
[0.236185] [01d4] *pgd=
[0.239873] Internal error: Oops: 5 [#1] SMP ARM
[0.244588] Modules linked in:
[0.247753] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
3.17.0-rc4-next-20140915-6-g8ba2dd0-dirty #421
[0.257342] task: bd878000 ti: bd88 task.ti: bd88
[0.262848] PC is at regmap_init+0x21c/0xab4
[0.267221] LR is at vprintk_emit+0x254/0x5e0
[0.271677] pc : [<80389420>]lr : [<8006a4f8>]psr: 6153
[0.271677] sp : bd881ae0  ip : bd881a48  fp : bd881b1c
[0.283354] r10:   r9 : bd8e1850  r8 : 0003
[0.288678] r7 :   r6 : 8098fccc  r5 : 8098ee0c  r4 : bd8f4e00
[0.295307] r3 : bd878000  r2 : 01e5  r1 : 806ee8f0  r0 : 808762c0
[0.301938] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment 
kernel
[0.309438] Control: 10c5387d  Table: 8000404a  DAC: 0015
[0.315284] Process swapper/0 (pid: 1, stack limit = 0xbd880240)
[0.321391] Stack: (0xbd881ae0 to 0xbd882000)
[0.325851] 1ae0: bd8e1850  bd881b1c bd881af8 8038f580 8098fccc 
 be7d49b8
[0.334136] 1b00: 8098fca4 bd917000 bd8e1850  bd881b34 bd881b20 
8038f68c 80389210
[0.342422] 1b20: bd91b480 8098fcc4 bd881b5c bd881b38 80398b24 8038f664 
 bd91ac10
[0.350708] 1b40: be7d4bc0 bd917010 bd917000 bd8e1850 bd881bac bd881b60 
803185a4 80398a54
[0.358993] 1b60: bd881b94 bd881b70     
 
[0.367277] 1b80:   bd917010 80983a64  bd916c10 
80983a64 
[0.375563] 1ba0: bd881bc4 bd881bb0 8037bb44 80318510 811c65f0 bd917010 
bd881bec bd881bc8
[0.383848] 1bc0: 8037a104 8037bb1c 80983a64 bd917010 8037a23c bd916c10 
 
[0.392134] 1be0: bd881c04 bd881bf0 8037a284 8037a004  bd917010 
bd881c2c bd881c08
[0.400419] 1c00: 80378614 8037a248 bd8038d8 bd8af7d4 bd916c10 bd917010 
bd917044 8098e308
[0.408704] 1c20: bd881c4c bd881c30 80379fb8 803785c0 bd803800 bd917018 
bd917010 8098e308
[0.416990] 1c40: bd881c6c bd881c50 8037961c 80379f48  bd917018 
 bd917010
[0.425275] 1c60: bd881ca4 bd881c70 80377904 80379598 bd881cc8 bd881cc0 
bd881cb8 bd881c88
[0.433560] 1c80: be7d4bc0 bd916c10  0001 bd917000 be7d4c10 
bd881cb4 bd881ca8
[0.441845] 1ca0: 804f1708 803774e8 bd881cfc bd881cb8 804f1f2c 804f16dc 
bd881cdc bd881cc8
[0.450130] 1cc0: 806b6d7c 80060478 809b0220 6153 bd881cfc  
be7d4bc0 
[0.458415] 1ce0: 0001 8070bb80 bd916c10  bd881d5c bd881d00 
804f2068 804f1e5c
[0.466700] 1d00: bd878000 a153 809b0220  bd881d2c bd881d20 
80060480 80060284
[0.474985] 1d20: bd881d44 bd881d30 806b6d7c 80060478  be7d4bc0 
be7d49b8 
[0.483270] 1d40: 0001 8070bb80 bd916c10  bd881dbc bd881d60 
804f20c4 804f1f8c
[0.491556] 1d60: 0001 6153 809b0220  bd881d8c bd881d80 
80060480 80060284
[0.499841] 1d80: bd881da4 bd881d90 806b6d7c 80060478 be7d46f8 be7d49b8 
be7cf764 

[PATCH] [trivial] wireless:rtlwifi: Fix typo in rtl wifi drivers

2014-09-17 Thread Masanari Iida
This patch fix spelling typo "sleeped" in printk, found in
multiple rtlwifi drivers.

Signed-off-by: Masanari Iida 
---
 drivers/net/wireless/rtlwifi/rtl8188ee/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8192ce/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8192cu/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8723ae/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8723be/phy.c | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
index 1cd6c16..3d689e8 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
@@ -2019,7 +2019,7 @@ static bool _rtl88ee_phy_set_rf_power_state(struct 
ieee80211_hw *hw,
  RT_RF_OFF_LEVL_HALT_NIC);
} else {
RT_TRACE(rtlpriv, COMP_RF, DBG_DMESG,
-"Set ERFON sleeped:%d ms\n",
+"Set ERFON slept:%d ms\n",
 jiffies_to_msecs(jiffies - ppsc->
  last_sleep_jiffies));
ppsc->last_awake_jiffies = jiffies;
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
index 98b2230..ac3ffa2 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
@@ -480,7 +480,7 @@ static bool _rtl92ce_phy_set_rf_power_state(struct 
ieee80211_hw *hw,
  RT_RF_OFF_LEVL_HALT_NIC);
} else {
RT_TRACE(rtlpriv, COMP_RF, DBG_DMESG,
-"Set ERFON sleeped:%d ms\n",
+"Set ERFON slept:%d ms\n",
 jiffies_to_msecs(jiffies -
  ppsc->
  last_sleep_jiffies));
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c
index 9831ff1..519d6e5 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c
@@ -437,7 +437,7 @@ static bool _rtl92cu_phy_set_rf_power_state(struct 
ieee80211_hw *hw,
  RT_RF_OFF_LEVL_HALT_NIC);
} else {
RT_TRACE(rtlpriv, COMP_RF, DBG_DMESG,
-"Set ERFON sleeped:%d ms\n",
+"Set ERFON slept:%d ms\n",
 jiffies_to_msecs(jiffies -
  ppsc->last_sleep_jiffies));
ppsc->last_awake_jiffies = jiffies;
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
index 592125a..7c02247 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
@@ -3121,7 +3121,7 @@ bool rtl92d_phy_set_rf_power_state(struct ieee80211_hw 
*hw,
  RT_RF_OFF_LEVL_HALT_NIC);
} else {
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG,
-"awake, sleeped:%d ms state_inap:%x\n",
+"awake, slept:%d ms state_inap:%x\n",
 jiffies_to_msecs(jiffies -
  ppsc->last_sleep_jiffies),
 rtlpriv->psc.state_inap);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
index 77c5b5f..6853ace 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
@@ -565,7 +565,7 @@ bool rtl92s_phy_set_rf_power_state(struct ieee80211_hw *hw,
  RT_RF_OFF_LEVL_HALT_NIC);
} else {
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG,
-"awake, sleeped:%d ms state_inap:%x\n",
+"awake, slept:%d ms state_inap:%x\n",
 jiffies_to_msecs(jiffies -
  ppsc->
  last_sleep_jiffies),
diff --git a/drivers/net/wireless/rtlwifi/rtl8723ae/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8723ae/phy.c
index 3ea78af..95f9902 100644
--- a/drivers/net/wireless/rtlwifi/rtl8723ae/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8723ae/phy.c
@@ -1486,7 +1486,7 @@ static bool 

RE: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices

2014-09-17 Thread Pankaj Dubey
+CC: Dong Aisheng 

Hi Arnd,

On Wednesday, September 17, 2014, Arnd Bergmann wrote,
> > V2 of this patchset and related discussion can be found here [1].
> >
> > Changes since v2:
> >  - Added back platform device support from syscon, with one change that
> >syscon will not be probed for DT based platform.
> >  - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
> >users of syscon will not be broken.
> >  - Removed unwanted change in syscon.h.
> >  - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
> >Arnd Bergmann.
> >  - Added Tested-by of Vivek Gautam for testing on Exynos platform.
> 
> Looks fine. Provided you can figure out the problem that Dong Aisheng
reported,
> please add my
> 
> Acked-by: Arnd Bergmann 
>

Thanks. 
After he reported I have again done code walk-through of regmap_init_mmio
and 
could not see any such fatal error.  At the same time I have replied to Dong
Aisheng,
asking for more details and waiting for his reply. 
 
> > -}
> > +static struct syscon *of_syscon_register(struct device_node *np);
> >
> 
> One  minor comment: please avoid doing forward declarations of local
functions. It
> took me a while to understand what is going on because I expect all
functions to be
> ordered such that they only get called by functions below, and don't need
this.
> 
> Just move of_syscon_register() here directly.
> 

OK, I will remove forward declaration of "of_syscon_register" and respin
patch once again.

>   Arnd

Thanks,
Pankaj Dubey

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/3] phy: exynos-dp-video: Use syscon support to control pmu register

2014-09-17 Thread Vivek Gautam
Hi Kishon,


On Wed, Sep 17, 2014 at 10:24 PM, Kishon Vijay Abraham I  wrote:
>
>
> On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
>> Currently the DP_PHY_ENABLE register is mapped in the driver,
>> and accessed to control power to the PHY.
>> With mfd-syscon and regmap interface available at our disposal,
>> it's wise to use that instead of using a 'reg' property for the
>> controller and allocating a memory resource for that.
>>
>> To facilitate this, we have added another compatible string
>> for Exynso5420 SoC to acquire driver data which contains
>> different DP-PHY-CONTROL register offset.
>>
>> Signed-off-by: Vivek Gautam 
>> Cc: Jingoo Han 
>> Cc: Kishon Vijay Abraham I 
>
> Taking this in linux-phy tree. If someone has already taken this patch, please
> let me know.

Thanks for taking this. But just one check, i think i need to separate
out the Documentation
to a separate patch even before this driver patch. Isn't it ?

>
> Thanks
> Kishon
>
>> ---
>>
>> Changes since v2:
>>  - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
>>since that's available with us in "linux/mfd/syscon/exynos5-pmu.h" file.
>>
>> Changes since v1:
>>  - state->regs should have been "struct regmap *" instead of
>>"void __iomem *". So corrected the same.
>>
>>  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>>  drivers/phy/phy-exynos-dp-video.c  |   79 
>> +---
>>  2 files changed, 59 insertions(+), 27 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index 7a6feea..15e0f2c 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
>>  -
>>
>>  Required properties:
>> -- compatible : should be "samsung,exynos5250-dp-video-phy";
>> -- reg : offset and length of the Display Port PHY register set;
>> +- compatible : should be one of the following supported values:
>> +  - "samsung,exynos5250-dp-video-phy"
>> +  - "samsung,exynos5420-dp-video-phy"
>> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
>> +   control pmu registers for power isolation.
>>  - #phy-cells : from the generic PHY bindings, must be 0;
>>
>>  Samsung S5P/EXYNOS SoC series USB PHY
>> diff --git a/drivers/phy/phy-exynos-dp-video.c 
>> b/drivers/phy/phy-exynos-dp-video.c
>> index 8b3026e..53f44a0 100644
>> --- a/drivers/phy/phy-exynos-dp-video.c
>> +++ b/drivers/phy/phy-exynos-dp-video.c
>> @@ -13,44 +13,55 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>> -/* DPTX_PHY_CONTROL register */
>> -#define EXYNOS_DPTX_PHY_ENABLE   (1 << 0)
>> +struct exynos_dp_video_phy_drvdata {
>> + u32 phy_ctrl_offset;
>> +};
>>
>>  struct exynos_dp_video_phy {
>> - void __iomem *regs;
>> + struct regmap *regs;
>> + const struct exynos_dp_video_phy_drvdata *drvdata;
>>  };
>>
>> -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int 
>> on)
>> +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
>> + unsigned int on)
>>  {
>> - u32 reg;
>> + unsigned int val;
>> +
>> + if (IS_ERR(state->regs))
>> + return;
>>
>> - reg = readl(state->regs);
>> - if (on)
>> - reg |= EXYNOS_DPTX_PHY_ENABLE;
>> - else
>> - reg &= ~EXYNOS_DPTX_PHY_ENABLE;
>> - writel(reg, state->regs);
>> + val = on ? 0 : EXYNOS5_PHY_ENABLE;
>>
>> - return 0;
>> + regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
>> +EXYNOS5_PHY_ENABLE, val);
>>  }
>>
>>  static int exynos_dp_video_phy_power_on(struct phy *phy)
>>  {
>>   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>
>> - return __set_phy_state(state, 1);
>> + /* Disable power isolation on DP-PHY */
>> + exynos_dp_video_phy_pwr_isol(state, 0);
>> +
>> + return 0;
>>  }
>>
>>  static int exynos_dp_video_phy_power_off(struct phy *phy)
>>  {
>>   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>
>> - return __set_phy_state(state, 0);
>> + /* Enable power isolation on DP-PHY */
>> + exynos_dp_video_phy_pwr_isol(state, 1);
>> +
>> + return 0;
>>  }
>>
>>  static struct phy_ops exynos_dp_video_phy_ops = {
>> @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
>>   .owner  = THIS_MODULE,
>>  };
>>
>> +static const struct exynos_dp_video_phy_drvdata exynos5250_dp_video_phy = {
>> + .phy_ctrl_offset= EXYNOS5_DPTX_PHY_CONTROL,
>> +};
>> +
>> +static const struct exynos_dp_video_phy_drvdata exynos5420_dp_video_phy = {
>> +  

[RFC PATCH 0/3] Early boot self tests for RCU

2014-09-17 Thread Pranith Kumar
Hi Paul,

Please find the following patches which enable RCU early boot tests. For now
all we do in these tests are enqueue test callbacks and check if they are being
invoked or not.

I was able to reproduce the hang which Amit reported after reverting the fix. So
this should catch such errors if they occur in the future.

I enabled the selftests in a few rcutorture configurations.

Thanks!
--
Pranith

Pranith Kumar (3):
  rcu: Add early boot self tests
  doc: Document RCU self test boot params
  rcutorture: Enable RCU self test in configs

 Documentation/kernel-parameters.txt| 12 +++
 kernel/rcu/rcu.h   |  2 +
 kernel/rcu/tiny.c  |  4 +-
 kernel/rcu/tree.c  |  2 +
 kernel/rcu/update.c| 91 ++
 .../selftests/rcutorture/configs/rcu/TINY02|  2 +
 .../selftests/rcutorture/configs/rcu/TINY02.boot   |  2 +
 .../selftests/rcutorture/configs/rcu/TREE05.boot   |  1 +
 .../selftests/rcutorture/configs/rcu/TREE06.boot   |  4 +
 .../selftests/rcutorture/configs/rcu/TREE08|  2 +
 .../selftests/rcutorture/configs/rcu/TREE08.boot   |  2 +
 11 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot

-- 
2.1.0

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


[RFC PATCH 0/3] Early boot self tests for RCU

2014-09-17 Thread Pranith Kumar
Hi Paul,

Please find the following patches which enable RCU early boot tests. For now
all we do in these tests are enqueue test callbacks and check if they are being
invoked or not.

I was able to reproduce the hang which Amit reported after reverting the fix. So
this should catch such errors if they occur in the future.

I enabled the selftests in a few rcutorture configurations.

Thanks!
--
Pranith

Pranith Kumar (3):
  rcu: Add early boot self tests
  doc: Document RCU self test boot params
  rcutorture: Enable RCU self test in configs

 Documentation/kernel-parameters.txt| 12 +++
 kernel/rcu/rcu.h   |  2 +
 kernel/rcu/tiny.c  |  4 +-
 kernel/rcu/tree.c  |  2 +
 kernel/rcu/update.c| 91 ++
 .../selftests/rcutorture/configs/rcu/TINY02|  2 +
 .../selftests/rcutorture/configs/rcu/TINY02.boot   |  2 +
 .../selftests/rcutorture/configs/rcu/TREE05.boot   |  1 +
 .../selftests/rcutorture/configs/rcu/TREE06.boot   |  4 +
 .../selftests/rcutorture/configs/rcu/TREE08|  2 +
 .../selftests/rcutorture/configs/rcu/TREE08.boot   |  2 +
 11 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot

-- 
2.1.0

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


[RFC PATCH 3/3] rcutorture: Enable RCU self test in configs

2014-09-17 Thread Pranith Kumar
Add config and boot parameters to enable the self tests in rcutorture testing.

Signed-off-by: Pranith Kumar 
---
 tools/testing/selftests/rcutorture/configs/rcu/TINY02  | 2 ++
 tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot | 2 ++
 tools/testing/selftests/rcutorture/configs/rcu/TREE05.boot | 1 +
 tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot | 4 
 tools/testing/selftests/rcutorture/configs/rcu/TREE08  | 2 ++
 tools/testing/selftests/rcutorture/configs/rcu/TREE08.boot | 2 ++
 6 files changed, 13 insertions(+)
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot

diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TINY02 
b/tools/testing/selftests/rcutorture/configs/rcu/TINY02
index f4feaee..36e41df 100644
--- a/tools/testing/selftests/rcutorture/configs/rcu/TINY02
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TINY02
@@ -7,6 +7,8 @@ CONFIG_HZ_PERIODIC=y
 CONFIG_NO_HZ_IDLE=n
 CONFIG_NO_HZ_FULL=n
 CONFIG_RCU_TRACE=y
+CONFIG_PROVE_LOCKING=y
+CONFIG_PROVE_RCU=y
 CONFIG_DEBUG_LOCK_ALLOC=y
 CONFIG_DEBUG_OBJECTS_RCU_HEAD=n
 CONFIG_PREEMPT_COUNT=y
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot 
b/tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot
new file mode 100644
index 000..0f08027
--- /dev/null
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot
@@ -0,0 +1,2 @@
+rcupdate.rcu_self_test=1
+rcupdate.rcu_self_test_bh=1
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TREE05.boot 
b/tools/testing/selftests/rcutorture/configs/rcu/TREE05.boot
index 3b42b8b..15b3e1a 100644
--- a/tools/testing/selftests/rcutorture/configs/rcu/TREE05.boot
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TREE05.boot
@@ -1 +1,2 @@
 rcutorture.torture_type=sched
+rcupdate.rcu_self_test_sched=1
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot 
b/tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot
new file mode 100644
index 000..0436e07
--- /dev/null
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot
@@ -0,0 +1,4 @@
+rcupdate.rcu_self_test=1
+rcupdate.rcu_self_test_bh=1
+rcupdate.rcu_self_test_sched=1
+rcupdate.rcu_self_test_srcu=1
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TREE08 
b/tools/testing/selftests/rcutorture/configs/rcu/TREE08
index 316aa6c..1a9303d 100644
--- a/tools/testing/selftests/rcutorture/configs/rcu/TREE08
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TREE08
@@ -18,6 +18,8 @@ CONFIG_RCU_FANOUT_LEAF=2
 CONFIG_RCU_NOCB_CPU=y
 CONFIG_RCU_NOCB_CPU_ALL=y
 CONFIG_DEBUG_LOCK_ALLOC=n
+CONFIG_PROVE_LOCKING=y
+CONFIG_PROVE_RCU=y
 CONFIG_RCU_CPU_STALL_INFO=n
 CONFIG_RCU_BOOST=n
 CONFIG_DEBUG_OBJECTS_RCU_HEAD=n
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TREE08.boot 
b/tools/testing/selftests/rcutorture/configs/rcu/TREE08.boot
index 3b42b8b..2561daf 100644
--- a/tools/testing/selftests/rcutorture/configs/rcu/TREE08.boot
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TREE08.boot
@@ -1 +1,3 @@
 rcutorture.torture_type=sched
+rcupdate.rcu_self_test=1
+rcupdate.rcu_self_test_sched=1
-- 
2.1.0

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


[RFC PATCH 2/3] doc: Document RCU self test boot params

2014-09-17 Thread Pranith Kumar
Document the RCU self test boot parameters in kernel-parameters.txt.

Signed-off-by: Pranith Kumar 
---
 Documentation/kernel-parameters.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index c403957..6f5c01b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3054,6 +3054,18 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
messages.  Disable with a value less than or equal
to zero.
 
+   rcupdate.rcu_self_test= [KNL]
+   Run the RCU early boot self tests
+
+   rcupdate.rcu_self_test_bh= [KNL]
+   Run the RCU bh early boot self tests
+
+   rcupdate.rcu_self_test_sched= [KNL]
+   Run the RCU sched early boot self tests
+
+   rcupdate.rcu_self_test_srcu= [KNL]
+   Run the SRCU early boot self tests
+
rdinit= [KNL]
Format: 
Run specified binary instead of /init from the ramdisk,
-- 
2.1.0

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


[RFC PATCH 1/3] rcu: Add early boot self tests

2014-09-17 Thread Pranith Kumar
Add early boot self tests for RCU under CONFIG_PROVE_RCU.

Currently the only test is adding a dummy callback which increments a counter
which we then later verify after calling rcu_barrier*().

Signed-off-by: Pranith Kumar 
---
 kernel/rcu/rcu.h|  2 ++
 kernel/rcu/tiny.c   |  4 ++-
 kernel/rcu/tree.c   |  2 ++
 kernel/rcu/update.c | 91 +
 4 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index ff1a6de..07bb02e 100644
--- a/kernel/rcu/rcu.h
+++ b/kernel/rcu/rcu.h
@@ -135,4 +135,6 @@ int rcu_jiffies_till_stall_check(void);
  */
 #define TPS(x)  tracepoint_string(x)
 
+void rcu_early_boot_tests(void);
+
 #endif /* __LINUX_RCU_H */
diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
index c0623fc..d3d44c5 100644
--- a/kernel/rcu/tiny.c
+++ b/kernel/rcu/tiny.c
@@ -380,7 +380,9 @@ void call_rcu_bh(struct rcu_head *head, void (*func)(struct 
rcu_head *rcu))
 }
 EXPORT_SYMBOL_GPL(call_rcu_bh);
 
-void rcu_init(void)
+void __init rcu_init(void)
 {
open_softirq(RCU_SOFTIRQ, rcu_process_callbacks);
+
+   rcu_early_boot_tests();
 }
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index e4c6d60..f93a62c 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3766,6 +3766,8 @@ void __init rcu_init(void)
pm_notifier(rcu_pm_notify, 0);
for_each_online_cpu(cpu)
rcu_cpu_notify(NULL, CPU_UP_PREPARE, (void *)(long)cpu);
+
+   rcu_early_boot_tests();
 }
 
 #include "tree_plugin.h"
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 3ef8ba5..5929f0c 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -690,3 +690,94 @@ static void rcu_spawn_tasks_kthread(void)
 }
 
 #endif /* #ifdef CONFIG_TASKS_RCU */
+
+#ifdef CONFIG_PROVE_RCU
+
+/*
+ * Early boot self test parameters, one for each flavor
+ */
+static bool rcu_self_test;
+static bool rcu_self_test_bh;
+static bool rcu_self_test_sched;
+static bool rcu_self_test_srcu;
+
+module_param(rcu_self_test, bool, 0444);
+module_param(rcu_self_test_bh, bool, 0444);
+module_param(rcu_self_test_sched, bool, 0444);
+module_param(rcu_self_test_srcu, bool, 0444);
+
+static int rcu_self_test_counter;
+static struct rcu_head head;
+DEFINE_STATIC_SRCU(srcu_struct);
+
+static void test_callback(struct rcu_head *r)
+{
+   rcu_self_test_counter++;
+   pr_info("RCU test callback executed %d\n", rcu_self_test_counter);
+}
+
+static void early_boot_test_call_rcu(void)
+{
+   call_rcu(, test_callback);
+}
+
+static void early_boot_test_call_rcu_bh(void)
+{
+   call_rcu_bh(, test_callback);
+}
+
+static void early_boot_test_call_rcu_sched(void)
+{
+   call_rcu_sched(, test_callback);
+}
+
+static void early_boot_test_call_srcu(void)
+{
+   call_srcu(_struct, , test_callback);
+}
+
+void rcu_early_boot_tests(void)
+{
+   pr_info("Running RCU self tests\n");
+
+   if (rcu_self_test)
+   early_boot_test_call_rcu();
+   if (rcu_self_test_bh)
+   early_boot_test_call_rcu_bh();
+   if (rcu_self_test_sched)
+   early_boot_test_call_rcu_sched();
+   if (rcu_self_test_srcu)
+   early_boot_test_call_srcu();
+}
+
+static int rcu_verify_early_boot_tests(void)
+{
+   int ret = 0;
+   int early_boot_test_counter = 0;
+
+   if (rcu_self_test) {
+   early_boot_test_counter++;
+   rcu_barrier();
+   }
+   if (rcu_self_test_bh) {
+   early_boot_test_counter++;
+   rcu_barrier_bh();
+   }
+   if (rcu_self_test_sched) {
+   early_boot_test_counter++;
+   rcu_barrier_sched();
+   }
+   if (rcu_self_test_srcu) {
+   early_boot_test_counter++;
+   srcu_barrier(_struct);
+   }
+
+   if (rcu_self_test_counter != early_boot_test_counter)
+   ret = -1;
+
+   return ret;
+}
+late_initcall(rcu_verify_early_boot_tests);
+#else
+void rcu_early_boot_tests(void) {}
+#endif /* CONFIG_PROVE_RCU */
-- 
2.1.0

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


RE: [PATCH v2 3/4] net: stmmac: add support for Intel Quark X1000 [RESEND TO MAILING LIST]

2014-09-17 Thread Kweh, Hock Leong
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Wednesday, September 17, 2014 12:56 PM
> From: "Kweh, Hock Leong" 
> Date: Wed, 17 Sep 2014 02:41:39 +
> 
> > Thanks for the pointer. I did a quickly checking on the class number 
> > to see if I could use it for differentiation the ports number. 
> > Whereas I found them both have the same class number as well. Below 
> > shows the "lspci" dump to all the PCI devices on Quark X1000 Galileo 
> > board (Ethernet controllers are
> > 00:14.6 and 00:14.7). Very unfortunately we are unlikely to use the 
> > class number as well as pci_device_id for the differentiation.
>  ...
> > 00:14.6 "Class 0200" "8086" "0937" "8086" "0937"
> > 00:14.7 "Class 0200" "8086" "0937" "8086" "0937"
> 
> Are you kidding me?  It's a perfect way to identify this device, it 
> properly uses PCI_CLASS_NETWORK_ETHERNET (0x0200) in both cases and 
> this will not match any other function on this PCI device at all.
> 
> Please do as I suggested and use the PCI class for the differentiation 
> and matching during probing.

Hi David,

Thanks for your feedback so far. Appreciate it.

Sorry to my poorly written description that may have caused some confusion. My 
sincere apology here. 
Unfortunately, I don't really grasp your idea clearly based on your responses 
which I appreciate them a lot. 
Sorry for the long description below but I hope to clearly pen down my thinking 
process so that you can follow my thinking incrementally without being confused.

So, let's roll back a bit so that with my following description, you can help 
correct me if my understanding of using PCI function ID to differentiate PHY 
port that is associated with each Ethernet controller is wrong:

The high-level idea about the change that I made for STMMAC IP inside Quark is 
as follow:

(1) Based on Quark-specific PCI ID declared inside stmmac_id_table[],  the 
probe() function is
   called to continue setting-up STMMAC for Quark.

@@ -228,11 +303,13 @@ static int stmmac_pci_resume(struct pci_dev *pdev)
 
 #define STMMAC_VENDOR_ID 0x700
 #define STMMAC_DEVICE_ID 0x1108
+#define STMMAC_QUARK_X1000_ID 0x0937
 
 static const struct pci_device_id stmmac_id_table[] = {
{PCI_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID), PCI_ANY_ID,
PCI_ANY_ID, CHIP_STMICRO},
{PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_MAC), CHIP_STMICRO},
+   {PCI_VDEVICE(INTEL, STMMAC_QUARK_X1000_ID), CHIP_QUARK_X1000},
{}
 };

(2) Back-ground on STMMAC hardware configuration on Intel Galileo Gen 1 & Gen 2 
platforms:
Intel Quark SoC has 2 MAC controller as described by lspci output below:

00:14.6 Class 0200: 8086:0937> 1st MAC controller
00:14.7 Class 0200: 8086:0937> 2nd MAC controller

These Galileo boards use the same Intel Quark SoC and there is only one PHY 
connect to the 1st MAC [00:14.6 Class 0200: 8086:0937] The 2nd MAC [00:14.7 
Class 0200: 8086:0937] is NOT connected to any PHY at all.

So, it appears to me that the only way that I can differentiate between 1st & 
2nd MAC are based on PCI function ID, i.e. 14.6 & 14.7. Therefore, within the 
probe() function, for Intel Quark SoC only, the function performs next-level 
discovery of 1st or 2nd MAC controller through quark_run_time_config() 
function. 
For other PCI ID (currently STMICRO_MAC) there is NO next-level discovery 
involved as rt_config is NULL.
Changes shown below:

static struct platform_data platform_info[] = { @@ -59,15 +65,76 @@ static 
struct platform_data platform_info[] = {
.phy_reset = NULL,
.phy_mask = 0,
.pbl = 32,
+   .fixed_burst = 0,
.burst_len = DMA_AXI_BLEN_256,
+   .rt_config = NULL,  ===> no 2nd-level discovery 
for other PCI ID 
+   },
+   [CHIP_QUARK_X1000] = {
+   .phy_addr = 1,
+   .interface = PHY_INTERFACE_MODE_RMII,
+   .clk_csr = 2,
+   .has_gmac = 1,
+   .force_sf_dma_mode = 1,
+   .multicast_filter_bins = HASH_TABLE_SIZE,
+   .unicast_filter_entries = 1,
+   .phy_reset = NULL,
+   .phy_mask = 0,
+   .pbl = 16,
+   .fixed_burst = 1,
+   .burst_len = DMA_AXI_BLEN_256,
+   .rt_config = _run_time_config,   ==> Quark 
specific 2nd-level discovery
+   },
+};

(3) Within quark_run_time_config(), due to the only way to differentiate 1st or 
2nd MAC controller according to difference in function ID explained above, the 
following changes are made:

+static void quark_run_time_config(int chip_id, struct pci_dev *pdev) {
+   const char *board_name = dmi_get_system_info(DMI_BOARD_NAME);
+   int i;
+   int func_num = PCI_FUNC(pdev->devfn);
+
+   if (!board_name)
+   return;
+
+   for (i = 0; i < ARRAY_SIZE(quark_x1000_phy_info); i++) {
+  

Re: [PATCH 0/9] powerpc/powernv: Support for fastsleep and winkle

2014-09-17 Thread Shreyas B Prabhu
Hi,

In this patch series we use winkle for offlined cores. I successfully
tested the working of this with subcore functionality.

Test scenario was as follows:
1. Set SMT mode to 1, Set subores-per-core to 1
2. Offline a core, in this case cpu 32 (sending it to winkle)
3. Set subcores-per-core to 4
4. Online the core
5. Start a guest (Topology 1 core 2 threads) on a subcore, in this case
on cpu 36

This works without any glitch.

Thanks,
Shreyas

On Monday 25 August 2014 11:31 PM, Shreyas B. Prabhu wrote:
> Fast sleep is an idle state, where the core and the L1 and L2
> caches are brought down to a threshold voltage. This also means that
> the communication between L2 and L3 caches have to be fenced. However
> the current P8 chips have a bug wherein this fencing between L2 and
> L3 caches get delayed by a cpu cycle. This can delay L3 response to
> the other cpus if they request for data during this time. Thus they
> would fetch the same data from the memory which could lead to data
> corruption if L3 cache is not flushed.
> Patch 4 adds support to work around this.
> 
> 'Deep Winkle' is a deeper idle state where core and private L2 are powered
> off. While it offers higher power savings, it is at the cost of losing
> hypervisor register state and higher latency.
> Patch 5-9 adds support for winkle and uses it for offline cpus.
> 
> Patch 1 - Moves parameters required discover idle states to a location 
> common to both cpuidle driver and powernv core code
> Patch 2 - Populates idle state details from device tree
> Patch 3 - Enables cpus to run guest after waking up from fastsleep/winkle
> 
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Rafael J. Wysocki 
> Cc: Srivatsa S. Bhat 
> Cc: Preeti U. Murthy 
> Cc: Vaidyanathan Srinivasan 
> Cc: Rob Herring 
> Cc: Grant Likely 
> Cc: devicet...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> 
> Preeti U Murthy (2):
>   cpuidle/powernv: Populate cpuidle state details by querying the
> device-tree
>   powerpc/powernv/cpuidle: Add workaround to enable fastsleep
> 
> Shreyas B. Prabhu (6):
>   powerpc/kvm/book3s_hv: Enable CPUs to run guest after waking up from
> fast-sleep
>   powerpc/powernv: Add OPAL call to save and restore
>   powerpc: Adding macro for accessing Thread Switch Control Register
>   powerpc/powernv: Add winkle infrastructure
>   powerpc/powernv: Discover and enable winkle
>   powerpc/powernv: Enter deepest supported idle state in offline
> 
> Srivatsa S. Bhat (1):
>   powerpc/powernv: Enable Offline CPUs to enter deep idle states
> 
>  arch/powerpc/include/asm/machdep.h |   4 +
>  arch/powerpc/include/asm/opal.h|  10 ++
>  arch/powerpc/include/asm/paca.h|   3 +
>  arch/powerpc/include/asm/ppc-opcode.h  |   2 +
>  arch/powerpc/include/asm/processor.h   |   6 +-
>  arch/powerpc/include/asm/reg.h |   1 +
>  arch/powerpc/kernel/asm-offsets.c  |   1 +
>  arch/powerpc/kernel/exceptions-64s.S   |  37 ++---
>  arch/powerpc/kernel/idle.c |  30 
>  arch/powerpc/kernel/idle_power7.S  |  83 +-
>  arch/powerpc/platforms/powernv/opal-wrappers.S |   2 +
>  arch/powerpc/platforms/powernv/powernv.h   |   8 +
>  arch/powerpc/platforms/powernv/setup.c | 217 
> +
>  arch/powerpc/platforms/powernv/smp.c   |  13 +-
>  arch/powerpc/platforms/powernv/subcore.c   |  15 ++
>  drivers/cpuidle/cpuidle-powernv.c  |  40 -
>  16 files changed, 439 insertions(+), 33 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/


[PATCH] [trivial] treewide: Fix typos in Kconfig

2014-09-17 Thread Masanari Iida
This patch fix spelling typos found in Kconfig.

Signed-off-by: Masanari Iida 
---
 arch/blackfin/Kconfig   | 2 +-
 arch/mips/cavium-octeon/Kconfig | 2 +-
 drivers/i2c/busses/Kconfig  | 2 +-
 drivers/irqchip/Kconfig | 2 +-
 drivers/platform/x86/Kconfig| 8 
 drivers/usb/host/Kconfig| 2 +-
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index ed30699..af76634 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -671,7 +671,7 @@ config TICKSOURCE_CORETMR
default y
 endmenu
 
-menu "Clock souce"
+menu "Clock source"
depends on GENERIC_CLOCKEVENTS
 config CYCLES_CLOCKSOURCE
bool "CYCLES"
diff --git a/arch/mips/cavium-octeon/Kconfig b/arch/mips/cavium-octeon/Kconfig
index 6028666..c370426 100644
--- a/arch/mips/cavium-octeon/Kconfig
+++ b/arch/mips/cavium-octeon/Kconfig
@@ -1,7 +1,7 @@
 if CPU_CAVIUM_OCTEON
 
 config CAVIUM_CN63XXP1
-   bool "Enable CN63XXP1 errata worarounds"
+   bool "Enable CN63XXP1 errata workarounds"
default "n"
help
  The CN63XXP1 chip requires build time workarounds to
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..2e45ae3 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -357,7 +357,7 @@ config I2C_BCM_KONA
  If you say yes to this option, support will be included for the
  I2C interface on the Broadcom Kona family of processors.
 
- If you do not need KONA I2C inteface, say N.
+ If you do not need KONA I2C interface, say N.
 
 config I2C_BLACKFIN_TWI
tristate "Blackfin TWI I2C support"
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index b8632bf..a31a9e4 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -109,7 +109,7 @@ config XTENSA_MX
 config IRQ_CROSSBAR
bool
help
- Support for a CROSSBAR ip that preceeds the main interrupt controller.
+ Support for a CROSSBAR ip that precedes the main interrupt controller.
  The primary irqchip invokes the crossbar's callback which inturn 
allocates
  a free irq and configures the IP. Thus the peripheral interrupts are
  routed to one of the free irqchip interrupt lines.
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 3bbcbf1..4dd2cd8 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -540,7 +540,7 @@ config ASUS_NB_WMI
  This is a driver for newer Asus notebooks. It adds extra features
  like wireless radio and bluetooth control, leds, hotkeys, backlight...
 
- For more informations, see
+ For more information, see
  
 
  If you have an ACPI-WMI compatible Asus Notebook, say Y or M
@@ -553,7 +553,7 @@ config EEEPC_WMI
  This is a driver for newer Eee PC laptops. It adds extra features
  like wireless radio and bluetooth control, leds, hotkeys, backlight...
 
- For more informations, see
+ For more information, see
  
 
  If you have an ACPI-WMI compatible Eee PC laptop (>= 1000), say Y or M
@@ -657,7 +657,7 @@ config TOSHIBA_HAPS
depends on ACPI
---help---
  This driver adds support for the built-in accelerometer
- found on recent Toshiba laptops equiped with HID TOS620A
+ found on recent Toshiba laptops equipped with HID TOS620A
  device.
 
  This driver receives ACPI notify events 0x80 when the sensor
@@ -666,7 +666,7 @@ config TOSHIBA_HAPS
  been stabilized.
 
  Also provides sysfs entries to get/set the desired protection
- level and reseting the HDD protection interface.
+ level and resetting the HDD protection interface.
 
  If you have a recent Toshiba laptop with a built-in accelerometer
  device, say Y.
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 82800a7..56f4336 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -126,7 +126,7 @@ config XPS_USB_HCD_XILINX
select USB_EHCI_BIG_ENDIAN_DESC
select USB_EHCI_BIG_ENDIAN_MMIO
---help---
-   Xilinx xps USB host controller core is EHCI compilant and has
+   Xilinx xps USB host controller core is EHCI compliant and has
transaction translator built-in. It can be configured to either
support both high speed and full speed devices, or high speed
devices only.
-- 
2.1.0.238.gce1d3a9

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


Re: [PATCH v3 0/7] mtd: denali: A collection of trivial coding style fixes

2014-09-17 Thread Brian Norris
On Thu, Sep 18, 2014 at 11:31:35AM +0900, Masahiro Yamada wrote:
> On Wed, 17 Sep 2014 10:13:08 -0700 Brian Norris  
> wrote:
> > On Tue, Sep 16, 2014 at 08:04:18PM +0900, Masahiro Yamada wrote:
> > > Masahiro Yamada (7):
> > >   mtd: denali: fix the format of comment blocks
> > >   mtd: denali: remove unnecessary variable initializations
> > >   mtd: denali: remove unnecessary casts
> > >   mtd: denali: change the type of iterators to int
> > >   mtd: denali: remove a set-but-unused variable
> > >   mtd: denali: remove unnecessary parentheses
> > >   mtd: denali: fix indents and other trivial things
> > 
> > This series still doesn't apply to l2-mtd.git.
> 
> I resent the last three patches as v3.
> 
> v3 5/7 mtd: denali: remove a set-but-unused variable
> v3 6/7 mtd: denali: remove unnecessary parentheses
> v3 7/7 mtd: denali: fix indents and other trivial things
> 
> I confirmed they are applicable onto
> commit 93e3c8adf6fcf2204ca334237b92c7f8cdafce6f
> of l2-mtd.git
> 
> You said as follow:
> 
> On Mon, 15 Sep 2014 22:07:32 -0700
> Brian Norris  wrote:
> 
> > > Is there a chance for me to resend 5/7 to include this fix?
> > > Or is it too late?
> > 
> > Just send a new patch, please.

I mean "a new patch [on top of l2-mtd.git]", but I see that wasn't
clear.

> That's why I sent a new patch (v3 5/7) to replace
> commit 55ab9ec99bbfb4450dfa9bc0fd9e2c5052f4c3f7
> 
> 
> Did I do wrong?

Eh, just miscommunication from my end.

I don't like to back out patches for no good reason, but I suppose I can
back out patch 5/7 v2, and look at applying v3 instead.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: debug_dma_assert_idle - ohci - cpu touching an active dma mapped cacheline

2014-09-17 Thread poma
[ cut here ]
WARNING: CPU: 2 PID: 1065 at lib/dma-debug.c:593 
debug_dma_assert_idle+0x159/0x1d0()
ohci-pci :00:04.0: DMA-API: cpu touching an active dma mapped cacheline 
[cln=0x03004180]
CPU: 2 PID: 1065 Comm: tumblerd Not tainted 3.17.0-0.rc5.git1.1.fc22.i686 #1
Call Trace:
 [] dump_stack+0x48/0x60
 [] warn_slowpath_common+0x82/0xa0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] warn_slowpath_fmt+0x3e/0x60
 [] debug_dma_assert_idle+0x159/0x1d0
 [] ? anon_vma_prepare+0x29/0x140
 [] do_wp_page+0xe4/0x8c0
 [] handle_mm_fault+0x662/0xba0
 [] __do_page_fault+0x208/0x5d0
 [] ? vm_mmap_pgoff+0x9b/0xc0
 [] ? SyS_mmap_pgoff+0xe8/0x220
 [] ? trace_hardirqs_on_caller+0x13c/0x1e0
 [] ? __do_page_fault+0x5d0/0x5d0
 [] do_page_fault+0x1a/0x20
 [] error_code+0x6c/0x74
---[ end trace ce8b30fb8a3415c9 ]---
Mapped at:
 [] debug_dma_alloc_coherent+0x22/0x70
 [] ohci_init+0x22c/0x450
 [] ohci_setup+0x59/0x60
 [] ohci_pci_reset+0x4f/0x60
 [] usb_add_hcd+0x29a/0x8c0

$ lsusb -s 004:
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


poma


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


[PATCH 4/5] hw_random: don't double-check old_rng.

2014-09-17 Thread Rusty Russell
Interesting anti-pattern.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index b4a21e9521cf..6a34feca6b43 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -472,14 +472,13 @@ int hwrng_register(struct hwrng *rng)
}
 
old_rng = current_rng;
+   err = 0;
if (!old_rng) {
err = hwrng_init(rng);
if (err)
goto out_unlock;
set_current_rng(rng);
-   }
-   err = 0;
-   if (!old_rng) {
+
err = register_miscdev();
if (err) {
drop_current_rng();
-- 
1.9.1

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


[PATCH 3/5] hw_random: fix unregister race.

2014-09-17 Thread Rusty Russell
The previous patch added one potential problem: we can still be
reading from a hwrng when it's unregistered.  Add a wait for zero
in the hwrng_unregister path.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index dc9092a1075d..b4a21e9521cf 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -60,6 +60,7 @@ static DEFINE_MUTEX(rng_mutex);
 static DEFINE_MUTEX(reading_mutex);
 static int data_avail;
 static u8 *rng_buffer, *rng_fillbuf;
+static DECLARE_WAIT_QUEUE_HEAD(rng_done);
 static unsigned short current_quality;
 static unsigned short default_quality; /* = 0; default to "off" */
 
@@ -98,6 +99,7 @@ static inline void cleanup_rng(struct kref *kref)
 
if (rng->cleanup)
rng->cleanup(rng);
+   wake_up_all(_done);
 }
 
 static void set_current_rng(struct hwrng *rng)
@@ -529,6 +531,9 @@ void hwrng_unregister(struct hwrng *rng)
}
 
mutex_unlock(_mutex);
+
+   /* Just in case rng is reading right now, wait. */
+   wait_event(rng_done, atomic_read(>ref.refcount) == 0);
 }
 EXPORT_SYMBOL_GPL(hwrng_unregister);
 
-- 
1.9.1

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


[PATCH 2/5] hw_random: use reference counts on each struct hwrng.

2014-09-17 Thread Rusty Russell
current_rng holds one reference, and we bump it every time we want
to do a read from it.

This means we only hold the rng_mutex to grab or drop a reference,
so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't
block on read of /dev/hwrng.

Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.

This also solves the problem that the hwrng_fillfn thread was
accessing current_rng without a lock, which could change (eg. to NULL)
underneath it.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 135 --
 include/linux/hw_random.h |   2 +
 2 files changed, 94 insertions(+), 43 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index b1b6042ad85c..dc9092a1075d 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -91,6 +92,59 @@ static void add_early_randomness(struct hwrng *rng)
add_device_randomness(bytes, bytes_read);
 }
 
+static inline void cleanup_rng(struct kref *kref)
+{
+   struct hwrng *rng = container_of(kref, struct hwrng, ref);
+
+   if (rng->cleanup)
+   rng->cleanup(rng);
+}
+
+static void set_current_rng(struct hwrng *rng)
+{
+   BUG_ON(!mutex_is_locked(_mutex));
+   kref_get(>ref);
+   current_rng = rng;
+}
+
+static void drop_current_rng(void)
+{
+   BUG_ON(!mutex_is_locked(_mutex));
+   if (!current_rng)
+   return;
+
+   kref_put(_rng->ref, cleanup_rng);
+   current_rng = NULL;
+}
+
+/* Returns ERR_PTR(), NULL or refcounted hwrng */
+static struct hwrng *get_current_rng(void)
+{
+   struct hwrng *rng;
+
+   if (mutex_lock_interruptible(_mutex))
+   return ERR_PTR(-ERESTARTSYS);
+
+   rng = current_rng;
+   if (rng)
+   kref_get(>ref);
+
+   mutex_unlock(_mutex);
+   return rng;
+}
+
+static void put_rng(struct hwrng *rng)
+{
+   /*
+* Hold rng_mutex here so we serialize in case they set_current_rng
+* on rng again immediately.
+*/
+   mutex_lock(_mutex);
+   if (rng)
+   kref_put(>ref, cleanup_rng);
+   mutex_unlock(_mutex);
+}
+
 static inline int hwrng_init(struct hwrng *rng)
 {
if (rng->init) {
@@ -113,12 +167,6 @@ static inline int hwrng_init(struct hwrng *rng)
return 0;
 }
 
-static inline void hwrng_cleanup(struct hwrng *rng)
-{
-   if (rng && rng->cleanup)
-   rng->cleanup(rng);
-}
-
 static int rng_dev_open(struct inode *inode, struct file *filp)
 {
/* enforce read-only access to this chrdev */
@@ -154,21 +202,22 @@ static ssize_t rng_dev_read(struct file *filp, char 
__user *buf,
ssize_t ret = 0;
int err = 0;
int bytes_read, len;
+   struct hwrng *rng;
 
while (size) {
-   if (mutex_lock_interruptible(_mutex)) {
-   err = -ERESTARTSYS;
+   rng = get_current_rng();
+   if (IS_ERR(rng)) {
+   err = PTR_ERR(rng);
goto out;
}
-
-   if (!current_rng) {
+   if (!rng) {
err = -ENODEV;
-   goto out_unlock;
+   goto out;
}
 
mutex_lock(_mutex);
if (!data_avail) {
-   bytes_read = rng_get_data(current_rng, rng_buffer,
+   bytes_read = rng_get_data(rng, rng_buffer,
rng_buffer_size(),
!(filp->f_flags & O_NONBLOCK));
if (bytes_read < 0) {
@@ -200,7 +249,6 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
ret += len;
}
 
-   mutex_unlock(_mutex);
mutex_unlock(_mutex);
 
if (need_resched())
@@ -210,15 +258,16 @@ static ssize_t rng_dev_read(struct file *filp, char 
__user *buf,
err = -ERESTARTSYS;
goto out;
}
+
+   put_rng(rng);
}
 out:
return ret ? : err;
-out_unlock:
-   mutex_unlock(_mutex);
-   goto out;
+
 out_unlock_reading:
mutex_unlock(_mutex);
-   goto out_unlock;
+   put_rng(rng);
+   goto out;
 }
 
 
@@ -257,8 +306,8 @@ static ssize_t hwrng_attr_current_store(struct device *dev,
err = hwrng_init(rng);
if (err)
break;
-   hwrng_cleanup(current_rng);
-   current_rng = rng;
+   drop_current_rng();
+   set_current_rng(rng);
err = 0;
break;
}
@@ -272,17 +321,15 @@ static ssize_t 

[PATCH 1/5] hw_random: place mutex around read functions and buffers.

2014-09-17 Thread Rusty Russell
There's currently a big lock around everything, and it means that we
can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current)
while the rng is reading.  This is a real problem when the rng is slow,
or blocked (eg. virtio_rng with qemu's default /dev/random backend)

This doesn't help (it leaves the current lock untouched), just adds a
lock to protect the read function and the static buffers, in preparation
for transition.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aa30a25c8d49..b1b6042ad85c 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -53,7 +53,10 @@
 static struct hwrng *current_rng;
 static struct task_struct *hwrng_fill;
 static LIST_HEAD(rng_list);
+/* Protects rng_list and current_rng */
 static DEFINE_MUTEX(rng_mutex);
+/* Protects rng read functions, data_avail, rng_buffer and rng_fillbuf */
+static DEFINE_MUTEX(reading_mutex);
 static int data_avail;
 static u8 *rng_buffer, *rng_fillbuf;
 static unsigned short current_quality;
@@ -81,7 +84,9 @@ static void add_early_randomness(struct hwrng *rng)
unsigned char bytes[16];
int bytes_read;
 
+   mutex_lock(_mutex);
bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
+   mutex_unlock(_mutex);
if (bytes_read > 0)
add_device_randomness(bytes, bytes_read);
 }
@@ -128,6 +133,7 @@ static inline int rng_get_data(struct hwrng *rng, u8 
*buffer, size_t size,
int wait) {
int present;
 
+   BUG_ON(!mutex_is_locked(_mutex));
if (rng->read)
return rng->read(rng, (void *)buffer, size, wait);
 
@@ -160,13 +166,14 @@ static ssize_t rng_dev_read(struct file *filp, char 
__user *buf,
goto out_unlock;
}
 
+   mutex_lock(_mutex);
if (!data_avail) {
bytes_read = rng_get_data(current_rng, rng_buffer,
rng_buffer_size(),
!(filp->f_flags & O_NONBLOCK));
if (bytes_read < 0) {
err = bytes_read;
-   goto out_unlock;
+   goto out_unlock_reading;
}
data_avail = bytes_read;
}
@@ -174,7 +181,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
if (!data_avail) {
if (filp->f_flags & O_NONBLOCK) {
err = -EAGAIN;
-   goto out_unlock;
+   goto out_unlock_reading;
}
} else {
len = data_avail;
@@ -186,7 +193,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
if (copy_to_user(buf + ret, rng_buffer + data_avail,
len)) {
err = -EFAULT;
-   goto out_unlock;
+   goto out_unlock_reading;
}
 
size -= len;
@@ -194,6 +201,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
}
 
mutex_unlock(_mutex);
+   mutex_unlock(_mutex);
 
if (need_resched())
schedule_timeout_interruptible(1);
@@ -208,6 +216,9 @@ out:
 out_unlock:
mutex_unlock(_mutex);
goto out;
+out_unlock_reading:
+   mutex_unlock(_mutex);
+   goto out_unlock;
 }
 
 
@@ -348,13 +359,16 @@ static int hwrng_fillfn(void *unused)
while (!kthread_should_stop()) {
if (!current_rng)
break;
+   mutex_lock(_mutex);
rc = rng_get_data(current_rng, rng_fillbuf,
  rng_buffer_size(), 1);
+   mutex_unlock(_mutex);
if (rc <= 0) {
pr_warn("hwrng: no data available\n");
msleep_interruptible(1);
continue;
}
+   /* Outside lock, sure, but y'know: randomness. */
add_hwgenerator_randomness((void *)rng_fillbuf, rc,
   rc * current_quality * 8 >> 10);
}
-- 
1.9.1

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


[PATCH 5/5] hw_random: don't init list element we're about to add to list.

2014-09-17 Thread Rusty Russell
Another interesting anti-pattern.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 6a34feca6b43..96fa06716e95 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -485,7 +485,6 @@ int hwrng_register(struct hwrng *rng)
goto out_unlock;
}
}
-   INIT_LIST_HEAD(>list);
list_add_tail(>list, _list);
 
if (old_rng && !rng->init) {
-- 
1.9.1

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


Re: [PATCH v2 2/3] hw_random: fix stuck in catting hwrng attributes

2014-09-17 Thread Rusty Russell
Amos Kong  writes:

> I started a QEMU (non-smp) guest with one virtio-rng device, and read
> random data from /dev/hwrng by dd:
>
>  # dd if=/dev/hwrng of=/dev/null &
>
> In the same time, if I check hwrng attributes from sysfs by cat:
>
>  # cat /sys/class/misc/hw_random/rng_*
>
> The cat process always gets stuck with slow backend (5 k/s), if we
> use a quick backend (1.2 M/s), the cat process will cost 1 to 2
> minutes. The stuck doesn't exist for smp guest.
>
> Reading syscall enters kernel and call rng_dev_read(), it's user
> context. We used need_resched() to check if other tasks need to
> be run, but it almost always return false, and re-hold the mutex
> lock. The attributes accessing process always fails to hold the
> lock, so the cat gets stuck.
>
> User context doesn't allow other user contexts run on that CPU,
> unless the kernel code sleeps for some reason. This is why the
> need_reshed() always return false here.
>
> This patch removed need_resched() and always schedule other tasks
> then other tasks can have chance to hold the lock and execute
> protected code.

OK, this is going to be a rant.

Your explanation doesn't make sense at all.  Worse, your solution breaks
the advice of Kernighan & Plaugher: "Don't patch bad code - rewrite
it.".

But worst of all, this detailed explanation might have convinced me you
understood the problem better than I did, and applied your patch.

I did some tests.  For me, as expected, the process spends its time
inside the virtio rng read function, holding the mutex and thus blocking
sysfs access; it's not a failure of this code at all.

Your schedule_timeout() "fix" probably just helps by letting the host
refresh entropy, so we spend less time waiting in the read fn.

I will post a series, which unfortunately is only lightly tested, then
I'm going to have some beer to begin my holiday.  That may help me
forget my disappointment at seeing respected fellow developers
monkey-patching random code they don't understand.

Grrr
Rusty.

> Signed-off-by: Amos Kong 
> ---
>  drivers/char/hw_random/core.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index c591d7e..263a370 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -195,8 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char 
> __user *buf,
>  
>   mutex_unlock(_mutex);
>  
> - if (need_resched())
> - schedule_timeout_interruptible(1);
> + schedule_timeout_interruptible(1);
>  
>   if (signal_pending(current)) {
>   err = -ERESTARTSYS;
> -- 
> 1.9.3

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


RE: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

2014-09-17 Thread Ren, Qiaowei


On 2014-09-18, Kevin Easton wrote:
> On Thu, Sep 18, 2014 at 12:40:29AM +, Ren, Qiaowei wrote:
>>> Would it be prudent to use an error code other than EINVAL for the
>>> "hardware doesn't support it" case?
>>> 
>> Seems like no specific error code for this case.
> 
> ENXIO would probably be OK.  It's not too important as long as it's
> documented.
> 
Yes. Looks like that ENXIO will be better.

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


Re: [PATCH v5 2/4] dt-bindings: document Rockchip thermal

2014-09-17 Thread Caesar Wang


在 2014年09月18日 04:13, Dmitry Torokhov 写道:

On Wed, Sep 17, 2014 at 12:48:16PM -0700, Doug Anderson wrote:

Caesar,

On Tue, Sep 16, 2014 at 8:59 PM, Caesar Wang  wrote:

This add the necessary binding documentation for the thermal
found on Rockchip SoCs

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 
---
  .../bindings/thermal/rockchip-thermal.txt  | 41 ++
  1 file changed, 41 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
new file mode 100644
index 000..6fc8bc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -0,0 +1,41 @@
+* Temperature Sensor ADC (TSADC) on rockchip SoCs
+
+Required properties:
+- compatible: "rockchip,rk3288-tsadc"
+- reg: physical base address of the controller and length of memory mapped
+   region.
+- interrupts: The interrupt number to the cpu. The interrupt specifier format
+ depends on the interrupt controller.
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Shall be "tsadc" for the converter-clock, and "apb_pclk" for
+  the peripheral clock.
+- num-trips:  number of total trip points, this is required, set it 0 if none,
+ if greater than 0, the following properties must be defined;

nit: there is whitespace damage (space before tab) on the line before
this one.  It's more obvious in the patch you uploaded to gerrit which
highlights this in red:

https://chromium-review.googlesource.com/#/c/213967/5/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

Did you run your patches through checkpatch before submitting?

FWIW vim users like me can put the following in their .vimrc file to
have whitespace damage visible right away:

:highlight RedundantSpaces ctermbg=red guibg=red
:match RedundantSpaces /\s\+$\| \+\ze\t/

Thanks.


It's a very useful, Thank you  for sharing.


--
Best regards,
Caesar


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


Re: [PATCH v3 0/7] mtd: denali: A collection of trivial coding style fixes

2014-09-17 Thread Masahiro Yamada
Hi Brian,



On Wed, 17 Sep 2014 10:13:08 -0700
Brian Norris  wrote:

> On Tue, Sep 16, 2014 at 08:04:18PM +0900, Masahiro Yamada wrote:
> > 
> > 
> > Masahiro Yamada (7):
> >   mtd: denali: fix the format of comment blocks
> >   mtd: denali: remove unnecessary variable initializations
> >   mtd: denali: remove unnecessary casts
> >   mtd: denali: change the type of iterators to int
> >   mtd: denali: remove a set-but-unused variable
> >   mtd: denali: remove unnecessary parentheses
> >   mtd: denali: fix indents and other trivial things
> 
> This series still doesn't apply to l2-mtd.git.
> 
> Brian


I resent the last three patches as v3.

v3 5/7 mtd: denali: remove a set-but-unused variable
v3 6/7 mtd: denali: remove unnecessary parentheses
v3 7/7 mtd: denali: fix indents and other trivial things


I confirmed they are applicable onto
commit 93e3c8adf6fcf2204ca334237b92c7f8cdafce6f
of l2-mtd.git



You said as follow:

On Mon, 15 Sep 2014 22:07:32 -0700
Brian Norris  wrote:

> > Is there a chance for me to resend 5/7 to include this fix?
> > Or is it too late?
> 
> Just send a new patch, please.


That's why I sent a new patch (v3 5/7) to replace
commit 55ab9ec99bbfb4450dfa9bc0fd9e2c5052f4c3f7


Did I do wrong?



Best Regards
Masahiro Yamada

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


Re: [PATCH v4 14/18] ARM64 / ACPI: Add GICv2 specific ACPI boot support

2014-09-17 Thread Arnd Bergmann
On Wednesday 17 September 2014, Catalin Marinas wrote:
> > > I think it gets worse, this function is called from irqchip_init(). I
> > > would have been slightly happier if it was called from the arm64
> > > init_IRQ(). But putting an ARM specific GIC initialisation call in a
> > > generic irqchip_init() just looks weird. Can we do anything better here?
> > 
> > Yes this was discussed, please have a look at: 
> > https://lkml.org/lkml/2014/9/1/555
> > We had this in init_IRQ() in previous patch set, then we got feedback 
> > irqchip_init() is more appropriate. We can move it back to init_IRQ() 
> > and I am sold on this.
> 
> The irqchip_init() is indeed the place to call other interrupt
> controller initialisation functions but what I don't particularly like
> is calling the GIC one directly while the OF ones are checked against a
> match string. For GICv3 and later, do you plan to use the same
> acpi_gic_init() functions? Otherwise we could do something like
> ACPI_IRQCHIP_DECLARE() similar to the OF ones and a common function that
> probes whatever is built into the kernel.

I talked abouto this with Marc Z the other day, and I think it really
comes down to how we expect this to develop in the future:

If this is going to stay with the GICv2/v3/v4 line of interrupt controllers,
I see the ACPI_IRQCHIP_DECLARE() as total overdesign, since we wouldn't
ever need more than two entry points.

Doing ACPI_IRQCHIP_DECLARE() makes it possible to deal with other
incompatible irqchips as they come along, but also seems to invite
those.

Marc believes that it's inevitable that people will add lots of crazy
interrupt controllers to systems using ACPI and at that point I agree
it would be the right way to deal with it. However, I also think that
as long as people expect to be able to add lots of crazy interrupt
controller drivers, we are not ready to merge ACPI in the first place,
because it must first be clear to everybody that we are not going to
allow those nonstandard controller drivers to get merged.

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


Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

2014-09-17 Thread Kevin Easton
On Thu, Sep 18, 2014 at 12:40:29AM +, Ren, Qiaowei wrote:
> > Would it be prudent to use an error code other than EINVAL for the
> > "hardware doesn't support it" case?
> >
> Seems like no specific error code for this case.

ENXIO would probably be OK.  It's not too important as long as it's
documented.

> 
> >> @@ -2011,6 +2017,12 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned
> > long, arg2, unsigned long, arg3,
> >>me->mm->def_flags &= ~VM_NOHUGEPAGE;
> >>up_write(>mm->mmap_sem);
> >>break;
> >> +  case PR_MPX_REGISTER:
> >> +  error = MPX_REGISTER(me);
> >> +  break;
> >> +  case PR_MPX_UNREGISTER:
> >> +  error = MPX_UNREGISTER(me);
> >> +  break;
> > 
> > If you pass me->mm from prctl, that makes it clear that it's
> > per-process not per-thread, just like PR_SET_DUMPABLE / PR_GET_DUMPABLE.
> > 
> > This code should also enforce nulls in arg2 / arg3 / arg4,/ arg5 if
> > it's not using them, otherwise you'll be sunk if you ever want to use them 
> > later.
> > 
> > It seems like it only makes sense for all threads using the mm to have
> > the same bounds directory set.  If the interface was changed to
> > directly pass the address, then could the kernel take care of setting
> > it for *all* of the threads in the process? This seems like something
> > that would be easier for the kernel to do than userspace.
> > 
> If the interface was changed to this, it will be possible for insane 
> application to pass error bounds directory address to kernel. We still 
> have to call fpu_xsave() to check this.

I was actually thinking that the kernel would take care of the xsave / 
xrstor (for current), updating tsk->thread.fpu.state (for non-running
threads) and sending an IPI for threads running on other CPUs.

Of course userspace can always then manually change the bounds directory
address itself, but then it's quite clear that they're doing something
unsupported.  Just an idea, anyway.

- Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] audit: vfs: fix audit records error when write to a file

2014-09-17 Thread hujianyang
>
> Could you add me to your Cc: list on this thread, please?  I'm
> interested in the outcome...  Thanks!
>

Hi Richard,

I've resend a v2 patch and now quote it in the end of this mail
for you.

I'm sorry to say the previously work of mine seems useless. Moving
audit_inode() to the O_CREAT case in lookup_open() may miss some
conditions when we create a file.

fs/namei.c lookup_open() line 2828
"""
if ((nd->flags & LOOKUP_OPEN) && dir_inode->i_op->atomic_open) {
return atomic_open(nd, dentry, path, file, op, got_write,
   need_lookup, opened);
}
"""

We will miss this branch and other potential cases if we apply my
patch.

There is something wrong with audit, I think. But I don't know where.
One good way to solve this problem is go back to commit bfcec708 as
Jeff mentioned in commit 33e2208a and find the reason why the audit
of create operations is wrong. Do we have another way to fix it than
changing the third parameter of audit_inode() to LOOKUP_PARENT which
lead the audit of write confused?

I don't know much about audit. One of my colleagues is dealing with
this problem now. I'm very glad if someone else could help us.

Thanks~!

Hu


On 2014/9/9 10:34, hujianyang wrote:
> Changes from v1:
> 
>* Move audit_inode() to the beginning of O_CREAT case in
>  lookup_open() to avoid missing audit for ROFS error. This
>  lack is spotted by Jeff Layton 
> 
> commit 33e2208acfc1
> 
> audit: vfs: fix audit_inode call in O_CREAT case of do_last
> 
> fix a regression in auditing of open(..., O_CREAT) syscalls but
> introduce a new problem which lead the records of write operation
> confusion.
> 
> This error can be reproduced by these steps:
> 
>   touch /etc/test
>   echo "-w /etc/test" >>/etc/audit/audit.rules
>   /etc/init.d/auditd restart
> 
>   echo "abc" >> /etc/test
> 
> audit_name records are:
> 
> type=PATH msg=audit(1409764556.196:67): item=0 name="/etc/" inode=5097 
> dev=00:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT
> type=PATH msg=audit(1409764556.196:67): item=1 name=(null) inode=23161 
> dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
> type=PATH msg=audit(1409764556.196:67): item=2 name=(null) inode=23161 
> dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
> 
> but if we revert commit 33e2208acfc1, records are correct:
> 
> type=PATH msg=audit(1409763058.192:219): item=0 name="/etc/test" inode=1275 
> dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
> 
> We shouldn't leave audit_inode(.., LOOKUP_PARENT) in O_CREAT case
> of do_last() because this branch don't really know if vfs need to
> create a new file. There is no need to do vfs_create() if we open
> an existing file with O_CREAT flag and write to it. But this
> audit_inode() in O_CREAT case will record a msg as we create a new
> file and confuse the records of write.
> 
> This patch moves the audit for create operation to where a file
> really need to be created, the O_CREAT case in lookup_open().
> We have to add the pointer of struct filename as a parameter of
> lookup_open(). By doing this, the records of both create and write
> are correct.
> 
> Signed-off-by: hujianyang 
> ---
>  fs/namei.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index a996bb4..ca4a831 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2808,7 +2808,8 @@ looked_up:
>  static int lookup_open(struct nameidata *nd, struct path *path,
>   struct file *file,
>   const struct open_flags *op,
> - bool got_write, int *opened)
> + bool got_write, int *opened,
> + struct filename *name)
>  {
>   struct dentry *dir = nd->path.dentry;
>   struct inode *dir_inode = dir->d_inode;
> @@ -2841,6 +2842,8 @@ static int lookup_open(struct nameidata *nd, struct 
> path *path,
>   /* Negative dentry, just create the file */
>   if (!dentry->d_inode && (op->open_flag & O_CREAT)) {
>   umode_t mode = op->mode;
> +
> + audit_inode(name, dir, LOOKUP_PARENT);
>   if (!IS_POSIXACL(dir->d_inode))
>   mode &= ~current_umask();
>   /*
> @@ -2926,7 +2929,6 @@ static int do_last(struct nameidata *nd, struct path 
> *path,
>   if (error)
>   return error;
> 
> - audit_inode(name, dir, LOOKUP_PARENT);
>   error = -EISDIR;
>   /* trailing slashes? */
>   if (nd->last.name[nd->last.len])
> @@ -2945,7 +2947,7 @@ retry_lookup:
>*/
>   }
>   mutex_lock(>d_inode->i_mutex);
> - error = lookup_open(nd, path, file, op, got_write, opened);
> + error = lookup_open(nd, path, file, op, got_write, opened, name);
>   mutex_unlock(>d_inode->i_mutex);
> 
>   if (error <= 0) {
> 


--
To unsubscribe from this 

Re: [PATCH v3 2/3] power: reset: imx-snvs-poweroff: add power off driver for i.mx6

2014-09-17 Thread Robin Gong
On Wed, Sep 17, 2014 at 06:52:44PM +0100, Mark Rutland wrote:
> On Wed, Sep 17, 2014 at 10:57:59AM +0100, Robin Gong wrote:
> > This driver register pm_power_off with snvs power off function. If
> > your boards NOT use PMIC_ON_REQ to turn on/off external pmic, or use
> > other pin to do, please disable the driver in dts, otherwise, your
> > pm_power_off maybe overwrote by this driver.
> > 
> > Signed-off-by: Robin Gong 
> > ---
> >  .../bindings/power_supply/imx-snvs-poweroff.txt|   23 +++
> >  drivers/power/reset/Kconfig|9 +++
> >  drivers/power/reset/Makefile   |1 +
> >  drivers/power/reset/imx-snvs-poweroff.c|   66 
> > 
> >  4 files changed, 99 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/power_supply/imx-snvs-poweroff.txt
> >  create mode 100644 drivers/power/reset/imx-snvs-poweroff.c
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/power_supply/imx-snvs-poweroff.txt 
> > b/Documentation/devicetree/bindings/power_supply/imx-snvs-poweroff.txt
> > new file mode 100644
> > index 000..6caf64e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power_supply/imx-snvs-poweroff.txt
> > @@ -0,0 +1,23 @@
> > +i.mx6 Poweroff Driver
> > +
> > +SNVS_LPCR in SNVS module can power off the whole system by pull
> > +PMIC_ON_REQ low if PMIC_ON_REQ is connected with external PMIC.
> > +If you don't want to use PMIC_ON_REQ as power on/off control,
> > +please set status='disabled' to disable this driver.
> > +
> > +Required Properties:
> > +-compatible: "fsl,sec-v4.0-poweroff"
> > +-reg: Specifies the physical address of the SNVS_LPCR register
> 
> As you describe above, this is part of the SNVS module. So why does this
> need a separate node?
> 
> Surely there should just be a property on the SNVS node that desribers
> whether or not this can be used?
> 
> Mark.
>
Yes, put this function in rtc-snvs make things easier, honestly,this is our way
in internal tree. But looks more and more power off driver put in drivers/power
/reset,so we decided to add new power off driver. If it is ok to register
pm_power_off hook in drivers/rtc/rtc-snvs.c, I can drop this patch.
> > +
> > +Example:
> > +   snvs@020cc000 {
> > +   compatible = "fsl,sec-v4.0-mon", "simple-bus";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges = <0 0x020cc000 0x4000>;
> > +   .
> > +   snvs-poweroff@38 {
> > +   compatible = "fsl,sec-v4.0-poweroff";
> > +   reg = <0x38 0x4>;
> > +   };
> > +   }
> > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> > index ca41523..b26c547 100644
> > --- a/drivers/power/reset/Kconfig
> > +++ b/drivers/power/reset/Kconfig
> > @@ -45,6 +45,15 @@ config POWER_RESET_HISI
> > help
> >   Reboot support for Hisilicon boards.
> >  
> > +config POWER_RESET_IMX
> > +   bool "IMX6 power-off driver"
> > +   depends on POWER_RESET && SOC_IMX6
> > +   help
> > + This driver support power off external PMIC by PMIC_ON_REQ on i.mx6
> > + boards.If you want to use other pin to control external power,please
> > + say N here or disable in dts to make sure pm_power_off never be
> > + overwrote wrongly by this driver.
> > +
> >  config POWER_RESET_MSM
> > bool "Qualcomm MSM power-off driver"
> > depends on POWER_RESET && ARCH_QCOM
> > diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> > index a42e70e..2524daf 100644
> > --- a/drivers/power/reset/Makefile
> > +++ b/drivers/power/reset/Makefile
> > @@ -3,6 +3,7 @@ obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
> >  obj-$(CONFIG_POWER_RESET_BRCMSTB) += brcmstb-reboot.o
> >  obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
> >  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
> > +obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
> >  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> >  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
> >  obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
> > diff --git a/drivers/power/reset/imx-snvs-poweroff.c 
> > b/drivers/power/reset/imx-snvs-poweroff.c
> > new file mode 100644
> > index 000..d726ac4
> > --- /dev/null
> > +++ b/drivers/power/reset/imx-snvs-poweroff.c
> > @@ -0,0 +1,66 @@
> > +/* Power off driver for i.mx6
> > + * Copyright (c) 2014, FREESCALE CORPORATION.  All rights reserved.
> > + *
> > + * based on msm-poweroff.c
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License 

[PATCH 2/2 V7] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)

2014-09-17 Thread suravee.suthikulpanit
From: Suravee Suthikulpanit 

ARM GICv2m specification extends GICv2 to support MSI(-X) with
a new set of register frame. This patch introduces support for
the non-secure GICv2m register frame. Currently, GICV2m is available
in certain version of GIC-400.

The patch introduces a new property in ARM gic binding, the v2m subnode.
It is optional.

Signed-off-by: Suravee Suthikulpanit 
Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: Jason Cooper 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 Documentation/devicetree/bindings/arm/gic.txt |  55 
 arch/arm64/Kconfig|   1 +
 drivers/irqchip/Kconfig   |   7 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-gic-common.c  |  12 +
 drivers/irqchip/irq-gic-common.h  |   4 +
 drivers/irqchip/irq-gic-v2m.c | 356 ++
 drivers/irqchip/irq-gic.c |  82 +++---
 drivers/irqchip/irq-gic.h |  54 
 9 files changed, 542 insertions(+), 30 deletions(-)
 create mode 100644 drivers/irqchip/irq-gic-v2m.c
 create mode 100644 drivers/irqchip/irq-gic.h

diff --git a/Documentation/devicetree/bindings/arm/gic.txt 
b/Documentation/devicetree/bindings/arm/gic.txt
index c7d2fa1..38b2156 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -96,3 +96,58 @@ Example:
  <0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
};
+
+
+* GICv2m extension for MSI/MSI-x support (Optional)
+
+Certain revision of GIC-400 supports MSI/MSI-x via V2M register frame.
+This is enabled by specifying v2m sub-node.
+
+Required properties:
+
+- compatible: The value here should be "arm,gic-v2m-frame".
+
+- msi-controller: Identifies the node as an MSI controller.
+
+- reg   : GICv2m MSI interface register base and size
+
+Optional properties:
+
+- arm,msi-base-spi  : Specify base SPI the MSI frame.
+  The SPI base value can be from 32 to 1019.
+
+- arm,msi-num-spi   : Returns the number of contiguous SPIs assigned
+ to the frame.
+
+Note: "arm,msi-base-spi" and "arm,msi-num-spi" are used mainly for
+   providing HW workaround in the case where the MSI_TYPER register
+   is corrupted.
+
+Example:
+
+   interrupt-controller@e1101000 {
+   compatible = "arm,gic-400";
+   #interrupt-cells = <3>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-controller;
+   interrupts = <1 8 0xf04>;
+   ranges = <0 0 0 0xe110 0 0x10>;
+   reg = <0x0 0xe111 0 0x01000>,
+ <0x0 0xe112f000 0 0x02000>,
+ <0x0 0xe114 0 0x1>,
+ <0x0 0xe116 0 0x1>;
+   v2m0: v2m@0x8000 {
+   compatible = "arm,gic-v2m-frame";
+   msi-controller;
+   reg = <0x0 0x8 0 0x1000>;
+   };
+
+   
+
+   v2mN: v2m@0x9000 {
+   compatible = "arm,gic-v2m-frame";
+   msi-controller;
+   reg = <0x0 0x9 0 0x1000>;
+   };
+   };
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fd4e81a..83d5556 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -12,6 +12,7 @@ config ARM64
select ARM_ARCH_TIMER
select ARM_GIC
select AUDIT_ARCH_COMPAT_GENERIC
+   select ARM_GIC_V2M
select ARM_GIC_V3
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index b8632bf..ddb31ee 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -7,6 +7,13 @@ config ARM_GIC
select IRQ_DOMAIN
select MULTI_IRQ_HANDLER
 
+config ARM_GIC_V2M
+   bool
+   select IRQ_DOMAIN
+   select MULTI_IRQ_HANDLER
+   depends on ARM_GIC
+   depends on PCI && PCI_MSI
+
 config GIC_NON_BANKED
bool
 
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 73052ba..3bda951 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_SUNXI)  += irq-sun4i.o
 obj-$(CONFIG_ARCH_SUNXI)   += irq-sunxi-nmi.o
 obj-$(CONFIG_ARCH_SPEAR3XX)+= spear-shirq.o
 obj-$(CONFIG_ARM_GIC)  += irq-gic.o irq-gic-common.o
+obj-$(CONFIG_ARM_GIC_V2M)  += irq-gic-v2m.o
 obj-$(CONFIG_ARM_GIC_V3)   += irq-gic-v3.o irq-gic-common.o
 obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
 obj-$(CONFIG_ARM_VIC)  += irq-vic.o
diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index 60ac704..4b8cff2 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ 

[PATCH 1/2 V7] irqchip: gic: Add support for multiple MSI for ARM64

2014-09-17 Thread suravee.suthikulpanit
From: Suravee Suthikulpanit 

This patch implelments the ARM64 version of arch_setup_msi_irqs(),
which does not return 1 for when PCI_CAP_ID_MSI and nvec > 1.

Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: Jason Cooper 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suravee Suthikulpanit 
---
 arch/arm64/kernel/Makefile |  1 +
 arch/arm64/kernel/msi.c| 41 +
 2 files changed, 42 insertions(+)
 create mode 100644 arch/arm64/kernel/msi.c

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index df7ef87..a921c42 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
 arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
 arm64-obj-$(CONFIG_KGDB)   += kgdb.o
 arm64-obj-$(CONFIG_EFI)+= efi.o efi-stub.o efi-entry.o
+arm64-obj-$(CONFIG_PCI_MSI)+= msi.o
 
 obj-y  += $(arm64-obj-y) vdso/
 obj-m  += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/msi.c b/arch/arm64/kernel/msi.c
new file mode 100644
index 000..a295862
--- /dev/null
+++ b/arch/arm64/kernel/msi.c
@@ -0,0 +1,41 @@
+/*
+ * ARM64 architectural MSI implemention
+ *
+ * Support for Message Signalelled Interrupts for systems that
+ * implement ARM Generic Interrupt Controller: GICv2m.
+ *
+ * Copyright (C) 2014 Advanced Micro Devices, Inc.
+ * Authors: Suravee Suthikulpanit 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * ARM64 function for seting up MSI irqs.
+ * Based on driver/pci/msi.c: arch_setup_msi_irqs().
+ *
+ * Note:
+ * Current implementation assumes that all interrupt controller used in
+ * ARM64 architecture _MUST_ supports multi-MSI.
+ */
+int arm64_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+   struct msi_desc *entry;
+   int ret;
+
+   list_for_each_entry(entry, >msi_list, list) {
+   ret = arch_setup_msi_irq(dev, entry);
+   if (ret < 0)
+   return ret;
+   if (ret > 0)
+   return -ENOSPC;
+   }
+
+   return 0;
+}
-- 
1.9.3

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


[PATCH 0/2 V7] irqchip: gic: Introduce ARM GICv2m MSI(-X) support

2014-09-17 Thread suravee.suthikulpanit
From: Suravee Suthikulpanit 

NOTE: Resend w/ proper subject for the 2/2 patch.

This patch set introduces support for MSI(-X) in GICv2m specification,
which is implemented in some variation of GIC400.

This depends on and has been tested with the following patch set which
implements PCI supports for ARM64:

[PATCH v10 00/10] Support for creating generic PCI host bridges from DT
https://lkml.org/lkml/2014/9/8/333

[PATCH v10] Add support for PCI in AArch64
https://lkml.org/lkml/2014/9/8/325
 
Changes in V7:
* Fix error handling logic in gicv2m_of_init() and gicv2m_init_one().
  per Marc suggestions.
* Restructure the patch to integrate the multi-MSI support for V2m
  into the patch 2/2.
* Introduce "arm,gic-v2m-frame" compatible ID for the v2m DT binding.
* Introduce "arm,msi-base-spi" and "arm,msi-num-spi" property in the
  v2m DT binding for overwriting value in MSI_TYPER register.
* Add irq-gic-v2m.c: is_msi_spi_valid() to validate the SPI base and
  number of SPIs.
* Fix various comments from Marc (Many thanks).
* Add the missing CONFIG_ARM_GICV2M (per Marcin Juszkiewicz comment)

Suravee Suthikulpanit (2):
  irqchip: gic: Add support for multiple MSI for ARM64
  irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)

 Documentation/devicetree/bindings/arm/gic.txt |  55 
 arch/arm64/Kconfig|   1 +
 arch/arm64/kernel/Makefile|   1 +
 arch/arm64/kernel/msi.c   |  41 +++
 drivers/irqchip/Kconfig   |   7 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-gic-common.c  |  12 +
 drivers/irqchip/irq-gic-common.h  |   4 +
 drivers/irqchip/irq-gic-v2m.c | 356 ++
 drivers/irqchip/irq-gic.c |  82 +++---
 drivers/irqchip/irq-gic.h |  54 
 11 files changed, 584 insertions(+), 30 deletions(-)
 create mode 100644 arch/arm64/kernel/msi.c
 create mode 100644 drivers/irqchip/irq-gic-v2m.c
 create mode 100644 drivers/irqchip/irq-gic.h

-- 
1.9.3

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


Re: blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)

2014-09-17 Thread Ming Lei
On Thu, Sep 18, 2014 at 3:09 AM, David Hildenbrand
 wrote:
>> On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe  wrote:
>> >
>> > Another way would be to ensure that the timeout handler doesn't touch 
>> > hw_ctx
>> > or tag_sets that aren't fully initialized yet. But I think this is
>> > safer/cleaner.
>>
>> That may not be easy or enough to check if hw_ctx/tag_sets are
>> fully initialized if you mean all requests have been used one time.
>>
>> On Wed, Sep 17, 2014 at 10:11 PM, David Hildenbrand
>> > I was playing with a simple patch that just sets cmd_flags and 
>> > action_flags to
>>
>> What is action_flags?
>
> atomic_flags, sorry :)
>
> Otherwise e.g. REQ_ATOM_STARTED could already be set due to the randomness. I
> am not sure if this is really necessary, or if it is completely shielded by 
> the
> tag-handling code, but seemed to be clean for me to do it (and I remember it
> not being set within blk_mq_rq_ctx_init).

You are right, both cmd_flags and atomic_flags should be cleared
in blk_mq_init_rq_map().

>
>>
>> > 0. That should already be sufficient to hinder blk_mq_tag_to_rq and the 
>> > calling
>> > method to do the wrong thing.
>>
>> Yes, clearing rq->cmd_flags should be enough.
>>
>> And looks better to move rq initialization to __blk_mq_free_request()
>> too, otherwise timeout still may see old cmd_flags and rq->q before
>> rq's new initialization.
>
> Yes, __blk_mq_free_request() should also reset at least rq->cmd_flags, and I
> think we can remove the initialization from  __blk_mq_alloc_request().
>
> David
>
>>
>>
>> Thanks,
>



-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kdump: fix compiling error: undefined elfcorehdr_addr

2014-09-17 Thread Li, Zhen-Hua
While debugging the kdump kernel, I found there is a compiling error:
If is_kdump_kernel() is called in some driver(for example, add it in
debugging code in module qla2xxx), there will be a compiling error:

ERROR: "elfcorehdr_addr" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined!

Add EXPORT_SYMBOL for elfcorehdr_addr will fix this.

Signed-off-by: Li, Zhen-Hua 
---
 kernel/crash_dump.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/crash_dump.c b/kernel/crash_dump.c
index c766ee5..8cb4838 100644
--- a/kernel/crash_dump.c
+++ b/kernel/crash_dump.c
@@ -18,6 +18,7 @@ unsigned long saved_max_pfn;
  * it under CONFIG_CRASH_DUMP and not CONFIG_PROC_VMCORE.
  */
 unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+EXPORT_SYMBOL(elfcorehdr_addr);
 
 /*
  * stores the size of elf header of crash image
-- 
2.0.0-rc0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2 V7] irqchip: gic: Add support for multiple MSI for ARM64

2014-09-17 Thread suravee.suthikulpanit
From: Suravee Suthikulpanit 

This patch implelments the ARM64 version of arch_setup_msi_irqs(),
which does not return 1 for when PCI_CAP_ID_MSI and nvec > 1.

Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: Jason Cooper 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suravee Suthikulpanit 
---
 arch/arm64/kernel/Makefile |  1 +
 arch/arm64/kernel/msi.c| 41 +
 2 files changed, 42 insertions(+)
 create mode 100644 arch/arm64/kernel/msi.c

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index df7ef87..a921c42 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
 arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
 arm64-obj-$(CONFIG_KGDB)   += kgdb.o
 arm64-obj-$(CONFIG_EFI)+= efi.o efi-stub.o efi-entry.o
+arm64-obj-$(CONFIG_PCI_MSI)+= msi.o
 
 obj-y  += $(arm64-obj-y) vdso/
 obj-m  += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/msi.c b/arch/arm64/kernel/msi.c
new file mode 100644
index 000..a295862
--- /dev/null
+++ b/arch/arm64/kernel/msi.c
@@ -0,0 +1,41 @@
+/*
+ * ARM64 architectural MSI implemention
+ *
+ * Support for Message Signalelled Interrupts for systems that
+ * implement ARM Generic Interrupt Controller: GICv2m.
+ *
+ * Copyright (C) 2014 Advanced Micro Devices, Inc.
+ * Authors: Suravee Suthikulpanit 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * ARM64 function for seting up MSI irqs.
+ * Based on driver/pci/msi.c: arch_setup_msi_irqs().
+ *
+ * Note:
+ * Current implementation assumes that all interrupt controller used in
+ * ARM64 architecture _MUST_ supports multi-MSI.
+ */
+int arm64_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+   struct msi_desc *entry;
+   int ret;
+
+   list_for_each_entry(entry, >msi_list, list) {
+   ret = arch_setup_msi_irq(dev, entry);
+   if (ret < 0)
+   return ret;
+   if (ret > 0)
+   return -ENOSPC;
+   }
+
+   return 0;
+}
-- 
1.9.3

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


[PATCH 2/2] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)

2014-09-17 Thread suravee.suthikulpanit
From: Suravee Suthikulpanit 

ARM GICv2m specification extends GICv2 to support MSI(-X) with
a new set of register frame. This patch introduces support for
the non-secure GICv2m register frame. Currently, GICV2m is available
in certain version of GIC-400.

The patch introduces a new property in ARM gic binding, the v2m subnode.
It is optional.

Signed-off-by: Suravee Suthikulpanit 
Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: Jason Cooper 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 Documentation/devicetree/bindings/arm/gic.txt |  55 
 arch/arm64/Kconfig|   1 +
 drivers/irqchip/Kconfig   |   7 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-gic-common.c  |  12 +
 drivers/irqchip/irq-gic-common.h  |   4 +
 drivers/irqchip/irq-gic-v2m.c | 356 ++
 drivers/irqchip/irq-gic.c |  82 +++---
 drivers/irqchip/irq-gic.h |  54 
 9 files changed, 542 insertions(+), 30 deletions(-)
 create mode 100644 drivers/irqchip/irq-gic-v2m.c
 create mode 100644 drivers/irqchip/irq-gic.h

diff --git a/Documentation/devicetree/bindings/arm/gic.txt 
b/Documentation/devicetree/bindings/arm/gic.txt
index c7d2fa1..38b2156 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -96,3 +96,58 @@ Example:
  <0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
};
+
+
+* GICv2m extension for MSI/MSI-x support (Optional)
+
+Certain revision of GIC-400 supports MSI/MSI-x via V2M register frame.
+This is enabled by specifying v2m sub-node.
+
+Required properties:
+
+- compatible: The value here should be "arm,gic-v2m-frame".
+
+- msi-controller: Identifies the node as an MSI controller.
+
+- reg   : GICv2m MSI interface register base and size
+
+Optional properties:
+
+- arm,msi-base-spi  : Specify base SPI the MSI frame.
+  The SPI base value can be from 32 to 1019.
+
+- arm,msi-num-spi   : Returns the number of contiguous SPIs assigned
+ to the frame.
+
+Note: "arm,msi-base-spi" and "arm,msi-num-spi" are used mainly for
+   providing HW workaround in the case where the MSI_TYPER register
+   is corrupted.
+
+Example:
+
+   interrupt-controller@e1101000 {
+   compatible = "arm,gic-400";
+   #interrupt-cells = <3>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-controller;
+   interrupts = <1 8 0xf04>;
+   ranges = <0 0 0 0xe110 0 0x10>;
+   reg = <0x0 0xe111 0 0x01000>,
+ <0x0 0xe112f000 0 0x02000>,
+ <0x0 0xe114 0 0x1>,
+ <0x0 0xe116 0 0x1>;
+   v2m0: v2m@0x8000 {
+   compatible = "arm,gic-v2m-frame";
+   msi-controller;
+   reg = <0x0 0x8 0 0x1000>;
+   };
+
+   
+
+   v2mN: v2m@0x9000 {
+   compatible = "arm,gic-v2m-frame";
+   msi-controller;
+   reg = <0x0 0x9 0 0x1000>;
+   };
+   };
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fd4e81a..83d5556 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -12,6 +12,7 @@ config ARM64
select ARM_ARCH_TIMER
select ARM_GIC
select AUDIT_ARCH_COMPAT_GENERIC
+   select ARM_GIC_V2M
select ARM_GIC_V3
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index b8632bf..ddb31ee 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -7,6 +7,13 @@ config ARM_GIC
select IRQ_DOMAIN
select MULTI_IRQ_HANDLER
 
+config ARM_GIC_V2M
+   bool
+   select IRQ_DOMAIN
+   select MULTI_IRQ_HANDLER
+   depends on ARM_GIC
+   depends on PCI && PCI_MSI
+
 config GIC_NON_BANKED
bool
 
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 73052ba..3bda951 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_SUNXI)  += irq-sun4i.o
 obj-$(CONFIG_ARCH_SUNXI)   += irq-sunxi-nmi.o
 obj-$(CONFIG_ARCH_SPEAR3XX)+= spear-shirq.o
 obj-$(CONFIG_ARM_GIC)  += irq-gic.o irq-gic-common.o
+obj-$(CONFIG_ARM_GIC_V2M)  += irq-gic-v2m.o
 obj-$(CONFIG_ARM_GIC_V3)   += irq-gic-v3.o irq-gic-common.o
 obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
 obj-$(CONFIG_ARM_VIC)  += irq-vic.o
diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index 60ac704..4b8cff2 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ 

[PATCH 0/2 V7] irqchip: gic: Introduce ARM GICv2m MSI(-X) support

2014-09-17 Thread suravee.suthikulpanit
From: Suravee Suthikulpanit 

This patch set introduces support for MSI(-X) in GICv2m specification,
which is implemented in some variation of GIC400.

This depends on and has been tested with the following patch set which
implements PCI supports for ARM64:

[PATCH v10 00/10] Support for creating generic PCI host bridges from DT
https://lkml.org/lkml/2014/9/8/333

[PATCH v10] Add support for PCI in AArch64
https://lkml.org/lkml/2014/9/8/325
 
Changes in V7:
* Fix error handling logic in gicv2m_of_init() and gicv2m_init_one().
  per Marc suggestions.
* Restructure the patch to integrate the multi-MSI support for V2m
  into the patch 2/2.
* Introduce "arm,gic-v2m-frame" compatible ID for the v2m DT binding.
* Introduce "arm,msi-base-spi" and "arm,msi-num-spi" property in the
  v2m DT binding for overwriting value in MSI_TYPER register.
* Add irq-gic-v2m.c: is_msi_spi_valid() to validate the SPI base and
  number of SPIs.
* Fix various comments from Marc (Many thanks).
* Add the missing CONFIG_ARM_GICV2M (per Marcin Juszkiewicz comment)

Suravee Suthikulpanit (2):
  irqchip: gic: Add support for multiple MSI for ARM64
  irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)

 Documentation/devicetree/bindings/arm/gic.txt |  55 
 arch/arm64/Kconfig|   1 +
 arch/arm64/kernel/Makefile|   1 +
 arch/arm64/kernel/msi.c   |  41 +++
 drivers/irqchip/Kconfig   |   7 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-gic-common.c  |  12 +
 drivers/irqchip/irq-gic-common.h  |   4 +
 drivers/irqchip/irq-gic-v2m.c | 356 ++
 drivers/irqchip/irq-gic.c |  82 +++---
 drivers/irqchip/irq-gic.h |  54 
 11 files changed, 584 insertions(+), 30 deletions(-)
 create mode 100644 arch/arm64/kernel/msi.c
 create mode 100644 drivers/irqchip/irq-gic-v2m.c
 create mode 100644 drivers/irqchip/irq-gic.h

-- 
1.9.3

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


Re: [RESEND PATCH] arm: exynos: Allow rtc alarm and tick wakeup irq for exynos3250.

2014-09-17 Thread jonghwa3 . lee
On 2014년 09월 17일 17:53, Vikas Sajjan wrote:

> Hi,
> 
> On Wed, Sep 17, 2014 at 8:52 AM, Jonghwa Lee  wrote:
>> Add rtc alarm and tick irq to wakeup sources in exynos3250.
>>
>> Signed-off-by: Jonghwa Lee 
>> Acked-by : Chanwoo choi 
>> ---
>>  arch/arm/mach-exynos/pm.c |9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
>> index fa7218a..d78dcf9 100644
>> --- a/arch/arm/mach-exynos/pm.c
>> +++ b/arch/arm/mach-exynos/pm.c
>> @@ -66,6 +66,12 @@ static struct sleep_save exynos_core_save[] = {
>>
>>  static u32 exynos_irqwake_intmask = 0x;
>>
>> +static const struct exynos_wkup_irq exynos3250_wkup_irq[] = {
>> +   { 105, BIT(1) }, /* RTC alarm */
>> +   { 106, BIT(2) }, /* RTC tick */
>> +   { /* sentinel */ },
>> +};
>> +
>>  static const struct exynos_wkup_irq exynos4_wkup_irq[] = {
>> { 76, BIT(1) }, /* RTC alarm */
>> { 77, BIT(2) }, /* RTC tick */
>> @@ -81,9 +87,10 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[] 
>> = {
>>  static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
>>  {
>> const struct exynos_wkup_irq *wkup_irq;
>> -
>> if (soc_is_exynos5250())
>> wkup_irq = exynos5250_wkup_irq;
>> +   else if (soc_is_exynos3250())
>> +   wkup_irq = exynos3250_wkup_irq;
> 
> 
> Don't add anymore soc_is_exynosxxx() checks, please rebase on [1],
> which refactors the pm.c to use DT based lookup.
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg355266.html
>


Okay, I'll wait those patches are merged, then I'll rebase and repost it.

Thanks,
Jonghwa.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hwmon: ntc_thermistor: Add ntc thermistor to thermal subsystem as a sensor.

2014-09-17 Thread jonghwa3 . lee
On 2014년 09월 18일 00:48, Guenter Roeck wrote:

> On Wed, Sep 17, 2014 at 02:54:37PM +0900, Jonghwa Lee wrote:
>> To get more comprehensive and integrated thermal management, it adds ntc
>> thermistor to thermal framework as a thermal sensor. It's governed thermal
>> susbsystem only if it is described in DT node. Otherwise, it just notifies
>> temperature to userspace via sysfs as it used to be.
>>
>> Signed-off-by: Jonghwa Lee 
> 
> Looks ok as far as I can see. I applied it to hwmon-next. I'll let you know
> if there are any problems.
> 
> Guenter


Okay, thanks ;)

Best regards,
Jonghwa

> 
>> ---
>> Changes:
>> v3:
>>  - Add dependencies of thermal subsystem for proper building.
>> v2:
>>  - Remove NULL pointer checking already done by 
>> thermal_zone_of_sensor_unregister().
>>
>>  .../devicetree/bindings/hwmon/ntc_thermistor.txt   |3 +++
>>  drivers/hwmon/Kconfig  |1 +
>>  drivers/hwmon/ntc_thermistor.c |   25 
>> 
>>  3 files changed, 29 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
>> b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> index 2391e5c..fcca8e7 100644
>> --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> @@ -25,6 +25,9 @@ Requires node properties:
>>  - "io-channels" Channel node of ADC to be used for
>>  conversion.
>>  
>> +Optional node properties:
>> +- "#thermal-sensor-cells" Used to expose itself to thermal fw.
>> +
>>  Read more about iio bindings at
>>  Documentation/devicetree/bindings/iio/iio-bindings.txt
>>  
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 4289a4f..f790b41 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -1077,6 +1077,7 @@ config SENSORS_PC87427
>>  config SENSORS_NTC_THERMISTOR
>>  tristate "NTC thermistor support from Murata"
>>  depends on !OF || IIO=n || IIO
>> +depends on THERMAL || !THERMAL_OF
>>  help
>>This driver supports NTC thermistors sensor reading and its
>>interpretation. The driver can also monitor the temperature and
>> diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
>> index bd41072..4ff89b2 100644
>> --- a/drivers/hwmon/ntc_thermistor.c
>> +++ b/drivers/hwmon/ntc_thermistor.c
>> @@ -38,6 +38,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  
>>  struct ntc_compensation {
>>  int temp_c;
>> @@ -182,6 +183,7 @@ struct ntc_data {
>>  struct device *dev;
>>  int n_comp;
>>  char name[PLATFORM_NAME_SIZE];
>> +struct thermal_zone_device *tz;
>>  };
>>  
>>  #if defined(CONFIG_OF) && IS_ENABLED(CONFIG_IIO)
>> @@ -428,6 +430,20 @@ static int ntc_thermistor_get_ohm(struct ntc_data *data)
>>  return -EINVAL;
>>  }
>>  
>> +static int ntc_read_temp(void *dev, long *temp)
>> +{
>> +struct ntc_data *data = dev_get_drvdata(dev);
>> +int ohm;
>> +
>> +ohm = ntc_thermistor_get_ohm(data);
>> +if (ohm < 0)
>> +return ohm;
>> +
>> +*temp = get_temp_mc(data, ohm);
>> +
>> +return 0;
>> +}
>> +
>>  static ssize_t ntc_show_name(struct device *dev,
>>  struct device_attribute *attr, char *buf)
>>  {
>> @@ -562,6 +578,13 @@ static int ntc_thermistor_probe(struct platform_device 
>> *pdev)
>>  dev_info(>dev, "Thermistor type: %s successfully probed.\n",
>>  pdev_id->name);
>>  
>> +data->tz = thermal_zone_of_sensor_register(data->dev, 0, data->dev,
>> +ntc_read_temp, NULL);
>> +if (IS_ERR(data->tz)) {
>> +dev_dbg(>dev, "Failed to register to thermal fw.\n");
>> +data->tz = NULL;
>> +}
>> +
>>  return 0;
>>  err_after_sysfs:
>>  sysfs_remove_group(>dev->kobj, _attr_group);
>> @@ -578,6 +601,8 @@ static int ntc_thermistor_remove(struct platform_device 
>> *pdev)
>>  sysfs_remove_group(>dev->kobj, _attr_group);
>>  ntc_iio_channel_release(pdata);
>>  
>> +thermal_zone_of_sensor_unregister(data->dev, data->tz);
>> +
>>  return 0;
>>  }
>>  
>> -- 
>> 1.7.9.5
>>
> 


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


[PATCH] arm:extend the reserved mrmory for initrd to be page aligned

2014-09-17 Thread Wang, Yalin
this patch extend the start and end address of initrd to be page aligned,
so that we can free all memory including the un-page aligned head or tail
page of initrd, if the start or end address of initrd are not page
aligned, the page can't be freed by free_initrd_mem() function.

Signed-off-by: Yalin Wang 
---
 arch/arm/mm/init.c   | 5 +
 arch/arm64/mm/init.c | 8 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 659c75d..9221645 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -636,6 +636,11 @@ static int keep_initrd;
 void free_initrd_mem(unsigned long start, unsigned long end)
 {
if (!keep_initrd) {
+   if (start == initrd_start)
+   start = round_down(start, PAGE_SIZE);
+   if (end == initrd_end)
+   end = round_up(end, PAGE_SIZE);
+
poison_init_mem((void *)start, PAGE_ALIGN(end) - start);
free_reserved_area((void *)start, (void *)end, -1, "initrd");
}
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5472c24..c5512f6 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -334,8 +334,14 @@ static int keep_initrd;
 
 void free_initrd_mem(unsigned long start, unsigned long end)
 {
-   if (!keep_initrd)
+   if (!keep_initrd) {
+   if (start == initrd_start)
+   start = round_down(start, PAGE_SIZE);
+   if (end == initrd_end)
+   end = round_up(end, PAGE_SIZE);
+
free_reserved_area((void *)start, (void *)end, 0, "initrd");
+   }
 }
 
 static int __init keepinitrd_setup(char *__unused)
-- 
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/7] test: add firmware_class loader test

2014-09-17 Thread Sasha Levin
On 07/14/2014 05:38 PM, Kees Cook wrote:
> This provides a simple interface to trigger the firmware_class loader
> to test built-in, filesystem, and user helper modes. Additionally adds
> tests via the new interface to the selftests tree.
> 
> Signed-off-by: Kees Cook 

Hi folks,

While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following spew:

[  413.999779] misc test_firmware: Falling back to user helper
[  414.003728] WARNING: CPU: 25 PID: 9860 at lib/kobject.c:209 
kobject_add_internal+0x3a3/0x450()
[  414.006815] kobject: (8807b4ef5dc8): attempted to be registered with 
empty name!
[  414.009482] Modules linked in:
[  414.010818] CPU: 25 PID: 9860 Comm: trinity-c662 Tainted: GW  
3.17.0-rc5-next-20140917-sasha-00041-gd01267b #1198
[  414.014626]  0009 880236547a68 9d56d655 

[  414.017585]  880236547ab8 880236547aa8 9a15f3d1 
001e3540
[  414.020733]  8807b4ef5dc8 ffea 88043d114108 
8807b4ef5db8
[  414.023345] Call Trace:
[  414.024254] dump_stack (lib/dump_stack.c:52)
[  414.026232] warn_slowpath_common (kernel/panic.c:432)
[  414.028355] warn_slowpath_fmt (kernel/panic.c:446)
[  414.030366] ? __raw_spin_lock_init (kernel/locking/spinlock_debug.c:24)
[  414.032369] kobject_add_internal (lib/kobject.c:211 (discriminator 1))
[  414.034313] ? __dynamic_pr_debug (lib/dynamic_debug.c:561)
[  414.036254] kobject_add (lib/kobject.c:403)
[  414.038017] ? device_private_init (drivers/base/core.c:929)
[  414.040340] ? klist_init (lib/klist.c:90)
[  414.044729] device_add (drivers/base/core.c:1010)
[  414.049854] ? dev_set_name (drivers/base/core.c:876)
[  414.060790] _request_firmware (drivers/base/firmware_class.c:892 
drivers/base/firmware_class.c:957 drivers/base/firmware_class.c:1139)
[  414.062814] request_firmware (drivers/base/firmware_class.c:1189)
[  414.064796] trigger_request_store (lib/test_firmware.c:68)
[  414.066774] dev_attr_store (drivers/base/core.c:138)
[  414.068531] sysfs_kf_write (fs/sysfs/file.c:115)
[  414.070826] kernfs_fop_write (fs/kernfs/file.c:308)
[  414.074648] ? kernfs_vma_page_mkwrite (fs/kernfs/file.c:267)
[  414.076864] do_loop_readv_writev (fs/read_write.c:710)
[  414.078947] ? kernfs_vma_page_mkwrite (fs/kernfs/file.c:267)
[  414.081269] do_readv_writev (fs/read_write.c:842)
[  414.083281] ? preempt_count_sub (kernel/sched/core.c:2634)
[  414.085380] ? mutex_lock_nested (./arch/x86/include/asm/preempt.h:98 
kernel/locking/mutex.c:599 kernel/locking/mutex.c:616)
[  414.087401] ? __fdget_pos (fs/file.c:714)
[  414.089286] vfs_writev (fs/read_write.c:881)
[  414.091243] SyS_writev (fs/read_write.c:914 fs/read_write.c:905)
[  414.093053] tracesys_phase2 (arch/x86/kernel/entry_64.S:529)


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cgroup/kmemleak: add kmemleak_free() for cgroup deallocations.

2014-09-17 Thread Wang Nan
Commit ff7ee93f4 introduces kmemleak_alloc() for alloc_page_cgroup(),
but corresponding kmemleak_free() is missing, which makes kmemleak be
wrongly disabled after memory offlining. Log is pasted at the end of
this commit message.

This patch add kmemleak_free() into free_page_cgroup(). During page
offlining, this patch removes corresponding entries in kmemleak rbtree.
After that, the freed memory can be allocated again by other subsystems
without killing kmemleak.

bash # for x in 1 2 3 4; do echo offline > 
/sys/devices/system/memory/memory$x/state ; sleep 1; done ; dmesg | grep leak
[   45.537934] Offlined Pages 32768
[   46.617892] kmemleak: Cannot insert 0x880016969000 into the object 
search tree (overlaps existing)
[   46.617892] CPU: 0 PID: 412 Comm: sleep Not tainted 3.17.0-rc5+ #86
[   46.617892] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   46.617892]  880016823d10 880018bdfc38 81725d2c 
88001780e950
[   46.617892]  880016969000 880018bdfc88 8117a9e6 
880018bdfc78
[   46.617892]  0096 880017812800 81c2eda0 
880016969000
[   46.617892] Call Trace:
[   46.617892]  [] dump_stack+0x46/0x58
[   46.617892]  [] create_object+0x266/0x2c0
[   46.617892]  [] kmemleak_alloc+0x26/0x50
[   46.617892]  [] kmem_cache_alloc+0xd3/0x160
[   46.617892]  [] __sigqueue_alloc+0x49/0xd0
[   46.617892]  [] __send_signal+0xcb/0x410
[   46.617892]  [] send_signal+0x45/0x90
[   46.617892]  [] __group_send_sig_info+0x13/0x20
[   46.617892]  [] do_notify_parent+0x1bb/0x260
[   46.617892]  [] ? sched_move_task+0xaa/0x130
[   46.617892]  [] do_exit+0x767/0xa40
[   46.617892]  [] do_group_exit+0x44/0xa0
[   46.617892]  [] SyS_exit_group+0x17/0x20
[   46.617892]  [] system_call_fastpath+0x16/0x1b
[   46.617892] kmemleak: Kernel memory leak detector disabled
[   46.617892] kmemleak: Object 0x88001690 (size 524288):
[   46.617892] kmemleak:   comm "swapper/0", pid 0, jiffies 4294667296
[   46.617892] kmemleak:   min_count = 0
[   46.617892] kmemleak:   count = 0
[   46.617892] kmemleak:   flags = 0x1
[   46.617892] kmemleak:   checksum = 0
[   46.617892] kmemleak:   backtrace:
[   46.617892]  [] log_early+0x63/0x77
[   46.617892]  [] kmemleak_alloc+0x4b/0x50
[   46.617892]  [] init_section_page_cgroup+0x7f/0xf5
[   46.617892]  [] page_cgroup_init+0xc5/0xd0
[   46.617892]  [] start_kernel+0x333/0x408
[   46.617892]  [] x86_64_start_reservations+0x2a/0x2c
[   46.617892]  [] x86_64_start_kernel+0xf5/0xfc
[   46.617892]  [] 0x

Signed-off-by: Wang Nan 
Cc: Steven Rostedt 
---
 mm/page_cgroup.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 3708264..5331c2b 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -171,6 +171,7 @@ static void free_page_cgroup(void *addr)
sizeof(struct page_cgroup) * PAGES_PER_SECTION;
 
BUG_ON(PageReserved(page));
+   kmemleak_free(addr);
free_pages_exact(addr, table_size);
}
 }
-- 
1.8.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] X86: add IPI tracepoints

2014-09-17 Thread Nicolas Pitre

On X86 there are already tracepoints for IRQ vectors through which IPIs
are handled.  However this is highly X86 specific, and the IPI signaling
is not currently traced.

This is an attempt at adding generic IPI tracepoints to X86.

Signed-off-by: Nicolas Pitre 
Acked-by: Daniel Lezcano 
---

This is a resent.  This patch was part of a larger series that got 
merged during the last merge window.

diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index be8e1bde07..d193609bea 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -31,6 +31,16 @@
 #include 
 #include 
 #include 
+
+#define CREATE_TRACE_POINTS
+/*
+ * Those were defined in  and cause problems
+ * when including .
+ */
+#undef TRACE_INCLUDE_PATH
+#undef TRACE_INCLUDE_FILE
+#include 
+
 /*
  * Some notes on x86 processor bugs affecting SMP operation:
  *
@@ -124,11 +134,13 @@ static void native_smp_send_reschedule(int cpu)
WARN_ON(1);
return;
}
+   trace_ipi_raise(cpumask_of(cpu), tracepoint_string("RESCHEDULE"));
apic->send_IPI_mask(cpumask_of(cpu), RESCHEDULE_VECTOR);
 }
 
 void native_send_call_func_single_ipi(int cpu)
 {
+   trace_ipi_raise(cpumask_of(cpu), 
tracepoint_string("CALL_FUNCTION_SINGLE"));
apic->send_IPI_mask(cpumask_of(cpu), CALL_FUNCTION_SINGLE_VECTOR);
 }
 
@@ -136,6 +148,8 @@ void native_send_call_func_ipi(const struct cpumask *mask)
 {
cpumask_var_t allbutself;
 
+   trace_ipi_raise(mask, tracepoint_string("CALL_FUNCTION"));
+
if (!alloc_cpumask_var(, GFP_ATOMIC)) {
apic->send_IPI_mask(mask, CALL_FUNCTION_VECTOR);
return;
@@ -252,8 +266,10 @@ finish:
  */
 static inline void __smp_reschedule_interrupt(void)
 {
+   trace_ipi_entry(tracepoint_string("RESCHEDULE"));
inc_irq_stat(irq_resched_count);
scheduler_ipi();
+   trace_ipi_exit(tracepoint_string("RESCHEDULE"));
 }
 
 __visible void smp_reschedule_interrupt(struct pt_regs *regs)
@@ -291,8 +307,10 @@ __visible void smp_trace_reschedule_interrupt(struct 
pt_regs *regs)
 
 static inline void __smp_call_function_interrupt(void)
 {
+   trace_ipi_entry(tracepoint_string("CALL_FUNCTION"));
generic_smp_call_function_interrupt();
inc_irq_stat(irq_call_count);
+   trace_ipi_exit(tracepoint_string("CALL_FUNCTION"));
 }
 
 __visible void smp_call_function_interrupt(struct pt_regs *regs)
@@ -313,8 +331,10 @@ __visible void smp_trace_call_function_interrupt(struct 
pt_regs *regs)
 
 static inline void __smp_call_function_single_interrupt(void)
 {
+   trace_ipi_entry(tracepoint_string("CALL_FUNCTION_SINGLE"));
generic_smp_call_function_single_interrupt();
inc_irq_stat(irq_call_count);
+   trace_ipi_exit(tracepoint_string("CALL_FUNCTION_SINGLE"));
 }
 
 __visible void smp_call_function_single_interrupt(struct pt_regs *regs)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] msm:rpm-smd:change msm_rpm_smd_work method

2014-09-17 Thread Wang, Yalin
Hi Bjorn,

I see,
Thanks for your kind remind :)

-Original Message-
On Tue, Sep 16, 2014 at 7:05 PM, Wang, Yalin  wrote:
[..]
> diff --git a/arch/arm/mach-msm/rpm-smd.c b/arch/arm/mach-msm/rpm-smd.c

Hi Yalin,

This file does not exist in mainline and this is not the forum for sending 
patches to codeaurora.
Also note that your commit messages may not include "Change-id" when sending to 
LKML.

Regards,
Bjorn


Re: [PATCH 1/2] regulator: st-pwm: get voltage and duty table from dts

2014-09-17 Thread Chris Zhong


On 09/18/2014 12:54 AM, Doug Anderson wrote:

Hi,

On Wed, Sep 17, 2014 at 9:51 AM, Mark Brown  wrote:

On Wed, Sep 17, 2014 at 09:07:59PM +0800, Chris Zhong wrote:

Get voltage & duty table from device tree might be better, other platforms can 
also use this
driver without any modify.

Signed-off-by: Chris Zhong 
---

  drivers/regulator/Kconfig  |1 -
  drivers/regulator/st-pwm.c |   80 +++-

You need to update the binding document if you're updating the DT
bindings.

Mark: See part 2 .
Unfortunately you weren't CCed on that.  It also should have been
patch #1, not patch #2.

Chris: please change the order and make sure Mark is CCed on the
bindings.  Probably anyone CCed on the code change should be on the
bindings change (and probably vice versa, but maybe not as critical).

-Doug



Thanks.
I should not only use patman's script to created cc list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] mfd: rtsx: fix PM suspend for 5227 & 5249

2014-09-17 Thread micky_ching
From: Micky Ching 

Fix rts5227&5249 failed send buffer cmd after suspend,
PM_CTRL3 should reset before send any buffer cmd after suspend.
Otherwise, buffer cmd will failed, this will lead resume fail.

Signed-off-by: Micky Ching 
---
 drivers/mfd/rts5227.c|   19 +++
 drivers/mfd/rts5249.c|4 
 drivers/mfd/rtsx_pcr.h   |1 +
 include/linux/mfd/rtsx_pci.h |   12 
 4 files changed, 36 insertions(+)

diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 9c8eec8..8222a31 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -128,8 +128,27 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
return rtsx_pci_send_cmd(pcr, 100);
 }
 
+int rts5227_pm_reset(struct rtsx_pcr *pcr)
+{
+   int err;
+
+   /* init aspm */
+   err = rtsx_pci_update_cfg_byte(pcr, LCTLR, 0xFC, 0);
+   if (err < 0)
+   return err;
+
+   /* reset PM_CTRL3 before send buffer cmd */
+   return rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x00);
+}
+
 static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
 {
+   int err;
+
+   err = rts5227_pm_reset(pcr);
+   if (err < 0)
+   return err;
+
/* Optimize RX sensitivity */
return rtsx_pci_write_phy_register(pcr, 0x00, 0xBA42);
 }
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 573de7b..0f1b0e6 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -130,6 +130,10 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
 {
int err;
 
+   err = rts5227_pm_reset(pcr);
+   if (err < 0)
+   return err;
+
err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 07e4c2e..acc7a1e 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -72,4 +72,5 @@ do {  
\
pcr->ms_pull_ctl_disable_tbl = __device##_ms_pull_ctl_disable_tbl; \
 } while (0)
 
+int rts5227_pm_reset(struct rtsx_pcr *pcr);
 #endif
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..b34fec8 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -967,4 +967,16 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr 
*pcr)
return (u8 *)(pcr->host_cmds_ptr);
 }
 
+static inline int rtsx_pci_update_cfg_byte(struct rtsx_pcr *pcr, int addr,
+   u8 mask, u8 append)
+{
+   int err;
+   u8 val;
+
+   err = pci_read_config_byte(pcr->pci, addr, );
+   if (err < 0)
+   return err;
+   return pci_write_config_byte(pcr->pci, addr, (val & mask) | append);
+}
+
 #endif
-- 
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 v11 03/10] ARM: Define PCI_IOBASE as the base of virtual PCI IO space.

2014-09-17 Thread Liviu Dudau
This is needed for calls into OF code that parses PCI ranges.
It signals support for memory mapped PCI I/O accesses that
are described be device trees.

Cc: Russell King 
Cc: Arnd Bergmann 
Cc: Rob Herring 
Reviewed-by: Catalin Marinas 
Signed-off-by: Liviu Dudau 
---
 arch/arm/include/asm/io.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 3d23418..22b7529 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -178,6 +178,7 @@ static inline void __iomem *__typesafe_io(unsigned long 
addr)
 
 /* PCI fixed i/o mapping */
 #define PCI_IO_VIRT_BASE   0xfee0
+#define PCI_IOBASE PCI_IO_VIRT_BASE
 
 #if defined(CONFIG_PCI)
 void pci_ioremap_set_mem_type(int mem_type);
-- 
2.1.0

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


[PATCH v11 05/10] PCI: Create pci_host_bridge before its associated bus in pci_create_root_bus.

2014-09-17 Thread Liviu Dudau
Before commit 7b5436635800 the pci_host_bridge was created before the root bus.
As that commit has added a needless dependency on the bus for 
pci_alloc_host_bridge()
the creation order has been changed for no good reason. Revert the order of
creation as we are going to depend on the pci_host_bridge structure to retrieve 
the
domain number of the root bus.

Cc: Bjorn Helgaas 
Signed-off-by: Liviu Dudau 
Acked-by: Grant Likely 
Reviewed-by: Catalin Marinas 
Tested-by: Tanmay Inamdar 
---
 drivers/pci/probe.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e3cf8a2..5ff72ec 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -515,7 +515,7 @@ static void pci_release_host_bridge_dev(struct device *dev)
kfree(bridge);
 }
 
-static struct pci_host_bridge *pci_alloc_host_bridge(struct pci_bus *b)
+static struct pci_host_bridge *pci_alloc_host_bridge(void)
 {
struct pci_host_bridge *bridge;
 
@@ -524,7 +524,8 @@ static struct pci_host_bridge *pci_alloc_host_bridge(struct 
pci_bus *b)
return NULL;
 
INIT_LIST_HEAD(>windows);
-   bridge->bus = b;
+   bridge->dev.release = pci_release_host_bridge_dev;
+
return bridge;
 }
 
@@ -1761,9 +1762,15 @@ struct pci_bus *pci_create_root_bus(struct device 
*parent, int bus,
char bus_addr[64];
char *fmt;
 
+   bridge = pci_alloc_host_bridge();
+   if (!bridge)
+   return NULL;
+
+   bridge->dev.parent = parent;
+
b = pci_alloc_bus();
if (!b)
-   return NULL;
+   goto err_out;
 
b->sysdata = sysdata;
b->ops = ops;
@@ -1772,26 +1779,19 @@ struct pci_bus *pci_create_root_bus(struct device 
*parent, int bus,
if (b2) {
/* If we already got to this bus through a different bridge, 
ignore it */
dev_dbg(>dev, "bus already known\n");
-   goto err_out;
+   goto err_bus_out;
}
 
-   bridge = pci_alloc_host_bridge(b);
-   if (!bridge)
-   goto err_out;
-
-   bridge->dev.parent = parent;
-   bridge->dev.release = pci_release_host_bridge_dev;
+   bridge->bus = b;
dev_set_name(>dev, "pci%04x:%02x", pci_domain_nr(b), bus);
error = pcibios_root_bridge_prepare(bridge);
-   if (error) {
-   kfree(bridge);
+   if (error)
goto err_out;
-   }
 
error = device_register(>dev);
if (error) {
put_device(>dev);
-   goto err_out;
+   goto err_bus_out;
}
b->bridge = get_device(>dev);
device_enable_async_suspend(b->bridge);
@@ -1848,8 +1848,10 @@ struct pci_bus *pci_create_root_bus(struct device 
*parent, int bus,
 class_dev_reg_err:
put_device(>dev);
device_unregister(>dev);
-err_out:
+err_bus_out:
kfree(b);
+err_out:
+   kfree(bridge);
return NULL;
 }
 
-- 
2.1.0

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


[PATCH v11 01/10] Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.

2014-09-17 Thread Liviu Dudau
The inline version of ioport_map() that gets used when !CONFIG_GENERIC_IOMAP
is wrong. It returns a mapped (i.e. virtual) address that can start from
zero and completely ignores the PCI_IOBASE and IO_SPACE_LIMIT that most
architectures that use !CONFIG_GENERIC_MAP define.

Signed-off-by: Liviu Dudau 
Reviewed-by: Catalin Marinas 
Acked-by: Arnd Bergmann 
Tested-by: Tanmay Inamdar 
---
 include/asm-generic/io.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 975e1cc..2e2161b 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -331,7 +331,7 @@ static inline void iounmap(void __iomem *addr)
 #ifndef CONFIG_GENERIC_IOMAP
 static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
 {
-   return (void __iomem *) port;
+   return (void __iomem *)(PCI_IOBASE + (port & IO_SPACE_LIMIT));
 }
 
 static inline void ioport_unmap(void __iomem *p)
-- 
2.1.0

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


[PATCH v11 06/10] PCI: Introduce generic domain handling for PCI busses.

2014-09-17 Thread Liviu Dudau
From: Catalin Marinas 

The handling of PCI domains (or PCI segments in ACPI speak) is
usually a straightforward affair but its implementation is
currently left to the architectural code, with pci_domain_nr(b)
querying the value of the domain associated with bus b.

This patch introduces CONFIG_PCI_DOMAINS_GENERIC as an
option that can be selected if an architecture want a
simple implementation where the value of the domain
associated with a bus is stored in struct pci_bus.

The architectures that select CONFIG_PCI_DOMAINS_GENERIC will
then have to implement pci_bus_assign_domain_nr() as a way
of setting the domain number associated with a root bus.
All child busses except the root bus will inherit the domain_nr
value from their parent.

Cc: Bjorn Helgaas 
Cc: Arnd Bergmann 
Signed-off-by: Catalin Marinas 
[Renamed pci_set_domain_nr() to pci_bus_assign_domain_nr()]
Signed-off-by: Liviu Dudau 
---
 drivers/pci/probe.c | 11 ---
 include/linux/pci.h | 21 +
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 5ff72ec..ef891d2 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -485,7 +485,7 @@ void pci_read_bridge_bases(struct pci_bus *child)
}
 }
 
-static struct pci_bus *pci_alloc_bus(void)
+static struct pci_bus *pci_alloc_bus(struct pci_bus *parent)
 {
struct pci_bus *b;
 
@@ -500,6 +500,10 @@ static struct pci_bus *pci_alloc_bus(void)
INIT_LIST_HEAD(>resources);
b->max_bus_speed = PCI_SPEED_UNKNOWN;
b->cur_bus_speed = PCI_SPEED_UNKNOWN;
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
+   if (parent)
+   b->domain_nr = parent->domain_nr;
+#endif
return b;
 }
 
@@ -672,7 +676,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus 
*parent,
/*
 * Allocate a new bus, and inherit stuff from the parent..
 */
-   child = pci_alloc_bus();
+   child = pci_alloc_bus(parent);
if (!child)
return NULL;
 
@@ -1768,13 +1772,14 @@ struct pci_bus *pci_create_root_bus(struct device 
*parent, int bus,
 
bridge->dev.parent = parent;
 
-   b = pci_alloc_bus();
+   b = pci_alloc_bus(NULL);
if (!b)
goto err_out;
 
b->sysdata = sysdata;
b->ops = ops;
b->number = b->busn_res.start = bus;
+   pci_bus_assign_domain_nr(b, parent);
b2 = pci_find_bus(pci_domain_nr(b), bus);
if (b2) {
/* If we already got to this bus through a different bridge, 
ignore it */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 61978a4..a494e5d 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -456,6 +456,9 @@ struct pci_bus {
unsigned char   primary;/* number of primary bridge */
unsigned char   max_bus_speed;  /* enum pci_bus_speed */
unsigned char   cur_bus_speed;  /* enum pci_bus_speed */
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
+   int domain_nr;
+#endif
 
charname[48];
 
@@ -1288,6 +1291,24 @@ static inline int pci_domain_nr(struct pci_bus *bus) { 
return 0; }
 static inline int pci_proc_domain(struct pci_bus *bus) { return 0; }
 #endif /* CONFIG_PCI_DOMAINS */
 
+/*
+ * Generic implementation for PCI domain support. If your
+ * architecture does not need custom management of PCI
+ * domains then this implementation will be used
+ */
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
+static inline int pci_domain_nr(struct pci_bus *bus)
+{
+   return bus->domain_nr;
+}
+void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent);
+#else
+static inline void pci_bus_assign_domain_nr(struct pci_bus *bus,
+   struct device *parent)
+{
+}
+#endif
+
 /* some architectures require additional setup to direct VGA traffic */
 typedef int (*arch_set_vga_state_t)(struct pci_dev *pdev, bool decode,
  unsigned int command_bits, u32 flags);
-- 
2.1.0

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


[PATCH v11 02/10] PCI: Introduce helper functions to deal with PCI I/O ranges.

2014-09-17 Thread Liviu Dudau
Some architectures do not have a simple view of the PCI I/O space
and instead use a range of CPU addresses that map to bus addresses.
For some architectures these ranges will be expressed by OF bindings
in a device tree file.

This patch introduces a pci_register_io_range() helper function with
a generic implementation that can be used by such architectures to
keep track of the I/O ranges described by the PCI bindings. If the
PCI_IOBASE macro is not defined that signals lack of support for PCI
and we return an error.

In order to retrieve the CPU address associated with an I/O port, a
new helper function pci_pio_to_address() is introduced. This will
search in the list of ranges registered with pci_register_io_range()
and return the CPU address that corresponds to the given port.

Cc: Grant Likely 
Cc: Arnd Bergmann 
Reviewed-by: Catalin Marinas 
Acked-by: Rob Herring 
Signed-off-by: Liviu Dudau 
---
 drivers/of/address.c   | 100 +
 include/linux/of_address.h |   2 +
 2 files changed, 102 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index e371825..2373a92 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* Max address size we deal with */
@@ -601,12 +602,111 @@ const __be32 *of_get_address(struct device_node *dev, 
int index, u64 *size,
 }
 EXPORT_SYMBOL(of_get_address);
 
+#ifdef PCI_IOBASE
+struct io_range {
+   struct list_head list;
+   phys_addr_t start;
+   resource_size_t size;
+};
+
+static LIST_HEAD(io_range_list);
+static DEFINE_SPINLOCK(io_range_lock);
+#endif
+
+/*
+ * Record the PCI IO range (expressed as CPU physical address + size).
+ * Return a negative value if an error has occured, zero otherwise
+ */
+int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
+{
+#ifdef PCI_IOBASE
+   struct io_range *range;
+   resource_size_t allocated_size = 0;
+
+   /* check if the range hasn't been previously recorded */
+   spin_lock(_range_lock);
+   list_for_each_entry(range, _range_list, list) {
+   if (addr >= range->start && addr + size <= range->start + size)
+   return 0;
+   allocated_size += range->size;
+   }
+   spin_unlock(_range_lock);
+
+   /* range not registed yet, check for available space */
+   if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
+   /* if it's too big check if 64K space can be reserved */
+   if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT)
+   return -E2BIG;
+
+   size = SZ_64K;
+   pr_warn("Requested IO range too big, new size set to 64K\n");
+   }
+
+   /* add the range to the list */
+   range = kzalloc(sizeof(*range), GFP_KERNEL);
+   if (!range)
+   return -ENOMEM;
+
+   range->start = addr;
+   range->size = size;
+
+   spin_lock(_range_lock);
+   list_add_tail(>list, _range_list);
+   spin_unlock(_range_lock);
+#endif
+
+   return 0;
+}
+
+phys_addr_t pci_pio_to_address(unsigned long pio)
+{
+   phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
+
+#ifdef PCI_IOBASE
+   struct io_range *range;
+   resource_size_t allocated_size = 0;
+
+   if (pio > IO_SPACE_LIMIT)
+   return address;
+
+   spin_lock(_range_lock);
+   list_for_each_entry(range, _range_list, list) {
+   if (pio >= allocated_size && pio < allocated_size + 
range->size) {
+   address = range->start + pio - allocated_size;
+   break;
+   }
+   allocated_size += range->size;
+   }
+   spin_unlock(_range_lock);
+#endif
+
+   return address;
+}
+
 unsigned long __weak pci_address_to_pio(phys_addr_t address)
 {
+#ifdef PCI_IOBASE
+   struct io_range *res;
+   resource_size_t offset = 0;
+   unsigned long addr = -1;
+
+   spin_lock(_range_lock);
+   list_for_each_entry(res, _range_list, list) {
+   if (address >= res->start && address < res->start + res->size) {
+   addr = res->start - address + offset;
+   break;
+   }
+   offset += res->size;
+   }
+   spin_unlock(_range_lock);
+
+   return addr;
+#else
if (address > IO_SPACE_LIMIT)
return (unsigned long)-1;
 
return (unsigned long) address;
+#endif
 }
 
 static int __of_address_to_resource(struct device_node *dev,
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index fb7b722..f8cc7da 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -55,7 +55,9 @@ extern void __iomem *of_iomap(struct device_node *device, int 
index);
 extern const __be32 *of_get_address(struct device_node *dev, int index,
   u64 *size, unsigned int *flags);
 
+extern int 

Re: [PATCH 2/2] blk-mq: remove unnecessary blk_clear_rq_complete()

2014-09-17 Thread Ming Lei
On Thu, Sep 18, 2014 at 12:48 AM, Christoph Hellwig  wrote:
> On Wed, Sep 17, 2014 at 05:47:58PM +0800, Ming Lei wrote:
>> From: Ming Lei 
>>
>> This patch removes two unnecessary blk_clear_rq_complete(),
>> the REQ_ATOM_COMPLETE flag is cleared inside blk_mq_start_request(),
>> so:
>>
>>   - The blk_clear_rq_complete() in blk_flush_restore_request()
>>   needn't because the request will be freed later, and clearing
>>   it here may open a small race window with timeout.
>
> This one is defintively correct, blk_mq_end_io should take care of this.
>
>>   - The blk_clear_rq_complete() in blk_mq_requeue_request() isn't
>>   necessary too, even though REQ_ATOM_STARTED is cleared in
>>   __blk_mq_requeue_request(), in theory it still may cause a small
>>   race window with timeout since the two clear_bit() may be
>>   reordered.
>
> Why yo you think it's not nessecary?  The request is not in the drivers

The COMPLETED flag will be cleared in blk_mq_start_request(), so
it needn't to be cleared here, and it is a bit early and might cause
a tiny race window.

> hand at this point, so it should not be marked started.  Maybe I'm missing
> something, but this sounds like it could very likely cause regressions.

The STARTED flag has been cleared in __blk_mq_requeue_request(),
I mean the COMPLETED flag, consider the following situation:

- one req is queued to driver, and the req is completed from
the device just before its timeout expired
- the driver checks the result and finds it need to requeue for some reason
- blk_mq_requeue_request() is called to requeue the req
- COMPLETED is cleared before clearing STARTED because of
writes reorder
- timeout just comes between the two writes
- then the request may be completed another time because of timeout

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/


[PATCH v11 08/10] OF: PCI: Add support for parsing PCI host bridge resources from DT

2014-09-17 Thread Liviu Dudau
Provide a function to parse the PCI DT ranges that can be used to
create a pci_host_bridge structure together with its associated
bus.

Cc: Bjorn Helgaas 
Cc: Arnd Bergmann 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: Catalin Marinas 
Signed-off-by: Liviu Dudau 
---
 drivers/of/of_pci.c| 108 +
 include/linux/of_pci.h |  11 +
 2 files changed, 119 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 7eaeac2..c18b8da 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -1,7 +1,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "of_private.h"
 
@@ -151,6 +153,112 @@ int of_pci_get_domain_nr(struct device_node *node, bool 
allocate_if_missing)
 }
 EXPORT_SYMBOL_GPL(of_pci_get_domain_nr);
 
+/**
+ * of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
+ * @dev: device node of the host bridge having the range property
+ * @busno: bus number associated with the bridge root bus
+ * @bus_max: maximum number of busses for this bridge
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a variable that will contain on return the physical
+ * address for the start of the I/O range.
+ *
+ * It is the callers job to free the @resources list.
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+int of_pci_get_host_bridge_resources(struct device_node *dev,
+   unsigned char busno, unsigned char bus_max,
+   struct list_head *resources, resource_size_t *io_base)
+{
+   struct resource *res;
+   struct resource *bus_range;
+   struct of_pci_range range;
+   struct of_pci_range_parser parser;
+   char range_type[4];
+   int err;
+
+   if (!io_base)
+   return -EINVAL;
+   *io_base = OF_BAD_ADDR;
+
+   bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
+   if (!bus_range)
+   return -ENOMEM;
+
+   pr_info("PCI host bridge %s ranges:\n", dev->full_name);
+
+   err = of_pci_parse_bus_range(dev, bus_range);
+   if (err) {
+   bus_range->start = busno;
+   bus_range->end = bus_max;
+   bus_range->flags = IORESOURCE_BUS;
+   pr_info("  No bus range found for %s, using %pR\n",
+   dev->full_name, _range);
+   } else {
+   if (bus_range->end > bus_range->start + bus_max)
+   bus_range->end = bus_range->start + bus_max;
+   }
+   pci_add_resource(resources, bus_range);
+
+   /* Check for ranges property */
+   err = of_pci_range_parser_init(, dev);
+   if (err)
+   goto parse_failed;
+
+   pr_debug("Parsing ranges property...\n");
+   for_each_of_pci_range(, ) {
+   /* Read next ranges element */
+   if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
+   snprintf(range_type, 4, " IO");
+   else if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_MEM)
+   snprintf(range_type, 4, "MEM");
+   else
+   snprintf(range_type, 4, "err");
+   pr_info("  %s %#010llx..%#010llx -> %#010llx\n", range_type,
+   range.cpu_addr, range.cpu_addr + range.size - 1,
+   range.pci_addr);
+
+   /*
+* If we failed translation or got a zero-sized region
+* then skip this range
+*/
+   if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+   continue;
+
+   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+   if (!res) {
+   err = -ENOMEM;
+   goto parse_failed;
+   }
+
+   err = of_pci_range_to_resource(, dev, res);
+   if (err) {
+   kfree(res);
+   goto parse_failed;
+   }
+
+   if (resource_type(res) == IORESOURCE_IO) {
+   if (*io_base != OF_BAD_ADDR)
+   pr_warn("More than one I/O resource converted. 
CPU offset for old range lost!\n");
+   *io_base = range.cpu_addr;
+   }
+
+   pci_add_resource_offset(resources, res, res->start - 
range.pci_addr);
+   }
+
+   return 0;
+
+parse_failed:
+   pci_free_resource_list(resources);
+   return err;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
 #ifdef CONFIG_PCI_MSI
 
 static LIST_HEAD(of_pci_msi_chip_list);
diff --git a/include/linux/of_pci.h 

[PATCH v11 00/10] Support for creating generic PCI host bridges from DT

2014-09-17 Thread Liviu Dudau
This is my version 11 of the attempt at adding support for generic PCI host
bridge controllers that make use of device tree information to
configure themselves. It contains minor cleanups compared with v10 to address
the existing comments.

I'm going to ask for this series to be included in -next.

Example on how a host bridge driver can use the series:

static int foohb_probe(struct platform_device *pdev)
{
struct device_node *dn = pdev->dev.of_node;
struct foohb_drv *drv;
resource_size_t io_base = 0;  /* phys address for start of IO */
struct pci_bus *bus;
int err = 0;
LIST_HEAD(res);

.
err = of_pci_get_host_bridge_resources(dn, 0, 255, , _base);
if (err)
goto err_handling;
err = foohb_setup(drv, , , _base);
if (err)
goto err_handling;
.
pci_add_flags();
bus = pci_scan_root_bus(>dev, 0, _ops, drv, );
if (!bus)
goto err_handling;

return 0;

err_handling:
..
return err;
}

Changes from v10:
 - Addressed Lorenzo's comments wrt io_base not being initialised inside the
   function that is supposed to modify it and also updated the comments to
   explain the values returned by the function
 - Updated pci_domain_nr helper function to split the allocation of the domain
   number from the parsing of the device tree to find maximum defined domain
   value
 - Fixed up the commit author for commit 6/10

Changes from v9:
 - Moved the DT parsing and assigning of IRQ patch from this series into arm64
   specific patch. This keeps existing pcibios_add_device() unchanged and adds
   an arch-specific version that can later be expanded to cater for dma_ops.
 - Incorporated the fix for users of of_pci_range_to_resources() into the patch
   that changes the behaviour for easier bisection.
 - Added fixes for tegra and rcar host drivers in their usage of
   of_pci_range_to_resources()
 - Broke up of_create_pci_host_bridge() to remove the callback function. The
   function left has been renamed into of_pci_get_host_bridge_resources(). The
   added benefit of that is that the architectural hook for fixing up host 
bridge
   resources now dissappears.
 - Reshuffled the way pgprot_device gets introduced. It is now part of the patch
   that adds pci_remap_iospace() function. The arm64 specific override is moved
   into the arm64 patchset.
 - Added a patch to pci_scan_root_bus() to assign unassigned resources if PCI
   flags are not PCI_PROBE_ONLY

v10 thread here: https://lkml.org/lkml/2014/9/8/333
v9 thread here, with links to previous threads: 
https://lkml.org/lkml/2014/8/12/361

Best regards,
Liviu

Catalin Marinas (1):
  PCI: Introduce generic domain handling for PCI busses.

Liviu Dudau (9):
  Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.
  PCI: Introduce helper functions to deal with PCI I/O ranges.
  ARM: Define PCI_IOBASE as the base of virtual PCI IO space.
  PCI: OF: Fix the conversion of IO ranges into IO resources.
  PCI: Create pci_host_bridge before its associated bus in
pci_create_root_bus.
  OF: Introduce helper function for getting PCI domain_nr
  OF: PCI: Add support for parsing PCI host bridge resources from DT
  PCI: Assign unassigned bus resources in pci_scan_root_bus()
  PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources
into CPU space

 arch/arm/include/asm/io.h |   1 +
 arch/arm/mach-integrator/pci_v3.c |  23 +++---
 drivers/of/address.c  | 146 
 drivers/of/of_pci.c   | 170 ++
 drivers/pci/host/pci-tegra.c  |  10 ++-
 drivers/pci/host/pcie-rcar.c  |  21 +++--
 drivers/pci/pci.c |  33 
 drivers/pci/probe.c   |  46 +++
 include/asm-generic/io.h  |   2 +-
 include/asm-generic/pgtable.h |   4 +
 include/linux/of_address.h|  15 +---
 include/linux/of_pci.h|  18 
 include/linux/pci.h   |  24 ++
 13 files changed, 463 insertions(+), 50 deletions(-)

-- 
2.1.0

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


[PATCH v11] Add support for PCI in AArch64

2014-09-17 Thread Liviu Dudau
Hi,

This patch adds support for PCIe to AArch64. It depends on my v11 patch
that adds support for creating generic host bridge resources from device
trees. With that in place, I was able to boot a platform that
has PCIe host bridge support and use a PCIe network card.

Changes from v10:
 - Added Catalin's Acked-by

Changes from v9:
 - Moved the pcibios_add_device() patch that parses the IRQ number from DT into 
here.
 - Moved the arm64-specific redefine of pgprot_device here from the generic 
patchset.
 - Readability fix for definition of IO_SPACE_LIMIT

Changes from v8:
  - Added support for generic PCI domains

Changes from v7:
  - Rebased to v3.16-rc3
  - Removed pci_ioremap_io() function as it is provided by my v8 generic
PCI host bridge patches under a different name.

Changes from v6:
  - Guard the pci_domain_nr() inline implementation with #ifdef CONFIG_PCI as
to avoid conflict with default empty version present in include/linux/pci.h.
Thanks to Jingoo Han for catching this.

Changes from v5:
  - Removed pcibios_fixup_bridge_ranges() as the week default version is fine.
  - Removed the ALIGN() call in pcibios_align_resource()
  - Stopped exporting pcibios_align_resource()

Changes from v4:
  - Fixed the pci_domain_nr() implementation for arm64. Now we use
find_pci_host_bride() to find the host bridge before we retrieve
the domain number.

Changes from v3:
  - Added Acks accumulated so far ;)
  - Still carrying Catalin's patch for moving the PCI_IO_BASE until it
lands in linux-next or mainline, in order to ease applying the series

Changes from v2:
  - Implement an arch specific version of pci_register_io_range() and
pci_address_to_pio().
  - Return 1 from pci_proc_domain().

Changes from v1:
  - Added Catalin's patch for moving the PCI_IO_BASE location and extend
its size to 16MB
  - Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
keeping track of assigned IO space and returns an io_offset. At the
moment the code is added in arch/arm64 but it can be moved in drivers/pci.
  - Added a fix for the generic ioport_map() function when !CONFIG_GENERIC_IOMAP
as suggested by Arnd.

v10 thread here: https://lkml.org/lkml/2014/9/8/325
v9 thread here: https://lkml.org/lkml/2014/8/12/394
v8 thread here: https://lkml.org/lkml/2014/7/1/705
v7 thread here: https://lkml.org/lkml/2014/3/14/320
v6 thread here: https://lkml.org/lkml/2014/3/5/41
v5 thread here: https://lkml.org/lkml/2014/3/4/307
v4 thread here: https://lkml.org/lkml/2014/3/3/298
v3 thread here: https://lkml.org/lkml/2014/2/28/211
v2 thread here: https://lkml.org/lkml/2014/2/27/255
v1 thread here: https://lkml.org/lkml/2014/2/3/389

Best regards,
Liviu

Liviu Dudau (1):
  arm64: Add architectural support for PCIe

 arch/arm64/Kconfig   | 22 ++-
 arch/arm64/include/asm/Kbuild|  1 +
 arch/arm64/include/asm/io.h  |  3 +-
 arch/arm64/include/asm/pci.h | 37 +
 arch/arm64/include/asm/pgtable.h |  2 ++
 arch/arm64/kernel/Makefile   |  1 +
 arch/arm64/kernel/pci.c  | 59 
 7 files changed, 123 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/include/asm/pci.h
 create mode 100644 arch/arm64/kernel/pci.c

-- 
2.1.0

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


[PATCH v11 10/10] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

2014-09-17 Thread Liviu Dudau
Introduce a default implementation for remapping PCI bus I/O resources
onto the CPU address space. Architectures with special needs may
provide their own version, but most should be able to use this one.

Cc: Bjorn Helgaas 
Cc: Arnd Bergmann 
Cc: Rob Herring 
Reviewed-by: Catalin Marinas 
Signed-off-by: Liviu Dudau 
---
 drivers/pci/pci.c | 33 +
 include/asm-generic/pgtable.h |  4 
 include/linux/pci.h   |  3 +++
 3 files changed, 40 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 2c9ac70..654b44c 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2704,6 +2704,39 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, 
const char *res_name)
 }
 EXPORT_SYMBOL(pci_request_regions_exclusive);
 
+/**
+ * pci_remap_iospace - Remap the memory mapped I/O space
+ * @res: Resource describing the I/O space
+ * @phys_addr: physical address where the range will be mapped.
+ *
+ * Remap the memory mapped I/O space described by the @res
+ * into the CPU physical address space. Only architectures
+ * that have memory mapped IO defined (and hence PCI_IOBASE)
+ * should call this function.
+ */
+int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
+{
+   int err = -ENODEV;
+
+#ifdef PCI_IOBASE
+   if (!(res->flags & IORESOURCE_IO))
+   return -EINVAL;
+
+   if (res->end > IO_SPACE_LIMIT)
+   return -EINVAL;
+
+   err = ioremap_page_range(res->start + (unsigned long)PCI_IOBASE,
+   res->end + 1 + (unsigned long)PCI_IOBASE,
+   phys_addr, pgprot_device(PAGE_KERNEL));
+#else
+   /* this architecture does not have memory mapped I/O space,
+  so this function should never be called */
+   WARN_ON(1);
+#endif
+
+   return err;
+}
+
 static void __pci_set_master(struct pci_dev *dev, bool enable)
 {
u16 old_cmd, cmd;
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 53b2acc..977e545 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -249,6 +249,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
 #define pgprot_writecombine pgprot_noncached
 #endif
 
+#ifndef pgprot_device
+#define pgprot_device pgprot_noncached
+#endif
+
 /*
  * When walking page tables, get the address of the next boundary,
  * or the end address of the range if that comes earlier.  Although no
diff --git a/include/linux/pci.h b/include/linux/pci.h
index a494e5d..fc8c529 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1100,6 +1100,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus 
*bus,
  resource_size_t),
void *alignf_data);
 
+
+int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
+
 static inline dma_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
 {
struct pci_bus_region region;
-- 
2.1.0

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


[PATCH v11 09/10] PCI: Assign unassigned bus resources in pci_scan_root_bus()

2014-09-17 Thread Liviu Dudau
If the firmware has not assigned all the bus resources and
we are not just probing the PCIe busses, it makes sense to
assign the unassigned resources in pci_scan_root_bus().

Cc: Bjorn Helgaas 
Cc: Arnd Bergmann 
Cc: Jason Gunthorpe 
Cc: Rob Herring 
Signed-off-by: Liviu Dudau 
---
 drivers/pci/probe.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ef891d2..508cf61 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1953,6 +1953,9 @@ struct pci_bus *pci_scan_root_bus(struct device *parent, 
int bus,
if (!found)
pci_bus_update_busn_res_end(b, max);
 
+   if (!pci_has_flag(PCI_PROBE_ONLY))
+   pci_assign_unassigned_bus_resources(b);
+
pci_bus_add_devices(b);
return b;
 }
-- 
2.1.0

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


[PATCH v11] arm64: Add architectural support for PCIe

2014-09-17 Thread Liviu Dudau
Use the generic PCI domain and OF functions
to provide support for PCI Express on arm64.

Acked-by: Catalin Marinas 
Signed-off-by: Liviu Dudau 
---
 arch/arm64/Kconfig   | 22 ++-
 arch/arm64/include/asm/Kbuild|  1 +
 arch/arm64/include/asm/io.h  |  3 +-
 arch/arm64/include/asm/pci.h | 37 +
 arch/arm64/include/asm/pgtable.h |  2 ++
 arch/arm64/kernel/Makefile   |  1 +
 arch/arm64/kernel/pci.c  | 59 
 7 files changed, 123 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/include/asm/pci.h
 create mode 100644 arch/arm64/kernel/pci.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fd4e81a..6b01df9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -81,7 +81,7 @@ config MMU
def_bool y
 
 config NO_IOPORT_MAP
-   def_bool y
+   def_bool y if !PCI
 
 config STACKTRACE_SUPPORT
def_bool y
@@ -156,6 +156,26 @@ menu "Bus support"
 config ARM_AMBA
bool
 
+config PCI
+   bool "PCI support"
+   help
+ This feature enables support for PCIe bus system. If you say Y
+ here, the kernel will include drivers and infrastructure code
+ to support PCIe bus devices.
+
+config PCI_DOMAINS
+   def_bool PCI
+
+config PCI_DOMAINS_GENERIC
+   def_bool PCI
+
+config PCI_SYSCALL
+   def_bool PCI
+
+source "drivers/pci/Kconfig"
+source "drivers/pci/pcie/Kconfig"
+source "drivers/pci/hotplug/Kconfig"
+
 endmenu
 
 menu "Kernel Features"
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 0b3fcf8..07cb417 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -29,6 +29,7 @@ generic-y += mman.h
 generic-y += msgbuf.h
 generic-y += mutex.h
 generic-y += pci.h
+generic-y += pci-bridge.h
 generic-y += poll.h
 generic-y += preempt.h
 generic-y += resource.h
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index e0ecdcf..f998d90 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -121,7 +121,8 @@ static inline u64 __raw_readq(const volatile void __iomem 
*addr)
 /*
  *  I/O port access primitives.
  */
-#define IO_SPACE_LIMIT 0x
+#define arch_has_dev_port()(1)
+#define IO_SPACE_LIMIT (SZ_32M - 1)
 #define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_32M))
 
 static inline u8 inb(unsigned long addr)
diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
new file mode 100644
index 000..872ba93
--- /dev/null
+++ b/arch/arm64/include/asm/pci.h
@@ -0,0 +1,37 @@
+#ifndef __ASM_PCI_H
+#define __ASM_PCI_H
+#ifdef __KERNEL__
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define PCIBIOS_MIN_IO 0x1000
+#define PCIBIOS_MIN_MEM0
+
+/*
+ * Set to 1 if the kernel should re-assign all PCI bus numbers
+ */
+#define pcibios_assign_all_busses() \
+   (pci_has_flag(PCI_REASSIGN_ALL_BUS))
+
+/*
+ * PCI address space differs from physical memory address space
+ */
+#define PCI_DMA_BUS_IS_PHYS(0)
+
+extern int isa_dma_bridge_buggy;
+
+#ifdef CONFIG_PCI
+static inline int pci_proc_domain(struct pci_bus *bus)
+{
+   return 1;
+}
+#endif  /* CONFIG_PCI */
+
+#endif  /* __KERNEL__ */
+#endif  /* __ASM_PCI_H */
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index ffe1ba0..a968523 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -296,6 +296,8 @@ static inline int has_transparent_hugepage(void)
__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE) 
| PTE_PXN | PTE_UXN)
 #define pgprot_writecombine(prot) \
__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | 
PTE_PXN | PTE_UXN)
+#define pgprot_device(prot) \
+   __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) 
| PTE_PXN | PTE_UXN)
 #define __HAVE_PHYS_MEM_ACCESS_PROT
 struct file;
 extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index df7ef87..1ed5a06 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
 arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
 arm64-obj-$(CONFIG_KGDB)   += kgdb.o
 arm64-obj-$(CONFIG_EFI)+= efi.o efi-stub.o efi-entry.o
+arm64-obj-$(CONFIG_PCI)+= pci.o
 
 obj-y  += $(arm64-obj-y) vdso/
 obj-m  += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
new file mode 100644
index 000..0d755d6
--- /dev/null
+++ b/arch/arm64/kernel/pci.c
@@ -0,0 +1,59 @@
+/*
+ * Code borrowed from powerpc/kernel/pci-common.c
+ *
+ * Copyright (C) 2003 Anton Blanchard , IBM
+ * Copyright (C) 

[PATCH v11 07/10] OF: Introduce helper function for getting PCI domain_nr

2014-09-17 Thread Liviu Dudau
Add of_pci_get_domain_nr() to retrieve the PCI domain number
of a given device from DT. If the information is not present,
the function can be requested to allocate a new domain number.

Cc: Bjorn Helgaas 
Cc: Arnd Bergmann 
Cc: Grant Likely 
Cc: Rob Herring 
Reviewed-by: Catalin Marinas 
Signed-off-by: Liviu Dudau 
---
 drivers/of/of_pci.c| 62 ++
 include/linux/of_pci.h |  7 ++
 2 files changed, 69 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 8481996..7eaeac2 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -3,6 +3,8 @@
 #include 
 #include 
 
+#include "of_private.h"
+
 static inline int __of_pci_pci_compare(struct device_node *node,
   unsigned int data)
 {
@@ -89,6 +91,66 @@ int of_pci_parse_bus_range(struct device_node *node, struct 
resource *res)
 }
 EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
 
+static atomic_t of_domain_nr = ATOMIC_INIT(-1);
+
+/*
+ * Get the maximum value for a domain number from the device tree
+ */
+static int of_get_max_pci_domain_nr(void)
+{
+   struct alias_prop *app;
+   int max_domain = -1;
+
+   mutex_lock(_mutex);
+   list_for_each_entry(app, _lookup, link) {
+   if (strncmp(app->stem, "pci-domain", 10) != 0)
+   continue;
+
+   max_domain = max(max_domain, app->id);
+   }
+   mutex_unlock(_mutex);
+
+   return max_domain;
+}
+
+/**
+ * This function will try to obtain the host bridge domain number by
+ * using of_alias_get_id() call with "pci-domain" as a stem. If that
+ * fails, a local allocator will be used. The local allocator can
+ * be requested to return a new domain_nr if the information is missing
+ * from the device tree.
+ *
+ * @node: device tree node with the domain information
+ * @allocate_if_missing: if DT lacks information about the domain nr,
+ * allocate a new number.
+ *
+ * Returns the associated domain number from DT, or a new domain number
+ * if DT information is missing and @allocate_if_missing is true. If
+ * @allocate_if_missing is false then the last allocated domain number
+ * will be returned.
+ */
+int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
+{
+   int domain;
+
+   domain = atomic_read(_domain_nr);
+   if (domain == -1) {
+   /* first run, get max defined domain nr in device tree */
+   domain = of_get_max_pci_domain_nr();
+   /* then set the start value for allocator to be max + 1 */
+   atomic_set(_domain_nr, domain + 1);
+   }
+   domain = of_alias_get_id(node, "pci-domain");
+   if (domain == -ENODEV) {
+   domain = atomic_read(_domain_nr);
+   if (allocate_if_missing)
+   atomic_inc(_domain_nr);
+   }
+
+   return domain;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_domain_nr);
+
 #ifdef CONFIG_PCI_MSI
 
 static LIST_HEAD(of_pci_msi_chip_list);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index dde3a4a..3a3824c 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -15,6 +15,7 @@ struct device_node *of_pci_find_child_device(struct 
device_node *parent,
 int of_pci_get_devfn(struct device_node *np);
 int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
+int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing);
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq)
 {
@@ -43,6 +44,12 @@ of_pci_parse_bus_range(struct device_node *node, struct 
resource *res)
 {
return -EINVAL;
 }
+
+static inline int
+of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
+{
+   return -1;
+}
 #endif
 
 #if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
-- 
2.1.0

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


[PATCH v11 04/10] PCI: OF: Fix the conversion of IO ranges into IO resources.

2014-09-17 Thread Liviu Dudau
The ranges property for a host bridge controller in DT describes
the mapping between the PCI bus address and the CPU physical address.
The resources framework however expects that the IO resources start
at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
The conversion from pci ranges to resources failed to take that into account.

In the process move the function into drivers/of/address.c as it now
depends on pci_address_to_pio() code and make it return an error code.
Also fix all the drivers that depend on the old behaviour by fetching
the CPU physical address based on the port number.

Cc: Grant Likely 
Cc: Rob Herring 
Cc: Arnd Bergmann 
Cc: Linus Walleij 
Cc: Thierry Reding 
Cc: Simon Horman 
Cc: Catalin Marinas 
Signed-off-by: Liviu Dudau 
---
 arch/arm/mach-integrator/pci_v3.c | 23 ++--
 drivers/of/address.c  | 46 +++
 drivers/pci/host/pci-tegra.c  | 10 ++---
 drivers/pci/host/pcie-rcar.c  | 21 +-
 include/linux/of_address.h| 13 ++-
 5 files changed, 82 insertions(+), 31 deletions(-)

diff --git a/arch/arm/mach-integrator/pci_v3.c 
b/arch/arm/mach-integrator/pci_v3.c
index 05e1f73..3321e1b 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -660,6 +660,7 @@ static void __init pci_v3_preinit(void)
 {
unsigned long flags;
unsigned int temp;
+   phys_addr_t io_address = pci_pio_to_address(io_mem.start);
 
pcibios_min_mem = 0x0010;
 
@@ -701,7 +702,7 @@ static void __init pci_v3_preinit(void)
/*
 * Setup window 2 - PCI IO
 */
-   v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_mem.start) |
+   v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_address) |
V3_LB_BASE_ENABLE);
v3_writew(V3_LB_MAP2, v3_addr_to_lb_map2(0));
 
@@ -742,6 +743,7 @@ static void __init pci_v3_preinit(void)
 static void __init pci_v3_postinit(void)
 {
unsigned int pci_cmd;
+   phys_addr_t io_address = pci_pio_to_address(io_mem.start);
 
pci_cmd = PCI_COMMAND_MEMORY |
  PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
@@ -758,7 +760,7 @@ static void __init pci_v3_postinit(void)
   "interrupt: %d\n", ret);
 #endif
 
-   register_isa_ports(non_mem.start, io_mem.start, 0);
+   register_isa_ports(non_mem.start, io_address, 0);
 }
 
 /*
@@ -867,33 +869,32 @@ static int __init pci_v3_probe(struct platform_device 
*pdev)
 
for_each_of_pci_range(, ) {
if (!range.flags) {
-   of_pci_range_to_resource(, np, _mem);
+   ret = of_pci_range_to_resource(, np, _mem);
conf_mem.name = "PCIv3 config";
}
if (range.flags & IORESOURCE_IO) {
-   of_pci_range_to_resource(, np, _mem);
+   ret = of_pci_range_to_resource(, np, _mem);
io_mem.name = "PCIv3 I/O";
}
if ((range.flags & IORESOURCE_MEM) &&
!(range.flags & IORESOURCE_PREFETCH)) {
non_mem_pci = range.pci_addr;
non_mem_pci_sz = range.size;
-   of_pci_range_to_resource(, np, _mem);
+   ret = of_pci_range_to_resource(, np, _mem);
non_mem.name = "PCIv3 non-prefetched mem";
}
if ((range.flags & IORESOURCE_MEM) &&
(range.flags & IORESOURCE_PREFETCH)) {
pre_mem_pci = range.pci_addr;
pre_mem_pci_sz = range.size;
-   of_pci_range_to_resource(, np, _mem);
+   ret = of_pci_range_to_resource(, np, _mem);
pre_mem.name = "PCIv3 prefetched mem";
}
-   }
 
-   if (!conf_mem.start || !io_mem.start ||
-   !non_mem.start || !pre_mem.start) {
-   dev_err(>dev, "missing ranges in device node\n");
-   return -EINVAL;
+   if (ret < 0) {
+   dev_err(>dev, "missing ranges in device node\n");
+   return -EINVAL;
+   }
}
 
pci_v3.map_irq = of_irq_parse_and_map_pci;
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 2373a92..ff10b64 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -947,3 +947,49 @@ bool of_dma_is_coherent(struct device_node *np)
return false;
 }
 EXPORT_SYMBOL_GPL(of_dma_is_coherent);
+
+/*
+ * of_pci_range_to_resource - Create a resource from an of_pci_range
+ * @range: the PCI range that describes the resource
+ * @np:device node where the range belongs to
+ * @res:   pointer to a valid resource that will be updated to
+ *  reflect the values contained in the range.
+ *
+ * 

Re: [PATCH v5 11/12] sched: replace capacity_factor by utilization

2014-09-17 Thread Vincent Guittot
On 17 September 2014 15:25, Peter Zijlstra  wrote:
> On Tue, Sep 16, 2014 at 12:14:54AM +0200, Vincent Guittot wrote:
>> On 15 September 2014 13:42, Peter Zijlstra  wrote:
>
>> > OK, I've reconsidered _again_, I still don't get it.
>> >
>> > So fundamentally I think its wrong to scale with the capacity; it just
>> > doesn't make any sense. Consider big.little stuff, their CPUs are
>> > inherently asymmetric in capacity, but that doesn't matter one whit for
>> > utilization numbers. If a core is fully consumed its fully consumed, no
>> > matter how much work it can or can not do.
>> >
>> >
>> > So the only thing that needs correcting is the fact that these
>> > statistics are based on clock_task and some of that time can end up in
>> > other scheduling classes, at which point we'll never get 100% even
>> > though we're 'saturated'. But correcting for that using capacity doesn't
>> > 'work'.
>>
>> I'm not sure to catch your last point because the capacity is the only
>> figures that take into account the "time" consumed by other classes.
>> Have you got in mind another way to take into account the other
>> classes ?
>
> So that was the entire point of stuffing capacity in? Note that that
> point was not at all clear.
>
> This is very much like 'all we have is a hammer, and therefore
> everything is a nail'. The rt fraction is a 'small' part of what the
> capacity is.
>
>> So we have cpu_capacity that is the capacity that can be currently
>> used by cfs class
>> We have cfs.usage_load_avg that is the sum of running time of cfs
>> tasks on the CPU and reflect the % of usage of this CPU by CFS tasks
>> We have to use the same metrics to compare available capacity for CFS
>> and current cfs usage
>
> -ENOPARSE
>
>> Now we have to use the same unit so we can either weight the
>> cpu_capacity_orig with the cfs.usage_load_avg and compare it with
>> cpu_capacity
>> or with divide cpu_capacity by cpu_capacity_orig and scale it into the
>> SCHED_LOAD_SCALE range. Is It what you are proposing ?
>
> I'm so not getting it; orig vs capacity still includes
> arch_scale_freq_capacity(), so that is not enough to isolate the rt
> fraction.

This patch does not try to solve any scale invariance issue. This
patch removes capacity_factor because it rarely works correctly.
capacity_factor tries to compute how many tasks a group of CPUs can
handle at the time we are doing the load balance. The capacity_factor
is hardly working for SMT system: it sometimes works for big cores and
but fails to do the right thing for little cores.

Below are two examples to illustrate the problem that this patch solves:

capacity_factor makes the assumption that max capacity of a CPU is
SCHED_CAPACITY_SCALE and the load of a thread is always is
SCHED_LOAD_SCALE. It compares the output of these figures with the sum
of nr_running to decide if a group is overloaded or not.

But if the default capacity of a CPU is less than SCHED_CAPACITY_SCALE
(640 as an example), a group of 3 CPUS will have a max capacity_factor
of 2 ( div_round_closest(3x640/1024) = 2) which means that it will be
seen as overloaded if we have only one task per CPU.

Then, if the default capacity of a CPU is greater than
SCHED_CAPACITY_SCALE (1512 as an example), a group of 4 CPUs will have
a capacity_factor of 4 (at max and thanks to the fix[0] for SMT system
that prevent the apparition of ghost CPUs) but if one CPU is fully
used by a rt task (and its capacity is reduced to nearly nothing), the
capacity factor of the group will still be 4
(div_round_closest(3*1512/1024) = 5).

So, this patch tries to solve this issue by removing capacity_factor
and replacing it with the 2 following metrics :
-the available CPU capacity for CFS tasks which is the one currently
used by load_balance
-the capacity that are effectively used by CFS tasks on the CPU. For
that, i have re-introduced the usage_avg_contrib which is in the range
[0..SCHED_CPU_LOAD] whatever the capacity of the CPU on which the task
is running, is. This usage_avg_contrib doesn't solve the scaling
in-variance problem, so i have to scale the usage with original
capacity in get_cpu_utilization (that will become get_cpu_usage in the
next version) in order to compare it with available capacity.

Once the scaling invariance will have been added in usage_avg_contrib,
we can remove the scale by cpu_capacity_orig in get_cpu_utilization.
But the scaling invariance will come in another patchset.

Hope that this explanation makes the goal of this patchset clearer.
And I can add this explanation in the commit log if you found it clear
enough

Vincent

[0] https://lkml.org/lkml/2013/8/28/194
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: About RK3288 i2c scl duty cycle

2014-09-17 Thread addy ke
Add public list

On 2014/9/17 23:17, Doug Anderson wrote:
> Addy,
> 
> On Tue, Sep 16, 2014 at 6:30 PM, addy...@rock-chips.com
>  wrote:
>> hi, all
> 
> Any reason why you didn't add some public lists?  It seems like this
> is a perfect discussion for linux-i2c.
> 
> 
>> According to i2c-bus specification(version2.1, page 32, Table5, FAST-MODE):
>> The minimum LOW period of the scl clock is <1.3us>, and the minimum HIGH
>> period of the scl clock is <0.6us>.
>> T(min_low) : T(min_high)  ~= 2 : 1
>>
>> If  in fast mode(scl rate = 400Khz)
>> 1)Under ideal conditions, T(scl_low) = T(scl_high) = <1.25us>
>> 2)Our measurement, T(scl_low) = <1.3us>, T(scl_high) = <1.25us>
>>
>> The low period of the scl clock is critical.
>>
>> Do we need set   to increase T(scl_low)?   // T(scl_low )
>> : T(scl_High) = 2 : 1
> 
> I can't say I've ever looked at that pat of the i2c spec before, but
> what you say seems reasonable to me.  ...well for 400kHz, at least.
> At 100kHz you shouldn't use the same 2:1 ratio.

Yes, in normal-mode(100K) we can be only used 1:1 ratio.
But in FAST-MODE maybe we must use 2:1 ratio.

In Table 5(Characteristics of the SDA and SCL bus lines for F/S-mode I2C-bus 
devices)

1)FAST-MODE(400K):
  The minimum LOW period of the scl clock1.3us
  the minimum HIGH period of the scl clock   0.6us
  T(min_low) : T(min_high)  ~= 2 : 1

  But I can't see any ratio about In FAST-mode(400k) and Normal-mode(100k).
2)Normal-MODE(100K):
  The minimum LOW period of the scl clock4.7us
  the minimum HIGH period of the scl clock   4.0us
  T(min_low) : T(min_high)  ~= 1 : 1

3) HS-mode(3.4M)
  ratio of 1 to 2 is required, decribed as follows:
  Hs-mode master devices generate a serial clock signal with a HIGH to LOW 
ratio of 1 to 2
> 
> I'm sure other drivers have solved this problem too, so maybe you can
> copy some code.  In i2c-designware-core.c you can see them doing all
> the calculations you need, I think.
> 
> 
> -Doug
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ceph: remove redundant code for max file size verification

2014-09-17 Thread Yan, Zheng
On Wed, Sep 17, 2014 at 5:26 PM, Chao Yu  wrote:
> Both ceph_update_writeable_page and ceph_setattr will verify file size
> with max size ceph supported.
> There are two caller for ceph_update_writeable_page, ceph_write_begin and
> ceph_page_mkwrite. For ceph_write_begin, we have already verified the size in
> generic_write_checks of ceph_write_iter; for ceph_page_mkwrite, we have no
> chance to change file size when mmap. Likewise we have already verified the 
> size
> in inode_change_ok when we call ceph_setattr.
> So let's remove the redundant code for max file size verification.
>
> Signed-off-by: Chao Yu 
> ---
>  fs/ceph/addr.c  | 9 -
>  fs/ceph/inode.c | 6 --
>  2 files changed, 15 deletions(-)
>
> diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
> index 90b3954..18c06bb 100644
> --- a/fs/ceph/addr.c
> +++ b/fs/ceph/addr.c
> @@ -1076,12 +1076,6 @@ retry_locked:
> /* past end of file? */
> i_size = inode->i_size;   /* caller holds i_mutex */
>
> -   if (i_size + len > inode->i_sb->s_maxbytes) {
> -   /* file is too big */
> -   r = -EINVAL;
> -   goto fail;
> -   }
> -
> if (page_off >= i_size ||
> (pos_in_page == 0 && (pos+len) >= i_size &&
>  end_in_page - pos_in_page != PAGE_CACHE_SIZE)) {
> @@ -1099,9 +1093,6 @@ retry_locked:
> if (r < 0)
> goto fail_nosnap;
> goto retry_locked;
> -
> -fail:
> -   up_read(>snap_rwsem);
>  fail_nosnap:
> unlock_page(page);
> return r;
> diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
> index 04c89c2..25c242e 100644
> --- a/fs/ceph/inode.c
> +++ b/fs/ceph/inode.c
> @@ -1813,10 +1813,6 @@ int ceph_setattr(struct dentry *dentry, struct iattr 
> *attr)
> if (ia_valid & ATTR_SIZE) {
> dout("setattr %p size %lld -> %lld\n", inode,
>  inode->i_size, attr->ia_size);
> -   if (attr->ia_size > inode->i_sb->s_maxbytes) {
> -   err = -EINVAL;
> -   goto out;
> -   }
> if ((issued & CEPH_CAP_FILE_EXCL) &&
> attr->ia_size > inode->i_size) {
> inode->i_size = attr->ia_size;
> @@ -1896,8 +1892,6 @@ int ceph_setattr(struct dentry *dentry, struct iattr 
> *attr)
> if (mask & CEPH_SETATTR_SIZE)
> __ceph_do_pending_vmtruncate(inode);
> return err;
> -out:
> -   spin_unlock(>i_ceph_lock);
>  out_put:
> ceph_mdsc_put_request(req);
> return err;
> --
> 2.0.1.474.g72c7794
>
>

Reviewed-by: Yan, Zheng 

I added  this to testing branch of client-client.

Thanks
Yan, Zheng


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


  1   2   3   4   5   6   7   8   9   10   >