Re: [PATCH 1/1] dmaengine: dw: fix nollp issue

[Andy Shevchenko]

On Mon, Sep 28, 2015 at 5:55 AM, yitian  wrote:
> when channel number is less than maximum number, the register
> address of all channels is wrong, which causes the "nollp" flag
> is set for all channels even if HW supports llp.
>

Thanks for the fix, though proper one is already under review here:
http://www.spinics.net/lists/dmaengine/msg06143.html

You might break a channel prioritization.

> Signed-off-by: Yitian Bu 
> ---
>  drivers/dma/dw/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> index cf1c87f..c2e9ac8 100644
> --- a/drivers/dma/dw/core.c
> +++ b/drivers/dma/dw/core.c
> @@ -1591,7 +1591,7 @@ int dw_dma_probe(struct dw_dma_chip *chip, struct
> dw_dma_platform_data *pdata)
> INIT_LIST_HEAD(&dw->dma.channels);
> for (i = 0; i < nr_channels; i++) {
> struct dw_dma_chan  *dwc = &dw->chan[i];
> -   int r = nr_channels - i - 1;
> +   int r = DW_DMA_MAX_NR_CHANNELS - i - 1;
>
> dwc->chan.device = &dw->dma;
> dma_cookie_init(&dwc->chan);
> --
> 1.7.12.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/



-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86/efi: Map EFI memmap entries in-order at runtime

[Matthew Garrett]

On Mon, Sep 28, 2015 at 08:16:46AM +0200, Ingo Molnar wrote:

> So the question is, what does Windows do?

It's pretty trivial to hack OVMF to dump the SetVirtualAddressMap() 
arguments to the qemu debug port. Unfortunately I'm about to drop mostly 
offline for a week, otherwise I'd give it a go...

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

[PATCH net-next v2] BNX2: fix a Null Pointer for stats_blk

[Weidong Wang]

we have two processes to do:
P1#: ifconfig eth0 down; which will call bnx2_close, then will
, and set Null to stats_blk
P2#: ifconfig eth0; which will call bnx2_get_stats64, it will
use stats_blk.
In one case:
--P1#--   --P2#--
  stats_blk(no null)
bnx2_free_mem
->bp->stats_blk = NULL
  GET_64BIT_NET_STATS

then it will cause 'NULL Pointer' Problem.
it is as well with 'ethtool -S ethx'.

Allocate the statistics block at probe time so that this problem is
impossible

Signed-off-by: Tianhong Ding 
---
Change in v2:
 - Use Allocate the statistics block instead of spinlock, which
   suggested by David Miller.
 - Updating commit message according to changes.

---
 drivers/net/ethernet/broadcom/bnx2.c | 61 +++-
 1 file changed, 40 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2.c 
b/drivers/net/ethernet/broadcom/bnx2.c
index 2b66ef3..1f33982 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -813,22 +813,11 @@ bnx2_alloc_rx_mem(struct bnx2 *bp)
 }

 static void
-bnx2_free_mem(struct bnx2 *bp)
+bnx2_free_stats_blk(struct net_device *dev)
 {
-   int i;
+   struct bnx2 *bp = netdev_priv(dev);
struct bnx2_napi *bnapi = &bp->bnx2_napi[0];

-   bnx2_free_tx_mem(bp);
-   bnx2_free_rx_mem(bp);
-
-   for (i = 0; i < bp->ctx_pages; i++) {
-   if (bp->ctx_blk[i]) {
-   dma_free_coherent(&bp->pdev->dev, BNX2_PAGE_SIZE,
- bp->ctx_blk[i],
- bp->ctx_blk_mapping[i]);
-   bp->ctx_blk[i] = NULL;
-   }
-   }
if (bnapi->status_blk.msi) {
dma_free_coherent(&bp->pdev->dev, bp->status_stats_size,
  bnapi->status_blk.msi,
@@ -839,11 +828,12 @@ bnx2_free_mem(struct bnx2 *bp)
 }

 static int
-bnx2_alloc_mem(struct bnx2 *bp)
+bnx2_alloc_stats_blk(struct net_device *dev)
 {
-   int i, status_blk_size, err;
+   int i, status_blk_size;
struct bnx2_napi *bnapi;
void *status_blk;
+   struct bnx2 *bp = netdev_priv(dev);

/* Combine status and statistics blocks into one allocation. */
status_blk_size = L1_CACHE_ALIGN(sizeof(struct status_block));
@@ -852,11 +842,10 @@ bnx2_alloc_mem(struct bnx2 *bp)
 BNX2_SBLK_MSIX_ALIGN_SIZE);
bp->status_stats_size = status_blk_size +
sizeof(struct statistics_block);
-
status_blk = dma_zalloc_coherent(&bp->pdev->dev, bp->status_stats_size,
 &bp->status_blk_mapping, GFP_KERNEL);
if (status_blk == NULL)
-   goto alloc_mem_err;
+   return -ENOMEM;

bnapi = &bp->bnx2_napi[0];
bnapi->status_blk.msi = status_blk;
@@ -865,11 +854,10 @@ bnx2_alloc_mem(struct bnx2 *bp)
bnapi->hw_rx_cons_ptr =
&bnapi->status_blk.msi->status_rx_quick_consumer_index0;
if (bp->flags & BNX2_FLAG_MSIX_CAP) {
-   for (i = 1; i < bp->irq_nvecs; i++) {
+   for (i = 1; i < BNX2_MAX_MSIX_HW_VEC; i++) {
struct status_block_msix *sblk;

bnapi = &bp->bnx2_napi[i];
-
sblk = (status_blk + BNX2_SBLK_MSIX_ALIGN_SIZE * i);
bnapi->status_blk.msix = sblk;
bnapi->hw_tx_cons_ptr =
@@ -879,11 +867,35 @@ bnx2_alloc_mem(struct bnx2 *bp)
bnapi->int_num = i << 24;
}
}
-
bp->stats_blk = status_blk + status_blk_size;
-
bp->stats_blk_mapping = bp->status_blk_mapping + status_blk_size;

+   return 0;
+}
+
+static void
+bnx2_free_mem(struct bnx2 *bp)
+{
+   int i;
+
+   bnx2_free_tx_mem(bp);
+   bnx2_free_rx_mem(bp);
+
+   for (i = 0; i < bp->ctx_pages; i++) {
+   if (bp->ctx_blk[i]) {
+   dma_free_coherent(&bp->pdev->dev, BNX2_PAGE_SIZE,
+ bp->ctx_blk[i],
+ bp->ctx_blk_mapping[i]);
+   bp->ctx_blk[i] = NULL;
+   }
+   }
+}
+
+static int
+bnx2_alloc_mem(struct bnx2 *bp)
+{
+   int i, err;
+
if (BNX2_CHIP(bp) == BNX2_CHIP_5709) {
bp->ctx_pages = 0x2000 / BNX2_PAGE_SIZE;
if (bp->ctx_pages == 0)
@@ -8330,6 +8342,11 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device 
*dev)

bp->phy_addr = 1;

+   /* allocate stats_blk */
+   rc = bnx2_alloc_stats_blk(dev);
+   if (rc)
+   goto err_out_unmap;
+
/* Disable WOL support if we are running on a SERDES chip. */
if (BNX2_CHIP(bp) == BNX2_CHIP_5709)
bnx2_get_5709_media(bp);
@@ 

[PATCH 4/9] fs:ubifs: add hook for UBI bakvol in ubifs layer

[beanhuo]

Add hook for UBI bakvol in ubifs layer.

open/close bakvol operation in ubifs mount.

Signed-off-by: Bean Huo 
---
 fs/ubifs/super.c | 6 ++
 fs/ubifs/ubifs.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 9547a278..f3bf548 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1463,6 +1463,8 @@ static int mount_ubifs(struct ubifs_info *c)
dbg_gen("max. seq. number:%llu", c->max_sqnum);
dbg_gen("commit number:   %llu", c->cmt_no);
 
+   init_bakvol(c->ubi, 1);
+
return 0;
 
 out_infos:
@@ -1774,6 +1776,10 @@ static void ubifs_put_super(struct super_block *sb)
 * the mutex is locked.
 */
mutex_lock(&c->umount_mutex);
+
+   /* Disable ubi MLC power loss backup function */
+   init_bakvol(c->ubi, 0);
+
if (!c->ro_mount) {
/*
 * First of all kill the background thread to make sure it does
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index de75902..4af2d5a 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -1479,6 +1479,7 @@ extern const struct inode_operations 
ubifs_dir_inode_operations;
 extern const struct inode_operations ubifs_symlink_inode_operations;
 extern struct backing_dev_info ubifs_backing_dev_info;
 extern struct ubifs_compressor *ubifs_compressors[UBIFS_COMPR_TYPES_CNT];
+extern void init_bakvol(struct ubi_volume_desc *desc, uint8_t choice);
 
 /* io.c */
 void ubifs_ro_mode(struct ubifs_info *c, int err);
-- 
1.9.1

[PATCH 6/9] drivers:mtd:ubi:add hook for UBI bakvol in ubi_io_write

[beanhuo]

Add hook for UBI bakvol in ubi_io_write.

Modify ubi_io_write, if program lower page of MLC NAND,
Duplicated it and backup one copy into internal log volume by
Dual plane program method.

Signed-off-by: Bean Huo 
---
 drivers/mtd/ubi/io.c | 63 +---
 1 file changed, 55 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index 5bbd1f0..912c458 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
@@ -236,8 +236,9 @@ int ubi_io_write(struct ubi_device *ubi, const void *buf, 
int pnum, int offset,
 int len)
 {
int err;
-   size_t written;
+   size_t retlen;
loff_t addr;
+   int skip = 0;
 
dbg_io("write %d bytes to PEB %d:%d", len, pnum, offset);
 
@@ -281,14 +282,60 @@ int ubi_io_write(struct ubi_device *ubi, const void *buf, 
int pnum, int offset,
}
 
addr = (loff_t)pnum * ubi->peb_size + offset;
-   err = mtd_write(ubi->mtd, addr, len, &written, buf);
-   if (err) {
-   ubi_err(ubi, "error %d while writing %d bytes to PEB %d:%d, 
written %zd bytes",
-   err, len, pnum, offset, written);
-   dump_stack();
-   ubi_dump_flash(ubi, pnum, offset, len);
+
+#ifdef CONFIG_MTD_UBI_MLC_NAND_BAKVOL
+   if ((offset == 0) && (len == ubi->peb_size))
+   skip = 1;
+
+   if (ubi_check_backup_volume(ubi) && (!skip)) {
+   loff_t addr_temp;
+   unsigned char *buf_temp = (unsigned char *)buf;
+   int len_temp;
+   int writelen = 0;
+
+   addr_temp = addr;
+
+   for (len_temp = len; len_temp > 0; len_temp -= ubi->min_io_size,
+   addr_temp += ubi->min_io_size,
+   buf_temp += ubi->min_io_size) {
+   /* Split data according to min_io_size */
+
+   if (len_temp/ubi->min_io_size)
+   writelen = ubi->min_io_size;
+   else
+   writelen %= ubi->min_io_size;
+
+   if (is_backup_need(ubi, addr_temp)) {
+   err = ubi_backup_data_to_backup_volume(ubi,
+   addr_temp, writelen, &retlen, buf_temp);
+   } else
+   err = mtd_write(ubi->mtd, addr_temp, writelen,
+   &retlen, buf_temp);
+
+   if (err) {
+   ubi_err(ubi, "Writing %d byptes to PEB %d:%d",
+   writelen, pnum, offset);
+   ubi_err(ubi, "Error %d", err);
+   ubi_err(ubi, "Written %zd bytes", retlen);
+   dump_stack();
+   ubi_dump_flash(ubi, pnum, offset, writelen);
+   } else
+   ubi_assert(retlen == writelen);
+   }
} else
-   ubi_assert(written == len);
+#endif
+   {
+   err = mtd_write(ubi->mtd, addr, len, &retlen, buf);
+   if (err) {
+   ubi_err(ubi, "Writing %d byptes to PEB %d:%d",
+   len, pnum, offset);
+   ubi_err(ubi, "Error %d", err);
+   ubi_err(ubi, "Written %zd bytes", retlen);
+   dump_stack();
+   ubi_dump_flash(ubi, pnum, offset, len);
+   } else
+   ubi_assert(retlen == len);
+   }
 
if (!err) {
err = self_check_write(ubi, buf, pnum, offset, len);
-- 
1.9.1

[PATCH 1/9] drivers:nand:mtd: add support for UBI bakvol in mtd layer

[beanhuo]

Add support for UBI bakvol in mtd layer.

This solution based on MLC NAND dual plane program.
so add hook in mtd layer.

Signed-off-by: Bean Huo 
---
 include/linux/mtd/mtd.h  | 19 +++
 include/linux/mtd/nand.h |  4 
 include/linux/mtd/ubi.h  |  9 +
 3 files changed, 32 insertions(+)

diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index f17fa75..cfcb3a68 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -204,6 +204,9 @@ struct mtd_info {
  struct mtd_oob_ops *ops);
int (*_write_oob) (struct mtd_info *mtd, loff_t to,
   struct mtd_oob_ops *ops);
+   int (*_dual_plane_write_oob) (struct mtd_info *mtd, loff_t to_plane0,
+   struct mtd_oob_ops *ops_plane0, loff_t to_plane1,
+   struct mtd_oob_ops *ops_plane1);
int (*_get_fact_prot_info) (struct mtd_info *mtd, size_t len,
size_t *retlen, struct otp_info *buf);
int (*_read_fact_prot_reg) (struct mtd_info *mtd, loff_t from,
@@ -280,6 +283,22 @@ static inline int mtd_write_oob(struct mtd_info *mtd, 
loff_t to,
return mtd->_write_oob(mtd, to, ops);
 }
 
+static inline int mtd_write_dual_plane_oob(struct mtd_info *mtd,
+   loff_t to_plane0, struct mtd_oob_ops *ops0, loff_t to_plane1,
+   struct mtd_oob_ops *ops1)
+{
+   ops0->retlen = ops0->oobretlen = 0;
+   ops1->retlen = ops1->oobretlen = 0;
+
+   if (!mtd->_dual_plane_write_oob)
+   return -EOPNOTSUPP;
+   if (!(mtd->flags & MTD_WRITEABLE))
+   return -EROFS;
+
+   return mtd->_dual_plane_write_oob(mtd, to_plane0, ops0,
+   to_plane1, ops1);
+}
+
 int mtd_get_fact_prot_info(struct mtd_info *mtd, size_t len, size_t *retlen,
   struct otp_info *buf);
 int mtd_read_fact_prot_reg(struct mtd_info *mtd, loff_t from, size_t len,
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 272f429..4c5be01 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -77,6 +77,7 @@ extern int nand_unlock(struct mtd_info *mtd, loff_t ofs, 
uint64_t len);
 #define NAND_CMD_READ1 1
 #define NAND_CMD_RNDOUT5
 #define NAND_CMD_PAGEPROG  0x10
+#define NAND_CMD_MULTI_PAGEPROG0x11
 #define NAND_CMD_READOOB   0x50
 #define NAND_CMD_ERASE10x60
 #define NAND_CMD_STATUS0x70
@@ -671,6 +672,9 @@ struct nand_chip {
int (*write_page)(struct mtd_info *mtd, struct nand_chip *chip,
uint32_t offset, int data_len, const uint8_t *buf,
int oob_required, int page, int cached, int raw);
+   int (*write_plane_page)(struct mtd_info *mtd, struct nand_chip *chip,
+   uint32_t offset, int data_len, const uint8_t *buf,
+   int oob_required, int page, int plane, int raw);
int (*onfi_set_features)(struct mtd_info *mtd, struct nand_chip *chip,
int feature_addr, uint8_t *subfeature_para);
int (*onfi_get_features)(struct mtd_info *mtd, struct nand_chip *chip,
diff --git a/include/linux/mtd/ubi.h b/include/linux/mtd/ubi.h
index 1e271cb..1da3418 100644
--- a/include/linux/mtd/ubi.h
+++ b/include/linux/mtd/ubi.h
@@ -35,6 +35,15 @@
  */
 #define UBI_MAX_SG_COUNT 64
 
+enum {
+   UBI_BAKVOL_UNONE,
+   UBI_BAKVOL_INIT_INFO,
+   UBI_BAKVOL_INIT_INFO_DONE,
+   UBI_BAKVOL_INIT_VOLUME,
+   UBI_BAKVOL_INIT_VOLUME_DONE,
+   UBI_BAKVOL_RUN
+};
+
 /*
  * enum ubi_open_mode - UBI volume open mode constants.
  *
-- 
1.9.1

[PATCH 3/9] drivers:mtd:ubi:add metadata struct for UBI bakvol

[beanhuo]

Add metadata struct for UBI bakvol.
Currently , bakvol reserves 20 PEBs for internal log volume.
Shares wear-leveling operation with ubi. 


Signed-off-by: Bean Huo 
---
 drivers/mtd/ubi/ubi-media.h | 40 
 1 file changed, 40 insertions(+)

diff --git a/drivers/mtd/ubi/ubi-media.h b/drivers/mtd/ubi/ubi-media.h
index d0d072e..3315d5b 100644
--- a/drivers/mtd/ubi/ubi-media.h
+++ b/drivers/mtd/ubi/ubi-media.h
@@ -31,6 +31,7 @@
 #define __UBI_MEDIA_H__
 
 #include 
+#include 
 
 /* The version of UBI images supported by this implementation */
 #define UBI_VERSION 1
@@ -295,7 +296,11 @@ struct ubi_vid_hdr {
 } __packed;
 
 /* Internal UBI volumes count */
+#ifdef CONFIG_MTD_UBI_MLC_NAND_BAKVOL
+#define UBI_INT_VOL_COUNT 2
+#else
 #define UBI_INT_VOL_COUNT 1
+#endif
 
 /*
  * Starting ID of internal volumes: 0x7fffefff.
@@ -312,6 +317,15 @@ struct ubi_vid_hdr {
 #define UBI_LAYOUT_VOLUME_NAME   "layout volume"
 #define UBI_LAYOUT_VOLUME_COMPAT UBI_COMPAT_REJECT
 
+/* The backup log volume */
+
+#define UBI_BACKUP_VOLUME_ID (UBI_INTERNAL_VOL_START + 1)
+#define UBI_BACKUP_VOLUME_TYPE   UBI_VID_DYNAMIC
+#define UBI_BACKUP_VOLUME_ALIGN  1
+#define UBI_BACKUP_VOLUME_EBS20
+#define UBI_BACKUP_VOLUME_NAME   "log volume"
+#define UBI_BACKUP_VOLUME_COMPAT UBI_COMPAT_REJECT
+
 /* The maximum number of volumes per one UBI device */
 #define UBI_MAX_VOLUMES 128
 
@@ -325,6 +339,32 @@ struct ubi_vid_hdr {
 #define UBI_VTBL_RECORD_SIZE_CRC (UBI_VTBL_RECORD_SIZE - sizeof(__be32))
 
 /**
+ * struct ubi_bkblk_info - the information for one backup block .
+ * @pbn: physical block number
+ * @lbn:  logic block number
+ * @plane: this block belongs to which plane
+ * @pgnum: the page number (lower page) that can be programmed last time
+ */
+struct ubi_bkblk_info {
+   __be32  pbn;
+   __be32  lbn;
+   __u8plane;
+   __be32  pgnum;
+   struct  list_head node;
+};
+
+/**
+ * struct ubi_bkblk_tbl - a table for backup blocks.
+ * @volume_built: indicate if backup volume be initted
+ * @bcount_of_plane:  block count that has bee applied for corresponding plane
+ */
+struct ubi_bkblk_tbl {
+   __u8volume_built;
+   __be32  bcount_of_plane[2];
+   struct  list_head head;
+};
+
+/**
  * struct ubi_vtbl_record - a record in the volume table.
  * @reserved_pebs: how many physical eraseblocks are reserved for this volume
  * @alignment: volume alignment
-- 
1.9.1

[PATCH 9/9] driver:mtd:ubi:add bakvol module in UBI layer

[beanhuo]

Add bakvol module in UBI layer.
This patch is based on NAND dual plane program.
Currently, because different NAND vender with different paired page sequence,
so this patch now only support Micron 70s/80s/90s MLC NAND.


Signed-off-by: Bean Huo 
---
 drivers/mtd/ubi/Kconfig  |   15 +
 drivers/mtd/ubi/Makefile |2 +
 drivers/mtd/ubi/bakvol.c | 1106 ++
 3 files changed, 1123 insertions(+)
 create mode 100644 drivers/mtd/ubi/bakvol.c

diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
index f0855ce..d9f01fa 100644
--- a/drivers/mtd/ubi/Kconfig
+++ b/drivers/mtd/ubi/Kconfig
@@ -77,6 +77,21 @@ config MTD_UBI_FASTMAP
 
   If in doubt, say "N".
 
+config MTD_UBI_MLC_NAND_BAKVOL
+   bool "UBI solution for NAND pair page (Experimental feature)"
+   default n
+   help
+  This used for MLC NAND paired page power-cut protection.
+
+  MLC NAND paired page power loss is a known issue so far.
+  Namely, MLC NAND pages are coupled in a sense that if you cut
+  power while writing to a page, you corrupt not only this page,
+  but also one of the previous pages which is paired with the current
+  one. More detail information,please refer to follwoing link:
+  http://www.linux-mtd.infradead.org/doc/ubifs.html
+
+  If in doubt, say "N".
+
 config MTD_UBI_GLUEBI
tristate "MTD devices emulation driver (gluebi)"
help
diff --git a/drivers/mtd/ubi/Makefile b/drivers/mtd/ubi/Makefile
index 4e3c3d7..f8cf01c 100644
--- a/drivers/mtd/ubi/Makefile
+++ b/drivers/mtd/ubi/Makefile
@@ -5,4 +5,6 @@ ubi-y += misc.o debug.o
 ubi-$(CONFIG_MTD_UBI_FASTMAP) += fastmap.o
 ubi-$(CONFIG_MTD_UBI_BLOCK) += block.o
 
+ubi-$(CONFIG_MTD_UBI_MLC_NAND_BAKVOL) += bakvol.o
+
 obj-$(CONFIG_MTD_UBI_GLUEBI) += gluebi.o
diff --git a/drivers/mtd/ubi/bakvol.c b/drivers/mtd/ubi/bakvol.c
new file mode 100644
index 000..c2c99fd
--- /dev/null
+++ b/drivers/mtd/ubi/bakvol.c
@@ -0,0 +1,1106 @@
+/* This version ported to the Linux-UBI system by Micron
+ *
+ * Based on: Micorn APPARATUSES AND METHODS FOR MEMORY MANAGEMENT
+ *
+ */
+
+/*===
+  A UBI solution for MLC NAND powerloss
+
+  This driver implements backup lower page to a log volume.
+
+  The contents of this file are subject to the Mozilla Public
+  License Version 1.1 (the "License"); You may obtain a copy of
+  the License at http://www.mozilla.org/MPL/.But you can use this
+  file, no matter in compliance with the License or not.
+
+  The initial developer of the original code is Beanhuo
+  .  Portions created by Micorn.
+
+  Alternatively, the contents of this file may be used under the
+  terms of the GNU General Public License version 2 (the "GPL"), in
+  which case the provisions of the GPL are applicable instead of the
+  above.  If you wish to allow the use of your version of this file
+  only under the terms of the GPL and not to allow others to use
+  your version of this file under the MPL, indicate your decision
+  by deleting the provisions above and replace them with the notice
+  and other provisions required by the GPL.  If you do not delete
+  the provisions above, a recipient may use your version of this
+  file under either the MPL or the GPL.
+
+===*/
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ubi.h"
+
+u8 corruption;
+struct mtd_oob_ops *oob_ops_bak, *oob_ops_src;
+struct mtd_oob_ops *oob_ops; /* Global read/write point */
+static u8 BK_free = UBI_BACKUP_VOLUME_EBS;
+
+struct recover_data_info {
+   uint8_t perch; /* 1 used,0 free */
+   loff_t original_data_addr;  /* Orginal corrupted page address */
+   u32 original_peb;
+   u32 original_page;
+   u32 bk_pb; /* Backup block phisical num */
+   uint8_t *datbuf; /* Contains corruption page data */
+   uint8_t *oobbuf;
+};
+
+struct recover_data_info BK[UBI_BACKUP_VOLUME_EBS]; /* Backup date buffer */
+
+/* Temporary variables used during scanning */
+struct ubi_ec_hdr *ech;
+struct ubi_vid_hdr *vidh;
+
+/* Following defined Micronn NAND version */
+#define MICRON_NAND_VERSION_L7X_CONFIG 1
+#define MICRON_NAND_VERSION_L8X_CONFIG 0
+#define MICRON_NAND_VERSION_L9X_CONFIG 0
+#undef DEBUG
+
+/**
+ *  if phy_paeg_num is lower page, return 1
+ *  if phy_page_num is upper page, return 0
+ *  if phy_page_num is SLC page,return -1
+ */
+static int is_lowerpage(int phy_page_num)
+{
+
+   int ret;
+#if MICRON_NAND_VERSION_L8X_CONFIG
+   /* used for Micron L8x parallel nand */
+   switch (phy_page_num) {
+   case 2:
+   case 3:
+   case 248:
+   case 249:
+   case 252:
+   case 253:
+   case 254:
+   case 255:
+   ret = -1;/* This page belongs to SLC page. */
+   break;
+   default:
+   if (phy_page_num % 4 < 2) {
+   /* If remainder is 2,3 ,this page 

[PATCH 0/9] drivers:mtd:UBI: add bakvol module for MLC NAND paired page issue

[beanhuo]

Hello,

This series aims at adding a bakvol module for MLC NAND paired page
Power loss protection.
MLC NAND paired page power loss is a known issue so far, MLC NAND pages are
coupled in a sense that if you cut power while writing to a page, you corrupt 
not only
this page, but also one of the previous pages which is paired with the current 
one.
Currently, there is no a perfect solution for this. 
This paired page solution is based on NAND multiple plane program feature. For 
this
Patch, only used dual plane page program, means two different plane pages can
Be programmed together at the same time.
Dual plane page program only implements in backup operation. Only lower page 
data
Be duplicated and back up into a internal log volume by dual plane program 
method.

This patch has been testing on Micron 70s/80s/90s MLC NAND.
Of course there are some places needed to be improved and simplified.

Any suggestion and comments welcomed.


Bean Huo (9):
  drivers:nand:mtd: add support for UBI bakvol in mtd layer
  drivers:mtd:ubi:add definition for UBI bakvol operation
  drivers:mtd:ubi:add metadata struct for UBI bakvol
  fs:ubifs: add hook for UBI bakvol in ubifs layer
  drivers:mtd:ubi:add support for getting block according to plane
  drivers:mtd:ubi:add hook for UBI bakvol in ubi_io_write
  drivers:mtd:add NAND dual plane program support
  drivers:mtd:ubi:init UBI bakvol and recover corrupted lower page
  drivers:mtd:ubi:add bakvol module in UBI layer

 drivers/mtd/mtdpart.c|   21 +
 drivers/mtd/nand/nand_base.c |  401 +++
 drivers/mtd/ubi/Kconfig  |   15 +
 drivers/mtd/ubi/Makefile |2 +
 drivers/mtd/ubi/attach.c |   26 +-
 drivers/mtd/ubi/bakvol.c | 1106 ++
 drivers/mtd/ubi/build.c  |7 +
 drivers/mtd/ubi/io.c |   63 ++-
 drivers/mtd/ubi/ubi-media.h  |   40 ++
 drivers/mtd/ubi/ubi.h|   17 +
 drivers/mtd/ubi/wl.c |  134 +
 fs/ubifs/super.c |6 +
 fs/ubifs/ubifs.h |1 +
 include/linux/mtd/mtd.h  |   19 +
 include/linux/mtd/nand.h |4 +
 include/linux/mtd/ubi.h  |9 +
 16 files changed, 1862 insertions(+), 9 deletions(-)
 create mode 100644 drivers/mtd/ubi/bakvol.c

-- 
1.9.1
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�&j:+v�����赙zZ+��+zf＂�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

[PATCH 8/9] drivers:mtd:ubi:init UBI bakvol and recover corrupted lower page

[beanhuo]

During UBI attach, bakvol be initialized,
And if exist corrupted lower page, recover it by its backup data in internal 
Log volume.

Signed-off-by: Bean Huo 
---
 drivers/mtd/ubi/attach.c | 26 +-
 drivers/mtd/ubi/build.c  |  7 +++
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/ubi/attach.c b/drivers/mtd/ubi/attach.c
index 68eea5b..4e00d79 100644
--- a/drivers/mtd/ubi/attach.c
+++ b/drivers/mtd/ubi/attach.c
@@ -919,6 +919,17 @@ static int scan_peb(struct ubi_device *ubi, struct 
ubi_attach_info *ai,
err = ubi_io_read_vid_hdr(ubi, pnum, vidh, 0);
if (err < 0)
return err;
+
+#ifdef CONFIG_MTD_UBI_MLC_NAND_BAKVOL
+   /*
+* Before ubi scan the NAND flash, call ubi_backup_volume_scan
+* to build the backup volume first. when the ubi scan NAND and
+* find corrupt data, then we can try to check if there is backup
+* data in the backup volume.
+*/
+   ubi_backup_volume_scan(ubi, vidh, pnum);
+#endif
+
switch (err) {
case 0:
break;
@@ -995,7 +1006,8 @@ static int scan_peb(struct ubi_device *ubi, struct 
ubi_attach_info *ai,
*vid = vol_id;
if (sqnum)
*sqnum = be64_to_cpu(vidh->sqnum);
-   if (vol_id > UBI_MAX_VOLUMES && vol_id != UBI_LAYOUT_VOLUME_ID) {
+   if ((vol_id > UBI_MAX_VOLUMES && vol_id != UBI_LAYOUT_VOLUME_ID)
+   && vol_id != UBI_BACKUP_VOLUME_ID) {
int lnum = be32_to_cpu(vidh->lnum);
 
/* Unsupported internal volume */
@@ -1408,6 +1420,12 @@ int ubi_attach(struct ubi_device *ubi, int force_scan)
if (!ai)
return -ENOMEM;
 
+#ifdef CONFIG_MTD_UBI_MLC_NAND_BAKVOL
+   err = ubi_backup_volume_init(ubi);
+   if (err)
+   goto out_ai;
+#endif
+
 #ifdef CONFIG_MTD_UBI_FASTMAP
/* On small flash devices we disable fastmap in any case. */
if ((int)mtd_div_by_eb(ubi->mtd->size, ubi->mtd) <= UBI_FM_MAX_START) {
@@ -1449,6 +1467,12 @@ int ubi_attach(struct ubi_device *ubi, int force_scan)
if (err)
goto out_ai;
 
+#ifdef CONFIG_MTD_UBI_MLC_NAND_BAKVOL
+   err = ubi_backup_volume_init_tail(ubi, ai);
+   if (err)
+   goto out_ai;
+#endif
+
err = ubi_wl_init(ubi, ai);
if (err)
goto out_vtbl;
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 22fd19c..05524f7 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -1033,6 +1033,11 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num,
 
ubi_devices[ubi_num] = ubi;
ubi_notify_all(ubi, UBI_VOLUME_ADDED, NULL);
+
+#ifdef CONFIG_MTD_UBI_MLC_NAND_BAKVOL
+   ubi_bad_data_recovery(ubi);
+#endif
+
return ubi_num;
 
 out_debugfs:
@@ -1118,6 +1123,8 @@ int ubi_detach_mtd_dev(int ubi_num, int anyway)
 */
get_device(&ubi->dev);
 
+   clear_bakvol(ubi);
+
ubi_debugfs_exit_dev(ubi);
uif_close(ubi);
 
-- 
1.9.1

Re: [PATCH 1/1] dmaengine: dw: resolve recursion lock when audio playback

[Andy Shevchenko]

On Mon, Sep 28, 2015 at 6:23 AM, Viresh Kumar  wrote:
> On 26 September 2015 at 05:38, yitian  wrote:
>> when audio playback is running, user space will call
>> snd_pcm_lib_write1() function, it will first get pcm stream lock,
>> after that it may call function snd_pcm_update_hw_ptr(), the call
>> stack will be as below:
>>   snd_pcm_lib_write1  <-- got pcm stream lock
>>--> snd_pcm_update_hw_ptr
>>  --> dwc_tx_status
>>   --> dwc_scan_descriptors
>>--> callback
>> --> dmaengine_pcm_dma_complete
>>  --> snd_pcm_period_elapsed <-- get stream lock again
>> recursion lock occurs in snd_pcm_period_elapsed function.
>> remove dwc_scan_descriptors from dwc_tx_status can fix this issue.
>>
>> Signed-off-by: Yitian Bu 
>> ---
>>  drivers/dma/dw/core.c | 6 +-
>>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> I am not sure if this is a sane way of doing that, and we were scanning
> the descriptors for some valid reason..

Actually one of the patches in a pile sitting in my private repo is
also including similar change. In my case the reason is to support
cyclic transfers natively.

> Though, I am on vacation for few days now and will be able to look
> at the details later.

Have a good rest then!

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

[PATCH 7/9] drivers:mtd:add NAND dual plane program support

[beanhuo]

Add NAND dual plane program function.

Signed-off-by: Bean Huo 
---
 drivers/mtd/mtdpart.c|  21 +++
 drivers/mtd/nand/nand_base.c | 401 +++
 2 files changed, 422 insertions(+)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index cafdb88..3ee96e7 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -147,6 +147,7 @@ static int part_read_user_prot_reg(struct mtd_info *mtd, 
loff_t from,
size_t len, size_t *retlen, u_char *buf)
 {
struct mtd_part *part = PART(mtd);
+
return part->master->_read_user_prot_reg(part->master, from, len,
 retlen, buf);
 }
@@ -155,6 +156,7 @@ static int part_get_user_prot_info(struct mtd_info *mtd, 
size_t len,
   size_t *retlen, struct otp_info *buf)
 {
struct mtd_part *part = PART(mtd);
+
return part->master->_get_user_prot_info(part->master, len, retlen,
 buf);
 }
@@ -203,6 +205,23 @@ static int part_write_oob(struct mtd_info *mtd, loff_t to,
return part->master->_write_oob(part->master, to + part->offset, ops);
 }
 
+static int part_write_dual_plane_oob(struct mtd_info *mtd, loff_t to_plane0,
+   struct mtd_oob_ops *ops_plane0, loff_t to_plane1,
+   struct mtd_oob_ops *ops_plane1)
+{
+   struct mtd_part *part = PART(mtd);
+
+   if ((to_plane0 >= mtd->size) || ((to_plane1 >= mtd->size)))
+   return -EINVAL;
+   if ((ops_plane0->datbuf && to_plane0 + ops_plane0->len > mtd->size) ||
+   (ops_plane1->datbuf && to_plane1 + ops_plane0->len > mtd->size))
+   return -EINVAL;
+
+   return part->master->_dual_plane_write_oob(part->master,
+   to_plane0 + part->offset, ops_plane0,
+   to_plane1 + part->offset, ops_plane1);
+}
+
 static int part_write_user_prot_reg(struct mtd_info *mtd, loff_t from,
size_t len, size_t *retlen, u_char *buf)
 {
@@ -409,6 +428,8 @@ static struct mtd_part *allocate_partition(struct mtd_info 
*master,
slave->mtd._read_oob = part_read_oob;
if (master->_write_oob)
slave->mtd._write_oob = part_write_oob;
+   if (master->_dual_plane_write_oob)
+   slave->mtd._dual_plane_write_oob = part_write_dual_plane_oob;
if (master->_read_user_prot_reg)
slave->mtd._read_user_prot_reg = part_read_user_prot_reg;
if (master->_read_fact_prot_reg)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ceb68ca..bcc9e92 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2249,6 +2249,75 @@ static int nand_write_page_syndrome(struct mtd_info *mtd,
 
return 0;
 }
+/**
+ * nand_write_plane_page - [REPLACEABLE] write one page
+ * @mtd: MTD device structure
+ * @chip: NAND chip descriptor
+ * @offset: address offset within the page
+ * @data_len: length of actual data to be written
+ * @buf: the data to write
+ * @oob_required: must write chip->oob_poi to OOB
+ * @page: page number to write
+ * @plane: multiple plane programming
+ * @raw: use _raw version of write_page
+ */
+static int nand_write_plane_page(struct mtd_info *mtd, struct nand_chip *chip,
+   uint32_t offset, int data_len, const uint8_t *buf,
+   int oob_required, int page, int plane, int raw)
+{
+   int status, subpage;
+
+   if (!(chip->options & NAND_NO_SUBPAGE_WRITE) &&
+   chip->ecc.write_subpage)
+   subpage = offset || (data_len < mtd->writesize);
+   else
+   subpage = 0;
+
+   chip->cmdfunc(mtd, NAND_CMD_SEQIN, 0x00, page);
+
+   if (unlikely(raw))
+   status = chip->ecc.write_page_raw(mtd, chip, buf,
+   oob_required);
+   else if (subpage)
+   status = chip->ecc.write_subpage(mtd, chip, offset, data_len,
+   buf, oob_required);
+   else
+   status = chip->ecc.write_page(mtd, chip, buf, oob_required);
+
+   if (status < 0)
+   return status;
+
+   /* Multipal plane progamming */
+   if (plane) {
+   chip->cmdfunc(mtd, NAND_CMD_MULTI_PAGEPROG, -1, -1);
+   status = chip->waitfunc(mtd, chip);
+   /*
+* See if operation failed and additional status checks are
+* available.
+*/
+   if ((status & NAND_STATUS_FAIL) && (chip->errstat))
+   status = chip->errstat(mtd, chip, FL_WRITING, status, page);
+
+   if (status & NAND_STATUS_FAIL)
+   return -EIO;
+
+   } else if (!plane || !NAND_HAS_CACHEPROG(chip)) {
+
+   chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1

[PATCH 5/9] drivers:mtd:ubi:add support for getting block according to plane

[beanhuo]

Dual plane program must address two blocks located two different planes.


Signed-off-by: Bean Huo 
---
 drivers/mtd/ubi/wl.c | 134 +++
 1 file changed, 134 insertions(+)

diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 275d9fb..9d2268a 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -140,6 +140,7 @@ static int self_check_in_wl_tree(const struct ubi_device 
*ubi,
 struct ubi_wl_entry *e, struct rb_root *root);
 static int self_check_in_pq(const struct ubi_device *ubi,
struct ubi_wl_entry *e);
+static int produce_free_peb(struct ubi_device *ubi);
 
 /**
  * wl_tree_add - add a wear-leveling entry to a WL RB-tree.
@@ -371,6 +372,72 @@ static struct ubi_wl_entry *find_mean_wl_entry(struct 
ubi_device *ubi,
return e;
 }
 
+static struct ubi_wl_entry *find_wl_plane_entry(struct ubi_device *ubi,
+   struct rb_root *root, int diff, int plane)
+{
+   struct rb_node *p;
+   struct ubi_wl_entry *e, *prev_e = NULL, *prev_bk_e = NULL, *bk_e = NULL;
+   int max;
+
+   e = rb_entry(rb_first(root), struct ubi_wl_entry, u.rb);
+   max = e->ec + diff;
+
+   p = root->rb_node;
+   while (p) {
+   struct ubi_wl_entry *e1;
+
+   e1 = rb_entry(p, struct ubi_wl_entry, u.rb);
+   if (e1->ec >= max)
+   p = p->rb_left;
+   else {
+   p = p->rb_right;
+   prev_e = e;
+
+   if (e->pnum%2 == plane)
+   prev_bk_e = e;
+
+   e = e1;
+
+   if (e1->pnum%2 == plane)
+   bk_e = e1;
+   }
+   }
+
+   /**
+   *If no fastmap has been written and this WL entry can be used
+   * as anchor PEB, hold it back and return the second best WL entry
+   * such that fastmap can use the anchor PEB later.
+   **/
+   if (prev_bk_e && !ubi->fm_disabled &&
+   !ubi->fm && bk_e->pnum < UBI_FM_MAX_START)
+   return prev_bk_e;
+
+   return bk_e;
+}
+
+static struct ubi_wl_entry *find_mean_plane_wl_entry(struct ubi_device *ubi,
+   struct rb_root *root, int plane)
+{
+   struct ubi_wl_entry *e, *first, *last;
+
+   first = rb_entry(rb_first(root), struct ubi_wl_entry, u.rb);
+   last = rb_entry(rb_last(root), struct ubi_wl_entry, u.rb);
+
+   e = rb_entry(root->rb_node, struct ubi_wl_entry, u.rb);
+
+   if ((last->ec - first->ec < WL_FREE_MAX_DIFF) && (e->pnum%2 == plane)) {
+#ifdef CONFIG_MTD_UBI_FASTMAP
+   /* If no fastmap has been written and this WL entry can be used
+* as anchor PEB, hold it back and return the second best
+* WL entry such that fastmap can use the anchor PEB later. */
+   e = may_reserve_for_fm(ubi, e, root);
+#endif
+   } else
+   e = find_wl_plane_entry(ubi, root, WL_FREE_MAX_DIFF/2, plane);
+
+   return e;
+}
+
 /**
  * wl_get_wle - get a mean wl entry to be used by ubi_wl_get_peb() or
  * refill_wl_user_pool().
@@ -1751,6 +1818,50 @@ static int self_check_in_pq(const struct ubi_device *ubi,
dump_stack();
return -EINVAL;
 }
+
+static int __wl_get_plane_peb(struct ubi_device *ubi, int plane)
+{
+   int err;
+   struct ubi_wl_entry *e;
+
+retry:
+   if (!ubi->free.rb_node) {
+   if (ubi->works_count == 0) {
+   ubi_err(ubi, "no free eraseblocks");
+   ubi_assert(list_empty(&ubi->works));
+   return -ENOSPC;
+   }
+
+   err = produce_free_peb(ubi);
+   if (err < 0)
+   return err;
+   goto retry;
+   }
+
+   e = find_mean_plane_wl_entry(ubi, &ubi->free, plane);
+   if (!e) {
+   ubi_err(ubi, "no free eraseblocks");
+   return -ENOSPC;
+   }
+
+   self_check_in_wl_tree(ubi, e, &ubi->free);
+
+   /*
+* Move the physical eraseblock to the protection queue where it will
+* be protected from being moved for some time.
+*/
+   rb_erase(&e->u.rb, &ubi->free);
+   ubi->free_count--;
+   dbg_wl("PEB %d EC %d", e->pnum, e->ec);
+#ifndef CONFIG_MTD_UBI_FASTMAP
+   /* We have to enqueue e only if fastmap is disabled,
+* is fastmap enabled prot_queue_add() will be called by
+* ubi_wl_get_peb() after removing e from the pool. */
+   prot_queue_add(ubi, e);
+#endif
+   return e->pnum;
+}
+
 #ifndef CONFIG_MTD_UBI_FASTMAP
 static struct ubi_wl_entry *get_peb_for_wl(struct ubi_device *ubi)
 {
@@ -1839,6 +1950,29 @@ retry:
 
return e->pnum;
 }
+
+int ubi_wl_get_plane_peb(struct ubi_device *ubi, int plane)
+{
+   int peb, err;
+
+   spin_lock(&ubi

[PATCH 2/9] drivers:mtd:ubi:add definition for UBI bakvol operation

[beanhuo]

Add macro definition for UBI bakvol operation.

Signed-off-by: Bean Huo 
---
 drivers/mtd/ubi/ubi.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
index 2974b67..746dfbe 100644
--- a/drivers/mtd/ubi/ubi.h
+++ b/drivers/mtd/ubi/ubi.h
@@ -438,6 +438,7 @@ struct ubi_debug_info {
  * @vtbl_slots: how many slots are available in the volume table
  * @vtbl_size: size of the volume table in bytes
  * @vtbl: in-RAM volume table copy
+ * @bkblk_tbl: backup block table
  * @device_mutex: protects on-flash volume table and serializes volume
  *creation, deletion, update, re-size, re-name and set
  *property
@@ -547,6 +548,7 @@ struct ubi_device {
int vtbl_slots;
int vtbl_size;
struct ubi_vtbl_record *vtbl;
+   struct ubi_bkblk_tbl *bkblk_tbl;
struct mutex device_mutex;
 
int max_ec;
@@ -797,6 +799,20 @@ int ubi_vtbl_rename_volumes(struct ubi_device *ubi,
struct list_head *rename_list);
 int ubi_read_volume_table(struct ubi_device *ubi, struct ubi_attach_info *ai);
 
+/* bakvol.c*/
+int ubi_check_backup_volume(struct ubi_device *ubi);
+int ubi_backup_data_to_backup_volume(struct ubi_device *ubi, loff_t addr,
+   size_t len, size_t *retlen, const void *buf);
+int ubi_backup_volume_init(struct ubi_device *ubi);
+int ubi_backup_volume_scan(struct ubi_device *ubi,
+   struct ubi_vid_hdr *vidh, int pnum);
+int ubi_backup_volume_init_tail(struct ubi_device *ubi,
+   struct ubi_attach_info *si);
+int ubi_bad_data_recovery(struct ubi_device *ubi);
+int is_backup_need(struct ubi_device *ubi, loff_t addr);
+void init_bakvol(struct ubi_volume_desc *desc, uint8_t choice);
+void clear_bakvol(struct ubi_device *ubi);
+
 /* vmt.c */
 int ubi_create_volume(struct ubi_device *ubi, struct ubi_mkvol_req *req);
 int ubi_remove_volume(struct ubi_volume_desc *desc, int no_vtbl);
@@ -846,6 +862,7 @@ int self_check_eba(struct ubi_device *ubi, struct 
ubi_attach_info *ai_fastmap,
 
 /* wl.c */
 int ubi_wl_get_peb(struct ubi_device *ubi);
+int ubi_wl_get_plane_peb(struct ubi_device *ubi, int plane);
 int ubi_wl_put_peb(struct ubi_device *ubi, int vol_id, int lnum,
   int pnum, int torture);
 int ubi_wl_flush(struct ubi_device *ubi, int vol_id, int lnum);
-- 
1.9.1

RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

[河合英宏 / KAWAI，HIDEHIRO]

> Hi Hidehiro,
> 
> [auto build test results on v4.3-rc2 -- if it's inappropriate base, please 
> ignore]
> 
> config: ia64-allyesconfig (attached as .config)
> reproduce:
>   wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
>   chmod +x ~/bin/make.cross
>   git checkout 0077681103150af584e5e592c0238fd010654c26
>   # save the attached .config to linux build tree
>   make.cross ARCH=ia64
[snip]
>arch/ia64/include/uapi/asm/cmpxchg.h:56:2: warning: value computed is not 
> used [-Wunused-value]
> ((__typeof__(*(ptr))) __xchg((unsigned long) (x), (ptr), sizeof(*(ptr
>  ^
>arch/ia64/include/asm/atomic.h:135:30: note: in expansion of macro 'xchg'
> #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
>  ^
> >> kernel/kexec_core.c:899:3: note: in expansion of macro 'atomic_xchg'
>   atomic_xchg(&panic_cpu, -1);
>   ^

I changed to use atomic_xchg() instead of atomic_set() in V3
because atomic_set() doesn't mean memory barrier.  However,
I thought again and there is no need of barrier; there is no
problem if a competitor sees old value of panic_cpu or new one.
So, atomic_set() is sufficient and using it will remove this warning.

I will resend the fixed version later.

> vim +/atomic_xchg +899 kernel/kexec_core.c
> 
>883
>884/*
>885 * Only one CPU is allowed to execute the crash_kexec() 
> code as with
>886 * panic().  Otherwise parallel calls of panic() and 
> crash_kexec()
>887 * may stop each other.  To exclude them, we use 
> panic_cpu here too.
>888 */
>889this_cpu = raw_smp_processor_id();
>890old_cpu = atomic_cmpxchg(&panic_cpu, -1, this_cpu);
>891if (old_cpu == -1) {
>892/* This is the 1st CPU which comes here, so go 
> ahead. */
>893__crash_kexec(regs);
>894
>895/*
>896 * Reset panic_cpu to allow another 
> panic()/crash_kexec()
>897 * call.
>898 */
>  > 899atomic_xchg(&panic_cpu, -1);
>900}
>901}
>902
>903size_t crash_get_memory_size(void)
>904{
>905size_t size = 0;
>906
>907mutex_lock(&kexec_mutex);
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

Re: [PATCH] cpufreq: p4-clockmod: Replace bool_int_array[NR_CPUS] with bitmap

[Jean Delvare]

On Sun, 27 Sep 2015 19:58:11 +0200, Denys Vlasenko wrote:
> On 09/27/2015 06:10 PM, Jean Delvare wrote:
> > Looks good, however I think you should #include  to
> > avoid build failures in the future or on certain architectures.
> 
>  already includes 
> on any arch.

Today it does. Tomorrow, who knows.

> p4-clockmod.c builds only on x86 arch, it's Pentium 4
> on demand clock modulation/speed scaling module.

That is a valid point. My comment was generic, I did not pay attention
to the specific driver.

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

Re: [RFC PATCH] drm/i915: PSR regressions on Broadwell

[Jani Nikula]

On Sat, 26 Sep 2015, Brian Norris  wrote:
> When using PSR, I see the screen freeze after only a few frames (sometimes a
> split second; sometimes it seems like practically the first frame). Bisecting
> led me to commit 3301d4092106 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT
> logic") in v4.2. This patch is the simplest fix that gets it working again for
> me, but it's probably wrong.
>
> Random thought: perhaps my panel's DPCD is programmed incorrectly?
>
> Anyway, any tips on fixing this properly?

Here's a thought:

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index a04b4dc5ed9b..3a911d4a2308 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -274,6 +274,8 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp)
idle_frames += 4;
}
 
+   idle_frames = clamp(idle_frames, 0, 15);
+
I915_WRITE(EDP_PSR_CTL(dev), val |
   (IS_BROADWELL(dev) ? 0 : link_entry_time) |
   max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT |

We do clamp the VBT value to range 0..15, but then go on to add to it.

Otherwise, up to Rodrigo I guess.

BR,
Jani.


>
> Seen on Chromebook Pixel 2.
>
> Also required this patch to get PSR properly running on 4.3-rc2:
>
> https://patchwork.freedesktop.org/patch/57698/
>
> Signed-off-by: Brian Norris 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 7e335a8546f6..4cd33b76b8a6 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -261,7 +261,8 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   uint32_t val = 0x0;
>   const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
>  
> - if (intel_dp->psr_dpcd[1] & DP_PSR_NO_TRAIN_ON_EXIT) {
> + if ((intel_dp->psr_dpcd[1] & DP_PSR_NO_TRAIN_ON_EXIT) &&
> + !IS_BROADWELL(dev)) {
>   /* It doesn't mean we shouldn't send TPS patters, so let's
>  send the minimal TP1 possible and skip TP2. */
>   val |= EDP_PSR_TP1_TIME_100us;
> -- 
> 2.6.0.rc2.230.g3dd15c0
>

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kexec: fix out of the ELF headers buffer issue in syscall kexec_file_load()

[Baoquan He]

Hi Chun-Yi,

On 09/28/15 at 02:41pm, Lee, Chun-Yi wrote:
> On big machines have CPU number that's very nearly to consume whole ELF
> headers buffer that's page aligned, 4096, 8192... Then the page fault error
> randomly happened.
> 
> This patch modified the code in fill_up_crash_elf_data() by using
> walk_system_ram_res() instead of walk_system_ram_range() to count the max
> number of crash memory ranges. That's because the walk_system_ram_range()
> filters out small memory regions that reside the same page, but
> walk_system_ram_res() does not.
> 
> The oringial page fault issue sometimes happened on big machines when
> preparing ELF headers:
> 
> [  305.291522] BUG: unable to handle kernel paging request at c90613fc9000
> [  305.299621] IP: [] 
> prepare_elf64_ram_headers_callback+0x165/0x260
> [  305.308300] PGD e32067 PUD 6dcbec54067 PMD 9dc9bdeb067 PTE 0
> [  305.315393] Oops: 0002 [#1] SMP
> [...snip]
> [  305.420953] task: 8e1c01ced600 ti: 8e1c03ec2000 task.ti: 
> 8e1c03ec2000
> [  305.429292] RIP: 0010:[]  [] 
> prepare_elf64_ra
> m_headers_callback+0x165/0x260
> [...snip]
> 
> After tracing prepare_elf64_headers() and 
> prepare_elf64_ram_headers_callback(),
> the code uses walk_system_ram_res() to fill-in crash memory regions 
> information
> to program header, so it counts those small memory regions that reside in a
> page area. But, when kernel was using walk_system_ram_range() in
> fill_up_crash_elf_data() to count the number of crash memory regions, it
> filters out small regions.
> 
> I printed those small memory regions, for example:
> 
> kexec: Get nr_ram ranges. vaddr=0x880077592258 paddr=0x77592258, sz=0xdc0
> 
> Base on the logic of walk_system_ram_range(), this memory region will be
> filter out:
> 
> pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
> end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
> end_pfn - pfn = 0x77593 - 0x77593 = 0  <=== if (end_pfn > pfn)  [FAIL]
> 
> So, the max_nr_ranges that counted by kernel doesn't include small memory
> regions. That causes the page fault issue happened in later code path for
> preparing EFL headers,
> 
> This issue was hided on small machine that doesn't have too many CPU because
> the free space of ELF headers buffer can cover the number of small memory
> regions. But, when the machine has more CPUs or the number of memory regions
> very nearly to consume whole page aligned buffer, e.g. 4096, 8192... Then
> issue will happen randomly.

It's a good finding and fix sounds reasonable. I didn't get why too many
CPUs will cause this bug. From your big machine can you check which
regions they are and what they are used for? I guess you mean the
crash_notes region, but not very sure.

> 
> Signed-off-by: Lee, Chun-Yi 
> ---
>  arch/x86/kernel/crash.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index e068d66..ad273b3d 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -185,8 +185,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
>  }
>  
>  #ifdef CONFIG_KEXEC_FILE
> -static int get_nr_ram_ranges_callback(unsigned long start_pfn,
> - unsigned long nr_pfn, void *arg)
> +static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
>  {
>   int *nr_ranges = arg;
>  
> @@ -214,7 +213,7 @@ static void fill_up_crash_elf_data(struct crash_elf_data 
> *ced,
>  
>   ced->image = image;
>  
> - walk_system_ram_range(0, -1, &nr_ranges,
> + walk_system_ram_res(0, -1, &nr_ranges,
>   get_nr_ram_ranges_callback);
>  
>   ced->max_nr_ranges = nr_ranges;
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linux v4.2] workqueue: llvmlinux: acpid: BUG: sleeping function called from invalid context at kernel/workqueue.c:2680

[Sedat Dilek]

On Mon, Sep 28, 2015 at 8:50 AM, Sedat Dilek  wrote:
> [ CC only relevant people plus Paul as he took care in another thread ]
>
> First of all, sorry for flooding anybody or any mailing-list.
>
> Of course, using LLVM/Clang for the Linux-kernel is still WIP, but
> this does not mean using a different compiler does not find any
> bugs...
>
> Fascinated somehow of this problem I entered the "tracing" area.
> I played a bit with tracing and irq-flags (hardirqs).
>
> This is what I discovered now.
>
> [ TEST-1 ]
>
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -731,6 +731,7 @@ void usbhid_close(struct hid_device *hid)
>  */
> spin_lock_irq(&usbhid->lock);
> if (!--hid->open) {
> +   trace_hardirqs_off();
> spin_unlock_irq(&usbhid->lock);
> hid_cancel_delayed_stuff(usbhid);
> if (!(hid->quirks & HID_QUIRK_ALWAYS_POLL)) {
> @@ -1392,6 +1393,8 @@ static void usbhid_disconnect(struct usb_interface 
> *intf)
>
>  static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid)
>  {
> +   might_sleep();
> +
> del_timer_sync(&usbhid->io_retry);
> cancel_work_sync(&usbhid->reset_work);
>  }
>
> This makes the BUG line go away - only changes in the HID area.
>
> [ TEST-2 ]
>
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -732,6 +732,7 @@ void usbhid_close(struct hid_device *hid)
> spin_lock_irq(&usbhid->lock);
> if (!--hid->open) {
> spin_unlock_irq(&usbhid->lock);
> +   trace_hardirqs_off();
> hid_cancel_delayed_stuff(usbhid);
> if (!(hid->quirks & HID_QUIRK_ALWAYS_POLL)) {
> usb_kill_urb(usbhid->urbin);
> @@ -1392,6 +1393,8 @@ static void usbhid_disconnect(struct usb_interface 
> *intf)
>
>  static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid)
>  {
> +   might_sleep();
> +
> del_timer_sync(&usbhid->io_retry);
> cancel_work_sync(&usbhid->reset_work);
>  }
>
> This results in...
>
> [   23.236024] BUG: sleeping function called from invalid context at
> drivers/hid/usbhid/hid-core.c:1396
> [   23.236148] in_atomic(): 0, irqs_disabled(): 1, pid: 1419, name: acpid
> [   23.236233] 3 locks held by acpid/1419:
> [   23.236235]  #0:  (&evdev->mutex){+.+...}, at: []
> evdev_release+0xbc/0xf0
> [   23.236250]  #1:  (&dev->mutex#2){+.+...}, at: []
> input_close_device+0x27/0x70
> [   23.236264]  #2:  (hid_open_mut){+.+...}, at: []
> usbhid_close+0x28/0xd0 [usbhid]
> [   23.236277] irq event stamp: 3406
> [   23.236280] hardirqs last  enabled at (3405): []
> _raw_spin_unlock_irq+0x32/0x60
> [   23.236286] hardirqs last disabled at (3406): []
> usbhid_close+0x5d/0xd0 [usbhid]
> [   23.236292] softirqs last  enabled at (2806): []
> local_bh_enable+0x9/0x20
> [   23.236298] softirqs last disabled at (2804): []
> local_bh_disable+0x9/0x20
> [   23.236306] CPU: 3 PID: 1419 Comm: acpid Not tainted
> 4.3.0-rc3-4-llvmlinux-amd64 #3
> [   23.236309] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> [   23.236313]  8800c760b000 0096 
> 8800bce53c88
> [   23.236320]  8149cabd 8800bce53cb8 810cd5aa
> a009780c
> [   23.236328]  8800c5fd5740  0574
> 8800bce53cf8
> [   23.236334] Call Trace:
> [   23.236342]  [] dump_stack+0x7d/0xa0
> [   23.236347]  [] ___might_sleep+0x28a/0x2a0
> [   23.236351]  [] __might_sleep+0x4f/0xc0
> [   23.236357]  [] usbhid_close+0x75/0xd0 [usbhid]
> [   23.236366]  [] hidinput_close+0x31/0x40 [hid]
> [   23.236373]  [] ? hidinput_open+0x40/0x40 [hid]
> [   23.236378]  [] input_close_device+0x48/0x70
> [   23.236382]  [] evdev_release+0xd6/0xf0
> [   23.236387]  [] __fput+0x107/0x240
> [   23.236392]  [] fput+0x16/0x20
> [   23.236397]  [] task_work_run+0x6c/0xe0
> [   23.236403]  [] prepare_exit_to_usermode+0x13a/0x140
> [   23.236408]  [] syscall_return_slowpath+0x281/0x2f0
> [   23.236414]  [] ? filp_close+0x65/0x90
> [   23.236420]  [] ? trace_hardirqs_on_caller+0x19/0x290
> [   23.236425]  [] ? trace_hardirqs_on_thunk+0x17/0x19
> [   23.236431]  [] int_ret_from_sys_call+0x25/0x9f
>
> I will not do a statement :-).
>
> Looking at TEST-1, the spin_unlock_irq() within the if-statement seems
> to do cause problems with tracing / irq-flags.
>
> I have added my kernel-config, llvmlinux patchset, diffs with
> corresponding dmesg-logs (look into the attached tarball).
>
> Hope this really helps you.
>

I looked over some commits which had problems with tracing and
irq-flags (hardirq)...

[ TEST-3 ]

I am not an locking expert, when I replace...

spin_{un}lock_irq() with spin_{un}lock_bh()

...within usbhid_close() in drivers/hid/usbhid/hid-core.c...

This makes the BUG line go away for me.

--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hi

[PATCH 0/1] tip-queue 2015-09-28

[Borislav Petkov]

From: Borislav Petkov 

Hi Ingo,

just one this week. It is for tip/x86/ras and it corrects what we should
be actually doing in the MCA code when offlining a CPU on Intel.

Thanks.

Ashok Raj (1):
  x86/mce: Don't clear shared banks on Intel when offlining CPUs

 arch/x86/kernel/cpu/mcheck/mce.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

-- 
2.3.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] x86/mce: Don't clear shared banks on Intel when offlining CPUs

[Borislav Petkov]

From: Ashok Raj 

It is not safe to clear global MCi_CTL banks during CPU offline or
suspend/resume operations. These MSRs are either thread-scoped (meaning
private to a thread), or core-scoped (private to threads in that core
only), or with a socket scope: visible and controllable from all threads
in the socket.

When we offline a single CPU, clearing those MCi_CTL bits will stop
signaling for all the shared, i.e., socket-wide resources, such as LLC,
iMC, etc.

In addition, it might be possible to compromise the integrity of an
Intel Secure Guard eXtentions (SGX) system if the attacker has control
of the host system and is able to inject errors which would be otherwise
ignored when MCi_CTL bits are cleared.

Hence on SGX enabled systems, if MCi_CTL is cleared, SGX gets disabled.

Reviewed-by: Tony Luck 
Tested-by: Serge Ayoun 
Signed-off-by: Ashok Raj 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Serge Ayoun 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: linux-edac 
Cc: x86-ml 
Link: 
http://lkml.kernel.org/r/1441391390-16985-1-git-send-email-ashok@intel.com
[ Cleanup text. ]
Signed-off-by: Borislav Petkov 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 9d014b82a124..17b5ec6edcb6 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -2042,7 +2042,7 @@ int __init mcheck_init(void)
  * Disable machine checks on suspend and shutdown. We can't really handle
  * them later.
  */
-static int mce_disable_error_reporting(void)
+static void mce_disable_error_reporting(void)
 {
int i;
 
@@ -2052,17 +2052,32 @@ static int mce_disable_error_reporting(void)
if (b->init)
wrmsrl(MSR_IA32_MCx_CTL(i), 0);
}
-   return 0;
+   return;
+}
+
+static void vendor_disable_error_reporting(void)
+{
+   /*
+* Don't clear on Intel CPUs. Some of these MSRs are socket-wide.
+* Disabling them for just a single offlined CPU is bad, since it will
+* inhibit reporting for all shared resources on the socket like the
+* last level cache (LLC), the integrated memory controller (iMC), etc.
+*/
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
+   return;
+
+   mce_disable_error_reporting();
 }
 
 static int mce_syscore_suspend(void)
 {
-   return mce_disable_error_reporting();
+   vendor_disable_error_reporting();
+   return 0;
 }
 
 static void mce_syscore_shutdown(void)
 {
-   mce_disable_error_reporting();
+   vendor_disable_error_reporting();
 }
 
 /*
@@ -2342,19 +2357,14 @@ static void mce_device_remove(unsigned int cpu)
 static void mce_disable_cpu(void *h)
 {
unsigned long action = *(unsigned long *)h;
-   int i;
 
if (!mce_available(raw_cpu_ptr(&cpu_info)))
return;
 
if (!(action & CPU_TASKS_FROZEN))
cmci_clear();
-   for (i = 0; i < mca_cfg.banks; i++) {
-   struct mce_bank *b = &mce_banks[i];
 
-   if (b->init)
-   wrmsrl(MSR_IA32_MCx_CTL(i), 0);
-   }
+   vendor_disable_error_reporting();
 }
 
 static void mce_reenable_cpu(void *h)
-- 
2.3.5

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

Re: [PATCH 2/2] x86/cpu/cacheinfo: amd_get/set_l3_disable_slot should be static

[Borislav Petkov]

On Sun, Sep 27, 2015 at 11:40:46PM +0800, Geliang Tang wrote:
> Fixes the following sparse warnings:
> 
>  arch/x86/kernel/cpu/intel_cacheinfo.c:329:5: warning: symbol
>  'amd_get_l3_disable_slot' was not declared. Should it be static?
> 
>  arch/x86/kernel/cpu/intel_cacheinfo.c:406:5: warning: symbol
>  'amd_set_l3_disable_slot' was not declared. Should it be static?
> 
> Signed-off-by: Geliang Tang 
> ---
>  arch/x86/kernel/cpu/intel_cacheinfo.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Both applied,
thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] dmaengine: dw: resolve recursion lock when audio playback

[yitian]

> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> Sent: Monday, September 28, 2015 3:06 PM
> To: Viresh Kumar 
> Cc: yitian ; Viresh Kumar
> ; Andy Shevchenko
> ; Vinod Koul ;
> Dan Williams ; dmaengine
> ; Linux Kernel Mailing List
> 
> Subject: Re: [PATCH 1/1] dmaengine: dw: resolve recursion 
> > I am not sure if this is a sane way of doing that, and we were scanning
> > the descriptors for some valid reason..
> 
> Actually one of the patches in a pile sitting in my private repo is
> also including similar change. In my case the reason is to support
> cyclic transfers natively.
> 

Yes, i am using DW DMAC to support cyclic transfer.
Currently it is very easy to get recursion lock crash, but
after this patch everything is fine on my device.
I am waiting for your further guide.
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] CHROMIUM: iio: Add Dyna-Image AP3223 ambient light and proximity driver

[Suresh Rajashekara]

Minimal implementation. This is based on the driver provided by
the vendor (which wasn't in the IIO framework). Authors of the
driver from the vendor included
* John Huang 
* Templeton Tsai 
* Vic Lee 

Signed-off-by: Suresh Rajashekara 
---
 .../devicetree/bindings/iio/light/ap3223.txt   |  18 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 drivers/iio/light/Kconfig  |  10 +
 drivers/iio/light/Makefile |   1 +
 drivers/iio/light/ap3223.c | 394 +
 drivers/iio/light/ap3223.h | 227 
 6 files changed, 651 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/ap3223.txt
 create mode 100644 drivers/iio/light/ap3223.c
 create mode 100644 drivers/iio/light/ap3223.h

diff --git a/Documentation/devicetree/bindings/iio/light/ap3223.txt 
b/Documentation/devicetree/bindings/iio/light/ap3223.txt
new file mode 100644
index 000..b255d27
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/ap3223.txt
@@ -0,0 +1,18 @@
+* Dyna Image AP3223 ambient light sensor and proximity sensor
+
+http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2&dpid=8
+
+Required properties:
+
+  - compatible : should be "dynaimage,ap3223"
+  - reg : the I2C address of the sensor
+
+Example:
+
+ap3223@1c {
+   compatible = "dynaimage,ap3223";
+   reg = <0x1c>;
+
+   pinctrl-0 = <&ap3223_pins>;
+   pinctrl-names = "default";
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 5f20add..704da45 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -46,6 +46,7 @@ digilent  Diglent, Inc.
 dlgDialog Semiconductor
 dlink  D-Link Corporation
 dmoData Modul AG
+dynaimage  Dyna-Image
 ebvEBV Elektronik
 edtEmerging Display Technologies
 elan   Elan Microelectronic Corp.
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index ae68c64..5255aa2 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -27,6 +27,16 @@ config AL3320A
 To compile this driver as a module, choose M here: the
 module will be called al3320a.
 
+config AP3223
+   tristate "AP3223 ambient light and proximity sensor"
+   depends on I2C
+   help
+Say Y here if you want to build a driver for the Dyna Image AP3223
+ambient light and proximity sensor.
+
+To compile this driver as a module, choose M here: the
+module will be called ap3223.
+
 config APDS9300
tristate "APDS9300 ambient light sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index b12a516..13a74f9 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -5,6 +5,7 @@
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_ADJD_S311)+= adjd_s311.o
 obj-$(CONFIG_AL3320A)  += al3320a.o
+obj-$(CONFIG_AP3223)   += ap3223.o
 obj-$(CONFIG_APDS9300) += apds9300.o
 obj-$(CONFIG_CM32181)  += cm32181.o
 obj-$(CONFIG_CM3232)   += cm3232.o
diff --git a/drivers/iio/light/ap3223.c b/drivers/iio/light/ap3223.c
new file mode 100644
index 000..55bbcdd
--- /dev/null
+++ b/drivers/iio/light/ap3223.c
@@ -0,0 +1,394 @@
+/*
+ * ap3223.c
+ *
+ * Copyright (C) 2015 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Note about the original authors:
+ *
+ * The driver for AP3223 was originally distributed by dyna image in a
+ * different framework. This driver uses code from that driver and converts
+ * it to iio framework. The non-iio driver from dyna image is not available
+ * online anywhere, so there is no reference for it here. However, that driver
+ * is also GPLv2. The following is part of the header found in that file
+ * (The GPL notice from the original header is removed)
+ *
+ * >> This file is part of the AP3223, AP3212C and AP3216C sensor driver.
+ * >> AP3426 is combined proximity and ambient light sensor.
+ * >> AP3216C is combined proximity, ambient light sensor and IRLED.
+ * >>
+ * >> Contact: John Huang 
+ * >> Templeton Tsai 
+ *
+ * Another author initials mentioned in that file was just YC (and no name).
+ *
+ * Not sure for what kernel version the driver from dyna image was written for.
+ * Vic Lee  made modifications to it to run on 3.14.
+ */
+
+#incl

Re: gpios search behaviour for gpio from _DSD

[Mika Westerberg]

On Sat, Sep 26, 2015 at 09:30:59PM +0200, Olliver Schinagl wrote:
> What i ment is, without strcmp, the loop would test for:
> 
> reset-gpio and then reset-gpios (and then gpio and gpios)
> 
> So why the strcmp at all, Why only reset-gpios? Will the _DSD or acpi break
> and if we probe for reset-gpio (first, instead of reset-gpios)? I'm asking
> because i'm trying some work on gpio lib and this section is getting
> reworked too. While doing that I want to remove the strcmp. Hence, the
> question if things break on the ACPI side (I'm mostly failiar with OF.

I think it is there because we really want to force "-gpios" format for
named gpios (not "-gpio"). DT does not do it because they have lots of
existing "-gpio" users whereas in ACPI there is no such burden.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Darlehen.

Haben Sie sich für ein Darlehen oder Hypotheken und ständig abgelehnt suchen 
die von Finanzinstituten ist Mr.James Rodriguez ein Gläubiger bietet Darlehen 
zu einem Zinssatz von 3% Personen / Unternehmensverbände, Unternehmen, 
Betrieben, Schulen, Kirchen, usw., die in der sind Bedarf an Geld in einer 
Amortisationszeit von 1 bis 30 years.We Angebot 5.000,00 Euro auf 50 Mio. Euro 
bis zu einschließlich 18 und älter gelten müssen Sie sind. Wir sind 
vertrauenswürdig, zuverlässig und dynamisch. kontaktieren Sie uns jetzt: 
jr9304...@gmail.com

Ihre Namen ..
Menge benötigt werden ..
Dauer: ..
Dein Land ...
Deine Adresse ..
Telefon ...
Monatliches Einkommen ...
Sex  ...
Dein Alter ...

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

Re: [PATCH] kselftest: replace $(RM) with rm -f command

[Yuan Sun]

See the in-line comment.
On 2015/9/28 10:10, Wang Long wrote:

Some test's Makefile using "$(RM)" while the other's
using "rm -f". It is better to use one of them in all
tests.

"rm -f" is better, because it is less magic, and everyone
konws what is does.

Signed-off-by: Wang Long 
---
  tools/testing/selftests/capabilities/Makefile | 2 +-
  tools/testing/selftests/kcmp/Makefile | 2 +-
  tools/testing/selftests/membarrier/Makefile   | 2 +-
  tools/testing/selftests/memfd/Makefile| 2 +-
  tools/testing/selftests/net/Makefile  | 2 +-
  tools/testing/selftests/seccomp/Makefile  | 2 +-
  tools/testing/selftests/size/Makefile | 2 +-
  tools/testing/selftests/vm/Makefile   | 2 +-
  tools/testing/selftests/x86/Makefile  | 2 +-
  tools/testing/selftests/zram/Makefile | 2 +-
  10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/tools/testing/selftests/capabilities/Makefile 
b/tools/testing/selftests/capabilities/Makefile
index 8c8f0c1..dcc1972 100644
--- a/tools/testing/selftests/capabilities/Makefile
+++ b/tools/testing/selftests/capabilities/Makefile
@@ -12,7 +12,7 @@ CFLAGS := -O2 -g -std=gnu99 -Wall -lcap-ng
  all: $(TARGETS)
  
  clean:

-   $(RM) $(TARGETS)
+   rm -f $(TARGETS)
  
  $(TARGETS): %: %.c

$(CC) -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
diff --git a/tools/testing/selftests/kcmp/Makefile 
b/tools/testing/selftests/kcmp/Makefile
index 2ae7450..2deaee0 100644
--- a/tools/testing/selftests/kcmp/Makefile
+++ b/tools/testing/selftests/kcmp/Makefile
@@ -7,4 +7,4 @@ TEST_PROGS := kcmp_test
  include ../lib.mk
  
  clean:

-   $(RM) kcmp_test kcmp-test-file
+   rn -f kcmp_test kcmp-test-file

It should be rm, not rn.

diff --git a/tools/testing/selftests/membarrier/Makefile 
b/tools/testing/selftests/membarrier/Makefile
index a1a9708..f23fc58 100644
--- a/tools/testing/selftests/membarrier/Makefile
+++ b/tools/testing/selftests/membarrier/Makefile
@@ -7,4 +7,4 @@ all: $(TEST_PROGS)
  include ../lib.mk
  
  clean:

-   $(RM) $(TEST_PROGS)
+   rm -f $(TEST_PROGS)
diff --git a/tools/testing/selftests/memfd/Makefile 
b/tools/testing/selftests/memfd/Makefile
index 3e7eb79..068fa93 100644
--- a/tools/testing/selftests/memfd/Makefile
+++ b/tools/testing/selftests/memfd/Makefile
@@ -19,4 +19,4 @@ run_fuse: build_fuse
@./run_fuse_test.sh || echo "fuse_test: [FAIL]"
  
  clean:

-   $(RM) memfd_test fuse_test
+   rm -f memfd_test fuse_test
diff --git a/tools/testing/selftests/net/Makefile 
b/tools/testing/selftests/net/Makefile
index fac4782..ec7eaa4 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -16,4 +16,4 @@ TEST_FILES := $(NET_PROGS)
  include ../lib.mk
  
  clean:

-   $(RM) $(NET_PROGS)
+   rm -f $(NET_PROGS)
diff --git a/tools/testing/selftests/seccomp/Makefile 
b/tools/testing/selftests/seccomp/Makefile
index 8401e87..c16072a 100644
--- a/tools/testing/selftests/seccomp/Makefile
+++ b/tools/testing/selftests/seccomp/Makefile
@@ -7,4 +7,4 @@ all: $(TEST_PROGS)
  include ../lib.mk
  
  clean:

-   $(RM) $(TEST_PROGS)
+   rm -f $(TEST_PROGS)
diff --git a/tools/testing/selftests/size/Makefile 
b/tools/testing/selftests/size/Makefile
index bbd0b53..cefe914 100644
--- a/tools/testing/selftests/size/Makefile
+++ b/tools/testing/selftests/size/Makefile
@@ -8,4 +8,4 @@ TEST_PROGS := get_size
  include ../lib.mk
  
  clean:

-   $(RM) get_size
+   rm -f get_size
diff --git a/tools/testing/selftests/vm/Makefile 
b/tools/testing/selftests/vm/Makefile
index 3c53cac..26663c7 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -24,4 +24,4 @@ TEST_FILES := $(BINARIES)
  include ../lib.mk
  
  clean:

-   $(RM) $(BINARIES)
+   rm -f $(BINARIES)
diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index 29089b2..48b2406 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -32,7 +32,7 @@ all_32: $(BINARIES_32)
  all_64: $(BINARIES_64)
  
  clean:

-   $(RM) $(BINARIES_32) $(BINARIES_64)
+   rm -f $(BINARIES_32) $(BINARIES_64)
  
  $(TARGETS_C_32BIT_ALL:%=%_32): %_32: %.c

$(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
diff --git a/tools/testing/selftests/zram/Makefile 
b/tools/testing/selftests/zram/Makefile
index 29d8034..e1591c8 100644
--- a/tools/testing/selftests/zram/Makefile
+++ b/tools/testing/selftests/zram/Makefile
@@ -6,4 +6,4 @@ TEST_FILES := zram01.sh zram02.sh zram_lib.sh
  include ../lib.mk
  
  clean:

-   $(RM) err.log
+   rm -f err.log


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

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

[Arnd Bergmann]

On Monday 28 September 2015 13:34:38 Zhen Lei wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 07d1811..25cec57 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -85,7 +85,7 @@ config ARM64
> select PERF_USE_VMALLOC
> select POWER_RESET
> select POWER_SUPPLY
> -   select RTC_LIB
> +   select RTC_LIB if !EFI
> select SPARSE_IRQ
> select SYSCTL_EXCEPTION_TRACE
> select HAVE_CONTEXT_TRACKING

Sorry, we can't do that: enabling EFI has to be done in a way that it only
adds features but not disables them.

Your patch breaks RTC on all non-EFI platforms as soon as CONFIG_EFI
is selected by the user.

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: [RFC PATCH v3 1/3] mmc: sprd: Add MMC host driver for Spreadtrum SoC

[Shawn Lin]

On 2015/9/28 15:18, Hongtao Wu wrote:

 >>

On Thu, Sep 10, 2015 at 9:28 PM, Ulf Hansson mailto:ulf.hans...@linaro.org>> wrote:
 >
 > On 14 August 2015 at 18:55, Hongtao Wu mailto:wuh...@gmail.com>> wrote:


[...]



Yes, most of this data can be removed, such as caps, caps2, base_clk.
However ocr_avail and signal_default_voltage are useful for us.
We can't fetch ocr_avail from external regulator via
mmc_regulator_get_supply,
because our regulator driver can't supply mmc_regulator_get_ocrmask()
interface for MMC driver.


Sorry for the noise but... IMO, your need to quirk your regulator driver 
stuffs rather than mmc.



And sometimes our external regulator can not supply 3.0v or 1.8v default
signal voltage that we expect. So this 3.0v or 1.8v default signal
voltage are
mandatory.





--
Best Regards
Shawn Lin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: No more new fbdev drivers, please

[Gerd Hoffmann]

  Hi,

> As Daniel mentioned, the connector+encoder+crtc combination is one of
> those simplifications that would make sense if more such drivers are
> added.

Another one is memory management.  It's pretty complex because it can
handle _way_ more than what simple drivers need, and the result is
_alot_ of ttm boilerplate in the drivers.

cheers,
  Gerd


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

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

[Ard Biesheuvel]

On 28 September 2015 at 06:34, Zhen Lei  wrote:
> Now, ARM64 is also support EFI startup. We hope use EFI runtime services
> to get/set current time and date.
>
> RTC_LIB only controls some configs in drivers/char/Kconfig(included
> EFI_RTC), and will be automatically selected when RTC_CLASS opened. So
> this patch have no functional change but give an opportunity to select
> EFI_RTC when RTC_CLASS closed.
>
> Signed-off-by: Zhen Lei 
> ---
>  arch/arm64/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 07d1811..25cec57 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -85,7 +85,7 @@ config ARM64
> select PERF_USE_VMALLOC
> select POWER_RESET
> select POWER_SUPPLY
> -   select RTC_LIB
> +   select RTC_LIB if !EFI
> select SPARSE_IRQ
> select SYSCTL_EXCEPTION_TRACE
> select HAVE_CONTEXT_TRACKING

You can currently enable EFI_RTC just fine on arm64 when EFI is enabled.
Why exactly do you need this patch on top?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] drivers:mtd:UBI: add bakvol module for MLC NAND paired page issue

[Boris Brezillon]

Hi Bean,

Next time you send a patch series, could send all the patches in reply
to the cover letter?

On Mon, 28 Sep 2015 07:02:35 +
Bean Huo 霍斌斌 (beanhuo)  wrote:

> Hello,
> 
> This series aims at adding a bakvol module for MLC NAND paired page
> Power loss protection.
> MLC NAND paired page power loss is a known issue so far, MLC NAND pages are
> coupled in a sense that if you cut power while writing to a page, you corrupt 
> not only
> this page, but also one of the previous pages which is paired with the 
> current one.
> Currently, there is no a perfect solution for this. 
> This paired page solution is based on NAND multiple plane program feature. 
> For this
> Patch, only used dual plane page program, means two different plane pages can
> Be programmed together at the same time.
> Dual plane page program only implements in backup operation. Only lower page 
> data
> Be duplicated and back up into a internal log volume by dual plane program 
> method.

Hm, I'm not very fond of the idea, especially because of the complexity
caused by dual plane program operations (you can't take a random block
to write your backup on it, which means WL is complexified too), and
the fact that you're duplicating data (thus introducing a performance
penalty and storage overhead).

> 
> This patch has been testing on Micron 70s/80s/90s MLC NAND.
> Of course there are some places needed to be improved and simplified.
> 
> Any suggestion and comments welcomed.

Sure, I'll try to review it soon.

Thanks for submitting those patches.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-sunxi] [PATCH 0/2] ASoC: Add support for the Allwinner A10 codec

[Maxime Ripard]

Hi Priit,

On Tue, Sep 22, 2015 at 04:26:57PM +0300, Priit Laes wrote:
> On Sat, 2015-09-12 at 15:26 +0200, Maxime Ripard wrote:
> > Hi everyone,
> > 
> > This patch set adds the support for what Allwinner calls the codec on
> > their SoCs.
> > 
> > This codec is actually a combination of a codec and DAI, tied
> > together
> > in a single memory-mapped IP. It is completely standalone, and
> > outputs
> > directly the analog signal.
> > 
> > While it supports both playback and capture, the capture is not
> > implemented in this patch, and will be posted eventually as a
> > separate
> > one.
> > 
> > This set, in order to be functional, has a dependency on the audio
> > clocks patch set posted separately. However, it doesn't needs this to
> > compile properly, so I guess it can be merged without really caring
> > for the merging status of the clock patches.
> 
> It works on Gemei G9 tablet which has also extra chip that
> automatically switches output over from internal speakers to headphones
> when connector is inserted.
> 
> Now I noticed some weird things:
> 
> When I have all the switches as ON in alsamixer, and I start disabling
> them, I get following weird results.
> 
> Left Mixer Left - LML
> Right Mixer Left - LMR
> Right Mixer Right - RMR
> 
> Very faint output:
> LML - ON
> RML - Mute
> RMR - ON
> 
> Output works fully:
> LML - Mute
> RML - Mute
> RMR - Mute
> 
> When I Mute Pre-Amplifier and fiddle any of LML, RML or RMR, the output
> stays mute even after setting Pre-Amplifier Mute back on:
> 
> 1. All switches on
> 2. Mute pre-amplifier
> 3. Mute RMR
> 4. Pre-Amilifier Mute Off
> .. Music stays off
> 5. Toggle Pre-Amplifier twice - output turns on

Unfortunately, I don't have access to that SoC or that setup.

Do you have another A10 board with a simpler audio setup, like a
cubieboard?

> And also following in dmesg:
> sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok
> sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack
> sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Left -> direct -> 
> Headphone Jack
> sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack
> sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Right -> direct -> 
> Headphone Jack

That one is weird, I'll look into this.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH 0/7] tty: serial: msm: Add DMA support and fix bit definitions

[Ivan T. Ivanov]

On Fri, 2015-09-25 at 00:27 +0100, Srinivas Kandagatla wrote:
> Hi Ivan,
> On 12/09/15 14:02, Ivan T. Ivanov wrote:
> > Hi,
> > 
> > Following patches add DMA support for UARTDM type of hardware.
> > 
> > Changes have been tested on UARTDM v1.3(APQ8064) and v1.4(APQ8016).
> > 
> > Patches from Gurav were published long ago here[1], I just addressed
> > remaining comments and coding style issues.
> > 
> > Any comments are welcome.
> Looks like Magic Sysrq is broken with this patches.


Will check it shortly.

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

Re: [PATCH v7 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

[Christian Borntraeger]

Am 24.09.2015 um 21:02 schrieb Hemant Kumar:
> Its better to remove the dependency on uapi/kvm_perf.h to allow dynamic
> discovery of kvm events (if its needed). To do this, some extern
> variables have been introduced with which we can keep the generic
> functions generic.
> 
> Signed-off-by: Hemant Kumar 

When touching s390, can you CC the s390 maintainers? We are not powerpc :-)
Alexander, can you have a look at this series?


> ---
>  tools/perf/arch/s390/util/kvm-stat.c | 10 +++-
>  tools/perf/arch/x86/util/kvm-stat.c  | 12 +-
>  tools/perf/builtin-kvm.c | 44 
> ++--
>  tools/perf/util/kvm-stat.h   |  3 +++
>  4 files changed, 50 insertions(+), 19 deletions(-)
> 
> diff --git a/tools/perf/arch/s390/util/kvm-stat.c 
> b/tools/perf/arch/s390/util/kvm-stat.c
> index a5dbc07..c2acb3e 100644
> --- a/tools/perf/arch/s390/util/kvm-stat.c
> +++ b/tools/perf/arch/s390/util/kvm-stat.c
> @@ -10,7 +10,11 @@
>   */
> 
>  #include "../../util/kvm-stat.h"
> -#include 
> +#include 
> +
> +#define DECODE_STR_LEN 40
> +#define VCPU_ID "id"
> +#define KVM_EXIT_REASON "icptcode"
> 
>  define_exit_reasons_table(sie_exit_reasons, sie_intercept_code);
>  define_exit_reasons_table(sie_icpt_insn_codes, icpt_insn_codes);
> @@ -83,6 +87,10 @@ const char * const kvm_events_tp[] = {
>   NULL,
>  };
> 
> +const char *vcpu_id_str = VCPU_ID;
> +const int decode_str_len = DECODE_STR_LEN;
> +const char *exit_reason_code = KVM_EXIT_REASON;
> +
>  struct kvm_reg_events_ops kvm_reg_events_ops[] = {
>   { .name = "vmexit", .ops = &exit_events },
>   { NULL, NULL },
> diff --git a/tools/perf/arch/x86/util/kvm-stat.c 
> b/tools/perf/arch/x86/util/kvm-stat.c
> index 14e4e66..2d0d43b5 100644
> --- a/tools/perf/arch/x86/util/kvm-stat.c
> +++ b/tools/perf/arch/x86/util/kvm-stat.c
> @@ -1,5 +1,11 @@
>  #include "../../util/kvm-stat.h"
> -#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DECODE_STR_LEN 20
> +#define VCPU_ID "vcpu_id"
> +#define KVM_EXIT_REASON "exit_reason"
> 
>  define_exit_reasons_table(vmx_exit_reasons, VMX_EXIT_REASONS);
>  define_exit_reasons_table(svm_exit_reasons, SVM_EXIT_REASONS);
> @@ -129,6 +135,10 @@ const char * const kvm_events_tp[] = {
>   NULL,
>  };
> 
> +const char *vcpu_id_str = VCPU_ID;
> +const int decode_str_len = DECODE_STR_LEN;
> +const char *exit_reason_code = KVM_EXIT_REASON;
> +
>  struct kvm_reg_events_ops kvm_reg_events_ops[] = {
>   { .name = "vmexit", .ops = &exit_events },
>   { .name = "mmio", .ops = &mmio_events },
> diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
> index fc1cffb..dbb1b1e 100644
> --- a/tools/perf/builtin-kvm.c
> +++ b/tools/perf/builtin-kvm.c
> @@ -31,20 +31,19 @@
>  #include 
> 
>  #ifdef HAVE_KVM_STAT_SUPPORT
> -#include 
>  #include "util/kvm-stat.h"
> 
> -void exit_event_get_key(struct perf_evsel *evsel,
> - struct perf_sample *sample,
> - struct event_key *key)
> +void exit_event_get_key(struct perf_evsel *evsel __maybe_unused,
> +struct perf_sample *sample __maybe_unused,
> +struct event_key *key __maybe_unused)
>  {
>   key->info = 0;
> - key->key = perf_evsel__intval(evsel, sample, KVM_EXIT_REASON);
> + key->key = perf_evsel__intval(evsel, sample, exit_reason_code);
>  }
> 
> -bool kvm_exit_event(struct perf_evsel *evsel)
> +bool kvm_exit_event(struct perf_evsel *evsel __maybe_unused)
>  {
> - return !strcmp(evsel->name, KVM_EXIT_TRACE);
> + return !strncmp(evsel->name, kvm_events_tp[1], strlen(evsel->name));
>  }
> 
>  bool exit_event_begin(struct perf_evsel *evsel,
> @@ -58,9 +57,9 @@ bool exit_event_begin(struct perf_evsel *evsel,
>   return false;
>  }
> 
> -bool kvm_entry_event(struct perf_evsel *evsel)
> +bool kvm_entry_event(struct perf_evsel *evsel __maybe_unused)
>  {
> - return !strcmp(evsel->name, KVM_ENTRY_TRACE);
> + return !strncmp(evsel->name, kvm_events_tp[0], strlen(evsel->name));
>  }
> 
>  bool exit_event_end(struct perf_evsel *evsel,
> @@ -71,8 +70,8 @@ bool exit_event_end(struct perf_evsel *evsel,
>  }
> 
>  static const char *get_exit_reason(struct perf_kvm_stat *kvm,
> -struct exit_reasons_table *tbl,
> -u64 exit_code)
> + struct exit_reasons_table *tbl,
> + u64 exit_code)
>  {
>   while (tbl->reason != NULL) {
>   if (tbl->exit_code == exit_code)
> @@ -92,7 +91,7 @@ void exit_event_decode_key(struct perf_kvm_stat *kvm,
>   const char *exit_reason = get_exit_reason(kvm, key->exit_reasons,
> key->key);
> 
> - scnprintf(decode, DECODE_STR_LEN, "%s", exit_reason);
> + scnprintf(decode, decode_str_len, "%s", exit_reason);
>  }
> 
>  static bool register_kvm_events_ops(struct perf_kvm_stat *kvm)
> @@ -358,7 +357,11 @@ static bool han

4.3.0-rc1: BUG in sb16 init in arch_dma_alloc_attrs()

[Meelis Roos]

My trusty K6/430TX machine with ISA SB16 variant has worked fine until 
4.2. However, in 4.3.0-rc1 and 4.3.0-rc3-00025-ge3be426 I get a null 
pointer dereferencing BUG during SB16 initialization. Full dmesg and 
config are below.

[0.00] Linux version 4.3.0-rc3-00025-ge3be426 (mroos@roos) (gcc version 
5.2.1 20150808 (Debian 5.2.1-15) ) #10 Mon Sep 28 02:40:08 EEST 2015
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'lazy' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009] usable
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x03ff] usable
[0.00] BIOS-e820: [mem 0x-0x] reserved
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] Legacy DMI 2.0 present.
[0.00] DMI:/i430TX, BIOS 4.51 PG 08/20/98
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x4000 max_arch_pfn = 0x10
[0.00] MTRR: Disabled
[0.00] initial memory mapped: [mem 0x-0x017f]
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x03c0-0x03ff]
[0.00]  [mem 0x03c0-0x03ff] page 4M
[0.00] init_memory_mapping: [mem 0x0010-0x03bf]
[0.00]  [mem 0x0010-0x003f] page 4k
[0.00]  [mem 0x0040-0x03bf] page 4M
[0.00] 64MB LOWMEM available.
[0.00]   mapped low ram: 0 - 0400
[0.00]   low ram: 0 - 0400
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   Normal   [mem 0x0100-0x03ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009]
[0.00]   node   0: [mem 0x0010-0x03ff]
[0.00] Initmem setup node 0 [mem 0x1000-0x03ff]
[0.00] On node 0 totalpages: 16287
[0.00] free_area_init_node: node 0, pgdat c13b8e00, node_mem_map 
c3f80020
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 3999 pages, LIFO batch:0
[0.00]   Normal zone: 96 pages used for memmap
[0.00]   Normal zone: 12288 pages, LIFO batch:1
[0.00] e820: [mem 0x0400-0xfffe] available for PCI devices
[0.00] clocksource: refined-jiffies: mask: 0x max_cycles: 
0x, max_idle_ns: 1911260446275 ns
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 16159
[0.00] Kernel command line: 
BOOT_IMAGE=/boot/vmlinuz-4.3.0-rc3-00025-ge3be426 root=/dev/sda1 ro
[0.00] PID hash table entries: 256 (order: -2, 1024 bytes)
[0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Initializing CPU#0
[0.00] Memory: 60092K/65148K available (2841K kernel code, 213K rwdata, 
772K rodata, 288K init, 196K bss, 5056K reserved, 0K cma-reserved)
[0.00] virtual kernel memory layout:
   fixmap  : 0xfffe5000 - 0xf000   ( 104 kB)
   vmalloc : 0xc480 - 0xfffe3000   ( 951 MB)
   lowmem  : 0xc000 - 0xc400   (  64 MB)
 .init : 0xc13c - 0xc1408000   ( 288 kB)
 .data : 0xc12c6ad5 - 0xc13be720   ( 991 kB)
 .text : 0xc100 - 0xc12c6ad5   (2842 kB)
[0.00] Checking if this processor honours the WP bit even in supervisor 
mode...Ok.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] CPU 0 irqstacks, hard=c3806000 soft=c3808000
[0.00] Console: colour VGA+ 80x25
[0.00] console [tty0] enabled
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 267.271 MHz processor
[0.010022] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 534.54 BogoMIPS (lpj=2672710)
[0.010172] pid_max: default: 32768 minimum: 301
[0.010571] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.010662] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.013253] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[0.013350] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[0.013417] CPU: AMD-K6tm w/ multimedia extensions (family: 0x5, model: 

Re: [PATCH v2] mtd: nand: pxa3xx-nand: switch to dmaengine

[Robert Jarzmik]

Brian Norris  writes:

> On Sun, Sep 27, 2015 at 05:18:56PM -0700, Brian Norris wrote:
>> Sparse has one complaint, but I have no others:
>> 
>> On Sun, Sep 06, 2015 at 03:12:47PM +0200, Robert Jarzmik wrote:
>> > diff --git a/drivers/mtd/nand/pxa3xx_nand.c 
>> > b/drivers/mtd/nand/pxa3xx_nand.c
>> > index 2f39bfe34584..1e9d462065e8 100644
>> > --- a/drivers/mtd/nand/pxa3xx_nand.c
>> > +++ b/drivers/mtd/nand/pxa3xx_nand.c
>> > @@ -15,7 +15,9 @@
>> ...
>> > @@ -564,57 +567,61 @@ static void handle_data_pio(struct pxa3xx_nand_info 
>> > *info)
>> [...]
>> > +static void start_data_dma(struct pxa3xx_nand_info *info)
>> > +{
>> > +  enum dma_data_direction direction;
>> 
>> I think this should be dma_transfer_direction. See warning below.
>
> I just fixed this up and pushed to l2-mtd.git. I can revert and apply
> something different if you'd like.
Thanks, your fix is perfectly correct.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: nand: pxa3xx-nand: prevent DFI bus lockup on removal

[Robert Jarzmik]

Brian Norris  writes:

> On Sat, Sep 26, 2015 at 10:19:07PM +0200, Robert Jarzmik wrote:
>> Robert Jarzmik  writes:
>> 
>> > After the conversion of pxa architecture to common clock framework, the
>> > NAND clock can be disabled on driver exit.
>> >
>> > In this case, it happens that if the driver used the NAND and set the
>> > DFI arbitration bit, the next access to a static memory controller area,
>> > such as an ethernet card, will stall the system bus, and the core will
>> > be stalled forever.
>> >
>> > This is especially true on pxa31x SoCs, where the NDCR was augmented
>> > with a new bit to prevent this lockups by giving full ownership of the
>> > DFI arbiter to the SMC, in change SCr#6.
>> >
>> > Fix this by clearing the DFI arbritration bit in driver exit. This
>> > effectively prevents a lockup on zylonite when removing pxa3xx-nand
>> > module, and using ethernet afterwards.
>> >
>> > Signed-off-by: Robert Jarzmik 
>> Hi Brian,
>> 
>> Are you happy with this patch, and if so could you queue it please ?
>
> It looks OK to me, but it doesn't apply to the latest l2-mtd.git. Am I
> missing something? I didn't try too hard to work out the conflict
> myself.
OK, I'll rebase it on your tree and resend a "PATCH v2 REBASED" version today.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

[Ingo Molnar]

* Denys Vlasenko  wrote:

> On 09/26/2015 09:50 PM, H. Peter Anvin wrote:
> > NAK.  We really should map the GDT read-only on all 64 bit systems,
> > since we can't hide the address from SLDT.  Same with the IDT.
> 
> Sorry, I don't understand your point.

So the problem is that right now the SGDT instruction (which is unprivileged) 
leaks the real address of the kernel image:

 fomalhaut:~> ./sgdt 
 SGDT: 88303fd89000 / 007f

that '88303fd89000' is a kernel address.

 fomalhaut:~> cat sgdt.c 
 #include 
 #include 

 int main(void)
 {
 struct gdt_desc {
 unsigned short  limit;
 unsigned long   addr;
 } __attribute__((packed)) gdt_desc = { -1, -1 };

 asm volatile("sgdt %0": "=m" (gdt_desc));

 printf("SGDT: %016lx / %04x\n", gdt_desc.addr, gdt_desc.limit);

 return 0;
 }

Your observation in the changelog and your patch:

> >> It is page-sized because of paravirt. [...]

... conflicts with the intention to mark (remap) the primary GDT address 
read-only 
on native kernels as well.

So what we should do instead is to use the page alignment properly and remap 
the 
GDT to a read-only location, and load that one.

This would have a couple of advantages:

 - This would give kernel address randomization more teeth on x86.

 - An additional advantage would be that rootkits overwriting the GDT would 
have 
   a bit more work to do.

 - A third advantage would be that for NUMA systems we could 'mirror' the GDT 
into
   node-local memory and load those. This makes GDT load cache-misses a bit less
   expensive.

The IDT is already remapped:

 fomalhaut:~> ./sidt 
 Sidt: ff57b000 / 0fff
 fomalhaut:~> cat sidt.c
 #include 
 #include 

 int main(void)
 {
 struct idt_desc {
 unsigned short  limit;
 unsigned long   addr;
 } __attribute__((packed)) idt_desc = { -1, -1 };

 asm volatile("sidt %0": "=m" (idt_desc));

 printf("Sidt: %016lx / %04x\n", idt_desc.addr, idt_desc.limit);

 return 0;
 }

Thanks,

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

Re: [PATCH v6 2/2] iio: mcp4531: Driver for Microchip digital potentiometers

[Peter Rosin]

On 2015-09-27 17:50, Jonathan Cameron wrote:
> On 23/09/15 15:26, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> Add support for Microchip digital potentiometers and rheostats
>>  MCP4531, MCP4532, MCP4551, MCP4552
>>  MCP4631, MCP4632, MCP4651, MCP4652
>>
>> DEVICE   Wipers  Steps  Resistor Opts (kOhm)  i2c address
>> MCP4531  1   1295, 10, 50, 100010111x
>> MCP4532  1   1295, 10, 50, 10001011xx
>> MCP4551  1   2575, 10, 50, 100010111x
>> MCP4552  1   2575, 10, 50, 10001011xx
>> MCP4631  2   1295, 10, 50, 1000101xxx
>> MCP4632  2   1295, 10, 50, 10001011xx
>> MCP4651  2   2575, 10, 50, 1000101xxx
>> MCP4652  2   2575, 10, 50, 10001011xx
>>
>> Datasheet: http://www.microchip.com/downloads/en/DeviceDoc/22096b.pdf
> Applied to the togreg branch of iio.git - initially pushed out as
> testing for the autobuilders to play with it.
> 
> If anyone wants to add reviewed-by / acked-by then as I'll be
> rebasing sometime in next few days anyway there is still time!

Great, thanks,

but I don't see this where I expected it[1]. So, the question is if I'm
too impatient, if am I looking in the wrong place or if you perhaps forgot
to actually push it out? Or if something went totally wrong and the patches
got lost...

Cheers,
Peter

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

[tip:perf/core] perf/core, perf/x86: Change needlessly global functions and a variable to static

[tip-bot for Geliang Tang]

Commit-ID:  18ab2cd3ee9d52dc64c5ae984146a261a328c4e8
Gitweb: http://git.kernel.org/tip/18ab2cd3ee9d52dc64c5ae984146a261a328c4e8
Author: Geliang Tang 
AuthorDate: Sun, 27 Sep 2015 23:25:50 +0800
Committer:  Ingo Molnar 
CommitDate: Mon, 28 Sep 2015 08:09:52 +0200

perf/core, perf/x86: Change needlessly global functions and a variable to static

Fixes various sparse warnings.

Signed-off-by: Geliang Tang 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/70c14234da1bed6e3e67b9c419e2d5e376ab4f32.1443367286.git.geliangt...@163.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/intel_cacheinfo.c | 8 
 kernel/events/core.c  | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index be4febc..e38d338 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -157,7 +157,7 @@ struct _cpuid4_info_regs {
struct amd_northbridge *nb;
 };
 
-unsigned short num_cache_leaves;
+static unsigned short num_cache_leaves;
 
 /* AMD doesn't have CPUID4. Emulate it here to report the same
information to the user.  This makes some assumptions about the machine:
@@ -326,7 +326,7 @@ static void amd_calc_l3_indices(struct amd_northbridge *nb)
  *
  * @returns: the disabled index if used or negative value if slot free.
  */
-int amd_get_l3_disable_slot(struct amd_northbridge *nb, unsigned slot)
+static int amd_get_l3_disable_slot(struct amd_northbridge *nb, unsigned slot)
 {
unsigned int reg = 0;
 
@@ -403,8 +403,8 @@ static void amd_l3_disable_index(struct amd_northbridge 
*nb, int cpu,
  *
  * @return: 0 on success, error status on failure
  */
-int amd_set_l3_disable_slot(struct amd_northbridge *nb, int cpu, unsigned slot,
-   unsigned long index)
+static int amd_set_l3_disable_slot(struct amd_northbridge *nb, int cpu,
+   unsigned slot, unsigned long index)
 {
int ret = 0;
 
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f87b434..ea02109 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -196,7 +196,7 @@ static int perf_sample_period_ns __read_mostly  = 
DEFAULT_SAMPLE_PERIOD_NS;
 static int perf_sample_allowed_ns __read_mostly =
DEFAULT_SAMPLE_PERIOD_NS * DEFAULT_CPU_TIME_MAX_PERCENT / 100;
 
-void update_perf_cpu_limits(void)
+static void update_perf_cpu_limits(void)
 {
u64 tmp = perf_sample_period_ns;
 
@@ -472,7 +472,7 @@ perf_cgroup_set_timestamp(struct task_struct *task,
  * mode SWOUT : schedule out everything
  * mode SWIN : schedule in based on cgroup for next
  */
-void perf_cgroup_switch(struct task_struct *task, int mode)
+static void perf_cgroup_switch(struct task_struct *task, int mode)
 {
struct perf_cpu_context *cpuctx;
struct pmu *pmu;
@@ -7390,7 +7390,7 @@ static int perf_pmu_nop_int(struct pmu *pmu)
return 0;
 }
 
-DEFINE_PER_CPU(unsigned int, nop_txn_flags);
+static DEFINE_PER_CPU(unsigned int, nop_txn_flags);
 
 static void perf_pmu_start_txn(struct pmu *pmu, unsigned int flags)
 {
@@ -7750,7 +7750,7 @@ static int perf_try_init_event(struct pmu *pmu, struct 
perf_event *event)
return ret;
 }
 
-struct pmu *perf_init_event(struct perf_event *event)
+static struct pmu *perf_init_event(struct perf_event *event)
 {
struct pmu *pmu = NULL;
int idx;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] lib/vsprintf.c: handle invalid format specifiers more robustly

[Andy Shevchenko]

On Fri, 2015-09-25 at 19:41 +0200, Rasmus Villemoes wrote:
> If we meet any invalid or unsupported format specifier, 'handling' it
> by just printing it as a literal string is not safe: Presumably the
> format string and the arguments passed gcc's type checking, but that
> means something like sprintf(buf, "%n %pd", &intvar, dentry) would 
> end
> up interpreting &intvar as a struct dentry*.
> 
> When the offending specifier was %n it used to be at the end of the
> format string, but we can't rely on that always being the case. Also,
> gcc doesn't complain about some more or less exotic qualifiers (or
> 'length modifiers' in posix-speak) such as 'j' or 'q', but being
> unrecognized by the kernel's printf implementation, they'd be
> interpreted as unknown specifiers, and the rest of arguments would be
> interpreted wrongly.
> 
> So let's complain about anything we don't understand, not just %n, 
> and
> stop pretending that we'd be able to make sense of the rest of the
> format/arguments. If the offending specifier is in a printk() call we
> unfortunately only get a "BUG: recent printk recursion!", but at 
> least
> direct users of the sprintf family will be caught.

I like the fix (I noticed the same issue after commented out Martin's
patch).

Few minor comments below.

Reviewed-by: Andy Shevchenko 

> 
> Signed-off-by: Rasmus Villemoes 
> ---
>  lib/vsprintf.c | 31 +--
>  1 file changed, 21 insertions(+), 10 deletions(-)
> 
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 95cd63b43b99..f2590a80937f 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1769,14 +1769,14 @@ qualifier:
>  
>   case 'n':
>   /*
> -  * Since %n poses a greater security risk than 
> utility, treat
> -  * it as an invalid format specifier. Warn about its 
> use so
> -  * that new instances don't get added.
> +  * Since %n poses a greater security risk than

Any reason to wrap first string?

> +  * utility, treat it as any other invalid or
> +  * unsupported format specifier.
>*/
> - WARN_ONCE(1, "Please remove ignored %%n in '%s'\n", 
> fmt);
>   /* Fall-through */
>  
>   default:
> + WARN_ONCE(1, "Please remove unsupported %%%c in 
> format string\n", *fmt);
>   spec->type = FORMAT_TYPE_INVALID;
>   return fmt - start;
>   }
> @@ -1944,10 +1944,15 @@ int vsnprintf(char *buf, size_t size, const 
> char *fmt, va_list args)
>   break;
>  
>   case FORMAT_TYPE_INVALID:
> - if (str < end)
> - *str = '%';
> - ++str;
> - break;
> + /*
> +  * Presumably the arguments passed gcc's 
> type
> +  * checking, but there is no safe or sane 
> way
> +  * for us to continue parsing the format and
> +  * fetching from the va_list; the remaining
> +  * specifiers and arguments would be out of
> +  * sync.

Could we use wider strings in the commentary here?

> +  */
> + goto out;
>  
>   default:
>   switch (spec.type) {
> @@ -1992,6 +1997,7 @@ int vsnprintf(char *buf, size_t size, const 
> char *fmt, va_list args)
>   }
>   }
>  
> +out:
>   if (size > 0) {
>   if (str < end)
>   *str = '\0';
> @@ -2189,9 +2195,10 @@ do {   >   
> >   >   > \
> 
>  
>   switch (spec.type) {
>   case FORMAT_TYPE_NONE:
> - case FORMAT_TYPE_INVALID:
>   case FORMAT_TYPE_PERCENT_CHAR:
>   break;
> + case FORMAT_TYPE_INVALID:
> + goto out;
>  
>   case FORMAT_TYPE_WIDTH:
>   case FORMAT_TYPE_PRECISION:
> @@ -2253,6 +2260,7 @@ do {>   
> >   >   > \
> 
>   }
>   }
>  
> +out:
>   return (u32 *)(PTR_ALIGN(str, sizeof(u32))) - bin_buf;
>  #undef save_arg
>  }
> @@ -2375,12 +2383,14 @@ int bstr_printf(char *buf, size_t size, const 
> char *fmt, const u32 *bin_buf)
>   break;
>  
>   case FORMAT_TYPE_PERCENT_CHAR:
> - case FORMAT_TYPE_INVALID:
>   if (str < end)
>   *str = '%';
>   ++str;
>   break;
>  
> + case FORMAT_TYPE_INVALID:
> + goto out;
> +
>   default: {
>   unsigned long long num;
>  
> @@ -2423,6 +2433,7 @@ int bstr_printf(char *buf, size_t size, const 
> char *fmt, const u32 *bin_buf)
>   } /* switch(spec.type) */
>   } 

Re: [PATCH] kexec: fix out of the ELF headers buffer issue in syscall kexec_file_load()

[Baoquan He]

On 09/28/15 at 02:41pm, Lee, Chun-Yi wrote:
> On big machines have CPU number that's very nearly to consume whole ELF
> headers buffer that's page aligned, 4096, 8192... Then the page fault error
> randomly happened.
> 
> This patch modified the code in fill_up_crash_elf_data() by using
> walk_system_ram_res() instead of walk_system_ram_range() to count the max
> number of crash memory ranges. That's because the walk_system_ram_range()
> filters out small memory regions that reside the same page, but
> walk_system_ram_res() does not.
> 
> The oringial page fault issue sometimes happened on big machines when
> preparing ELF headers:
> 
> [  305.291522] BUG: unable to handle kernel paging request at c90613fc9000
> [  305.299621] IP: [] 
> prepare_elf64_ram_headers_callback+0x165/0x260
> [  305.308300] PGD e32067 PUD 6dcbec54067 PMD 9dc9bdeb067 PTE 0
> [  305.315393] Oops: 0002 [#1] SMP
> [...snip]
> [  305.420953] task: 8e1c01ced600 ti: 8e1c03ec2000 task.ti: 
> 8e1c03ec2000
> [  305.429292] RIP: 0010:[]  [] 
> prepare_elf64_ra
> m_headers_callback+0x165/0x260
> [...snip]
> 
> After tracing prepare_elf64_headers() and 
> prepare_elf64_ram_headers_callback(),
> the code uses walk_system_ram_res() to fill-in crash memory regions 
> information
> to program header, so it counts those small memory regions that reside in a
> page area. But, when kernel was using walk_system_ram_range() in
> fill_up_crash_elf_data() to count the number of crash memory regions, it
> filters out small regions.
> 
> I printed those small memory regions, for example:
> 
> kexec: Get nr_ram ranges. vaddr=0x880077592258 paddr=0x77592258, sz=0xdc0
> 
> Base on the logic of walk_system_ram_range(), this memory region will be
> filter out:
> 
> pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
> end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
> end_pfn - pfn = 0x77593 - 0x77593 = 0  <=== if (end_pfn > pfn)  [FAIL]
> 
> So, the max_nr_ranges that counted by kernel doesn't include small memory
> regions. That causes the page fault issue happened in later code path for
> preparing EFL headers,
> 
> This issue was hided on small machine that doesn't have too many CPU because
> the free space of ELF headers buffer can cover the number of small memory
> regions. But, when the machine has more CPUs or the number of memory regions
> very nearly to consume whole page aligned buffer, e.g. 4096, 8192... Then
> issue will happen randomly.

CC akpm too.

Read code again and I think it makes sense to use walk_system_ram_res.
And in prepare_elf64_headers it also uses walk_system_ram_res. That's
why you can find this bug. Otherwise we never find this and those small
regions which only spread in one page will be lost in vmcore.

Besides could you please rearrange your patch log? It's not easy to get
what this patch have done.

> 
> Signed-off-by: Lee, Chun-Yi 
> ---
>  arch/x86/kernel/crash.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index e068d66..ad273b3d 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -185,8 +185,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
>  }
>  
>  #ifdef CONFIG_KEXEC_FILE
> -static int get_nr_ram_ranges_callback(unsigned long start_pfn,
> - unsigned long nr_pfn, void *arg)
> +static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
>  {
>   int *nr_ranges = arg;
>  
> @@ -214,7 +213,7 @@ static void fill_up_crash_elf_data(struct crash_elf_data 
> *ced,
>  
>   ced->image = image;
>  
> - walk_system_ram_range(0, -1, &nr_ranges,
> + walk_system_ram_res(0, -1, &nr_ranges,
>   get_nr_ram_ranges_callback);
>  
>   ced->max_nr_ranges = nr_ranges;
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 2/2] iio: mcp4531: Driver for Microchip digital potentiometers

[Daniel Baluta]

On Mon, Sep 28, 2015 at 10:59 AM, Peter Rosin  wrote:
> On 2015-09-27 17:50, Jonathan Cameron wrote:
>> On 23/09/15 15:26, Peter Rosin wrote:
>>> From: Peter Rosin 
>>>
>>> Add support for Microchip digital potentiometers and rheostats
>>>  MCP4531, MCP4532, MCP4551, MCP4552
>>>  MCP4631, MCP4632, MCP4651, MCP4652
>>>
>>> DEVICE   Wipers  Steps  Resistor Opts (kOhm)  i2c address
>>> MCP4531  1   1295, 10, 50, 100010111x
>>> MCP4532  1   1295, 10, 50, 10001011xx
>>> MCP4551  1   2575, 10, 50, 100010111x
>>> MCP4552  1   2575, 10, 50, 10001011xx
>>> MCP4631  2   1295, 10, 50, 1000101xxx
>>> MCP4632  2   1295, 10, 50, 10001011xx
>>> MCP4651  2   2575, 10, 50, 1000101xxx
>>> MCP4652  2   2575, 10, 50, 10001011xx
>>>
>>> Datasheet: http://www.microchip.com/downloads/en/DeviceDoc/22096b.pdf
>> Applied to the togreg branch of iio.git - initially pushed out as
>> testing for the autobuilders to play with it.
>>
>> If anyone wants to add reviewed-by / acked-by then as I'll be
>> rebasing sometime in next few days anyway there is still time!
>
> Great, thanks,
>
> but I don't see this where I expected it[1]. So, the question is if I'm
> too impatient, if am I looking in the wrong place or if you perhaps forgot
> to actually push it out? Or if something went totally wrong and the patches
> got lost...

Make sure you look for the testing branch. Also, do not worry about this.

Sometimes, Jonathan  pushes the patches locally to his setup and later
syncs with the remote repo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Darlehen anbieten

[DIAMOND SWISS LOAN COMPANY]

Guten Tag,


Dies ist Diamant Swiss Darlehen Unternehmen Darlehen bieten.


Diamant Swiss Darlehen Unternehmen bietet flexible und erschwingliche Kredite 
für jeden Zweck zu helfen, Ihre Ziele zu erreichen. wir Darlehen zu niedrigen 
Zinssatz von 1,5%. Hier sind einige wichtige Merkmale der persönlichen Kredit 
von Diamant Swiss Darlehen Unternehmen angeboten. Hier sind die Loan Faktoren 
arbeiten wir mit den führenden britischen Broker, die den Zugang zu 
Top-Kreditgeber haben und in der Lage, die beste finanzielle Lösung zu einem 
erschwinglichen price.Please finden, wenn Sie interessiert sind kontaktieren 
Sie uns bitte über diese E-Mail: diamonds_wisslo...@hotmail.com



Nach der Reaktion, werden Sie einen Antrag auf Kredit fill empfangen. Keine 
soziale Sicherheit und keine Bonitätsprüfung, 100% garantiert.


Es wird uns eine Ehre, wenn Sie uns erlauben, zu Ihren Diensten.



Mehr Informationen benötigt

Ihre Namen:
Adresse: ...
Telefon: ...
Benötigte Menge: 
Dauer: ...
Beruf: ...
Monatliches Einkommen Level: 
Geschlecht: ...
Geburtsdatum: 
Status: .
Land: ..
Zweck: .

Treffen Sie Ihre finanziellen Bedürfnisse ist unser Stolz.

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

Darlehen anbieten

[DIAMOND SWISS LOAN COMPANY]

Guten Tag,


Dies ist Diamant Swiss Darlehen Unternehmen Darlehen bieten.


Diamant Swiss Darlehen Unternehmen bietet flexible und erschwingliche Kredite 
für jeden Zweck zu helfen, Ihre Ziele zu erreichen. wir Darlehen zu niedrigen 
Zinssatz von 1,5%. Hier sind einige wichtige Merkmale der persönlichen Kredit 
von Diamant Swiss Darlehen Unternehmen angeboten. Hier sind die Loan Faktoren 
arbeiten wir mit den führenden britischen Broker, die den Zugang zu 
Top-Kreditgeber haben und in der Lage, die beste finanzielle Lösung zu einem 
erschwinglichen price.Please finden, wenn Sie interessiert sind kontaktieren 
Sie uns bitte über diese E-Mail: diamonds_wisslo...@hotmail.com



Nach der Reaktion, werden Sie einen Antrag auf Kredit fill empfangen. Keine 
soziale Sicherheit und keine Bonitätsprüfung, 100% garantiert.


Es wird uns eine Ehre, wenn Sie uns erlauben, zu Ihren Diensten.



Mehr Informationen benötigt

Ihre Namen:
Adresse: ...
Telefon: ...
Benötigte Menge: 
Dauer: ...
Beruf: ...
Monatliches Einkommen Level: 
Geschlecht: ...
Geburtsdatum: 
Status: .
Land: ..
Zweck: .

Treffen Sie Ihre finanziellen Bedürfnisse ist unser Stolz.

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

Darlehen anbieten

[DIAMOND SWISS LOAN COMPANY]

Guten Tag,


Dies ist Diamant Swiss Darlehen Unternehmen Darlehen bieten.


Diamant Swiss Darlehen Unternehmen bietet flexible und erschwingliche Kredite 
für jeden Zweck zu helfen, Ihre Ziele zu erreichen. wir Darlehen zu niedrigen 
Zinssatz von 1,5%. Hier sind einige wichtige Merkmale der persönlichen Kredit 
von Diamant Swiss Darlehen Unternehmen angeboten. Hier sind die Loan Faktoren 
arbeiten wir mit den führenden britischen Broker, die den Zugang zu 
Top-Kreditgeber haben und in der Lage, die beste finanzielle Lösung zu einem 
erschwinglichen price.Please finden, wenn Sie interessiert sind kontaktieren 
Sie uns bitte über diese E-Mail: diamonds_wisslo...@hotmail.com



Nach der Reaktion, werden Sie einen Antrag auf Kredit fill empfangen. Keine 
soziale Sicherheit und keine Bonitätsprüfung, 100% garantiert.


Es wird uns eine Ehre, wenn Sie uns erlauben, zu Ihren Diensten.



Mehr Informationen benötigt

Ihre Namen:
Adresse: ...
Telefon: ...
Benötigte Menge: 
Dauer: ...
Beruf: ...
Monatliches Einkommen Level: 
Geschlecht: ...
Geburtsdatum: 
Status: .
Land: ..
Zweck: .

Treffen Sie Ihre finanziellen Bedürfnisse ist unser Stolz.

Mr.Diamond Peters
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: rockchip: i2s: add 8 channels capture and lrck-mode support

[sugar]

Hi Mark Brown,

在 9/24/2015 00:24, Mark Brown 写道:

On Wed, Sep 23, 2015 at 11:41:22AM +0800, Sugar Zhang wrote:


+   /* configure tx/rx lrck use mode */
+   if (!of_property_read_u32(node, "rockchip,lrck-mode", &val)) {
+   if (val >= LRCK_TXRX && val <= LRCK_RX_SHARE)
+   regmap_update_bits(i2s->regmap, I2S_CKR,
+  I2S_CKR_TRCM_MASK,
+  I2S_CKR_TRCM(val));
+   }


This looks like it's for a board configuration thing so I'd not really
expect this to be handled in a device specific property - it's fairly
common to have this situation and we already have the symmetric_rates
flag for the DAI to handle it (and if we do end up adding this property
we'd need the driver to set that flag so that the core can handle things
properly and make sure that userspace doesn't try to set different rates
in different directions).

My initial thought here is that the machine driver should be responsible
for setting this and then the DAI driver should check to see if
symmetric_rates are in use and configure itself appropriately.  Is there
a reason why this won't work here?



It's for i2s ip configuration, in the most situation, there is no need
to use this property, except one case:

In order to save gpio pins for other function use, we may use single
lrck(tx or rx) pin. of course, it depends on product design. when in i2s
slave mode, we need to configure this to share lrck with tx/rx inside 
i2s logic.


symmetric_rates flag works fine on rockchip platform, but it can't cover 
the above case.


Do you have any suggestion about this or maybe there is no need to 
upstream this special part?


Best Regards
Sugar

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

RE: [PATCH 0/9] drivers:mtd:UBI: add bakvol module for MLC NAND paired page issue

[beanhuo]

> Hi Bean,
> 
> Next time you send a patch series, could send all the patches in reply to the
> cover letter?

No problem, we will format our submit-patch method, and standard it.


> > Hello,
> >
> > This series aims at adding a bakvol module for MLC NAND paired page
> > Power loss protection.
> > MLC NAND paired page power loss is a known issue so far, MLC NAND
> > pages are coupled in a sense that if you cut power while writing to a
> > page, you corrupt not only this page, but also one of the previous pages
> which is paired with the current one.
> > Currently, there is no a perfect solution for this.
> > This paired page solution is based on NAND multiple plane program
> > feature. For this Patch, only used dual plane page program, means two
> > different plane pages can Be programmed together at the same time.
> > Dual plane page program only implements in backup operation. Only
> > lower page data Be duplicated and back up into a internal log volume by
> dual plane program method.
> 
> Hm, I'm not very fond of the idea, especially because of the complexity caused
> by dual plane program operations (you can't take a random block to write your
> backup on it, which means WL is complexified too), and the fact that you're
> duplicating data (thus introducing a performance penalty and storage
> overhead).
Yes, dual plane program operation has special pages requirement. 
The page address bits, PA[7:0], must be identical for each issued address.
This is being defined by ONFI specification. It will definitely result in 
storage 
overhead, but the performance of dual plane program is better than normal page 
program.
Because we don't program source data and backup data one page by one page.

> >
> > This patch has been testing on Micron 70s/80s/90s MLC NAND.
> > Of course there are some places needed to be improved and simplified.
> >
> > Any suggestion and comments welcomed.
> 
> Sure, I'll try to review it soon.

Thanks, this is a initial version, I think, there are some places needed to be 
perfected.

> Thanks for submitting those patches.
> 
> Best Regards,
> 
> Boris
> 
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()

[Konstantin Khlebnikov]

On 25.09.2015 20:56, Oleg Nesterov wrote:

On 09/25, Konstantin Khlebnikov wrote:


+struct ns_common *proc_ns_fdget(int fd, int nstype, struct fd *fd_ref)
  {
-   struct file *file;
+   struct ns_common *ns;
+   struct fd f;

-   file = fget(fd);
-   if (!file)
+   f = fdget(fd);
+   if (!f.file)
return ERR_PTR(-EBADF);

-   if (file->f_op != &ns_file_operations)
+   if (f.file->f_op != &ns_file_operations)
+   goto out_invalid;
+
+   ns = get_proc_ns(file_inode(f.file));
+   if (nstype && (ns->ops->type != nstype))
goto out_invalid;

-   return file;
+   *fd_ref = f;
+   return ns;

  out_invalid:
-   fput(file);
+   fdput(f);
return ERR_PTR(-EINVAL);
  }


Well yes, fdget() makes sense but this is minor.

Honestly, I do not really like the new helper... I understand this
is subjective, so I won't insist. But how about 1/1? We do not need
fd/file at all. With this patch your sys_getvpid() can just use
proc_get_ns_by_fd(fd, CLONE_NEWPID) and put_pid_ns().


Hmm. My version has 0 or 2 atomic ops per get-put sequence.
Your version: 2 or 4 atomic ops. Plus even in worst case pinning by
struct fd theoretically scales better because it touches refcount at
struct file: there're might be many of them for one namespace.



Eric, what do you think?

See also "TODO" in the changelog.

Oleg.




--
Konstantin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86/efi: Map EFI memmap entries in-order at runtime

[Ingo Molnar]

* Ard Biesheuvel  wrote:

> On 27 September 2015 at 08:03, Ingo Molnar  wrote:
> >
> > * Matt Fleming  wrote:
> >
> [...]
> >> [...] The actual virtual addresses we pick are exactly the same with the 
> >> two
> >> patches.
> >
> > So I'm NAK-ing this for now:
> >
> >  - The code is it reads today pretends to be an 'allocator'. It is _NOT_ an
> >allocator, because all the sections have already been determined by the
> >firmware, and, as we just learned the hard way, we do not want to 
> > deviate from
> >that! There's nothing to 'allocate'!
> >
> >What these patches seem to implement is an elaborate 'allocator' that 
> > ends up
> >doing nothing on 'new 64-bit' ...
> >
> >  - The 32-bit and 64-bit and 'old_mmap' asymmetries:
> >
> > if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
> >
> >seem fragile and nonsensical. The question is: is it possible for the 
> > whole EFI
> >image to be larger than a couple of megabytes? If not then 32-bit should 
> > just
> >mirror the firmware layout as well, and if EFI_OLD_MEMMAP does anything
> >differently from this _obvious_ 1:1 mapping of the EFI memory offsets 
> > then it's
> >not worth keeping as a legacy, because there's just nothing better than
> >mirroring the firmware layout.
> >
> > My suggestion would be to just 1:1 map what the EFI tables describe, modulo 
> > the
> > single absolute offset by which we shift the whole thing to a single base.
> >
> > Is there any technical reason why we'd want to deviate from that? Gigabytes 
> > of
> > tables or gigabytes of holes that 32-bit cannot handle? Firmware that wants 
> > an OS
> > layout that differs from the firmware layout?
> >
> 
> The combined EFI_MEMORY_RUNTIME regions could span the entire 1:1 addressable 
> PA 
> space. They usually don't but it is a possibility, which means 32-bit will 
> not 
> generally be able to support this approach. [...]

Ok, that's a good argument which invalidates my NAK.

> [...] For 64-bit ARM, there are some minor complications when the base of RAM 
> is 
> up very high in physical memory, but we already fixed that for the boot time 
> ID 
> map and for KVM.
> 
> > Also, nobody seems to be asking the obvious hardware compatibility question 
> > when trying to implement a standard influenced in great part by an entity 
> > that 
> > is partly ignorant of and partly hostile to Linux: how does Windows map the 
> > EFI sections, under what OSs are these firmware versions tested? I suspect 
> > no 
> > firmware is released that crashes on bootup on all OSs that can run on that 
> > hardware, right?
> 
> Interestingly, it was the other way around this time. The engineers that 
> implemented this feature for EDK2 could not boot Windows 8 anymore, because 
> it 
> supposedly maps the regions in reverse order as well (and MS too will need to 
> backport a fix that inverts the mapping order). The engineers also tested 
> Linux/x86, by means of a SUSE installer image, which booted fine, most likely 
> due to the fact that it is an older version which still uses the old memmap 
> layout.

That's nice to hear!

> My concern with all of this is that this security feature will become an 
> obscure 
> opt-in feature rather than something UEFIv2.5 firmware implementations can 
> enable by default.

Ok, so I think the patches are mostly fine after all, except that I don't think 
the condition on 64-bit makes any sense:

+   if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {

I can see us being nervous wrt. backported patches, but is there any strong 
reason 
to not follow this up with a third (non-backported) patch that changes this to:

+   if (!efi_enabled(EFI_OLD_MEMMAP)) {

for v4.4?

Thanks,

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

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[Arnd Bergmann]

On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > On 25 September 2015 at 15:19, Rafael J. Wysocki  
> > > wrote:
> > > > So if you allow something like debugfs to update your structure, how
> > > > do you make sure there is the proper locking?
> > > 
> > > Not really sure at all.. Isn't there some debugfs locking that will
> > > jump in, to avoid updation of fields to the same device?
> > 
> > No, if you need any locking to access variable, you cannot use the
> > simple debugfs helpers but have to provide your own functions.
> > 
> > > >> Anyway, that problem isn't here for sure as its between two
> > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > >
> > > > I guess it might be more convenient to fold this into the other patch,
> > > > because we seem to be splitting hairs here.
> > > 
> > > I can and that's what I did. But then Arnd asked me to separate it
> > > out. I can fold it back if that's what you want.
> > 
> > It still makes sense to keep it separate I think, the patch is clearly
> > different from the other parts.
> 
> I just don't see much point in going from unsigned long to u32 and then
> from 32 to bool if we can go directly to bool in one go.

It's only important to keep the 34-file multi-subsystem trivial cleanup
that doesn't change any functionality separate from the bugfix. If you
like to avoid patching one of the files twice, the alternative would
be to first change the API for all other instances from u32 to bool
and leave ACPI alone, and then do the second patch that changes ACPI
from long to bool.

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: [linux-sunxi][alsa-devel][PATCH 3/3] ASOC: sunxi: Add support for the spdif block

[Maxime Ripard]

On Thu, Sep 24, 2015 at 04:30:05PM +0200, codekip...@gmail.com wrote:
> From: Marcus Cooper 
> 
> The sun4i, sun6i and sun7i SoC families have an SPDIF
> block which is capable of playback and capture.
> 
> This patch enables the playback of this block for
> the sun4i and sun7i families.
> 
> Signed-off-by: Marcus Cooper 
> ---
>  sound/soc/sunxi/Kconfig   |  10 +
>  sound/soc/sunxi/Makefile  |   4 +
>  sound/soc/sunxi/sunxi-machine-spdif.c | 110 +
>  sound/soc/sunxi/sunxi-spdif.c | 801 
> ++
>  4 files changed, 925 insertions(+)
>  create mode 100644 sound/soc/sunxi/sunxi-machine-spdif.c
>  create mode 100644 sound/soc/sunxi/sunxi-spdif.c
> 
> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
> index 84c72ec..053db02 100644
> --- a/sound/soc/sunxi/Kconfig
> +++ b/sound/soc/sunxi/Kconfig
> @@ -8,4 +8,14 @@ config SND_SUN4I_CODEC
> Select Y or M to add support for the Codec embedded in the Allwinner
> A10 and affiliated SoCs.
>  
> +config SND_SOC_SUNXI_DAI_SPDIF
> +tristate
> +select SND_SOC_GENERIC_DMAENGINE_PCM
> +select REGMAP_MMIO
> +
> +config SND_SOC_SUNXI_MACHINE_SPDIF
> +tristate "APB on-chip sun4i/sun5i/sun7i SPDIF"
> +select SND_SOC_SUNXI_DAI_SPDIF
> +help
> +  Say Y if you want to add support for SoC S/PDIF audio as simple 
> audio card.
>  endmenu
> diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
> index ea8a08c..7849a75 100644
> --- a/sound/soc/sunxi/Makefile
> +++ b/sound/soc/sunxi/Makefile
> @@ -1,2 +1,6 @@
>  obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
>  
> +snd-soc-sunxi-dai-spdif-objs := sunxi-spdif.o
> +obj-$(CONFIG_SND_SOC_SUNXI_DAI_SPDIF) += snd-soc-sunxi-dai-spdif.o
> +snd-soc-sunxi-machine-spdif-objs := sunxi-machine-spdif.o
> +obj-$(CONFIG_SND_SOC_SUNXI_MACHINE_SPDIF) += snd-soc-sunxi-machine-spdif.o
> diff --git a/sound/soc/sunxi/sunxi-machine-spdif.c 
> b/sound/soc/sunxi/sunxi-machine-spdif.c
> new file mode 100644
> index 000..f8f6bd8
> --- /dev/null
> +++ b/sound/soc/sunxi/sunxi-machine-spdif.c
> @@ -0,0 +1,110 @@
> +/*
> + * Copyright (C) 2015 Andrea Venturi 
> + * From code by (C) 2013 Freescale Semiconductor, Inc.
> + * (sound/soc/fsl/imx-spdif.c)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +struct sunxi_machine_spdif_data {
> + struct snd_soc_dai_link dai;
> + struct snd_soc_card card;
> +};
> +
> +static int sunxi_machine_spdif_audio_probe(struct platform_device *pdev)
> +{
> + struct device_node *spdif_np, *np = pdev->dev.of_node;
> + struct sunxi_machine_spdif_data *data;
> + int ret = 0;
> +
> + dev_dbg(&pdev->dev, "%s: Looking for spdif-controller\n", __func__);
> + spdif_np = of_parse_phandle(np, "spdif-controller", 0);
> + if (!spdif_np) {
> + dev_err(&pdev->dev, "failed to find spdif-controller\n");
> + ret = -EINVAL;
> + goto end;
> + }
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data) {
> + ret = -ENOMEM;
> + goto end;
> + }
> +
> + data->dai.name = "S/PDIF PCM";
> + data->dai.stream_name = "S/PDIF PCM";
> + data->dai.codec_dai_name = "snd-soc-dummy-dai";
> + data->dai.codec_name = "snd-soc-dummy";
> + data->dai.cpu_of_node = spdif_np;
> + data->dai.platform_of_node = spdif_np;
> + data->dai.playback_only = true;
> + data->dai.capture_only = true;
> +
> + if (of_property_read_bool(np, "spdif-out"))
> + data->dai.capture_only = false;
> +
> + if (of_property_read_bool(np, "spdif-in"))
> + data->dai.playback_only = false;
> +
> + if (data->dai.playback_only && data->dai.capture_only) {
> + dev_err(&pdev->dev, "no enabled S/PDIF DAI link\n");
> + goto end;
> + }
> +
> + data->card.dev = &pdev->dev;
> + data->card.dai_link = &data->dai;
> + data->card.num_links = 1;
> + data->card.owner = THIS_MODULE;
> +
> + ret = snd_soc_of_parse_card_name(&data->card, "model");
> + if (ret)
> + goto end;
> +
> + ret = devm_snd_soc_register_card(&pdev->dev, &data->card);
> + if (ret) {
> + dev_err(&pdev->dev, "snd_soc_register_card failed: %d\n", ret);
> + goto end;
> + }
> +
> + platform_set_drvdata(pdev, data);
> +
> +end:
> + of_node_put(spdif_np);
> +
> +

RE: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey

[Opensource [Steve Twiss]]

> Subject: Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for 
> DA9062 OnKey
> 
> On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> > On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:
> > > From: S Twiss 
> > >
> > > Add device tree bindings for the DA9062 OnKey driver component
> > >
> > > Signed-off-by: Steve Twiss 
> > >
> > > ---
> > > Changes in V3:
> > >  - Child driver specifics separated out into separate document
> > >in this case ../input/da9062-onkey.txt
> > > Changes in V2:
> > >  - No change
> > >
> > > This patch applies against linux-next and next-20150708
> > >
> > >
> > >  .../devicetree/bindings/input/da9062-onkey.txt | 36
> ++
> > >  Documentation/devicetree/bindings/mfd/da9062.txt   |  3 ++
> >
> > I dropped bits for mfd/da9062.txt, changed to mention both 9062 and
> > 9063, folded into the onkey patch and applied.
> 
> Argh, da9062 core is not in mainline yet... OK, below is the patch I
> had; if Lee does not pick it up I'll re-apply it when da9062 core hits
> mainline.
> 

Hi Lee and Dmitry,

This patch seems to have been missed. It is the main OnKey driver for DA9062 
and this
component was waiting for the DA9062 MFD core to make it into 
linux-mainline/v4.3-rc1.

Is there any reply on this yet please? There just seems to be a little patch 
administration
problem holding things up.

Regards,
Steve

> 
> Input: add DA9062 OnKey capability to DA9063 OnKey driver
> 
> From: S Twiss 
> 
> Add DA9062 OnKey support into the existing DA9063 OnKey driver
> component by
> using generic access tables for common register and bit mask definitions.
> 
> The following change will add generic register and bit mask support to the
> DA9063 OnKey.
> 
> The following alterations have been made to the DA9063 OnKey:
> 
> - Addition of a da906x_chip_config structure to hold all
>   generic registers and bitmasks for this type of OnKey component.
> - Addition of an struct of_device_id table for DA9063 and DA9062
>   defaults
> - Refactoring functions to use struct da9063_onkey accesses to generic
>   registers/masks instead of using defines from registers.h
> - Re-work of da9063_onkey_probe() to use of_match_node() and
>   dev_get_regmap() to provide initialisation of generic registers and
>   masks and access to regmap
> 
> Signed-off-by: Steve Twiss 
> Signed-off-by: Dmitry Torokhov 
> ---
>  .../devicetree/bindings/input/da9062-onkey.txt |   32 +
>  drivers/input/misc/Kconfig |8 +
>  drivers/input/misc/da9063_onkey.c  |  129 
> 
>  3 files changed, 140 insertions(+), 29 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/input/da9062-
> onkey.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt
> b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> new file mode 100644
> index 000..ab0e048
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> @@ -0,0 +1,32 @@
> +* Dialog DA9062/63 OnKey Module
> +
> +This module is part of the DA9062/DA9063. For more details about entire
> +chips see Documentation/devicetree/bindings/mfd/da9062.txt and
> +Documentation/devicetree/bindings/mfd/da9063.txt
> +
> +This module provides KEY_POWER, KEY_SLEEP and events.
> +
> +Required properties:
> +
> +  - compatible: should be one of:
> + dlg,da9062-onkey
> + dlg,da9063-onkey
> +
> +Optional properties:
> +
> +  - dlg,disable-key-power : Disable power-down using a long key-press. If
> this
> +entry exists the OnKey driver will remove support for the KEY_POWER
> key
> +press. If this entry does not exist then by default the key-press
> +triggered power down is enabled and the OnKey will support both
> KEY_POWER
> +and KEY_SLEEP.
> +
> +Example:
> +
> + pmic0: da9062@58 {
> +
> + onkey {
> + compatible = "dlg,da9063-onkey";
> + dlg,disable-key-power;
> + };
> +
> + };
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index d4f0a81..d4b993d 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -611,11 +611,11 @@ config INPUT_DA9055_ONKEY
> will be called da9055_onkey.
> 
>  config INPUT_DA9063_ONKEY
> - tristate "Dialog DA9063 OnKey"
> - depends on MFD_DA9063
> + tristate "Dialog DA9062/63 OnKey"
> + depends on MFD_DA9063 || MFD_DA9062
>   help
> -   Support the ONKEY of Dialog DA9063 Power Management IC as an
> -   input device reporting power button statue.
> +   Support the ONKEY of Dialog DA9063 and DA9062 Power
> Management ICs
> +   as an input device capable of reporting the power button status.
> 
> To compile this driver as a module, choose M here: the module
> will be called da9063_onkey.
> diff --git a/drivers/input/misc/da9063_onkey.c
> b/drivers/input/misc/da9063_onkey.c
> index f577585..

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

[Leizhen (ThunderTown)]

On 2015/9/28 15:35, Arnd Bergmann wrote:
> On Monday 28 September 2015 13:34:38 Zhen Lei wrote:
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 07d1811..25cec57 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -85,7 +85,7 @@ config ARM64
>> select PERF_USE_VMALLOC
>> select POWER_RESET
>> select POWER_SUPPLY
>> -   select RTC_LIB
>> +   select RTC_LIB if !EFI
>> select SPARSE_IRQ
>> select SYSCTL_EXCEPTION_TRACE
>> select HAVE_CONTEXT_TRACKING
> 
> Sorry, we can't do that: enabling EFI has to be done in a way that it only
> adds features but not disables them.

I run "make ARCH=arm64 menuconfig" and found that RTC_CLASS is selected by 
default. Actually, RTC_LIB only
controls whether to display some configs when run "make menuconfig". I list all 
informations below:

-make ARCH=arm64 menuconfig-
  [*] Real Time Clock  --->

-drivers/rtc/Kconfig---
menuconfig RTC_CLASS
bool "Real Time Clock"
default n
depends on !S390 && !UML
select RTC_LIB

---
find . -name "*Kconfig*" | xargs grep RTC_LIB
./drivers/rtc/Kconfig:config RTC_LIB
./drivers/rtc/Kconfig:  select RTC_LIB
./drivers/char/Kconfig:if RTC_LIB=n
./drivers/char/Kconfig:endif # RTC_LIB
./arch/x86/Kconfig: select RTC_LIB
./arch/arm/Kconfig: select RTC_LIB
./arch/arm64/Kconfig:   select RTC_LIB if !EFI
./arch/sh/Kconfig:  select RTC_LIB
./arch/mips/Kconfig:select RTC_LIB if !MACH_LOONGSON64

--drivers/char/Kconfig--
if RTC_LIB=n

config RTC
tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"

...

endif # RTC_LIB


> 
> Your patch breaks RTC on all non-EFI platforms as soon as CONFIG_EFI
> is selected by the user.

No, on non-EFI platforms, they can still use RTC as before. As I mentioned 
above,
RTC_LIB only controls whether to display some configs when run "make 
menuconfig".
On ARM64, (in this patch) I only allowed EFI_RTC can be showed when RTC_LIB was 
not selected.

--drivers/char/Kconfig--
if RTC_LIB=n

config RTC
tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"

...

config EFI_RTC
bool "EFI Real Time Clock Services"
depends on IA64 || ARM64

...

endif # RTC_LIB

> 
>   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] Staging: rtl8712: rtl871x_ioctl_linux.c Move constant to right side of the comparision

[Dan Carpenter]

Don't worry too much.  I think your patches are basically fine.  I'm a
fairly experience kernel dev but I don't know what an N/M patch is...

Just don't work on staging/rtl* any more.  The rest of staging is fine.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/12] mtd: nand-bbt: move nand_bbt.c to mtd folder

[peterpandong]

Hi Brian,

Thanks for your reply.

On Fri, Sep 25, 2015 at 06:48:05AM +, Brian Norris < 
computersforpe...@gmail.com >
wrote:
> Hi Peter,
> 
> First of all, thanks for taking the time to try to address my
> long-delayed comments. I hope to give this a proper look soon. (I also
> hope you can fix the email threading soon! I know that's a pain...)

Sorry for bringing inconvenience . I'm working on this now. I'm trying to enable
git-send-email on my server. Once it done, I will resend this series. But 
please look
at this series first if you have time.

> 
> But first, a simpler comment:
> 
> On Fri, Sep 25, 2015 at 06:48:05AM +, Peter Pan 潘栋 (peterpandong)
> wrote:
> > Since struct nand_chip is removed from nand_bbt.c, BBT is now
> > shareable. Both NAND and SPI NAND can use it. So move nand_bbt.c
> > from nand/ foler to mtd/ folder and create MTD_NAND_BBT config.
> > Both NAND and SPI NAND should depend on MTD_NAND_BBT.
> >
> > Signed-off-by: Peter Pan 
> > ---
> >  drivers/mtd/Kconfig |7 +
> >  drivers/mtd/Makefile|1 +
> >  drivers/mtd/nand/Kconfig|2 +-
> >  drivers/mtd/nand/Makefile   |2 +-
> >  drivers/mtd/nand/nand_bbt.c | 1289 
> > ---
> >  drivers/mtd/nand_bbt.c  | 1289
> +++
> >  6 files changed, 1299 insertions(+), 1291 deletions(-)
> >  delete mode 100644 drivers/mtd/nand/nand_bbt.c
> >  create mode 100644 drivers/mtd/nand_bbt.c
> >
> [...]
> > diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
> > deleted file mode 100644
> > index 47c1084..000
> > --- a/drivers/mtd/nand/nand_bbt.c
> > +++ /dev/null
> > @@ -1,1289 +0,0 @@
> 
> [snip deleting entire file]
> 
> > diff --git a/drivers/mtd/nand_bbt.c b/drivers/mtd/nand_bbt.c
> > new file mode 100644
> > index 000..47c1084
> > --- /dev/null
> > +++ b/drivers/mtd/nand_bbt.c
> > @@ -0,0 +1,1289 @@
> 
> [snip adding the whole file again -- exactly the same I hope?]

Yes. The whole file is exactly the same.

> 
> When moving files, it helps if you can use the '-M' (or
> '--find-renames') option to git-format-patch. That will give much
> smaller output that's easier to review. And if you had to change
> anything in the move, it should also help highlight exactly what
> changed, instead of including the entire file "diff".

Thanks a lot for your suggestion. I'm quite new with patch submit.
So please feel free to point out my missing/mistake. Thanks in advance.

> 
> Regards,
> Brian
> 
> P.S. Incidentally, this should also work around your issues with the
> copyright symbol. But then, I suspect that some people have used these
> sorts of non-ASCII characters just to fish out issues with mail
> clients/MTAs like yours :)
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

[Arnd Bergmann]

On Monday 28 September 2015 16:29:57 Leizhen wrote:
> 
> On 2015/9/28 15:35, Arnd Bergmann wrote:
> > On Monday 28 September 2015 13:34:38 Zhen Lei wrote:
> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >> index 07d1811..25cec57 100644
> >> --- a/arch/arm64/Kconfig
> >> +++ b/arch/arm64/Kconfig
> >> @@ -85,7 +85,7 @@ config ARM64
> >> select PERF_USE_VMALLOC
> >> select POWER_RESET
> >> select POWER_SUPPLY
> >> -   select RTC_LIB
> >> +   select RTC_LIB if !EFI
> >> select SPARSE_IRQ
> >> select SYSCTL_EXCEPTION_TRACE
> >> select HAVE_CONTEXT_TRACKING
> > 
> > Sorry, we can't do that: enabling EFI has to be done in a way that it only
> > adds features but not disables them.
> 
> I run "make ARCH=arm64 menuconfig" and found that RTC_CLASS is selected by 
> default. Actually, RTC_LIB only
> controls whether to display some configs when run "make menuconfig". I list 
> all informations below:
> 
> -make ARCH=arm64 menuconfig-
>   [*] Real Time Clock  --->
> 
> -drivers/rtc/Kconfig---
> menuconfig RTC_CLASS
> bool "Real Time Clock"
> default n
> depends on !S390 && !UML
> select RTC_LIB

Ok, I see. So your patch here has no effect at all and can be dropped, or
we can remove the 'select RTC_LIB' without the EFI dependency.

> ---
> find . -name "*Kconfig*" | xargs grep RTC_LIB
> ./drivers/rtc/Kconfig:config RTC_LIB
> ./drivers/rtc/Kconfig:select RTC_LIB
> ./drivers/char/Kconfig:if RTC_LIB=n
> ./drivers/char/Kconfig:endif # RTC_LIB
> ./arch/x86/Kconfig:   select RTC_LIB
> ./arch/arm/Kconfig:   select RTC_LIB
> ./arch/arm64/Kconfig: select RTC_LIB if !EFI
> ./arch/sh/Kconfig:select RTC_LIB
> ./arch/mips/Kconfig:  select RTC_LIB if !MACH_LOONGSON64
> 
> --drivers/char/Kconfig--
> if RTC_LIB=n
> 
> config RTC
> tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
> 
> ...
> 
> endif # RTC_LIB
> 
> 
> > 
> > Your patch breaks RTC on all non-EFI platforms as soon as CONFIG_EFI
> > is selected by the user.
> 
> No, on non-EFI platforms, they can still use RTC as before. As I mentioned 
> above,
> RTC_LIB only controls whether to display some configs when run "make 
> menuconfig".
> On ARM64, (in this patch) I only allowed EFI_RTC can be showed when RTC_LIB 
> was
> not selected.
>

but that is the wrong driver that uses the legacy API, we cannot have that
on ARM because it conflicts with the normal RTC_CLASS drivers.

> --drivers/char/Kconfig--
> if RTC_LIB=n
> 
> config RTC
> tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
> 
> ...
> 
> config EFI_RTC
> bool "EFI Real Time Clock Services"
> depends on IA64 || ARM64
> 
> ...
> 
> endif # RTC_LIB

The driver you want is RTC_DRV_EFI, not EFI_RTC.

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: [alsa-devel] [PATCH 1/2] dmaengine: OF DMAEngine API based on CONFIG_DMA_OF instead of CONFIG_OF

[Kuninori Morimoto]

Hi Vinod

> > > > 5fa422c ("dmaengine: move drivers/of/dma.c -> drivers/dma/of-dma.c")
> > > > moved OF base DMAEngine code to of-dma.c, then it based on 
> > > > CONFIG_DMA_OF.
> > > > But, OF base DMAEngine API on of_dma.h still based on CONFIG_OF now.
> > > > So, current kernel can't find OF base DMAEngine API if .config has 
> > > > CONFIG_OF,
> > > > but not have CONFIG_DMA_OF. This patch tidyup it.
> > > 
> > > I did a quick build with arm config, but didn't see any failures. But 
> > > still
> > > am worried about random config and other builds may find.
> > > 
> > > So I think it would be safer to merge this patch after merge window so 
> > > that
> > > we have ample time to fix any issue
> 
> Which branch can I find this patch ?

Which branch can I find this patch ?

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

Re: [PATCH 1/1] dmaengine: dw: resolve recursion lock when audio playback

[Andy Shevchenko]

On Mon, 2015-09-28 at 15:23 +0800, yitian wrote:
> > 
> > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> > Sent: Monday, September 28, 2015 3:06 PM
> > To: Viresh Kumar 
> > Cc: yitian ; Viresh Kumar
> > ; Andy Shevchenko
> > ; Vinod Koul <
> > vinod.k...@intel.com>;
> > Dan Williams ; dmaengine
> > ; Linux Kernel Mailing List
> > 
> > Subject: Re: [PATCH 1/1] dmaengine: dw: resolve recursion 
> > > I am not sure if this is a sane way of doing that, and we were 
> > > scanning
> > > the descriptors for some valid reason..
> > 
> > Actually one of the patches in a pile sitting in my private repo is
> > also including similar change. In my case the reason is to support
> > cyclic transfers natively.
> > 
> 
> Yes, i am using DW DMAC to support cyclic transfer.
> Currently it is very easy to get recursion lock crash, but
> after this patch everything is fine on my device.

What is an actual hardware you are running kernel on?

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

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

[Leizhen (ThunderTown)]

On 2015/9/28 15:40, Ard Biesheuvel wrote:
> On 28 September 2015 at 06:34, Zhen Lei  wrote:
>> Now, ARM64 is also support EFI startup. We hope use EFI runtime services
>> to get/set current time and date.
>>
>> RTC_LIB only controls some configs in drivers/char/Kconfig(included
>> EFI_RTC), and will be automatically selected when RTC_CLASS opened. So
>> this patch have no functional change but give an opportunity to select
>> EFI_RTC when RTC_CLASS closed.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 07d1811..25cec57 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -85,7 +85,7 @@ config ARM64
>> select PERF_USE_VMALLOC
>> select POWER_RESET
>> select POWER_SUPPLY
>> -   select RTC_LIB
>> +   select RTC_LIB if !EFI
>> select SPARSE_IRQ
>> select SYSCTL_EXCEPTION_TRACE
>> select HAVE_CONTEXT_TRACKING
> 
> You can currently enable EFI_RTC just fine on arm64 when EFI is enabled.
> Why exactly do you need this patch on top?

Because when we run "make ARCH=arm64 menuconfig", RTC_LIB is always selected. 
And we have no opportunity
to deselect it. And EFI_RTC can be displayed only when RTC_LIB=n.

drivers/rtc/Kconfig---
config RTC_LIB
bool

menuconfig RTC_CLASS
bool "Real Time Clock"
default n
depends on !S390 && !UML
select RTC_LIB

--drivers/char/Kconfig--
if RTC_LIB=n

..

config EFI_RTC
bool "EFI Real Time Clock Services"
depends on IA64 || ARM64

...

endif # RTC_LIB

> 
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] CHROMIUM: iio: Add Dyna-Image AP3223 ambient light and proximity driver

[Daniel Baluta]

CHROMIUM: iio: Add Dyna-Image AP3223 ambient light and proximity driver

Please remove CHROMIUM from the commit message. Consider using
something like this:

iio: light: Add Dyna-Image AP3223 ambient light and proximity driver

On Mon, Sep 28, 2015 at 8:00 AM, Suresh Rajashekara
 wrote:
> Minimal implementation. This is based on the driver provided by
> the vendor (which wasn't in the IIO framework). Authors of the
> driver from the vendor included
> * John Huang 
> * Templeton Tsai 
> * Vic Lee 

Please specify features supported by this driver. E.g:
Minimal implementation with support for raw light and proximity readings.

Also, please add a link to the datasheet if available.

>
> Signed-off-by: Suresh Rajashekara 
> ---
>  .../devicetree/bindings/iio/light/ap3223.txt   |  18 +
>  .../devicetree/bindings/vendor-prefixes.txt|   1 +
>  drivers/iio/light/Kconfig  |  10 +
>  drivers/iio/light/Makefile |   1 +
>  drivers/iio/light/ap3223.c | 394 
> +
>  drivers/iio/light/ap3223.h | 227 
>  6 files changed, 651 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/light/ap3223.txt

DT bindings should be sent as a separate patch in the same patch series, with
relevant DT people CC'ed (use ./scripts/get_maintainer.pl).

>  create mode 100644 drivers/iio/light/ap3223.c
>  create mode 100644 drivers/iio/light/ap3223.h
>
> diff --git a/Documentation/devicetree/bindings/iio/light/ap3223.txt 
> b/Documentation/devicetree/bindings/iio/light/ap3223.txt
> new file mode 100644
> index 000..b255d27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/ap3223.txt
> @@ -0,0 +1,18 @@
> +* Dyna Image AP3223 ambient light sensor and proximity sensor
> +
> +http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2&dpid=8
> +
> +Required properties:
> +
> +  - compatible : should be "dynaimage,ap3223"
> +  - reg : the I2C address of the sensor
> +
> +Example:
> +
> +ap3223@1c {
> +   compatible = "dynaimage,ap3223";
> +   reg = <0x1c>;
> +
> +   pinctrl-0 = <&ap3223_pins>;
> +   pinctrl-names = "default";
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 5f20add..704da45 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -46,6 +46,7 @@ digilent  Diglent, Inc.
>  dlgDialog Semiconductor
>  dlink  D-Link Corporation
>  dmoData Modul AG
> +dynaimage  Dyna-Image
>  ebvEBV Elektronik
>  edtEmerging Display Technologies
>  elan   Elan Microelectronic Corp.
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index ae68c64..5255aa2 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -27,6 +27,16 @@ config AL3320A
>  To compile this driver as a module, choose M here: the
>  module will be called al3320a.
>
> +config AP3223
> +   tristate "AP3223 ambient light and proximity sensor"

Dyna Image AP3323 ...

> +   depends on I2C
> +   help
> +Say Y here if you want to build a driver for the Dyna Image AP3223
> +ambient light and proximity sensor.
> +
> +To compile this driver as a module, choose M here: the
> +module will be called ap3223.
> +
>  config APDS9300
> tristate "APDS9300 ambient light sensor"
> depends on I2C
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index b12a516..13a74f9 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -5,6 +5,7 @@
>  # When adding new entries keep the list in alphabetical order
>  obj-$(CONFIG_ADJD_S311)+= adjd_s311.o
>  obj-$(CONFIG_AL3320A)  += al3320a.o
> +obj-$(CONFIG_AP3223)   += ap3223.o
>  obj-$(CONFIG_APDS9300) += apds9300.o
>  obj-$(CONFIG_CM32181)  += cm32181.o
>  obj-$(CONFIG_CM3232)   += cm3232.o
> diff --git a/drivers/iio/light/ap3223.c b/drivers/iio/light/ap3223.c
> new file mode 100644
> index 000..55bbcdd
> --- /dev/null
> +++ b/drivers/iio/light/ap3223.c
> @@ -0,0 +1,394 @@
> +/*
> + * ap3223.c

Add a small description for this file or remove the comment. As it is
now it doesn't make sense because we know the name of the file we
are reading.

> + *
> + * Copyright (C) 2015 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License fo

[PATCH] bna: fix error handling

[Andrzej Hajda]

Several functions can return negative value in case of error,
so their return type should be fixed as well as type of variables
to which this value is assigned.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107

Signed-off-by: Andrzej Hajda 
---
 drivers/net/ethernet/brocade/bna/bfa_ioc.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c 
b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
index b7a0f78..9e59663 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
@@ -1543,7 +1543,7 @@ bfa_flash_cmd_act_check(void __iomem *pci_bar)
 }
 
 /* Flush FLI data fifo. */
-static u32
+static int
 bfa_flash_fifo_flush(void __iomem *pci_bar)
 {
u32 i;
@@ -1573,11 +1573,11 @@ bfa_flash_fifo_flush(void __iomem *pci_bar)
 }
 
 /* Read flash status. */
-static u32
+static int
 bfa_flash_status_read(void __iomem *pci_bar)
 {
union bfa_flash_dev_status_reg  dev_status;
-   u32 status;
+   int status;
u32 ret_status;
int i;
 
@@ -1611,11 +1611,11 @@ bfa_flash_status_read(void __iomem *pci_bar)
 }
 
 /* Start flash read operation. */
-static u32
+static int
 bfa_flash_read_start(void __iomem *pci_bar, u32 offset, u32 len,
 char *buf)
 {
-   u32 status;
+   int status;
 
/* len must be mutiple of 4 and not exceeding fifo size */
if (len == 0 || len > BFA_FLASH_FIFO_SIZE || (len & 0x03) != 0)
@@ -1703,7 +1703,8 @@ static enum bfa_status
 bfa_flash_raw_read(void __iomem *pci_bar, u32 offset, char *buf,
   u32 len)
 {
-   u32 n, status;
+   u32 n;
+   int status;
u32 off, l, s, residue, fifo_sz;
 
residue = len;
-- 
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 1/1] ASoC: dwc: fix dma stop transferring issue

[kbuild test robot]

Hi yitian,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: i386-randconfig-r0-201539 (attached as .config)
reproduce:
  git checkout 3488a5ee9b79e2ced9fa43b78c9c5d0aa7e052f9
  # save the attached .config to linux build tree
  make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   sound/soc/dwc/designware_i2s.c: In function 'i2s_start':
>> sound/soc/dwc/designware_i2s.c:148:8: error: 'i' undeclared (first use in 
>> this function)
  for (i = 0; i < 4; i++) {
   ^
   sound/soc/dwc/designware_i2s.c:148:8: note: each undeclared identifier is 
reported only once for each function it appears in
>> sound/soc/dwc/designware_i2s.c:149:4: error: 'irq' undeclared (first use in 
>> this function)
   irq = i2s_read_reg(dev->i2s_base, IMR(i));
   ^

vim +/i +148 sound/soc/dwc/designware_i2s.c

   142struct snd_pcm_substream *substream)
   143  {
   144  
   145  i2s_write_reg(dev->i2s_base, IER, 1);
   146  
   147  if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
 > 148  for (i = 0; i < 4; i++) {
 > 149  irq = i2s_read_reg(dev->i2s_base, IMR(i));
   150  i2s_write_reg(dev->i2s_base, IMR(i), irq & 
~0x30);
   151  }
   152  i2s_write_reg(dev->i2s_base, ITER, 1);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH] fix handling bq27xxx_read result

[Andrzej Hajda]

The function can return negative value.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Signed-off-by: Andrzej Hajda 
---
 drivers/power/bq27xxx_battery.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/bq27xxx_battery.c b/drivers/power/bq27xxx_battery.c
index 473aa2f..994c78d 100644
--- a/drivers/power/bq27xxx_battery.c
+++ b/drivers/power/bq27xxx_battery.c
@@ -691,7 +691,7 @@ static bool bq27xxx_battery_dead(struct bq27xxx_device_info 
*di, u16 flags)
  */
 static int bq27xxx_battery_read_health(struct bq27xxx_device_info *di)
 {
-   u16 flags;
+   int flags;
 
flags = bq27xxx_read(di, BQ27XXX_REG_FLAGS, false);
if (flags < 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/

Re: [PATCH 3/4] lib/vsprintf.c: Remove SPECIAL handling in pointer()

[Andy Shevchenko]

On Fri, 2015-09-25 at 19:41 +0200, Rasmus Villemoes wrote:
> As a quick
> 
>git grep -E '%[ +0#-]*#[ +0#-]*(\*|[0-9]+)?(\.(\*|[0-9]+)?)?p'
> 
> shows, nobody uses the # flag with %p. Moreover, I think users are
> unlikely to show up since gcc will complain with
> 
>   warning: `#' flag used with ‘%p’ gnu_printf format [-Wformat]

I would refer to POSIX here

"# Specifies that the value is to be converted to an alternative form.
...
For other conversion specifiers, the behavior is undefined."

> 
> Since default_width is effectively always 2*sizeof(void*), we can
> simplify the prologue of pointer() and save a few instructions.
> 
> Signed-off-by: Rasmus Villemoes 
> ---
>  lib/vsprintf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 03fa10b4be96..98b0d7be3fb7 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1457,7 +1457,7 @@ static noinline_for_stack
>  char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> struct printf_spec spec)
>  {
> - int default_width = 2 * sizeof(void *) + (spec.flags & 
> SPECIAL ? 2 : 0);
> + const int default_width = 2 * sizeof(void *);
>  
>   if (!ptr && *fmt != 'K') {
>   /*

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

Re: [PATCH RESEND] ARM: dts: Move display-timings node from fimd to dp

[Tomeu Vizoso]

Hi Kukjin and Krzysztof,

could you take a look at this?

Thanks,

Tomeu

On 17 September 2015 at 14:48, Tomeu Vizoso  wrote:
> From: Sean Paul 
>
> This patch moves the display-timings node from fimd to dp to reflect the
> device tree bindings change.
>
> Signed-off-by: Sean Paul 
> [tomeu.viz...@collabora.com: Rebased]
> Signed-off-by: Tomeu Vizoso 
>
> ---
>
> Hi,
>
> looks like a long time ago the bindings were changed and the DTs for
> these boards weren't updated.
>
> I have retaken Sean's forgotten patch and rebased it, but I have only
> tested on an Arndale that exynos-drm doesn't complain about missing
> timings.
>
> Regards,
>
> Tomeu
> ---
>  arch/arm/boot/dts/exynos5250-arndale.dts  |  8 
>  arch/arm/boot/dts/exynos5250-smdk5250.dts | 16 
>  arch/arm/boot/dts/exynos5420-smdk5420.dts |  7 ---
>  3 files changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index db3f65f3eb45..c000532c1444 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -129,10 +129,6 @@
> samsung,color-depth = <1>;
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <4>;
> -};
> -
> -&fimd {
> -   status = "okay";
>
> display-timings {
> native-mode = <&timing0>;
> @@ -152,6 +148,10 @@
> };
>  };
>
> +&fimd {
> +   status = "okay";
> +};
> +
>  &hdmi {
> hpd-gpio = <&gpx3 7 GPIO_ACTIVE_LOW>;
> vdd_osc-supply = <&ldo10_reg>;
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index c625e71217aa..0f5dcd418af8 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -89,14 +89,6 @@
> pinctrl-names = "default";
> pinctrl-0 = <&dp_hpd>;
> status = "okay";
> -};
> -
> -&ehci {
> -   samsung,vbus-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
> -};
> -
> -&fimd {
> -   status = "okay";
>
> display-timings {
> native-mode = <&timing0>;
> @@ -116,6 +108,14 @@
> };
>  };
>
> +&ehci {
> +   samsung,vbus-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&fimd {
> +   status = "okay";
> +};
> +
>  &hdmi {
> hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
>  };
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index 98871f972c8a..7520d52f4e22 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -98,10 +98,7 @@
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <4>;
> status = "okay";
> -};
>
> -&fimd {
> -   status = "okay";
> display-timings {
> native-mode = <&timing0>;
> timing0: timing@0 {
> @@ -118,6 +115,10 @@
> };
>  };
>
> +&fimd {
> +   status = "okay";
> +};
> +
>  &hdmi {
> status = "okay";
> hpd-gpio = <&gpx3 7 0>;
> --
> 2.4.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] fix handling bq27xxx_read result

[Pali Rohár]

On Monday 28 September 2015 10:51:27 Andrzej Hajda wrote:
> The function can return negative value.
> 
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
> 
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/power/bq27xxx_battery.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/bq27xxx_battery.c
> b/drivers/power/bq27xxx_battery.c index 473aa2f..994c78d 100644
> --- a/drivers/power/bq27xxx_battery.c
> +++ b/drivers/power/bq27xxx_battery.c
> @@ -691,7 +691,7 @@ static bool bq27xxx_battery_dead(struct
> bq27xxx_device_info *di, u16 flags) */
>  static int bq27xxx_battery_read_health(struct bq27xxx_device_info
> *di) {
> - u16 flags;
> + int flags;
> 
>   flags = bq27xxx_read(di, BQ27XXX_REG_FLAGS, false);
>   if (flags < 0) {

Seems legal change, so

Acked-By: Pali Rohár 

-- 
Pali Rohár
pali.ro...@gmail.com


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

RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[David Laight]

From: Rafael J. Wysocki
> Sent: 27 September 2015 15:09
...
> > > Say you have three adjacent fields in a structure, x, y, z, each one byte 
> > > long.
> > > Initially, all of them are equal to 0.
> > >
> > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > >
> > > What's the result?
> >
> > I think every CPU's  cache architecure guarantees adjacent store
> > integrity, even in the face of SMP, so it's x==1 and y==2.  If you're
> > thinking of old alpha SMP system where the lowest store width is 32 bits
> > and thus you have to do RMW to update a byte, this was usually fixed by
> > padding (assuming the structure is not packed).  However, it was such a
> > problem that even the later alpha chips had byte extensions.

Does linux still support those old Alphas?

The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.

> OK, thanks!

You still have to ensure the compiler doesn't do wider rmw cycles.
I believe the recent versions of gcc won't do wider accesses for volatile data.

David

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH] drivers: staging: wilc1000: Replace message queue with standard Linux lists

[Dan Carpenter]

On Sun, Sep 27, 2015 at 07:43:18PM +0530, Chandra S Gorentla wrote:
> The message queue is replaced with standard Linux linked list.  A check for
> return value of receive method is added.
> 
> Signed-off-by: Chandra S Gorentla 
> ---
>  drivers/staging/wilc1000/host_interface.c |  7 +++-
>  drivers/staging/wilc1000/wilc_msgqueue.c  | 62 
> ++-
>  drivers/staging/wilc1000/wilc_platform.h  |  5 ++-
>  3 files changed, 36 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c 
> b/drivers/staging/wilc1000/host_interface.c
> index 62f4a8a..8d0776f 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -4304,11 +4304,16 @@ static int hostIFthread(void *pvArg)
>   u32 u32Ret;
>   struct host_if_msg msg;
>   tstrWILC_WFIDrv *pstrWFIDrv;
> + int recv_ret;

Name it "ret".

int ret;

>  
>   memset(&msg, 0, sizeof(struct host_if_msg));
>  
>   while (1) {
> - wilc_mq_recv(&gMsgQHostIF, &msg, sizeof(struct host_if_msg), 
> &u32Ret);
> + recv_ret = wilc_mq_recv(&gMsgQHostIF, &msg,
> + sizeof(struct host_if_msg), &u32Ret);
> + if (recv_ret)
> + continue;

This looks like a forever loop.

> +
>   pstrWFIDrv = (tstrWILC_WFIDrv *)msg.drvHandler;
>   if (msg.id == HOST_IF_MSG_EXIT) {
>   PRINT_D(GENERIC_DBG, "THREAD: Exiting HostIfThread\n");
> diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c 
> b/drivers/staging/wilc1000/wilc_msgqueue.c
> index 869736a..67617d5 100644
> --- a/drivers/staging/wilc1000/wilc_msgqueue.c
> +++ b/drivers/staging/wilc1000/wilc_msgqueue.c
> @@ -12,9 +12,15 @@
>   */
>  int wilc_mq_create(WILC_MsgQueueHandle *pHandle)
>  {
> + pHandle->msg_cache = kmem_cache_create("wilc_message_queue",
> + sizeof(Message),
> + 0, SLAB_POISON, NULL);
> + if (!pHandle->msg_cache)
> + return -ENOMEM;

This is a separate thing from using list macros.  Or maybe it's not but
that isn't explained in the changelog.  Do one thing per patch so it's
easier to review.

> +
>   spin_lock_init(&pHandle->strCriticalSection);
>   sema_init(&pHandle->hSem, 0);
> - pHandle->pstrMessageList = NULL;
> + INIT_LIST_HEAD(&pHandle->msg_list_head);
>   pHandle->u32ReceiversCount = 0;
>   pHandle->bExiting = false;
>   return 0;
> @@ -28,6 +34,7 @@ int wilc_mq_create(WILC_MsgQueueHandle *pHandle)
>   */
>  int wilc_mq_destroy(WILC_MsgQueueHandle *pHandle)
>  {
> + Message *msg;
>   pHandle->bExiting = true;
>  
>   /* Release any waiting receiver thread. */
> @@ -36,13 +43,16 @@ int wilc_mq_destroy(WILC_MsgQueueHandle *pHandle)
>   pHandle->u32ReceiversCount--;
>   }
>  
> - while (pHandle->pstrMessageList) {
> - Message *pstrMessge = pHandle->pstrMessageList->pstrNext;
> -
> - kfree(pHandle->pstrMessageList);
> - pHandle->pstrMessageList = pstrMessge;
> + while (!list_empty(&pHandle->msg_list_head)) {
> + msg = list_first_entry(&pHandle->msg_list_head,
> + Message, link);
> + list_del(&msg->link);
> + kfree(msg->pvBuffer);
> + kmem_cache_free(pHandle->msg_cache, msg);
>   }
>  
> + kmem_cache_destroy(pHandle->msg_cache);
> +
>   return 0;
>  }
>  
> @@ -74,41 +84,28 @@ int wilc_mq_send(WILC_MsgQueueHandle *pHandle,
>   spin_lock_irqsave(&pHandle->strCriticalSection, flags);
>  
>   /* construct a new message */
> - pstrMessage = kmalloc(sizeof(Message), GFP_ATOMIC);
> - if (!pstrMessage)
> + pstrMessage = kmem_cache_zalloc(pHandle->msg_cache, GFP_ATOMIC);
> + if (!pstrMessage) {
> + spin_unlock_irqrestore(&pHandle->strCriticalSection, flags);
>   return -ENOMEM;
> + }

Do the allocation outside the lock so it doesn't have to be atomic.

>   pstrMessage->u32Length = u32SendBufferSize;
> - pstrMessage->pstrNext = NULL;
>   pstrMessage->pvBuffer = kmalloc(u32SendBufferSize, GFP_ATOMIC);
>   if (!pstrMessage->pvBuffer) {
> + kmem_cache_free(pHandle->msg_cache, pstrMessage);
>   result = -ENOMEM;
>   goto ERRORHANDLER;

This goto is meaningless now that it doesn't handle any errors.  Just do
a direct return.  Except, wait, aren't we holding a couple locks?  This
looks buggy.

>   }
>   memcpy(pstrMessage->pvBuffer, pvSendBuffer, u32SendBufferSize);
>  
>   /* add it to the message queue */
> - if (!pHandle->pstrMessageList) {
> - pHandle->pstrMessageList  = pstrMessage;
> - } else {
> - Message *pstrTailMsg = pHandle->pstrMessageList;
> -
> - while (pstrTailMsg->pstrNext)
> - ps

[PATCH] arch/x86: fix out-of-bounds in get_wchan()

[Dmitry Vyukov]

get_wchan() checks that fp is within stack bounds,
but then dereferences fp+8. This can crash kernel
or leak sensitive information. Also the function
operates on a potentially running stack, but does
not use READ_ONCE. As the result it can check that
one value is within stack bounds, but then deref
another value.

Fix the bounds check and use READ_ONCE for all
volatile data.

The bug was discovered with KASAN.

Signed-off-by: Dmitry Vyukov 
---
FTR, here is the KASAN report:

[  124.575597] ERROR: AddressSanitizer: heap-buffer-overflow on address 
88002e28
[  124.578633] Accessed by thread T10915:
[  124.581050]   #2 810dd423 in __tsan_read8 ??:0
[  124.581893]   #3 8107c093 in get_wchan 
./arch/x86/kernel/process_64.c:444
[  124.582763]   #4 81342108 in do_task_stat array.c:0
[  124.583634]   #5 81342dcc in proc_tgid_stat ??:0
[  124.584548]   #6 8133c984 in proc_single_show base.c:0
[  124.585461]   #7 812d18cc in seq_read ./fs/seq_file.c:222
[  124.586313]   #8 8129e503 in vfs_read ??:0
[  124.587137]   #9 8129f800 in SyS_read ??:0
[  124.587827]   #10 81929bf5 in sysenter_dispatch 
./arch/x86/ia32/ia32entry.S:164
[  124.588738]
[  124.593434] Shadow bytes around the buggy address:
[  124.594270]   88002e27fd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[  124.595339]   88002e27fe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[  124.596453]   88002e27fe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[  124.597466]   88002e27ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[  124.598501]   88002e27ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[  124.599629] =>88002e28:[fa]fa fa fa fa fa fa fa fa fa 00 00 00 00 00 
00
[  124.600873]   88002e280080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[  124.601892]   88002e280100: 00 fa fa fa fa fa fa fa fa fa fa fa fa fa fa 
fa
[  124.603037]   88002e280180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 
fa
[  124.604047]   88002e280200: fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 
fd
[  124.605054]   88002e280280: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa 
fa
[  124.605993] Shadow byte legend (one shadow byte represents 8 application 
bytes):
[  124.606958]   Addressable:   00
[  124.607483]   Partially addressable: 01 02 03 04 05 06 07
[  124.608219]   Heap redzone:  fa
[  124.608724]   Heap kmalloc redzone:  fb
[  124.609249]   Freed heap region: fd
[  124.609753]   Shadow gap:fe
[  124.610292] 
=
---
 arch/x86/kernel/process_64.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 71d7849..a1fce34 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -506,17 +506,19 @@ unsigned long get_wchan(struct task_struct *p)
if (!p || p == current || p->state == TASK_RUNNING)
return 0;
stack = (unsigned long)task_stack_page(p);
-   if (p->thread.sp < stack || p->thread.sp >= stack+THREAD_SIZE)
+   /* The task can be already running at this point, so tread carefully. */
+   fp = READ_ONCE(p->thread.sp);
+   if (fp < stack || fp >= stack+THREAD_SIZE)
return 0;
-   fp = *(u64 *)(p->thread.sp);
+   fp = READ_ONCE(*(u64 *)fp);
do {
if (fp < (unsigned long)stack ||
-   fp >= (unsigned long)stack+THREAD_SIZE)
+   fp+8 >= (unsigned long)stack+THREAD_SIZE)
return 0;
-   ip = *(u64 *)(fp+8);
+   ip = READ_ONCE(*(u64 *)(fp+8));
if (!in_sched_functions(ip))
return ip;
-   fp = *(u64 *)fp;
+   fp = READ_ONCE(*(u64 *)fp);
} while (count++ < 16);
return 0;
 }
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] driver-core: platform: Provide helpers for multi-driver modules

[Daniel Vetter]

On Thu, Sep 24, 2015 at 7:02 PM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> Some modules register several sub-drivers. Provide a helper that makes
> it easy to register and unregister a list of sub-drivers, as well as
> unwind properly on error.
>
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Thierry Reding 

I raised this already on irc but let's do it here too for the record:
Eric Anholt has a very similar thing (but in drm only) with the
addition of also integrating with the component framework:

http://lists.freedesktop.org/archives/dri-devel/2015-September/090449.html

Having something that works for everyone (so includes msm and can be
used for vc4 too) would be great. Adding Eric.
-Daniel

> ---
>  Documentation/driver-model/platform.txt | 11 ++
>  drivers/base/platform.c | 60 
> +
>  include/linux/platform_device.h |  5 +++
>  3 files changed, 76 insertions(+)
>
> diff --git a/Documentation/driver-model/platform.txt 
> b/Documentation/driver-model/platform.txt
> index 07795ec51cde..e80468738ba9 100644
> --- a/Documentation/driver-model/platform.txt
> +++ b/Documentation/driver-model/platform.txt
> @@ -63,6 +63,17 @@ runtime memory footprint:
> int platform_driver_probe(struct platform_driver *drv,
>   int (*probe)(struct platform_device *))
>
> +Kernel modules can be composed of several platform drivers. The platform core
> +provides helpers to register and unregister an array of drivers:
> +
> +   int platform_register_drivers(struct platform_driver * const *drivers,
> + unsigned int count);
> +   void platform_unregister_drivers(struct platform_driver * const 
> *drivers,
> +unsigned int count);
> +
> +If one of the drivers fails to register, all drivers registered up to that
> +point will be unregistered in reverse order.
> +
>
>  Device Enumeration
>  ~~
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index f80aaaf9f610..b7d7987fda97 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -711,6 +711,66 @@ err_out:
>  }
>  EXPORT_SYMBOL_GPL(__platform_create_bundle);
>
> +/**
> + * platform_register_drivers - register an array of platform drivers
> + * @drivers: an array of drivers to register
> + * @count: the number of drivers to register
> + *
> + * Registers platform drivers specified by an array. On failure to register a
> + * driver, all previously registered drivers will be unregistered. Callers of
> + * this API should use platform_unregister_drivers() to unregister drivers in
> + * the reverse order.
> + *
> + * Returns: 0 on success or a negative error code on failure.
> + */
> +int platform_register_drivers(struct platform_driver * const *drivers,
> + unsigned int count)
> +{
> +   unsigned int i;
> +   int err;
> +
> +   for (i = 0; i < count; i++) {
> +   pr_debug("registering platform driver %ps\n", drivers[i]);
> +
> +   err = platform_driver_register(drivers[i]);
> +   if (err < 0) {
> +   pr_err("failed to register platform driver %ps: %d\n",
> +  drivers[i], err);
> +   goto error;
> +   }
> +   }
> +
> +   return 0;
> +
> +error:
> +   while (i--) {
> +   pr_debug("unregistering platform driver %ps\n", drivers[i]);
> +   platform_driver_unregister(drivers[i]);
> +   }
> +
> +   return err;
> +}
> +EXPORT_SYMBOL_GPL(platform_register_drivers);
> +
> +/**
> + * platform_unregister_drivers - unregister an array of platform drivers
> + * @drivers: an array of drivers to unregister
> + * @count: the number of drivers to unregister
> + *
> + * Unegisters platform drivers specified by an array. This is typically used
> + * to complement an earlier call to platform_register_drivers(). Drivers are
> + * unregistered in the reverse order in which they were registered.
> + */
> +void platform_unregister_drivers(struct platform_driver * const *drivers,
> +unsigned int count)
> +{
> +   while (count--) {
> +   pr_debug("unregistering platform driver %ps\n", 
> drivers[count]);
> +   platform_driver_unregister(drivers[count]);
> +   }
> +}
> +EXPORT_SYMBOL_GPL(platform_unregister_drivers);
> +
>  /* modalias support enables more hands-off userspace setup:
>   * (a) environment variable lets new-style hotplug events work once system is
>   * fully running:  "modprobe $MODALIAS"
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index bba08f44cc97..0c9f16bfdd99 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -270,6 +270,11 @@ extern struct platform_device *__platform_create_bundle(
> struct resource *res, unsigned 

Re: [PATCH V2 0/3] Updates to mce_amd_inj module

[Borislav Petkov]

On Fri, Sep 25, 2015 at 09:20:48AM -0500, Aravind Gopalakrishnan wrote:
> Aravind Gopalakrishnan (3):
>   RAS, mce_amd_inj: Return early on invalid input
>   RAS, mce_amd_inj: Add capability to trigger apic interrupts
>   RAS, mce_amd_inj: Inject errors on NBC for bank 4 errors
> 
>  arch/x86/ras/mce_amd_inj.c | 109 
> ++---
>  1 file changed, 102 insertions(+), 7 deletions(-)

All applied,
thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] CHROMIUM: iio: Add Dyna-Image AP3223 ambient light and proximity driver

[Jonathan Cameron]

On 28 September 2015 09:49:33 BST, Daniel Baluta  
wrote:
>CHROMIUM: iio: Add Dyna-Image AP3223 ambient light and proximity driver
>
>Please remove CHROMIUM from the commit message. Consider using
>something like this:
>
>iio: light: Add Dyna-Image AP3223 ambient light and proximity driver

One quick point in case you respin before I take a detailed look...
General kernel practice these days is to only have stuff in a header if needed 
by
 more than one c file. Otherwise defines etc belong at the top of the c file 
itself.
Hence here most of not all that header wants to be inline...
>
>On Mon, Sep 28, 2015 at 8:00 AM, Suresh Rajashekara
> wrote:
>> Minimal implementation. This is based on the driver provided by
>> the vendor (which wasn't in the IIO framework). Authors of the
>> driver from the vendor included
>> * John Huang 
>> * Templeton Tsai 
>> * Vic Lee 
>
>Please specify features supported by this driver. E.g:
>Minimal implementation with support for raw light and proximity
>readings.
>
>Also, please add a link to the datasheet if available.
>
>>
>> Signed-off-by: Suresh Rajashekara 
>> ---
>>  .../devicetree/bindings/iio/light/ap3223.txt   |  18 +
>>  .../devicetree/bindings/vendor-prefixes.txt|   1 +
>>  drivers/iio/light/Kconfig  |  10 +
>>  drivers/iio/light/Makefile |   1 +
>>  drivers/iio/light/ap3223.c | 394
>+
>>  drivers/iio/light/ap3223.h | 227
>
>>  6 files changed, 651 insertions(+)
>>  create mode 100644
>Documentation/devicetree/bindings/iio/light/ap3223.txt
>
>DT bindings should be sent as a separate patch in the same patch
>series, with
>relevant DT people CC'ed (use ./scripts/get_maintainer.pl).
>
>>  create mode 100644 drivers/iio/light/ap3223.c
>>  create mode 100644 drivers/iio/light/ap3223.h
>>
>> diff --git a/Documentation/devicetree/bindings/iio/light/ap3223.txt
>b/Documentation/devicetree/bindings/iio/light/ap3223.txt
>> new file mode 100644
>> index 000..b255d27
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/light/ap3223.txt
>> @@ -0,0 +1,18 @@
>> +* Dyna Image AP3223 ambient light sensor and proximity sensor
>> +
>>
>+http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2&dpid=8
>> +
>> +Required properties:
>> +
>> +  - compatible : should be "dynaimage,ap3223"
>> +  - reg : the I2C address of the sensor
>> +
>> +Example:
>> +
>> +ap3223@1c {
>> +   compatible = "dynaimage,ap3223";
>> +   reg = <0x1c>;
>> +
>> +   pinctrl-0 = <&ap3223_pins>;
>> +   pinctrl-names = "default";
>> +};
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
>b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 5f20add..704da45 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -46,6 +46,7 @@ digilent  Diglent, Inc.
>>  dlgDialog Semiconductor
>>  dlink  D-Link Corporation
>>  dmoData Modul AG
>> +dynaimage  Dyna-Image
>>  ebvEBV Elektronik
>>  edtEmerging Display Technologies
>>  elan   Elan Microelectronic Corp.
>> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
>> index ae68c64..5255aa2 100644
>> --- a/drivers/iio/light/Kconfig
>> +++ b/drivers/iio/light/Kconfig
>> @@ -27,6 +27,16 @@ config AL3320A
>>  To compile this driver as a module, choose M here: the
>>  module will be called al3320a.
>>
>> +config AP3223
>> +   tristate "AP3223 ambient light and proximity sensor"
>
>Dyna Image AP3323 ...
>
>> +   depends on I2C
>> +   help
>> +Say Y here if you want to build a driver for the Dyna Image
>AP3223
>> +ambient light and proximity sensor.
>> +
>> +To compile this driver as a module, choose M here: the
>> +module will be called ap3223.
>> +
>>  config APDS9300
>> tristate "APDS9300 ambient light sensor"
>> depends on I2C
>> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
>> index b12a516..13a74f9 100644
>> --- a/drivers/iio/light/Makefile
>> +++ b/drivers/iio/light/Makefile
>> @@ -5,6 +5,7 @@
>>  # When adding new entries keep the list in alphabetical order
>>  obj-$(CONFIG_ADJD_S311)+= adjd_s311.o
>>  obj-$(CONFIG_AL3320A)  += al3320a.o
>> +obj-$(CONFIG_AP3223)   += ap3223.o
>>  obj-$(CONFIG_APDS9300) += apds9300.o
>>  obj-$(CONFIG_CM32181)  += cm32181.o
>>  obj-$(CONFIG_CM3232)   += cm3232.o
>> diff --git a/drivers/iio/light/ap3223.c b/drivers/iio/light/ap3223.c
>> new file mode 100644
>> index 000..55bbcdd
>> --- /dev/null
>> +++ b/drivers/iio/light/ap3223.c
>> @@ -0,0 +1,394 @@
>> +/*
>> + * ap3223.c
>
>Add a small description for this file or remove the comment. As it is
>now it doesn't make sense because we know the name of the file we
>are reading.
>
>> + *
>> + * Copyright (C) 20

[PATCH] ASoC: atmel-classd: fix odd_ptr_err.cocci warnings

[kbuild test robot]

sound/soc/atmel/atmel-classd.c:578:5-11: inconsistent IS_ERR and PTR_ERR, 
PTR_ERR on line 579

 PTR_ERR should access the value just tested by IS_ERR

Semantic patch information:
 There can be false positives in the patch case, where it is the call
 IS_ERR that is wrong.

Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci

CC: Songjun Wu 
Signed-off-by: Fengguang Wu 
---

 atmel-classd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/atmel/atmel-classd.c
+++ b/sound/soc/atmel/atmel-classd.c
@@ -576,7 +576,7 @@ static int atmel_classd_probe(struct pla
 
dd->gclk = devm_clk_get(dev, "gclk");
if (IS_ERR(dd->aclk)) {
-   ret = PTR_ERR(dd->gclk);
+   ret = PTR_ERR(dd->aclk);
dev_err(dev, "failed to get GCK clock: %d\n", ret);
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ASoC: atmel-classd: fix platform_no_drv_owner.cocci warnings

[kbuild test robot]

sound/soc/atmel/atmel-classd.c:669:3-8: No need to set .owner here. The core 
will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Songjun Wu 
Signed-off-by: Fengguang Wu 
---

 atmel-classd.c |1 -
 1 file changed, 1 deletion(-)

--- a/sound/soc/atmel/atmel-classd.c
+++ b/sound/soc/atmel/atmel-classd.c
@@ -666,7 +666,6 @@ static int atmel_classd_remove(struct pl
 static struct platform_driver atmel_classd_driver = {
.driver = {
.name   = "atmel-classd",
-   .owner  = THIS_MODULE,
.of_match_table = of_match_ptr(atmel_classd_of_match),
.pm = &snd_soc_pm_ops,
},
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] test_printf: test printf family at runtime

[Andy Shevchenko]

On Fri, 2015-09-25 at 19:41 +0200, Rasmus Villemoes wrote:
> This adds a simple module for testing the kernel's printf
> facilities. Previously, some %p extensions have caused a wrong return
> value in case the entire output didn't fit and/or been unusable in
> kasprintf(). This should help catch such issues. Also, it should help
> ensure that changes to the formatting algorithms don't break 
> anything.
> 
> I'm not sure if we have a struct dentry or struct file lying around 
> at
> boot time or if we can fake one, but most %p extensions should be
> testable, as should the ordinary number and string formatting.
> 
> The nature of vararg functions means we can't use a more conventional
> table-driven approach.
> 
> For now, this is mostly a skeleton; contributions are very
> welcome. Some tests are/will be slightly annoying to write, since the
> expected output depends on stuff like CONFIG_*, sizeof(long), runtime
> values etc.

Few comments below.

> 
> Signed-off-by: Rasmus Villemoes 
> ---
>  lib/Kconfig.debug |   3 +
>  lib/Makefile  |   1 +
>  lib/test_printf.c | 364 
> ++
>  3 files changed, 368 insertions(+)
>  create mode 100644 lib/test_printf.c
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index ab76b99adc85..c23fc42dc659 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1685,6 +1685,9 @@ config TEST_STRING_HELPERS
>  config TEST_KSTRTOX
>   tristate "Test kstrto*() family of functions at runtime"
>  
> +config TEST_PRINTF
> + tristate "Test printf() family of functions at runtime"
> +
>  config TEST_RHASHTABLE
>   tristate "Perform selftest on resizable hash table"
>   default n
> diff --git a/lib/Makefile b/lib/Makefile
> index 13a7c6ae3fec..775de427ea92 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_TEST_RHASHTABLE) += test_rhashtable.o
>  obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o
>  obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o
>  obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o
> +obj-$(CONFIG_TEST_PRINTF) += test_printf.o
>  
>  ifeq ($(CONFIG_DEBUG_KOBJECT),y)
>  CFLAGS_kobject.o += -DDEBUG
> diff --git a/lib/test_printf.c b/lib/test_printf.c
> new file mode 100644
> index ..d9a2741c2909
> --- /dev/null
> +++ b/lib/test_printf.c
> @@ -0,0 +1,364 @@
> +/*
> + * Test cases for printf facility.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define BUF_SIZE 256
> +#define FILL_CHAR '$'
> +
> +#define PTR1 ((void*)0x01234567)
> +#define PTR2 ((void*)(long)(int)0xfedcba98)
> +
> +#if BITS_PER_LONG == 64
> +#define PTR1_ZEROES "0"
> +#define PTR1_SPACES " "
> +#define PTR1_STR "1234567"
> +#define PTR2_STR "fedcba98"
> +#define PTR_WIDTH 16
> +#else
> +#define PTR1_ZEROES "0"
> +#define PTR1_SPACES " "
> +#define PTR1_STR "1234567"
> +#define PTR2_STR "fedcba98"
> +#define PTR_WIDTH 8
> +#endif
> +#define PTR_WIDTH_STR stringify(PTR_WIDTH)
> +
> +static unsigned total_tests __initdata;
> +static unsigned failed_tests __initdata;
> +static char *test_buffer __initdata;
> +
> +static int __printf(4, 0) __init
> +do_test(int bufsize, const char *expect, int elen,
> + const char *fmt, va_list ap)
> +{
> + va_list aq;
> + int ret, written;
> +
> + total_tests++;
> +
> + memset(test_buffer, FILL_CHAR, BUF_SIZE);
> + va_copy(aq, ap);
> + ret = vsnprintf(test_buffer, bufsize, fmt, aq);
> + va_end(aq);
> +
> + if (ret != elen) {
> + pr_warn("bad return value, expected %d, got %d, 
> format was '%s'\n",
> + elen, ret, fmt);
> + return 1;
> + }
> +
> + if (!bufsize) {
> + if (memchr_inv(test_buffer, FILL_CHAR, BUF_SIZE)) {
> + pr_warn("vsnprintf(buf, 0, \"%s\", ...) 
> wrote to buffer\n",
> + fmt);
> + return 1;
> + }
> + return 0;
> + }
> +
> + written = min(bufsize-1, elen);
> + if (test_buffer[written]) {
> + pr_warn("vsnprintf(buf, %d, \"%s\", ...) did not nul
> -terminate buffer\n",
> + bufsize, fmt);
> + return 1;
> + }
> +
> + if (memcmp(test_buffer, expect, written)) {
> + pr_warn("vsnprintf(buf, %d, \"%s\", ...) wrote '%s', 
> expected '%.*s'\n",
> + bufsize, fmt, test_buffer, written, expect);
> + return 1;
> + }
> + return 0;
> +}
> +
> +
> +static void __printf(3, 4) __init
> +__test(const char *expect, int elen, const char *fmt, ...)
> +{
> + va_list ap;
> + int rand;
> + char *p;
> +
> + BUG_ON(elen >= BUF_SIZE);
> +
> + va_start(ap, fmt);
> +
> + /*
> +  * Every fmt+args is subjected to four tests: Three where we
> +  * tell vsnp

[PATCH linux-next v11 1/3] mfd: atmel-flexcom: create include file with macros used by DT bindings

[Cyrille Pitchen]

This patch defines some macros to be used as value for the
"atmel,flexcom-mode" DT property. This value is then written into
the Operating Mode (OPMODE) bit field of the Flexcom Mode Register.

Signed-off-by: Cyrille Pitchen 
Acked-by: Nicolas Ferre 
---
 include/dt-bindings/mfd/atmel-flexcom.h | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 include/dt-bindings/mfd/atmel-flexcom.h

diff --git a/include/dt-bindings/mfd/atmel-flexcom.h 
b/include/dt-bindings/mfd/atmel-flexcom.h
new file mode 100644
index ..a266fe4ee945
--- /dev/null
+++ b/include/dt-bindings/mfd/atmel-flexcom.h
@@ -0,0 +1,26 @@
+/*
+ * This header provides macros for Atmel Flexcom DT bindings.
+ *
+ * Copyright (C) 2015 Cyrille Pitchen 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#ifndef __DT_BINDINGS_ATMEL_FLEXCOM_H__
+#define __DT_BINDINGS_ATMEL_FLEXCOM_H__
+
+#define ATMEL_FLEXCOM_MODE_USART   1
+#define ATMEL_FLEXCOM_MODE_SPI 2
+#define ATMEL_FLEXCOM_MODE_TWI 3
+
+#endif /* __DT_BINDINGS_ATMEL_FLEXCOM_H__ */
-- 
1.8.2.2

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

[PATCH linux-next v11 0/3] mfd: flexcom: add a driver for Flexcom

[Cyrille Pitchen]

This series of patches a support to the Atmel Flexcom, a wrapper which
integrates an USART, a SPI controller and a TWI controller. Only one
peripheral can be used at a time. The active function is selected though
the Flexcom Mode Register.


ChangeLog

v11:
- replace "GPLv2 only" by a proper license statement  in
  "include/dt-bindings/mfd/atmel-flexcom.h" as suggested by Lee Jones.
- remove usage of Linux specific macros for the values of the
  "atmel,flexcom-mode" property in the DT bindings documentation.
- fix typo and reword some parts of the DT bindings documentation.

v10:
- add Acked-by from Nicolas Ferre

v9:
- go back to v5 (use the new "atmel,flexcom-mode" DT property).
- fix the name of the spi node in the DT example: from spi@f8034400 to
  spi@400
- align the fields of the struct platform_driver atmel_flexcom_driver as
  suggested by Lee Jones.

v8:
- fix the name of the spi node in the DT example: from spi@f8034400 to
  spi@2,0
- use the return code of op_property_read_u32_index() instead of -EINVAL
  to report error.
- add Acked-by from Nicolas Ferre

v7:
- read the operating mode from the very first u32 of the reg property from
  the first available child node (should be unique).
- update the DT bindings documentation accordingly.

v6:
- select the operating mode according to the "compatible" DT property of
  the first available child node (should be unique).
- remove the "atmel,flexcom-mode" DT property so the need of a header file
  defining macros for the possible values of this deprecated property.

v5:
- create a header file containing macros used by DT bindings
- use numeric constants instead of strings to select the Flexcom mode
- change the license to "GPL v2"
- update the DT binding documentation to make it more readable and add
  references to USART, SPI and I2C DT binding documentations. remove the
  useless label in the Example section.
- change the register prefix from FX_ to FLEX_ to match the Flexcom
  programmer datasheet.
- rename some variables to make them more understandable.

v4:
- check clk_prepare_enable() return code in atmel_flexcom_probe()
- add a commit message to the DT binding patch

v3:
- remove MODULE_ALIAS()
- add Acked-by from Boris Brezillon and Alexandre Belloni

v2:
- enhance the documentation of DT bindings and change the way the "ranges"
  property is used.
- replace __raw_readl() and __raw_writel() by readl() and writel().
- change the module license to "GPL" for v2 or later
- print the selected flexcom mode after the hardware version

Cyrille Pitchen (3):
  mfd: atmel-flexcom: create include file with macros used by DT
bindings
  mfd: devicetree: add bindings for Atmel Flexcom
  mfd: atmel-flexcom: add a driver for Atmel Flexible Serial
Communication Unit

 .../devicetree/bindings/mfd/atmel-flexcom.txt  |  63 +
 drivers/mfd/Kconfig|  11 +++
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/atmel-flexcom.c| 104 +
 include/dt-bindings/mfd/atmel-flexcom.h|  26 ++
 5 files changed, 205 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
 create mode 100644 drivers/mfd/atmel-flexcom.c
 create mode 100644 include/dt-bindings/mfd/atmel-flexcom.h

-- 
1.8.2.2

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

[PATCH linux-next v11 2/3] mfd: devicetree: add bindings for Atmel Flexcom

[Cyrille Pitchen]

This patch documents the DT bindings for the Atmel Flexcom which will be
introduced by sama5d2x SoCs. These bindings will be used by the actual
Flexcom driver to be sent in another patch.

Signed-off-by: Cyrille Pitchen 
Acked-by: Boris Brezillon 
Acked-by: Alexandre Belloni 
Acked-by: Nicolas Ferre 
---
 .../devicetree/bindings/mfd/atmel-flexcom.txt  | 63 ++
 1 file changed, 63 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt

diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt 
b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
new file mode 100644
index ..692300117c64
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
@@ -0,0 +1,63 @@
+* Device tree bindings for Atmel Flexcom (Flexible Serial Communication Unit)
+
+The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
+controller and an USART. Only one function can be used at a time and is chosen
+at boot time according to the device tree.
+
+Required properties:
+- compatible:  Should be "atmel,sama5d2-flexcom"
+- reg: Should be the offset/length value for Flexcom dedicated
+   I/O registers (without USART, TWI or SPI registers).
+- clocks:  Should be the Flexcom peripheral clock from PMC.
+- #address-cells:  Should be <1>
+- #size-cells: Should be <1>
+- ranges:  Should be one range for the full I/O register region
+   (including USART, TWI and SPI registers).
+- atmel,flexcom-mode:  Should be one of the following values:
+   - <1> for USART
+   - <2> for SPI
+   - <3> for I2C
+
+Required child:
+A single available child device of type matching the "atmel,flexcom-mode"
+property.
+
+The phandle provided by the clocks property of the child is the same as one for
+the Flexcom parent.
+
+For other properties, please refer to the documentations of the respective
+device:
+- ../serial/atmel-usart.txt
+- ../spi/spi_atmel.txt
+- ../i2c/i2c-at91.txt
+
+Example:
+
+flexcom@f8034000 {
+   compatible = "atmel,sama5d2-flexcom";
+   reg = <0xf8034000 0x200>;
+   clocks = <&flx0_clk>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0xf8034000 0x800>;
+   atmel,flexcom-mode = <2>;
+
+   spi@400 {
+   compatible = "atmel,at91rm9200-spi";
+   reg = <0x400 0x200>;
+   interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_flx0_default>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <&flx0_clk>;
+   clock-names = "spi_clk";
+   atmel,fifo-size = <32>;
+
+   mtd_dataflash@0 {
+   compatible = "atmel,at25f512b";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   };
+   };
+};
-- 
1.8.2.2

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

[PATCH linux-next v11 3/3] mfd: atmel-flexcom: add a driver for Atmel Flexible Serial Communication Unit

[Cyrille Pitchen]

This driver supports the new Atmel Flexcom. The Flexcom is a wrapper which
integrates one SPI controller, one I2C controller and one USART. Only one
function can be enabled at a time. This driver selects the function once
for all, when the Flexcom is probed, according to the value of the new
"atmel,flexcom-mode" device tree property.

This driver has chosen to present the Flexcom to the system as a MFD so
the implementation is seamless for the existing Atmel SPI, I2C and USART
drivers.

Also the Flexcom embeds FIFOs: the latest patches of the SPI, I2C and
USART drivers take advantage of this new feature.

Signed-off-by: Cyrille Pitchen 
Acked-by: Boris Brezillon 
Acked-by: Alexandre Belloni 
Acked-by: Nicolas Ferre 
---
 drivers/mfd/Kconfig |  11 +
 drivers/mfd/Makefile|   1 +
 drivers/mfd/atmel-flexcom.c | 104 
 3 files changed, 116 insertions(+)
 create mode 100644 drivers/mfd/atmel-flexcom.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 99d63675f073..87e84e7c71da 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -60,6 +60,17 @@ config MFD_AAT2870_CORE
  additional drivers must be enabled in order to use the
  functionality of the device.
 
+config MFD_ATMEL_FLEXCOM
+   tristate "Atmel Flexcom (Flexible Serial Communication Unit)"
+   select MFD_CORE
+   depends on OF
+   help
+ Select this to get support for Atmel Flexcom. This is a wrapper
+ which embeds a SPI controller, a I2C controller and a USART. Only
+ one function can be used at a time. The choice is done at boot time
+ by the probe function of this MFD driver according to a device tree
+ property.
+
 config MFD_ATMEL_HLCDC
tristate "Atmel HLCDC (High-end LCD Controller)"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d6c21e3c409f..a8b76b81b467 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -164,6 +164,7 @@ obj-$(CONFIG_MFD_SPMI_PMIC) += qcom-spmi-pmic.o
 obj-$(CONFIG_TPS65911_COMPARATOR)  += tps65911-comparator.o
 obj-$(CONFIG_MFD_TPS65090) += tps65090.o
 obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
+obj-$(CONFIG_MFD_ATMEL_FLEXCOM)+= atmel-flexcom.o
 obj-$(CONFIG_MFD_ATMEL_HLCDC)  += atmel-hlcdc.o
 obj-$(CONFIG_MFD_INTEL_LPSS)   += intel-lpss.o
 obj-$(CONFIG_MFD_INTEL_LPSS_PCI)   += intel-lpss-pci.o
diff --git a/drivers/mfd/atmel-flexcom.c b/drivers/mfd/atmel-flexcom.c
new file mode 100644
index ..e8e67be6b493
--- /dev/null
+++ b/drivers/mfd/atmel-flexcom.c
@@ -0,0 +1,104 @@
+/*
+ * Driver for Atmel Flexcom
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Author: Cyrille Pitchen 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* I/O register offsets */
+#define FLEX_MR0x0 /* Mode Register */
+#define FLEX_VERSION   0xfc/* Version Register */
+
+/* Mode Register bit fields */
+#define FLEX_MR_OPMODE_OFFSET  (0)  /* Operating Mode */
+#define FLEX_MR_OPMODE_MASK(0x3 << FLEX_MR_OPMODE_OFFSET)
+#define FLEX_MR_OPMODE(opmode) (((opmode) << FLEX_MR_OPMODE_OFFSET) &  \
+FLEX_MR_OPMODE_MASK)
+
+
+static int atmel_flexcom_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct clk *clk;
+   struct resource *res;
+   void __iomem *base;
+   u32 opmode;
+   int err;
+
+   err = of_property_read_u32(np, "atmel,flexcom-mode", &opmode);
+   if (err)
+   return err;
+
+   if (opmode < ATMEL_FLEXCOM_MODE_USART ||
+   opmode > ATMEL_FLEXCOM_MODE_TWI)
+   return -EINVAL;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   clk = devm_clk_get(&pdev->dev, NULL);
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+
+   err = clk_prepare_enable(clk);
+   if (err)
+   return err;
+
+   /*
+* Set the Operating Mode in the Mode Register: only the selected device
+* is clocked. Hence, registers of the other serial devices remain
+* inaccessible and are read as zero. Also the external I/O 

RE: [PATCH 1/1] dmaengine: dw: resolve recursion lock when audio playback

[yitian]

> From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com]
> Sent: Monday, September 28, 2015 4:46 PM
> To: yitian ; 'Andy Shevchenko'
> ; 'Viresh Kumar' 
> Cc: 'Viresh Kumar' ; 'Vinod Koul'
> ; 'Dan Williams' ;
> 'dmaengine' ; 'Linux Kernel Mailing List'
> 
> Subject: Re: [PATCH 1/1] dmaengine: dw: resolve recursion lock when
> audio playback
> 
> On Mon, 2015-09-28 at 15:23 +0800, yitian wrote:
> > >
> > > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> > > Sent: Monday, September 28, 2015 3:06 PM
> > > To: Viresh Kumar 
> > > Cc: yitian ; Viresh Kumar
> > > ; Andy Shevchenko
> > > ; Vinod Koul <
> > > vinod.k...@intel.com>;
> > > Dan Williams ; dmaengine
> > > ; Linux Kernel Mailing List
> > > 
> > > Subject: Re: [PATCH 1/1] dmaengine: dw: resolve recursion
> > > > I am not sure if this is a sane way of doing that, and we were
> > > > scanning
> > > > the descriptors for some valid reason..
> > >
> > > Actually one of the patches in a pile sitting in my private repo is
> > > also including similar change. In my case the reason is to support
> > > cyclic transfers natively.
> > >
> >
> > Yes, i am using DW DMAC to support cyclic transfer.
> > Currently it is very easy to get recursion lock crash, but
> > after this patch everything is fine on my device.
> 
> What is an actual hardware you are running kernel on?
> 
Hi Andy:

I am using a FPGA, with Cortex-A5 core, Designware I2S IP, Designware
DMAC IP. What I was done is to run tinyplay and tinycap to test the
playback and capture function on the FPGA. With my change, both of
them are okay now. I didn't push the patch which added cyclic DMA
support for dw DMAC because I didn't make it decent enough yet.


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

Re: [PATCH RESEND] ARM: dts: Move display-timings node from fimd to dp

[Krzysztof Kozlowski]

W dniu 28.09.2015 o 17:56, Tomeu Vizoso pisze:
> Hi Kukjin and Krzysztof,
> 
> could you take a look at this?

Of course, but please be patient. It waits on my todo list. I have just
returned from holidays.

Best regards,
Krzysztof

> 
> Thanks,
> 
> Tomeu
> 
> On 17 September 2015 at 14:48, Tomeu Vizoso  
> wrote:
>> From: Sean Paul 
>>
>> This patch moves the display-timings node from fimd to dp to reflect the
>> device tree bindings change.
>>
>> Signed-off-by: Sean Paul 
>> [tomeu.viz...@collabora.com: Rebased]
>> Signed-off-by: Tomeu Vizoso 
>>
>> ---
>>
>> Hi,
>>
>> looks like a long time ago the bindings were changed and the DTs for
>> these boards weren't updated.
>>
>> I have retaken Sean's forgotten patch and rebased it, but I have only
>> tested on an Arndale that exynos-drm doesn't complain about missing
>> timings.
>>
>> Regards,
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fs: change bh_lru_install() implementation

[yalin wang]

This patch use swap method to implement bh_lru_install,
it works like this:
swap new and [0] first, update old=[0],
then compare old and [1],
if old != new_bh && old != NULL, swap old and [1],
then start the next compare,
otherwise stop the compare.

Signed-off-by: yalin wang 
---
 fs/buffer.c | 33 -
 1 file changed, 12 insertions(+), 21 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 82283ab..d6769f1 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1287,40 +1287,31 @@ static inline void check_irqs_on(void)
  */
 static void bh_lru_install(struct buffer_head *bh)
 {
-   struct buffer_head *evictee = NULL;
+   struct buffer_head *old = NULL;
 
check_irqs_on();
bh_lru_lock();
if (__this_cpu_read(bh_lrus.bhs[0]) != bh) {
-   struct buffer_head *bhs[BH_LRU_SIZE];
-   int in;
+   struct buffer_head *temp;
int out = 0;
 
+   old = __this_cpu_read(bh_lrus.bhs[0]);
get_bh(bh);
-   bhs[out++] = bh;
-   for (in = 0; in < BH_LRU_SIZE; in++) {
-   struct buffer_head *bh2 =
-   __this_cpu_read(bh_lrus.bhs[in]);
-
-   if (bh2 == bh) {
-   __brelse(bh2);
+   __this_cpu_write(bh_lrus.bhs[out++], bh);
+   for (; out < BH_LRU_SIZE; out++) {
+   if (old == bh || old == NULL) {
+   break;
} else {
-   if (out >= BH_LRU_SIZE) {
-   BUG_ON(evictee != NULL);
-   evictee = bh2;
-   } else {
-   bhs[out++] = bh2;
-   }
+   temp = __this_cpu_read(bh_lrus.bhs[out]);
+   __this_cpu_write(bh_lrus.bhs[out], old);
+   old = temp;
}
}
-   while (out < BH_LRU_SIZE)
-   bhs[out++] = NULL;
-   memcpy(this_cpu_ptr(&bh_lrus.bhs), bhs, sizeof(bhs));
}
bh_lru_unlock();
 
-   if (evictee)
-   __brelse(evictee);
+   if (old)
+   __brelse(old);
 }
 
 /*
-- 
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: [linux-sunxi][alsa-devel][PATCH 3/3] ASOC: sunxi: Add support for the spdif block

[Code Kipper]

On 28 September 2015 at 10:25, Maxime Ripard
 wrote:
> On Thu, Sep 24, 2015 at 04:30:05PM +0200, codekip...@gmail.com wrote:
>> From: Marcus Cooper 
>>
>> The sun4i, sun6i and sun7i SoC families have an SPDIF
>> block which is capable of playback and capture.
>>
>> This patch enables the playback of this block for
>> the sun4i and sun7i families.
>>
>> Signed-off-by: Marcus Cooper 
>> ---
>>  sound/soc/sunxi/Kconfig   |  10 +
>>  sound/soc/sunxi/Makefile  |   4 +
>>  sound/soc/sunxi/sunxi-machine-spdif.c | 110 +
>>  sound/soc/sunxi/sunxi-spdif.c | 801 
>> ++
>>  4 files changed, 925 insertions(+)
>>  create mode 100644 sound/soc/sunxi/sunxi-machine-spdif.c
>>  create mode 100644 sound/soc/sunxi/sunxi-spdif.c
>>
>> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
>> index 84c72ec..053db02 100644
>> --- a/sound/soc/sunxi/Kconfig
>> +++ b/sound/soc/sunxi/Kconfig
>> @@ -8,4 +8,14 @@ config SND_SUN4I_CODEC
>> Select Y or M to add support for the Codec embedded in the Allwinner
>> A10 and affiliated SoCs.
>>
>> +config SND_SOC_SUNXI_DAI_SPDIF
>> +tristate
>> +select SND_SOC_GENERIC_DMAENGINE_PCM
>> +select REGMAP_MMIO
>> +
>> +config SND_SOC_SUNXI_MACHINE_SPDIF
>> +tristate "APB on-chip sun4i/sun5i/sun7i SPDIF"
>> +select SND_SOC_SUNXI_DAI_SPDIF
>> +help
>> +  Say Y if you want to add support for SoC S/PDIF audio as simple 
>> audio card.
>>  endmenu
>> diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
>> index ea8a08c..7849a75 100644
>> --- a/sound/soc/sunxi/Makefile
>> +++ b/sound/soc/sunxi/Makefile
>> @@ -1,2 +1,6 @@
>>  obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
>>
>> +snd-soc-sunxi-dai-spdif-objs := sunxi-spdif.o
>> +obj-$(CONFIG_SND_SOC_SUNXI_DAI_SPDIF) += snd-soc-sunxi-dai-spdif.o
>> +snd-soc-sunxi-machine-spdif-objs := sunxi-machine-spdif.o
>> +obj-$(CONFIG_SND_SOC_SUNXI_MACHINE_SPDIF) += snd-soc-sunxi-machine-spdif.o
>> diff --git a/sound/soc/sunxi/sunxi-machine-spdif.c 
>> b/sound/soc/sunxi/sunxi-machine-spdif.c
>> new file mode 100644
>> index 000..f8f6bd8
>> --- /dev/null
>> +++ b/sound/soc/sunxi/sunxi-machine-spdif.c
>> @@ -0,0 +1,110 @@
>> +/*
>> + * Copyright (C) 2015 Andrea Venturi 
>> + * From code by (C) 2013 Freescale Semiconductor, Inc.
>> + * (sound/soc/fsl/imx-spdif.c)
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct sunxi_machine_spdif_data {
>> + struct snd_soc_dai_link dai;
>> + struct snd_soc_card card;
>> +};
>> +
>> +static int sunxi_machine_spdif_audio_probe(struct platform_device *pdev)
>> +{
>> + struct device_node *spdif_np, *np = pdev->dev.of_node;
>> + struct sunxi_machine_spdif_data *data;
>> + int ret = 0;
>> +
>> + dev_dbg(&pdev->dev, "%s: Looking for spdif-controller\n", __func__);
>> + spdif_np = of_parse_phandle(np, "spdif-controller", 0);
>> + if (!spdif_np) {
>> + dev_err(&pdev->dev, "failed to find spdif-controller\n");
>> + ret = -EINVAL;
>> + goto end;
>> + }
>> +
>> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
>> + if (!data) {
>> + ret = -ENOMEM;
>> + goto end;
>> + }
>> +
>> + data->dai.name = "S/PDIF PCM";
>> + data->dai.stream_name = "S/PDIF PCM";
>> + data->dai.codec_dai_name = "snd-soc-dummy-dai";
>> + data->dai.codec_name = "snd-soc-dummy";
>> + data->dai.cpu_of_node = spdif_np;
>> + data->dai.platform_of_node = spdif_np;
>> + data->dai.playback_only = true;
>> + data->dai.capture_only = true;
>> +
>> + if (of_property_read_bool(np, "spdif-out"))
>> + data->dai.capture_only = false;
>> +
>> + if (of_property_read_bool(np, "spdif-in"))
>> + data->dai.playback_only = false;
>> +
>> + if (data->dai.playback_only && data->dai.capture_only) {
>> + dev_err(&pdev->dev, "no enabled S/PDIF DAI link\n");
>> + goto end;
>> + }
>> +
>> + data->card.dev = &pdev->dev;
>> + data->card.dai_link = &data->dai;
>> + data->card.num_links = 1;
>> + data->card.owner = THIS_MODULE;
>> +
>> + ret = snd_soc_of_parse_card_name(&data->card, "model");
>> + if (ret)
>> + goto end;
>> +
>> + ret = devm_snd_soc_register_card(&pdev->dev, &data->card);
>> + if (ret) {
>> + dev_err(&pdev->dev,

[PATCH] block: cmdline-parser: add support for hidden disk space

[Shawn Lin]

cmdline-partition now only support continuous disk space taken from
cmdline. When we need to reserve a disk space, for instance, 100m between
mmcblk0p1 and mmcblk0p2 for special use and wouldn't let kernel space
realize this "disk hole", we add this patch to ship adding this kind of
"disk hole" into the partition table. For any such cases, simply append
"hidden" to the end of subpart which is need to be reserved.

Signed-off-by: Shawn Lin 
---

 block/cmdline-parser.c | 12 +++-
 include/linux/cmdline-parser.h |  1 +
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/block/cmdline-parser.c b/block/cmdline-parser.c
index 9dbc67e..feecbcc 100644
--- a/block/cmdline-parser.c
+++ b/block/cmdline-parser.c
@@ -68,6 +68,11 @@ static int parse_subpart(struct cmdline_subpart **subpart, 
char *partdef)
partdef += 2;
}
 
+   if (!strncmp(partdef, "hidden", 6)) {
+   new_subpart->flags |= PF_HIDDEN;
+   partdef += 6;
+   }
+
*subpart = new_subpart;
return 0;
 fail:
@@ -128,7 +133,9 @@ static int parse_parts(struct cmdline_parts **parts, const 
char *bdevdef)
if (ret)
goto fail;
 
-   newparts->nr_subparts++;
+   if (!(subpart->flags & PF_HIDDEN))
+   newparts->nr_subparts++;
+
next_subpart = &(*next_subpart)->next_subpart;
}
 
@@ -245,6 +252,9 @@ int cmdline_parts_set(struct cmdline_parts *parts, sector_t 
disk_size,
 
from += subpart->size;
 
+   if (subpart->flags & PF_HIDDEN)
+   continue;
+
if (add_part(slot, subpart, param))
break;
}
diff --git a/include/linux/cmdline-parser.h b/include/linux/cmdline-parser.h
index 2e6dce6..7c1cb3c 100644
--- a/include/linux/cmdline-parser.h
+++ b/include/linux/cmdline-parser.h
@@ -14,6 +14,7 @@
 /* partition flags */
 #define PF_RDONLY   0x01 /* Device is read only */
 #define PF_POWERUP_LOCK 0x02 /* Always locked after reset */
+#define PF_HIDDEN   0x04 /* Hidden from partition table */
 
 struct cmdline_subpart {
char name[BDEVNAME_SIZE]; /* partition name, such as 'rootfs' */
-- 
2.3.7


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

Re: Build regressions/improvements in v4.3-rc3

[Russell King - ARM Linux]

On Mon, Sep 28, 2015 at 08:57:44AM +0200, Geert Uytterhoeven wrote:
> On Sun, Sep 27, 2015 at 9:34 PM, Geert Uytterhoeven
>  wrote:
> > JFYI, when comparing v4.3-rc3[1] to v4.3-rc2[3], the summaries are:
> >   - build errors: +8/-12
> 
>   + error: No rule to make target include/config/auto.conf:  => N/A
> 
> arm-randconfig

Not every randconfig failure is a kernel problem.  Here's an example:

Physical address of main memory (PHYS_OFFSET) [] (NEW) aborted!

Console input/output is redirected. Run 'make oldconfig' to update 
configuration.

This needs someone to provide a value, which means these failures are
not in fact failures of the kernel, but a failure of the build system
to anticipate that there may be Kconfig questions that need input.

So, these ones should be ignored.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] block: cmdline-parser: add support for hidden disk space

[kbuild test robot]

Hi Shawn,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: x86_64-randconfig-x005-201539 (attached as .config)
reproduce:
  git checkout 937e3ebb4c7763e6120eda4a7e5b8c96bd710a9f
  # save the attached .config to linux build tree
  make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/capability.h:16,
from include/linux/capability.h:15,
from include/linux/sched.h:15,
from include/linux/blkdev.h:4,
from include/linux/cmdline-parser.h:10,
from block/cmdline-parser.c:8:
   block/cmdline-parser.c: In function 'parse_parts':
   block/cmdline-parser.c:136:9: error: 'subpart' undeclared (first use in this 
function)
  if (!(subpart->flags & PF_HIDDEN))
^
   include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
 if (__builtin_constant_p((cond)) ? !!(cond) :   \
   ^
>> block/cmdline-parser.c:136:3: note: in expansion of macro 'if'
  if (!(subpart->flags & PF_HIDDEN))
  ^
   block/cmdline-parser.c:136:9: note: each undeclared identifier is reported 
only once for each function it appears in
  if (!(subpart->flags & PF_HIDDEN))
^
   include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
 if (__builtin_constant_p((cond)) ? !!(cond) :   \
   ^
>> block/cmdline-parser.c:136:3: note: in expansion of macro 'if'
  if (!(subpart->flags & PF_HIDDEN))
  ^

vim +/if +136 block/cmdline-parser.c

 2   * Parse command line, get partition information
 3   *
 4   * Written by Cai Zhiyong 
 5   *
 6   */
 7  #include 
   > 8  #include 
 9  
10  static int parse_subpart(struct cmdline_subpart **subpart, char 
*partdef)
11  {
12  int ret = 0;
13  struct cmdline_subpart *new_subpart;
14  
15  *subpart = NULL;
16  
17  new_subpart = kzalloc(sizeof(struct cmdline_subpart), 
GFP_KERNEL);
18  if (!new_subpart)
19  return -ENOMEM;
20  
21  if (*partdef == '-') {
22  new_subpart->size = (sector_t)(~0ULL);
23  partdef++;
24  } else {
25  new_subpart->size = (sector_t)memparse(partdef, 
&partdef);
26  if (new_subpart->size < (sector_t)PAGE_SIZE) {
27  pr_warn("cmdline partition size is invalid.");
28  ret = -EINVAL;
29  goto fail;
30  }
31  }
32  
33  if (*partdef == '@') {
34  partdef++;
35  new_subpart->from = (sector_t)memparse(partdef, 
&partdef);
36  } else {
37  new_subpart->from = (sector_t)(~0ULL);
38  }
39  
40  if (*partdef == '(') {
41  int length;
42  char *next = strchr(++partdef, ')');
43  
44  if (!next) {
45  pr_warn("cmdline partition format is invalid.");
46  ret = -EINVAL;
47  goto fail;
48  }
49  
50  length = min_t(int, next - partdef,
51 sizeof(new_subpart->name) - 1);
52  strncpy(new_subpart->name, partdef, length);
53  new_subpart->name[length] = '\0';
54  
55  partdef = ++next;
56  } else
57  new_subpart->name[0] = '\0';
58  
59  new_subpart->flags = 0;
60  
61  if (!strncmp(partdef, "ro", 2)) {
62  new_subpart->flags |= PF_RDONLY;
63  partdef += 2;
64  }
65  
66  if (!strncmp(partdef, "lk", 2)) {
67  new_subpart->flags |= PF_POWERUP_LOCK;
68  partdef += 2;
69  }
70  
71  if (!strncmp(partdef, "hidden", 6)) {
72  new_subpart->flags |= PF_HIDDEN;
73  partdef += 6;
74  }
75  
76  *subpart = new_subpart;
77  return 0;
78  fail:
79  kfree(new_subpart);
80  return ret;
81  }
82  
83  static void free_subpart(struct cmdline_parts *parts)
84  {
85  struct cmdline_subpart *subpart;
86  
87  while (parts->subpart) {
88

Re: [PATCH] kexec: fix out of the ELF headers buffer issue in syscall kexec_file_load()

[joeyli]

Hi,

On Mon, Sep 28, 2015 at 03:16:41PM +0800, Baoquan He wrote:
> Hi Chun-Yi,
> 
> On 09/28/15 at 02:41pm, Lee, Chun-Yi wrote:
> > On big machines have CPU number that's very nearly to consume whole ELF
> > headers buffer that's page aligned, 4096, 8192... Then the page fault error
> > randomly happened.
> > 
> > This patch modified the code in fill_up_crash_elf_data() by using
> > walk_system_ram_res() instead of walk_system_ram_range() to count the max
> > number of crash memory ranges. That's because the walk_system_ram_range()
> > filters out small memory regions that reside the same page, but
> > walk_system_ram_res() does not.
> > 
> > The oringial page fault issue sometimes happened on big machines when
> > preparing ELF headers:
> > 
> > [  305.291522] BUG: unable to handle kernel paging request at 
> > c90613fc9000
> > [  305.299621] IP: [] 
> > prepare_elf64_ram_headers_callback+0x165/0x260
> > [  305.308300] PGD e32067 PUD 6dcbec54067 PMD 9dc9bdeb067 PTE 0
> > [  305.315393] Oops: 0002 [#1] SMP
> > [...snip]
> > [  305.420953] task: 8e1c01ced600 ti: 8e1c03ec2000 task.ti: 
> > 8e1c03ec2000
> > [  305.429292] RIP: 0010:[]  [] 
> > prepare_elf64_ra
> > m_headers_callback+0x165/0x260
> > [...snip]
> > 
> > After tracing prepare_elf64_headers() and 
> > prepare_elf64_ram_headers_callback(),
> > the code uses walk_system_ram_res() to fill-in crash memory regions 
> > information
> > to program header, so it counts those small memory regions that reside in a
> > page area. But, when kernel was using walk_system_ram_range() in
> > fill_up_crash_elf_data() to count the number of crash memory regions, it
> > filters out small regions.
> > 
> > I printed those small memory regions, for example:
> > 
> > kexec: Get nr_ram ranges. vaddr=0x880077592258 paddr=0x77592258, 
> > sz=0xdc0
> > 
> > Base on the logic of walk_system_ram_range(), this memory region will be
> > filter out:
> > 
> > pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
> > end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
> > end_pfn - pfn = 0x77593 - 0x77593 = 0  <=== if (end_pfn > pfn)  [FAIL]
> > 
> > So, the max_nr_ranges that counted by kernel doesn't include small memory
> > regions. That causes the page fault issue happened in later code path for
> > preparing EFL headers,
> > 
> > This issue was hided on small machine that doesn't have too many CPU because
> > the free space of ELF headers buffer can cover the number of small memory
> > regions. But, when the machine has more CPUs or the number of memory regions
> > very nearly to consume whole page aligned buffer, e.g. 4096, 8192... Then
> > issue will happen randomly.
> 
> It's a good finding and fix sounds reasonable. I didn't get why too many
> CPUs will cause this bug. From your big machine can you check which
> regions they are and what they are used for? I guess you mean the
> crash_notes region, but not very sure.
> 

In prepare_elf64_headers, the logic to allocate ELF header buffer is:

/* extra phdr for vmcoreinfo elf note */
nr_phdr = nr_cpus + 1;
nr_phdr += ced->max_nr_ranges;

/*
 * kexec-tools creates an extra PT_LOAD phdr for kernel text mapping
 * area on x86_64 (8000 - a000).
 * I think this is required by tools like gdb. So same physical
 * memory will be mapped in two elf headers. One will contain kernel
 * text virtual addresses and other will have __va(physical) addresses.
 */
nr_phdr++;
elf_sz = sizeof(Elf64_Ehdr) + nr_phdr * sizeof(Elf64_Phdr);
elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);

So whole buffer will be consumed as following:
0   
4096
++++---+---+-+
| ELF header | each cpu PT_NOTE...| vmcoreinfo PT_NOTE | kernel text region 
PT_NOTE| PT_NOTE for memory regions|   free  |
| (64 bytes) | (n * 56 bytes) | (56 bytes) | (56 bytes) 
   | (n * 56 bytes)| |
++++---+---+-+

When the free space can cover the number of small memory regions, means the
difference between walk_system_ram_range() and walk_system_ram_res(), then
this issue will not trigger.

But, when the CPU number grows to very nearly to consume whole 4096 buffer
then the issue will be happen.


Thanks a lot!
Joey Lee


> > 
> > Signed-off-by: Lee, Chun-Yi 
> > ---
> >  arch/x86/kernel/crash.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> > index e068d66..ad273b3d 100644
> > --- a/arch/x86/kernel/crash.c
> > +++ b/arch/x86/kernel/crash.c
> > @@ -185,8 +185,7 @@ void native_machine

Re: [PATCH] arch/x86: fix out-of-bounds in get_wchan()

[Borislav Petkov]

On Mon, Sep 28, 2015 at 11:00:39AM +0200, Dmitry Vyukov wrote:
> get_wchan() checks that fp is within stack bounds,
> but then dereferences fp+8. This can crash kernel
> or leak sensitive information. Also the function
> operates on a potentially running stack, but does
> not use READ_ONCE. As the result it can check that
> one value is within stack bounds, but then deref
> another value.
> 
> Fix the bounds check and use READ_ONCE for all
> volatile data.
> 
> The bug was discovered with KASAN.
> 
> Signed-off-by: Dmitry Vyukov 
> ---
> FTR, here is the KASAN report:
> 
> [  124.575597] ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 88002e28
> [  124.578633] Accessed by thread T10915:
> [  124.581050]   #2 810dd423 in __tsan_read8 ??:0
> [  124.581893]   #3 8107c093 in get_wchan 
> ./arch/x86/kernel/process_64.c:444
> [  124.582763]   #4 81342108 in do_task_stat array.c:0
> [  124.583634]   #5 81342dcc in proc_tgid_stat ??:0
> [  124.584548]   #6 8133c984 in proc_single_show base.c:0
> [  124.585461]   #7 812d18cc in seq_read ./fs/seq_file.c:222
> [  124.586313]   #8 8129e503 in vfs_read ??:0
> [  124.587137]   #9 8129f800 in SyS_read ??:0
> [  124.587827]   #10 81929bf5 in sysenter_dispatch 
> ./arch/x86/ia32/ia32entry.S:164
> [  124.588738]
> [  124.593434] Shadow bytes around the buggy address:
> [  124.594270]   88002e27fd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00
> [  124.595339]   88002e27fe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00
> [  124.596453]   88002e27fe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00
> [  124.597466]   88002e27ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00
> [  124.598501]   88002e27ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00
> [  124.599629] =>88002e28:[fa]fa fa fa fa fa fa fa fa fa 00 00 00 00 
> 00 00
> [  124.600873]   88002e280080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00
> [  124.601892]   88002e280100: 00 fa fa fa fa fa fa fa fa fa fa fa fa fa 
> fa fa
> [  124.603037]   88002e280180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 
> fa fa
> [  124.604047]   88002e280200: fa fa fa fa fa fa fa fd fd fd fd fd fd fd 
> fd fd
> [  124.605054]   88002e280280: fd fd fd fd fd fd fd fd fd fd fd fd fd fd 
> fa fa
> [  124.605993] Shadow byte legend (one shadow byte represents 8 application 
> bytes):
> [  124.606958]   Addressable:   00
> [  124.607483]   Partially addressable: 01 02 03 04 05 06 07
> [  124.608219]   Heap redzone:  fa
> [  124.608724]   Heap kmalloc redzone:  fb
> [  124.609249]   Freed heap region: fd
> [  124.609753]   Shadow gap:fe
> [  124.610292] 
> =
> ---
>  arch/x86/kernel/process_64.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index 71d7849..a1fce34 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -506,17 +506,19 @@ unsigned long get_wchan(struct task_struct *p)
>   if (!p || p == current || p->state == TASK_RUNNING)
>   return 0;
>   stack = (unsigned long)task_stack_page(p);
> - if (p->thread.sp < stack || p->thread.sp >= stack+THREAD_SIZE)
> + /* The task can be already running at this point, so tread carefully. */
> + fp = READ_ONCE(p->thread.sp);
> + if (fp < stack || fp >= stack+THREAD_SIZE)
>   return 0;
> - fp = *(u64 *)(p->thread.sp);
> + fp = READ_ONCE(*(u64 *)fp);

Why isn't this:

fp = READ_ONCE(*(u64 *)p->thread.sp);

like the original code did?

Actually, the original code looks fishy to me too - it did access live
stack three times. And shouldn't we be accessing it only once?

I.e.,

fp_st = READ_ONCE(p->thread.sp);
if (fp_st < stack || fp_st >= stack + THREAD_SIZE)
return 0;
fp = *(u64 *)fp_st;

Hmm?

Maybe I'm not completely clear on how the whole locking happens here
because we do

if (!p || p == current || p->state == TASK_RUNNING)
return 0;

earlier but apparently we can become TASK_RUNNING after the check...

Also, shouldn't this one have a CVE number assigned or so due to the
leakage potential?

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] block: cmdline-parser: add support for hidden disk space

[kbuild test robot]

Hi Shawn,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: i386-randconfig-x005-201539 (attached as .config)
reproduce:
  git checkout 937e3ebb4c7763e6120eda4a7e5b8c96bd710a9f
  # save the attached .config to linux build tree
  make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   block/cmdline-parser.c: In function 'parse_parts':
>> block/cmdline-parser.c:136:9: error: 'subpart' undeclared (first use in this 
>> function)
  if (!(subpart->flags & PF_HIDDEN))
^
   block/cmdline-parser.c:136:9: note: each undeclared identifier is reported 
only once for each function it appears in

vim +/subpart +136 block/cmdline-parser.c

   130  buf[length] = '\0';
   131  
   132  ret = parse_subpart(next_subpart, buf);
   133  if (ret)
   134  goto fail;
   135  
 > 136  if (!(subpart->flags & PF_HIDDEN))
   137  newparts->nr_subparts++;
   138  
   139  next_subpart = &(*next_subpart)->next_subpart;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] kexec: fix out of the ELF headers buffer issue in syscall kexec_file_load()

[joeyli]

On Mon, Sep 28, 2015 at 04:07:57PM +0800, Baoquan He wrote:
> On 09/28/15 at 02:41pm, Lee, Chun-Yi wrote:
> > On big machines have CPU number that's very nearly to consume whole ELF
> > headers buffer that's page aligned, 4096, 8192... Then the page fault error
> > randomly happened.
> > 
> > This patch modified the code in fill_up_crash_elf_data() by using
> > walk_system_ram_res() instead of walk_system_ram_range() to count the max
> > number of crash memory ranges. That's because the walk_system_ram_range()
> > filters out small memory regions that reside the same page, but
> > walk_system_ram_res() does not.
> > 
> > The oringial page fault issue sometimes happened on big machines when
> > preparing ELF headers:
> > 
> > [  305.291522] BUG: unable to handle kernel paging request at 
> > c90613fc9000
> > [  305.299621] IP: [] 
> > prepare_elf64_ram_headers_callback+0x165/0x260
> > [  305.308300] PGD e32067 PUD 6dcbec54067 PMD 9dc9bdeb067 PTE 0
> > [  305.315393] Oops: 0002 [#1] SMP
> > [...snip]
> > [  305.420953] task: 8e1c01ced600 ti: 8e1c03ec2000 task.ti: 
> > 8e1c03ec2000
> > [  305.429292] RIP: 0010:[]  [] 
> > prepare_elf64_ra
> > m_headers_callback+0x165/0x260
> > [...snip]
> > 
> > After tracing prepare_elf64_headers() and 
> > prepare_elf64_ram_headers_callback(),
> > the code uses walk_system_ram_res() to fill-in crash memory regions 
> > information
> > to program header, so it counts those small memory regions that reside in a
> > page area. But, when kernel was using walk_system_ram_range() in
> > fill_up_crash_elf_data() to count the number of crash memory regions, it
> > filters out small regions.
> > 
> > I printed those small memory regions, for example:
> > 
> > kexec: Get nr_ram ranges. vaddr=0x880077592258 paddr=0x77592258, 
> > sz=0xdc0
> > 
> > Base on the logic of walk_system_ram_range(), this memory region will be
> > filter out:
> > 
> > pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
> > end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
> > end_pfn - pfn = 0x77593 - 0x77593 = 0  <=== if (end_pfn > pfn)  [FAIL]
> > 
> > So, the max_nr_ranges that counted by kernel doesn't include small memory
> > regions. That causes the page fault issue happened in later code path for
> > preparing EFL headers,
> > 
> > This issue was hided on small machine that doesn't have too many CPU because
> > the free space of ELF headers buffer can cover the number of small memory
> > regions. But, when the machine has more CPUs or the number of memory regions
> > very nearly to consume whole page aligned buffer, e.g. 4096, 8192... Then
> > issue will happen randomly.
> 
> CC akpm too.
> 
> Read code again and I think it makes sense to use walk_system_ram_res.
> And in prepare_elf64_headers it also uses walk_system_ram_res. That's
> why you can find this bug. Otherwise we never find this and those small
> regions which only spread in one page will be lost in vmcore.
> 
> Besides could you please rearrange your patch log? It's not easy to get
> what this patch have done.
>

To avoid confusing, I will simplify the patch description.
Removing things about CPU number but keep the difference between
walk_system_ram_res and walk_system_ram_range.


Thanks a lot!
Joey Lee
 
> > 
> > Signed-off-by: Lee, Chun-Yi 
> > ---
> >  arch/x86/kernel/crash.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> > index e068d66..ad273b3d 100644
> > --- a/arch/x86/kernel/crash.c
> > +++ b/arch/x86/kernel/crash.c
> > @@ -185,8 +185,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
> >  }
> >  
> >  #ifdef CONFIG_KEXEC_FILE
> > -static int get_nr_ram_ranges_callback(unsigned long start_pfn,
> > -   unsigned long nr_pfn, void *arg)
> > +static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
> >  {
> > int *nr_ranges = arg;
> >  
> > @@ -214,7 +213,7 @@ static void fill_up_crash_elf_data(struct 
> > crash_elf_data *ced,
> >  
> > ced->image = image;
> >  
> > -   walk_system_ram_range(0, -1, &nr_ranges,
> > +   walk_system_ram_res(0, -1, &nr_ranges,
> > get_nr_ram_ranges_callback);
> >  
> > ced->max_nr_ranges = nr_ranges;
> > -- 
> > 2.1.4
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/9] drivers:nand:mtd: add support for UBI bakvol in mtd layer

[Boris Brezillon]

Hi Bean,

On Mon, 28 Sep 2015 07:02:37 +
Bean Huo 霍斌斌 (beanhuo)  wrote:

> Add support for UBI bakvol in mtd layer.
> 
> This solution based on MLC NAND dual plane program.
> so add hook in mtd layer.

I know you don't have any other choices to expose "two-plane page
program" to the UBI layer, but I keep thinking that exposing that to
the MTD users is not a good idea (I might be wrong ;-)).

> 
> Signed-off-by: Bean Huo 
> ---
>  include/linux/mtd/mtd.h  | 19 +++
>  include/linux/mtd/nand.h |  4 
>  include/linux/mtd/ubi.h  |  9 +
>  3 files changed, 32 insertions(+)
> 
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index f17fa75..cfcb3a68 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -204,6 +204,9 @@ struct mtd_info {
> struct mtd_oob_ops *ops);
>   int (*_write_oob) (struct mtd_info *mtd, loff_t to,
>  struct mtd_oob_ops *ops);
> + int (*_dual_plane_write_oob) (struct mtd_info *mtd, loff_t to_plane0,
> + struct mtd_oob_ops *ops_plane0, loff_t to_plane1,
> + struct mtd_oob_ops *ops_plane1);


IMHO, if we were about to allow parallel write operations this should
be exposed as a more generic API, something like:

struct mtd_write_op {
loff_t to;
struct mtd_oob_ops ops;
};

struct mtd_multi_write_ops {
struct list_head writes;
};

int (*_multi_write)(struct mtd_info *mtd,
struct mtd_multi_write_ops *ops);

Then the NAND layer could optimize that if the NAND chip supports
"two-plane page program", and if 2 pages in the write list are
fulfilling the requirements.

>   int (*_get_fact_prot_info) (struct mtd_info *mtd, size_t len,
>   size_t *retlen, struct otp_info *buf);
>   int (*_read_fact_prot_reg) (struct mtd_info *mtd, loff_t from,
> @@ -280,6 +283,22 @@ static inline int mtd_write_oob(struct mtd_info *mtd, 
> loff_t to,
>   return mtd->_write_oob(mtd, to, ops);
>  }
>  
> +static inline int mtd_write_dual_plane_oob(struct mtd_info *mtd,
> + loff_t to_plane0, struct mtd_oob_ops *ops0, loff_t to_plane1,
> + struct mtd_oob_ops *ops1)
> +{
> + ops0->retlen = ops0->oobretlen = 0;
> + ops1->retlen = ops1->oobretlen = 0;
> +
> + if (!mtd->_dual_plane_write_oob)
> + return -EOPNOTSUPP;
> + if (!(mtd->flags & MTD_WRITEABLE))
> + return -EROFS;
> +
> + return mtd->_dual_plane_write_oob(mtd, to_plane0, ops0,
> + to_plane1, ops1);
> +}
> +
>  int mtd_get_fact_prot_info(struct mtd_info *mtd, size_t len, size_t *retlen,
>  struct otp_info *buf);
>  int mtd_read_fact_prot_reg(struct mtd_info *mtd, loff_t from, size_t len,
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 272f429..4c5be01 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -77,6 +77,7 @@ extern int nand_unlock(struct mtd_info *mtd, loff_t ofs, 
> uint64_t len);
>  #define NAND_CMD_READ1   1
>  #define NAND_CMD_RNDOUT  5
>  #define NAND_CMD_PAGEPROG0x10
> +#define NAND_CMD_MULTI_PAGEPROG  0x11
>  #define NAND_CMD_READOOB 0x50
>  #define NAND_CMD_ERASE1  0x60
>  #define NAND_CMD_STATUS  0x70
> @@ -671,6 +672,9 @@ struct nand_chip {
>   int (*write_page)(struct mtd_info *mtd, struct nand_chip *chip,
>   uint32_t offset, int data_len, const uint8_t *buf,
>   int oob_required, int page, int cached, int raw);
> + int (*write_plane_page)(struct mtd_info *mtd, struct nand_chip *chip,
> + uint32_t offset, int data_len, const uint8_t *buf,
> + int oob_required, int page, int plane, int raw);
>   int (*onfi_set_features)(struct mtd_info *mtd, struct nand_chip *chip,
>   int feature_addr, uint8_t *subfeature_para);
>   int (*onfi_get_features)(struct mtd_info *mtd, struct nand_chip *chip,
> diff --git a/include/linux/mtd/ubi.h b/include/linux/mtd/ubi.h
> index 1e271cb..1da3418 100644
> --- a/include/linux/mtd/ubi.h
> +++ b/include/linux/mtd/ubi.h
> @@ -35,6 +35,15 @@
>   */
>  #define UBI_MAX_SG_COUNT 64
>  
> +enum {
> + UBI_BAKVOL_UNONE,
> + UBI_BAKVOL_INIT_INFO,
> + UBI_BAKVOL_INIT_INFO_DONE,
> + UBI_BAKVOL_INIT_VOLUME,
> + UBI_BAKVOL_INIT_VOLUME_DONE,
> + UBI_BAKVOL_RUN
> +};
> +

Are those changes related to this patch?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.o

[PATCH 0/2] Fixes for next

[Ludovic Desroches]

Hi Stephen, Linus,

Here are fixes for next. I did the at91-pio4 patches on top of next-20150916
which doesn't contain some tglx's updates about irqs.

Ludovic Desroches (2):
  pinctrl: at91-pio4: use irq_set_handler_locked
  pinctrl: at91-pio4: irq argument as been removed from irq flow
handlers

 drivers/pinctrl/pinctrl-at91-pio4.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

-- 
2.5.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 1/2] pinctrl: at91-pio4: use irq_set_handler_locked

[Ludovic Desroches]

Use irq_set_handler_locked() as it avoids a redundant lookup of the
irq descriptor.

Signed-off-by: Ludovic Desroches 
---
 drivers/pinctrl/pinctrl-at91-pio4.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c 
b/drivers/pinctrl/pinctrl-at91-pio4.c
index 6aff632..041df59 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -167,23 +167,23 @@ static int atmel_gpio_irq_set_type(struct irq_data *d, 
unsigned type)
 
switch (type) {
case IRQ_TYPE_EDGE_RISING:
-   __irq_set_handler_locked(d->irq, handle_edge_irq);
+   irq_set_handler_locked(d, handle_edge_irq);
reg |= ATMEL_PIO_CFGR_EVTSEL_RISING;
break;
case IRQ_TYPE_EDGE_FALLING:
-   __irq_set_handler_locked(d->irq, handle_edge_irq);
+   irq_set_handler_locked(d, handle_edge_irq);
reg |= ATMEL_PIO_CFGR_EVTSEL_FALLING;
break;
case IRQ_TYPE_EDGE_BOTH:
-   __irq_set_handler_locked(d->irq, handle_edge_irq);
+   irq_set_handler_locked(d, handle_edge_irq);
reg |= ATMEL_PIO_CFGR_EVTSEL_BOTH;
break;
case IRQ_TYPE_LEVEL_LOW:
-   __irq_set_handler_locked(d->irq, handle_level_irq);
+   irq_set_handler_locked(d, handle_level_irq);
reg |= ATMEL_PIO_CFGR_EVTSEL_LOW;
break;
case IRQ_TYPE_LEVEL_HIGH:
-   __irq_set_handler_locked(d->irq, handle_level_irq);
+   irq_set_handler_locked(d, handle_level_irq);
reg |= ATMEL_PIO_CFGR_EVTSEL_HIGH;
break;
case IRQ_TYPE_NONE:
-- 
2.5.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] f2fs: fix to correct freed section number during gc

[Chao Yu]

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Saturday, September 26, 2015 2:04 AM
> To: Chao Yu
> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2] f2fs: fix to correct freed section number during gc
> 
> On Fri, Sep 25, 2015 at 05:50:55PM +0800, Chao Yu wrote:
> > This patch fixes to maintain the right section count freed in garbage
> > collecting when triggering a foreground gc.
> >
> > Besides, when a foreground gc is running on current selected section, once
> > we fail to gc one segment, it's better to abandon gcing the left segments
> > in current section, because anyway we will select next victim for
> > foreground gc, so gc on the left segments in previous section will become
> > overhead and also cause the long latency for caller.
> >
> > Signed-off-by: Chao Yu 
> > ---
> > v2:
> >  o avoid calc the wrong value when freed segments across sections.
> >  fs/f2fs/gc.c | 22 +-
> >  1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> > index e932740..256ebd4 100644
> > --- a/fs/f2fs/gc.c
> > +++ b/fs/f2fs/gc.c
> > @@ -802,7 +802,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi)
> > unsigned int segno = NULL_SEGNO;
> > unsigned int i;
> > int gc_type = BG_GC;
> > -   int nfree = 0;
> > +   int sec_freed = 0, seg_freed;
> > int ret = -1;
> > struct cp_control cpc;
> > struct gc_inode_list gc_list = {
> > @@ -817,7 +817,7 @@ gc_more:
> > if (unlikely(f2fs_cp_error(sbi)))
> > goto stop;
> >
> > -   if (gc_type == BG_GC && has_not_enough_free_secs(sbi, nfree)) {
> > +   if (gc_type == BG_GC && has_not_enough_free_secs(sbi, sec_freed)) {
> > gc_type = FG_GC;
> > if (__get_victim(sbi, &segno, gc_type) || prefree_segments(sbi))
> > write_checkpoint(sbi, &cpc);
> > @@ -833,13 +833,25 @@ gc_more:
> > ra_meta_pages(sbi, GET_SUM_BLOCK(sbi, segno), sbi->segs_per_sec,
> > META_SSA);
> >
> > -   for (i = 0; i < sbi->segs_per_sec; i++)
> > -   nfree += do_garbage_collect(sbi, segno + i, &gc_list, gc_type);
> > +   for (i = 0, seg_freed = 0; i < sbi->segs_per_sec; i++) {
> > +   /*
> > +* for FG_GC case, halt gcing left segments once failed one
> > +* of segments in selected section to avoid long latency.
> > +*/
> > +   if (!do_garbage_collect(sbi, segno + i, &gc_list, gc_type) &&
> > +   gc_type == FG_GC)
> > +   break;
> > +   if (gc_type == FG_GC)
> > +   seg_freed++;
> > +   }
> 
> How about?
> 
>   if (i == sbi->segs_per_sec && gc_type == FG_GC)
>   sec_free++;

I'll update it. See the following v3 patch.

Thanks,

> 
> > +
> > +   if (seg_freed == sbi->segs_per_sec)
> > +   sec_freed++;
> >
> > if (gc_type == FG_GC)
> > sbi->cur_victim_sec = NULL_SEGNO;
> >
> > -   if (has_not_enough_free_secs(sbi, nfree))
> > +   if (has_not_enough_free_secs(sbi, sec_freed))
> > goto gc_more;
> >
> > if (gc_type == FG_GC)
> > --
> > 2.5.2

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

[PATCH 2/2] pinctrl: at91-pio4: irq argument as been removed from irq flow handlers

[Ludovic Desroches]

Irq argument as been removed from irq flow handlers so use the irq
descriptor to retrieve data we need.

Signed-off-by: Ludovic Desroches 
---
 drivers/pinctrl/pinctrl-at91-pio4.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c 
b/drivers/pinctrl/pinctrl-at91-pio4.c
index 041df59..4aa6be0 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -222,9 +222,10 @@ static struct irq_chip atmel_gpio_irq_chip = {
.irq_set_type   = atmel_gpio_irq_set_type,
 };
 
-static void atmel_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
+static void atmel_gpio_irq_handler(struct irq_desc *desc)
 {
-   struct atmel_pioctrl *atmel_pioctrl = irq_get_handler_data(irq);
+   unsigned int irq = irq_desc_get_irq(desc);
+   struct atmel_pioctrl *atmel_pioctrl = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned long isr;
int n, bank = -1;
-- 
2.5.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 v2 00/02] irqchip: renesas-irqc: r8a7795 and generic chip update V2

[Magnus Damm]

irqchip: renesas-irqc: r8a7795 and generic chip update V2

[PATCH v2 01/02] irqchip: renesas-irqc: Add r8a7795 INTC-EX DT documentation
[PATCH v2 02/02] irqchip: renesas-irqc: Move over to nested generic chip

This series updates the IRQC driver with generic chip support including
nested locking. Also the DT documentation is extended with r8a7795
support.

Signed-off-by: Magnus Damm 
---

 Written against v4.3-rc3, thanks to Geert and Tglx for their help!

 Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt |1 
 drivers/irqchip/Kconfig |1 
 drivers/irqchip/irq-renesas-irqc.c  |   86 
+++---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/02] irqchip: renesas-irqc: Add r8a7795 INTC-EX DT documentation

[Magnus Damm]

From: Magnus Damm 

For some reason the name of the external interrupt controller
has changed name with r8a7795, so use "intc-ex" instead of "irqc"
as r8a7795 compat string to follow the friendly documentation.

Signed-off-by: Magnus Damm 
Acked-by: Geert Uytterhoeven 
---

 Changes since V1:
 - Use "intc-ex" instead of "irqc" to follow the data sheet.
 - Added ack from Geert.

 Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt |1 
+
 1 file changed, 1 insertion(+)

--- 0001/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt
+++ 
work/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt
2015-09-28 18:12:43.250513000 +0900
@@ -10,6 +10,7 @@ Required properties:
 - "renesas,irqc-r8a7792" (R-Car V2H)
 - "renesas,irqc-r8a7793" (R-Car M2-N)
 - "renesas,irqc-r8a7794" (R-Car E2)
+- "renesas,intc-ex-r8a7795" (R-Car H3)
 - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in
   interrupts.txt in this directory
 - clocks: Must contain a reference to the functional clock.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/02] irqchip: renesas-irqc: Move over to nested generic chip

[Magnus Damm]

From: Magnus Damm 

Convert the IRQC driver to rely on GENERIC_IRQ_CHIP and
set IRQ_GC_INIT_NESTED_LOCK to enable nested locking.

Signed-off-by: Magnus Damm 
---

 Changes since V1:
 - rebased on top of v4.3-rc3
 - folded in the IRQ_GC_INIT_NESTED_LOCK bits

 drivers/irqchip/Kconfig|1 
 drivers/irqchip/irq-renesas-irqc.c |   86 
 2 files changed, 31 insertions(+), 56 deletions(-)

--- 0001/drivers/irqchip/Kconfig
+++ work/drivers/irqchip/Kconfig2015-09-28 17:41:51.240513000 +0900
@@ -123,6 +123,7 @@ config RENESAS_INTC_IRQPIN
 
 config RENESAS_IRQC
bool
+   select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
 config ST_IRQCHIP
--- 0001/drivers/irqchip/irq-renesas-irqc.c
+++ work/drivers/irqchip/irq-renesas-irqc.c 2015-09-28 17:48:55.080513000 
+0900
@@ -62,33 +62,20 @@ struct irqc_priv {
struct irqc_irq irq[IRQC_IRQ_MAX];
unsigned int number_of_irqs;
struct platform_device *pdev;
-   struct irq_chip irq_chip;
+   struct irq_chip_generic *gc;
struct irq_domain *irq_domain;
struct clk *clk;
 };
 
-static void irqc_dbg(struct irqc_irq *i, char *str)
+static struct irqc_priv *irq_data_to_priv(struct irq_data *data)
 {
-   dev_dbg(&i->p->pdev->dev, "%s (%d:%d)\n",
-   str, i->requested_irq, i->hw_irq);
+   return data->domain->host_data;
 }
 
-static void irqc_irq_enable(struct irq_data *d)
-{
-   struct irqc_priv *p = irq_data_get_irq_chip_data(d);
-   int hw_irq = irqd_to_hwirq(d);
-
-   irqc_dbg(&p->irq[hw_irq], "enable");
-   iowrite32(BIT(hw_irq), p->cpu_int_base + IRQC_EN_SET);
-}
-
-static void irqc_irq_disable(struct irq_data *d)
+static void irqc_dbg(struct irqc_irq *i, char *str)
 {
-   struct irqc_priv *p = irq_data_get_irq_chip_data(d);
-   int hw_irq = irqd_to_hwirq(d);
-
-   irqc_dbg(&p->irq[hw_irq], "disable");
-   iowrite32(BIT(hw_irq), p->cpu_int_base + IRQC_EN_STS);
+   dev_dbg(&i->p->pdev->dev, "%s (%d:%d)\n",
+   str, i->requested_irq, i->hw_irq);
 }
 
 static unsigned char irqc_sense[IRQ_TYPE_SENSE_MASK + 1] = {
@@ -101,7 +88,7 @@ static unsigned char irqc_sense[IRQ_TYPE
 
 static int irqc_irq_set_type(struct irq_data *d, unsigned int type)
 {
-   struct irqc_priv *p = irq_data_get_irq_chip_data(d);
+   struct irqc_priv *p = irq_data_to_priv(d);
int hw_irq = irqd_to_hwirq(d);
unsigned char value = irqc_sense[type & IRQ_TYPE_SENSE_MASK];
u32 tmp;
@@ -120,7 +107,7 @@ static int irqc_irq_set_type(struct irq_
 
 static int irqc_irq_set_wake(struct irq_data *d, unsigned int on)
 {
-   struct irqc_priv *p = irq_data_get_irq_chip_data(d);
+   struct irqc_priv *p = irq_data_to_priv(d);
int hw_irq = irqd_to_hwirq(d);
 
irq_set_irq_wake(p->irq[hw_irq].requested_irq, on);
@@ -153,35 +140,11 @@ static irqreturn_t irqc_irq_handler(int
return IRQ_NONE;
 }
 
-/*
- * This lock class tells lockdep that IRQC irqs are in a different
- * category than their parents, so it won't report false recursion.
- */
-static struct lock_class_key irqc_irq_lock_class;
-
-static int irqc_irq_domain_map(struct irq_domain *h, unsigned int virq,
-  irq_hw_number_t hw)
-{
-   struct irqc_priv *p = h->host_data;
-
-   irqc_dbg(&p->irq[hw], "map");
-   irq_set_chip_data(virq, h->host_data);
-   irq_set_lockdep_class(virq, &irqc_irq_lock_class);
-   irq_set_chip_and_handler(virq, &p->irq_chip, handle_level_irq);
-   return 0;
-}
-
-static const struct irq_domain_ops irqc_irq_domain_ops = {
-   .map= irqc_irq_domain_map,
-   .xlate  = irq_domain_xlate_twocell,
-};
-
 static int irqc_probe(struct platform_device *pdev)
 {
struct irqc_priv *p;
struct resource *io;
struct resource *irq;
-   struct irq_chip *irq_chip;
const char *name = dev_name(&pdev->dev);
int ret;
int k;
@@ -241,40 +204,51 @@ static int irqc_probe(struct platform_de
 
p->cpu_int_base = p->iomem + IRQC_INT_CPU_BASE(0); /* SYS-SPI */
 
-   irq_chip = &p->irq_chip;
-   irq_chip->name = name;
-   irq_chip->irq_mask = irqc_irq_disable;
-   irq_chip->irq_unmask = irqc_irq_enable;
-   irq_chip->irq_set_type = irqc_irq_set_type;
-   irq_chip->irq_set_wake = irqc_irq_set_wake;
-   irq_chip->flags = IRQCHIP_MASK_ON_SUSPEND;
-
p->irq_domain = irq_domain_add_linear(pdev->dev.of_node,
  p->number_of_irqs,
- &irqc_irq_domain_ops, p);
+ &irq_generic_chip_ops, p);
if (!p->irq_domain) {
ret = -ENXIO;
dev_err(&pdev->dev, "cannot initialize irq domain\n");
goto err2;
}
 
+   ret = irq_alloc_domain_generic_chips(p->irq_domain, p->number_of_irqs,
+