date:20151208

Re: [linux-sunxi] [PATCH 01/23] mtd: kill the ecclayout->oobavail field

2015-12-08 Thread Boris Brezillon

Hi Priit,

On Tue, 08 Dec 2015 08:43:05 +0200
Priit Laes  wrote:

> On Mon, 2015-12-07 at 23:25 +0100, Boris Brezillon wrote:
> > ecclayout->oobavail is just redundant with the mtd->oobavail field.
> > Moreover, it prevents static const definition of ecc layouts since
> > the
> > NAND framework is calculating this value based on the ecclayout-
> > >oobfree
> > field.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/mtd/devices/docg3.c   |  5 ++-
> >  drivers/mtd/mtdswap.c | 16 -
> >  drivers/mtd/nand/brcmnand/brcmnand.c  |  3 --
> >  drivers/mtd/nand/docg4.c  |  1 -
> >  drivers/mtd/nand/hisi504_nand.c   |  1 -
> >  drivers/mtd/nand/nand_base.c  | 12 +++
> >  drivers/mtd/onenand/onenand_base.c| 16 -
> >  drivers/mtd/tests/oobtest.c   | 49 +--
> > 
> >  drivers/staging/mt29f_spinand/mt29f_spinand.c |  1 -
> >  fs/jffs2/wbuf.c   |  6 ++--
> >  include/linux/mtd/mtd.h   |  1 -
> >  11 files changed, 48 insertions(+), 63 deletions(-)
> > 
> [..]
> >  
> > diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> > b/drivers/mtd/nand/brcmnand/brcmnand.c
> > index 35d78f7..a906ec2 100644
> > --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> > +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> > @@ -845,9 +845,6 @@ static struct nand_ecclayout 
> > *brcmnand_create_layout(int ecc_level,
> >     break;
> >     }
> >  out:
> > -   /* Sum available OOB */
> > -   for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES_LARGE; i++)
> > -   layout->oobavail += layout->oobfree[i].length;
> >     return layout;
> >  }
> 
> You can get rid of the 'out' label and replace the single goto in this
> function with 'return layout'.

Yep, I'll fix that.

> 
> [...]
> >  
> > diff --git a/drivers/mtd/nand/nand_base.c
> > b/drivers/mtd/nand/nand_base.c
> > index 0748a13..1107f5c1 100644
> > --- a/drivers/mtd/nand/nand_base.c
> > +++ b/drivers/mtd/nand/nand_base.c
> > @@ -2037,7 +2037,7 @@ static int nand_do_read_oob(struct mtd_info
> > *mtd, loff_t from,
> >     stats = mtd->ecc_stats;
> >  
> >     if (ops->mode == MTD_OPS_AUTO_OOB)
> > -   len = chip->ecc.layout->oobavail;
> > +   len = mtd->oobavail;
> >     else
> >     len = mtd->oobsize;
> >  
> > @@ -2728,7 +2728,7 @@ static int nand_do_write_oob(struct mtd_info
> > *mtd, loff_t to,
> >      __func__, (unsigned int)to, (int)ops-
> > >ooblen);
> >  
> >     if (ops->mode == MTD_OPS_AUTO_OOB)
> > -   len = chip->ecc.layout->oobavail;
> > +   len = mtd->oobavail;
> >     else
> >     len = mtd->oobsize;
> >  
> [...]
> > diff --git a/drivers/mtd/onenand/onenand_base.c
> > b/drivers/mtd/onenand/onenand_base.c
> > index 43b3392..d70bbfd 100644
> > --- a/drivers/mtd/onenand/onenand_base.c
> > +++ b/drivers/mtd/onenand/onenand_base.c
> > @@ -1125,7 +1125,7 @@ static int onenand_mlc_read_ops_nolock(struct
> > mtd_info *mtd, loff_t from,
> >     (int)len);
> >  
> >     if (ops->mode == MTD_OPS_AUTO_OOB)
> > -   oobsize = this->ecclayout->oobavail;
> > +   oobsize = mtd->oobavail;
> >     else
> >     oobsize = mtd->oobsize;
> >  
> > @@ -1230,7 +1230,7 @@ static int onenand_read_ops_nolock(struct
> > mtd_info *mtd, loff_t from,
> >     (int)len);
> >  
> >     if (ops->mode == MTD_OPS_AUTO_OOB)
> > -   oobsize = this->ecclayout->oobavail;
> > +   oobsize = mtd->oobavail;
> >     else
> >     oobsize = mtd->oobsize;
> >  
> > @@ -1365,7 +1365,7 @@ static int onenand_read_oob_nolock(struct
> > mtd_info *mtd, loff_t from,
> >     ops->oobretlen = 0;
> >  
> >     if (mode == MTD_OPS_AUTO_OOB)
> > -   oobsize = this->ecclayout->oobavail;
> > +   oobsize = mtd->oobavail;
> >     else
> >     oobsize = mtd->oobsize;
> >  
> > @@ -1887,7 +1887,7 @@ static int onenand_write_ops_nolock(struct
> > mtd_info *mtd, loff_t to,
> >     return 0;
> >  
> >     if (ops->mode == MTD_OPS_AUTO_OOB)
> > -   oobsize = this->ecclayout->oobavail;
> > +   oobsize = mtd->oobavail;
> >     else
> >     oobsize = mtd->oobsize;
> >  
> > @@ -2063,7 +2063,7 @@ static int onenand_write_oob_nolock(struct
> > mtd_info *mtd, loff_t to,
> >     ops->oobretlen = 0;
> >  
> >     if (mode == MTD_OPS_AUTO_OOB)
> > -   oobsize = this->ecclayout->oobavail;
> > +   oobsize = mtd->oobavail;
> >     else
> >     oobsize = mtd->oobsize;
> 
> This identical construction seems to occur multiple times in multiple
> files. Would it make sense to create a macro for it?

Right, I'll make another patch move this logic into an inline function.

Thanks for the review.

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___

Re: [PATCH v2 18/25] cris: nand: remove useless mtd->priv = chip assignments

2015-12-08 Thread Jesper Nilsson

On Tue, Dec 01, 2015 at 12:03:15PM +0100, Boris Brezillon wrote:
> mtd_to_nand() now uses the container_of() approach to transform an
> mtd_info pointer into a nand_chip one. Drop useless mtd->priv
> assignments from NAND controller drivers.
> 
> Signed-off-by: Boris Brezillon 

Acked-by: Jesper Nilsson 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [linux-sunxi] [PATCH 21/23] staging: mt29f_spinand: switch to mtd_ooblayout_ops

2015-12-08 Thread Boris Brezillon

Hi Julian,

On Tue, 8 Dec 2015 10:59:53 +1100
Julian Calaby  wrote:

> Hi Boris,
> 
> On Tue, Dec 8, 2015 at 9:26 AM, Boris Brezillon
>  wrote:
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/staging/mt29f_spinand/mt29f_spinand.c | 44 
> > ---
> >  1 file changed, 26 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c 
> > b/drivers/staging/mt29f_spinand/mt29f_spinand.c
> > index cb9d5ab..967d50a 100644
> > --- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
> > +++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
> > @@ -42,23 +42,29 @@ static inline struct spinand_state *mtd_to_state(struct 
> > mtd_info *mtd)
> >  static int enable_hw_ecc;
> >  static int enable_read_hw_ecc;
> >
> > -static struct nand_ecclayout spinand_oob_64 = {
> > -   .eccbytes = 24,
> > -   .eccpos = {
> > -   1, 2, 3, 4, 5, 6,
> > -   17, 18, 19, 20, 21, 22,
> > -   33, 34, 35, 36, 37, 38,
> > -   49, 50, 51, 52, 53, 54, },
> > -   .oobfree = {
> > -   {.offset = 8,
> > -   .length = 8},
> > -   {.offset = 24,
> > -   .length = 8},
> > -   {.offset = 40,
> > -   .length = 8},
> > -   {.offset = 56,
> > -   .length = 8},
> > -   }
> > +static int spinand_oob_64_eccpos(struct mtd_info *mtd, int eccbyte)
> > +{
> > +   if (eccbyte > 23)
> > +   return -ERANGE;
> > +
> > +   return ((eccbyte / 6) * 16) + 1;
> 
> Are you sure this is correct? My reading of this is that we'd get 1
> for eccbytes 0 through 5.
> 
> Would
> 
> ((eccbyte / 6) * 16) + (eccbyte % 6) + 1
> 
> be more correct?

Absolutely. I'll fix that.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 15/25] cris: nand: use the mtd instance embedded in struct nand_chip

2015-12-08 Thread Jesper Nilsson

On Tue, Dec 01, 2015 at 12:03:12PM +0100, Boris Brezillon wrote:
> struct nand_chip now embeds an mtd device. Patch all drivers to make use
> of this mtd instance instead of using the instance embedded in their
> private struct or dynamically allocated.
> 
> Signed-off-by: Boris Brezillon 

Acked-by: Jesper Nilsson 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 19/23] mtd: nand: switch all drivers to mtd_ooblayout_ops

2015-12-08 Thread Ralf Baechle

On Mon, Dec 07, 2015 at 11:26:14PM +0100, Boris Brezillon wrote:

Looking good,

Acked-by: Ralf Baechle 

  Ralf
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: rdma:Delete unnecessary NULL check before calling function "kmem_cache_destroy"

2015-12-08 Thread Shah, Yash (Y.)

From: Yash Shah 

The kmem_cache_destroy() function tests whether its argument is NULL
and then returns immediately. 
Thus the NULL check before calling this function is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Yash Shah 
---
 drivers/staging/rdma/ehca/ehca_av.c   | 3 +--
 drivers/staging/rdma/ehca/ehca_cq.c   | 3 +--
 drivers/staging/rdma/ehca/ehca_main.c | 3 +--
 drivers/staging/rdma/ehca/ehca_mrmw.c | 6 ++
 drivers/staging/rdma/ehca/ehca_pd.c   | 3 +--
 drivers/staging/rdma/ehca/ehca_qp.c   | 3 +--
 6 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rdma/ehca/ehca_av.c 
b/drivers/staging/rdma/ehca/ehca_av.c
index fd7b6d0..94e088c 100644
--- a/drivers/staging/rdma/ehca/ehca_av.c
+++ b/drivers/staging/rdma/ehca/ehca_av.c
@@ -275,6 +275,5 @@ int ehca_init_av_cache(void)
 
 void ehca_cleanup_av_cache(void)
 {
-   if (av_cache)
-   kmem_cache_destroy(av_cache);
+   kmem_cache_destroy(av_cache);
 }
diff --git a/drivers/staging/rdma/ehca/ehca_cq.c 
b/drivers/staging/rdma/ehca/ehca_cq.c
index ea1b5c1..1aa7931 100644
--- a/drivers/staging/rdma/ehca/ehca_cq.c
+++ b/drivers/staging/rdma/ehca/ehca_cq.c
@@ -393,6 +393,5 @@ int ehca_init_cq_cache(void)
 
 void ehca_cleanup_cq_cache(void)
 {
-   if (cq_cache)
-   kmem_cache_destroy(cq_cache);
+   kmem_cache_destroy(cq_cache);
 }
diff --git a/drivers/staging/rdma/ehca/ehca_main.c 
b/drivers/staging/rdma/ehca/ehca_main.c
index 8246418..860b974 100644
--- a/drivers/staging/rdma/ehca/ehca_main.c
+++ b/drivers/staging/rdma/ehca/ehca_main.c
@@ -245,8 +245,7 @@ static void ehca_destroy_slab_caches(void)
ehca_cleanup_cq_cache();
ehca_cleanup_pd_cache();
 #ifdef CONFIG_PPC_64K_PAGES
-   if (ctblk_cache)
-   kmem_cache_destroy(ctblk_cache);
+   kmem_cache_destroy(ctblk_cache);
 #endif
 }
 
diff --git a/drivers/staging/rdma/ehca/ehca_mrmw.c 
b/drivers/staging/rdma/ehca/ehca_mrmw.c
index f914b30..553e883 100644
--- a/drivers/staging/rdma/ehca/ehca_mrmw.c
+++ b/drivers/staging/rdma/ehca/ehca_mrmw.c
@@ -2251,10 +2251,8 @@ int ehca_init_mrmw_cache(void)
 
 void ehca_cleanup_mrmw_cache(void)
 {
-   if (mr_cache)
-   kmem_cache_destroy(mr_cache);
-   if (mw_cache)
-   kmem_cache_destroy(mw_cache);
+   kmem_cache_destroy(mr_cache);
+   kmem_cache_destroy(mw_cache);
 }
 
 static inline int ehca_init_top_bmap(struct ehca_top_bmap *ehca_top_bmap,
diff --git a/drivers/staging/rdma/ehca/ehca_pd.c 
b/drivers/staging/rdma/ehca/ehca_pd.c
index 351577a..2a8aae4 100644
--- a/drivers/staging/rdma/ehca/ehca_pd.c
+++ b/drivers/staging/rdma/ehca/ehca_pd.c
@@ -119,6 +119,5 @@ int ehca_init_pd_cache(void)
 
 void ehca_cleanup_pd_cache(void)
 {
-   if (pd_cache)
-   kmem_cache_destroy(pd_cache);
+   kmem_cache_destroy(pd_cache);
 }
diff --git a/drivers/staging/rdma/ehca/ehca_qp.c 
b/drivers/staging/rdma/ehca/ehca_qp.c
index 2e89356..896c01f 100644
--- a/drivers/staging/rdma/ehca/ehca_qp.c
+++ b/drivers/staging/rdma/ehca/ehca_qp.c
@@ -2252,6 +2252,5 @@ int ehca_init_qp_cache(void)
 
 void ehca_cleanup_qp_cache(void)
 {
-   if (qp_cache)
-   kmem_cache_destroy(qp_cache);
+   kmem_cache_destroy(qp_cache);
 }
-- 
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 05/23] mtd: nand: jz4770: kill the ->ecc_layout field

2015-12-08 Thread Harvey Hunt


Hi Boris,

On 07/12/15 22:26, Boris Brezillon wrote:

->ecc_layout is not used by any board file. Kill this field to avoid any
confusion. New boards are encouraged to use the default ECC layout defined
in NAND core.

Signed-off-by: Boris Brezillon 
---
  arch/mips/include/asm/mach-jz4740/jz4740_nand.h | 2 --
  drivers/mtd/nand/jz4740_nand.c  | 3 ---
  2 files changed, 5 deletions(-)

diff --git a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h 
b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
index 79cff26..398733e 100644
--- a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
+++ b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
@@ -25,8 +25,6 @@ struct jz_nand_platform_data {
int num_partitions;
struct mtd_partition*partitions;

-   struct nand_ecclayout   *ecc_layout;
-
unsigned char banks[JZ_NAND_NUM_BANKS];

void (*ident_callback)(struct platform_device *, struct nand_chip *,
diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
index 5a99a93..c4fe446 100644
--- a/drivers/mtd/nand/jz4740_nand.c
+++ b/drivers/mtd/nand/jz4740_nand.c
@@ -446,9 +446,6 @@ static int jz_nand_probe(struct platform_device *pdev)
chip->ecc.bytes  = 9;
chip->ecc.strength   = 4;

-   if (pdata)
-   chip->ecc.layout = pdata->ecc_layout;
-
chip->chip_delay = 50;
chip->cmd_ctrl = jz_nand_cmd_ctrl;
chip->select_chip = jz_nand_select_chip;



Is there a typo in this commit title? The JZ4740 and JZ4770 have quite 
different NAND controller interfaces, so I don't think that the JZ4740 
driver will support the JZ4770.


Thanks,

Harvey
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 05/23] mtd: nand: jz4770: kill the ->ecc_layout field

2015-12-08 Thread Boris Brezillon

On Tue, 8 Dec 2015 10:30:40 +
Harvey Hunt  wrote:

> Hi Boris,
> 
> On 07/12/15 22:26, Boris Brezillon wrote:
> > ->ecc_layout is not used by any board file. Kill this field to avoid any
> > confusion. New boards are encouraged to use the default ECC layout defined
> > in NAND core.
> >
> > Signed-off-by: Boris Brezillon 
> > ---
> >   arch/mips/include/asm/mach-jz4740/jz4740_nand.h | 2 --
> >   drivers/mtd/nand/jz4740_nand.c  | 3 ---
> >   2 files changed, 5 deletions(-)
> >
> > diff --git a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h 
> > b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
> > index 79cff26..398733e 100644
> > --- a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
> > +++ b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
> > @@ -25,8 +25,6 @@ struct jz_nand_platform_data {
> > int num_partitions;
> > struct mtd_partition*partitions;
> >
> > -   struct nand_ecclayout   *ecc_layout;
> > -
> > unsigned char banks[JZ_NAND_NUM_BANKS];
> >
> > void (*ident_callback)(struct platform_device *, struct nand_chip *,
> > diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
> > index 5a99a93..c4fe446 100644
> > --- a/drivers/mtd/nand/jz4740_nand.c
> > +++ b/drivers/mtd/nand/jz4740_nand.c
> > @@ -446,9 +446,6 @@ static int jz_nand_probe(struct platform_device *pdev)
> > chip->ecc.bytes = 9;
> > chip->ecc.strength  = 4;
> >
> > -   if (pdata)
> > -   chip->ecc.layout = pdata->ecc_layout;
> > -
> > chip->chip_delay = 50;
> > chip->cmd_ctrl = jz_nand_cmd_ctrl;
> > chip->select_chip = jz_nand_select_chip;
> >
> 
> Is there a typo in this commit title? The JZ4740 and JZ4770 have quite 
> different NAND controller interfaces, so I don't think that the JZ4740 
> driver will support the JZ4770.

Yes, it's a typo, I meant jz4740, I'll fix my commit message
accordingly.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

PLEASE CONFIRM

2015-12-08 Thread George Mathew




 Dear Friend

 My name is Mr. George Mathew, I am a banker. It is true that we have  
not meet each other in person
 but I strongly believe that where there is no trust no friendship in  
every business.


 I have a deceased customers pending fund whom you share the same  
last name with, I am his personal
 finance adviser before his accidental death, that being the main  
reason why I alone working
 in the bank here know much about the existence of this fund and the  
secrets surrounding this money.


 But before I disclose the full details to you, I will like to know  
your interest and willingness to assist
 me by reverting back to me with your information like Phone number  
for easier communication and your contact address.


 Thanks and hope to hear from you soon

 Sincerely Yours
 Mr. George Mathew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

PLEASE CONFIRM

2015-12-08 Thread George Mathew




 Dear Friend

 My name is Mr. George Mathew, I am a banker. It is true that we have  
not meet each other in person
 but I strongly believe that where there is no trust no friendship in  
every business.


 I have a deceased customers pending fund whom you share the same  
last name with, I am his personal
 finance adviser before his accidental death, that being the main  
reason why I alone working
 in the bank here know much about the existence of this fund and the  
secrets surrounding this money.


 But before I disclose the full details to you, I will like to know  
your interest and willingness to assist
 me by reverting back to me with your information like Phone number  
for easier communication and your contact address.


 Thanks and hope to hear from you soon

 Sincerely Yours
 Mr. George Mathew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: Skein: Moved macros from skein_block.c to header file.

2015-12-08 Thread Jason Cooper

Sanidhya,

*Much* better.  Only two two small nits (things which Greg may be able
to fix up when applying), and one comment.

nit: Patch subject should be 'staging: skein: ...'

On Mon, Dec 07, 2015 at 09:37:24PM -0500, Sanidhya Solanki wrote:
> The original code defined macros in the source code, making it
> harder to read. Moved them to the header file, as per the TODO file.
> 
> Upadated the TODO file.

nit: typo 'Updated'

> 
> Signed-off-by: Sanidhya Solanki 
> ---
>  drivers/staging/skein/TODO  | 1 -
>  drivers/staging/skein/skein_block.c | 6 --
>  drivers/staging/skein/skein_block.h | 7 +++
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/skein/TODO b/drivers/staging/skein/TODO
> index cd3508d..e3de0c7 100644
> --- a/drivers/staging/skein/TODO
> +++ b/drivers/staging/skein/TODO
> @@ -1,6 +1,5 @@
>  skein/threefish TODO
>  
> - - move macros into appropriate header files

There are a lot more macros to relocate than what we see below.  I'd
prefer to edit the TODO only after it's all cleaned up.  Sorry if I
wasn't clear before.  I was assuming previous versions of your patches
were tests, and that once you had the process down, you'd hit all of the
macros.

So, the question is: Would you like this to be the first patch so you
can see the whole process once?  If so, we need to leave the TODO item
intact.  Otherwise, I think you've got the whole submission process down
now so you can go ahead and do all the macros.

Just let us know.

thx,

Jason.

>   - add / pass test vectors
>   - module support
>  
> diff --git a/drivers/staging/skein/skein_block.c 
> b/drivers/staging/skein/skein_block.c
> index 45b4732..2120392 100644
> --- a/drivers/staging/skein/skein_block.c
> +++ b/drivers/staging/skein/skein_block.c
> @@ -26,12 +26,6 @@
>  #define SKEIN_LOOP 001 /* default: unroll 256 and 512, but not 1024 */
>  #endif
>  
> -#define BLK_BITS(WCNT * 64) /* some useful definitions for code here 
> */
> -#define KW_TWK_BASE (0)
> -#define KW_KEY_BASE (3)
> -#define ks  (kw + KW_KEY_BASE)
> -#define ts  (kw + KW_TWK_BASE)
> -
>  #ifdef SKEIN_DEBUG
>  #define debug_save_tweak(ctx)   \
>  {   \
> diff --git a/drivers/staging/skein/skein_block.h 
> b/drivers/staging/skein/skein_block.h
> index 9d40f4a..0fd4bfe 100644
> --- a/drivers/staging/skein/skein_block.h
> +++ b/drivers/staging/skein/skein_block.h
> @@ -7,6 +7,13 @@
>  ** This algorithm and source code is released to the public domain.
>  **
>  /
> +
> +#define BLK_BITS(WCNT * 64) /* some useful definitions for code here 
> */
> +#define KW_TWK_BASE (0)
> +#define KW_KEY_BASE (3)
> +#define ks  (kw + KW_KEY_BASE)
> +#define ts  (kw + KW_TWK_BASE)
> +
>  #ifndef _SKEIN_BLOCK_H_
>  #define _SKEIN_BLOCK_H_
>  
> -- 
> 2.5.0
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v8 32/55] [media] media: use macros to check for V4L2 subdev entities

2015-12-08 Thread Mauro Carvalho Chehab

Em Sun, 06 Dec 2015 04:16:15 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> Thank you for the patch.
> 
> On Sunday 30 August 2015 00:06:43 Mauro Carvalho Chehab wrote:
> > Instead of relying on media subtype, use the new macros to detect
> > if an entity is a subdev or an A/V DMA entity.
> > 
> > Please note that most drivers assume that there's just AV_DMA or
> > V4L2 subdevs. This is not true anymore, as we've added MC support
> > for DVB, and there are plans to add support for ALSA and FB/DRM
> > too.
> > 
> > Ok, on the current pipelines supported by those drivers, just V4L
> > stuff are there, but, assuming that some day a pipeline that also
> > works with other subsystems will ever added, it is better to add
> > explicit checks for the AV_DMA stuff.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > 
> > diff --git a/drivers/media/platform/exynos4-is/common.c
> > b/drivers/media/platform/exynos4-is/common.c index
> > 0eb34ecb8ee4..8c9a29e0e294 100644
> > --- a/drivers/media/platform/exynos4-is/common.c
> > +++ b/drivers/media/platform/exynos4-is/common.c
> > @@ -22,8 +22,7 @@ struct v4l2_subdev *fimc_find_remote_sensor(struct
> > media_entity *entity) while (pad->flags & MEDIA_PAD_FL_SINK) {
> > /* source pad */
> > pad = media_entity_remote_pad(pad);
> > -   if (pad == NULL ||
> > -   media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > break;
> > 
> > sd = media_entity_to_v4l2_subdev(pad->entity);
> > diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
> > b/drivers/media/platform/exynos4-is/fimc-capture.c index
> > 0627a93b2f3b..e9810fee4c30 100644
> > --- a/drivers/media/platform/exynos4-is/fimc-capture.c
> > +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
> > @@ -1141,8 +1141,7 @@ static int fimc_pipeline_validate(struct fimc_dev
> > *fimc) }
> > }
> > 
> > -   if (src_pad == NULL ||
> > -   media_entity_type(src_pad->entity) != 
> > MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!src_pad || !is_media_entity_v4l2_subdev(src_pad->entity))
> > break;
> > 
> > /* Don't call FIMC subdev operation to avoid nested locking */
> > @@ -1397,7 +1396,7 @@ static int fimc_link_setup(struct media_entity
> > *entity, struct fimc_vid_cap *vc = &fimc->vid_cap;
> > struct v4l2_subdev *sensor;
> > 
> > -   if (media_entity_type(remote->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!is_media_entity_v4l2_subdev(remote->entity))
> > return -EINVAL;
> > 
> > if (WARN_ON(fimc == NULL))
> > diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > b/drivers/media/platform/exynos4-is/fimc-isp-video.c index
> > 3d9ccbf5f10f..5fbaf5e39903 100644
> > --- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > @@ -467,8 +467,7 @@ static int isp_video_pipeline_validate(struct fimc_isp
> > *isp)
> > 
> > /* Retrieve format at the source pad */
> > pad = media_entity_remote_pad(pad);
> > -   if (pad == NULL ||
> > -   media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > break;
> > 
> > sd = media_entity_to_v4l2_subdev(pad->entity);
> > diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
> > b/drivers/media/platform/exynos4-is/fimc-lite.c index
> > b2607da4ad14..c2327147b360 100644
> > --- a/drivers/media/platform/exynos4-is/fimc-lite.c
> > +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
> > @@ -814,8 +814,7 @@ static int fimc_pipeline_validate(struct fimc_lite
> > *fimc) }
> > /* Retrieve format at the source pad */
> > pad = media_entity_remote_pad(pad);
> > -   if (pad == NULL ||
> > -   media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > break;
> > 
> > sd = media_entity_to_v4l2_subdev(pad->entity);
> > @@ -988,7 +987,6 @@ static int fimc_lite_link_setup(struct media_entity
> > *entity, {
> > struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> > struct fimc_lite *fimc = v4l2_get_subdevdata(sd);
> > -   unsigned int remote_ent_type = media_entity_type(remote->entity);
> > int ret = 0;
> > 
> > if (WARN_ON(fimc == NULL))
> > @@ -1000,7 +998,7 @@ static int fimc_lite_link_setup(struct media_entity
> > *entity,
> > 
> > switch (local->index) {
> > case FLITE_SD_PAD_SINK:
> > -   if (remote_ent_type != MEDIA_ENT_T_V4L2_SUBDEV) {
> > +   if (!is_media_entity_v4l2_subdev(remote->entity)) {
> > ret = -EINVAL;
> > break;
> > }
> > @@ -1018,7 +1016,7 @@ static int fimc_lite_link_set

[PATCH] staging: android: ashmem.c: destroy slabs when init fails

2015-12-08 Thread Wenwei Tao

when ashmem init fails, destroy the slabs, leave
no garbage.

Signed-off-by: Wenwei Tao 
---
 drivers/staging/android/ashmem.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 3f2a3d6..5bb1283 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -831,14 +831,14 @@ static struct miscdevice ashmem_misc = {
 
 static int __init ashmem_init(void)
 {
-   int ret;
+   int ret = -ENOMEM;
 
ashmem_area_cachep = kmem_cache_create("ashmem_area_cache",
   sizeof(struct ashmem_area),
   0, 0, NULL);
if (unlikely(!ashmem_area_cachep)) {
pr_err("failed to create slab cache\n");
-   return -ENOMEM;
+   goto out;
}
 
ashmem_range_cachep = kmem_cache_create("ashmem_range_cache",
@@ -846,13 +846,13 @@ static int __init ashmem_init(void)
0, 0, NULL);
if (unlikely(!ashmem_range_cachep)) {
pr_err("failed to create slab cache\n");
-   return -ENOMEM;
+   goto out_free1;
}
 
ret = misc_register(&ashmem_misc);
if (unlikely(ret)) {
pr_err("failed to register misc device!\n");
-   return ret;
+   goto out_free2;
}
 
register_shrinker(&ashmem_shrinker);
@@ -860,5 +860,12 @@ static int __init ashmem_init(void)
pr_info("initialized\n");
 
return 0;
+
+out_free2:
+   kmem_cache_destroy(ashmem_range_cachep);
+out_free1:
+   kmem_cache_destroy(ashmem_area_cachep);
+out:
+   return ret;
 }
 device_initcall(ashmem_init);
-- 
1.8.3.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v8 33/55] [media] omap3/omap4/davinci: get rid of MEDIA_ENT_T_V4L2_SUBDEV abuse

2015-12-08 Thread Mauro Carvalho Chehab

Em Sun, 06 Dec 2015 04:08:17 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> Thank you for the patch.
> 
> On Sunday 30 August 2015 00:06:44 Mauro Carvalho Chehab wrote:
> > On omap3/omap4/davinci drivers, MEDIA_ENT_T_V4L2_SUBDEV macro is
> > abused in order to "simplify" the pad checks.
> 
> As explained in a couple of other replies to similar patches, it's not a hack 
> :-)

That's actually the first reply (at least looking at the patches
order ;)

This is a hack, since it mixes a global subdev type with a private
PAD type, defined only inside the driver, on switch cases like:
CCDC_PAD_SINK | MEDIA_ENT_T_V4L2_SUBDEV:

That implicitly consider that:
local->index | media_entity_type(remote->entity)

will be a number where the local->index bits will never ever be
used by media_entity_type() return macro.

With such assumption, any change at the numberspace returned by
media_entity_type() would break the driver, and people changing
the core won't even be noticing it, as this is a driver-specific thing.

There's absolute nothing inside the core, even before this patchset
that would warrant that the bits used by local->index (CCDC_PAD_SINK 
and CCDC_PAD_SOURCE) won't be used on media_entity_type() return
value.

So, for me this is a hack, and a dangerous one, because it adds
hidden namespace coupling inside the driver that would break if the
core changes.

> 
> > Basically, it does a logical or of this macro, in order to check
> > for a local index and if the entity is either a subdev or not.
> > 
> > As we'll get rid of MEDIA_ENT_T_V4L2_SUBDEV macro,
> 
> This is the reason for this patch, and I agree with it.
> 
> > replace it by 2 << 16 where it occurs, and add a note saying that the code
> > there is actually a hack.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > 
> > diff --git a/drivers/media/platform/omap3isp/ispccdc.c
> > b/drivers/media/platform/omap3isp/ispccdc.c index
> > 9a811f5741fa..f0e530c98188 100644
> > --- a/drivers/media/platform/omap3isp/ispccdc.c
> > +++ b/drivers/media/platform/omap3isp/ispccdc.c
> > @@ -2513,9 +2513,14 @@ static int ccdc_link_setup(struct media_entity
> > *entity, struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> > struct isp_ccdc_device *ccdc = v4l2_get_subdevdata(sd);
> > struct isp_device *isp = to_isp_device(ccdc);
> > +   int index = local->index;
> 
> The index can never be negative, you can use unsigned int.

Ok. Will address on a later patch.
> 
> > 
> > -   switch (local->index | media_entity_type(remote->entity)) {
> > -   case CCDC_PAD_SINK | MEDIA_ENT_T_V4L2_SUBDEV:
> > +   /* FIXME: this is actually a hack! */
> 
> Please, let's not introduce a hack to replace valid code. I'm certainly fine 
> with removing usage of MEDIA_ENT_T_V4L2_SUBDEV, but drivers should be 
> modified 
> cleanly.

I just preserved the existing hack, by replacing MEDIA_ENT_T_V4L2_SUBDEV macro
that will be removed by its value (2 << 16).

> If you rename the index variable to link and use a macro (I would call it 
> LINK_TO_SUBDEV for instance) instead of 2 << 16 the implementation wouldn't 
> be 
> that bad, as what the switch operates on is the link, not the pad. I would 
> also create a LINK_TO_DEVNODE macro, even if it evaluates to 0, to clearly 
> label each case.

Sorry but I didn't follow you here. Could you please send us a patch
or a code example explaining what you're meaning?

> 
> > +   if (is_media_entity_v4l2_subdev(remote->entity))
> > +   index |= 2 << 16;
> 
> Why 2 << 16 and not 1 << 16 ?

Because that's the value of MEDIA_ENT_T_V4L2_SUBDEV. This is a hack:
any value here is just a magic number with no physical meaning.

Using 1 << 16 would be as good or as bad as 2 << 16.

> Same comments for all the other files below (but please see the very end for 
> one last comment).
> 
> > +   switch (index) {
> > +   case CCDC_PAD_SINK | 2 << 16:
> > /* Read from the sensor (parallel interface), CCP2, CSI2a or
> >  * CSI2c.
> >  */
> > @@ -2543,7 +2548,7 @@ static int ccdc_link_setup(struct media_entity
> > *entity, * Revisit this when it will be implemented, and return -EBUSY for
> > now. */
> > 
> > -   case CCDC_PAD_SOURCE_VP | MEDIA_ENT_T_V4L2_SUBDEV:
> > +   case CCDC_PAD_SOURCE_VP | 2 << 16:
> > /* Write to preview engine, histogram and H3A. When none of
> >  * those links are active, the video port can be disabled.
> >  */
> > @@ -2556,7 +2561,7 @@ static int ccdc_link_setup(struct media_entity
> > *entity, }
> > break;
> > 
> > -   case CCDC_PAD_SOURCE_OF | MEDIA_ENT_T_DEVNODE:
> > +   case CCDC_PAD_SOURCE_OF:
> > /* Write to memory */
> > if (flags & MEDIA_LNK_FL_ENABLED) {
> > if (ccdc->output & ~CCDC_OUTPUT_MEMORY)
> > @@ -2567,7 +2572,7 @@ static int ccdc_link_setup(struct media_entity
> > *entity, }
> > break;
> > 
> > -   case CCDC_PAD_SOURCE_OF | MEDIA_ENT_T_V4L2_SUBDEV:
>

[PATCH v2 0/5] Drivers: hv: ring_buffer: do some code cleanup and optimization

2015-12-08 Thread Vitaly Kuznetsov

Changes since v1: added PATCH 4/5 and 5/5.

1) Fix comment style in ring_buffer.c
2) Remove unneeded smp_read_barrier_depends() from hyperv.h
3) Unify hv_ringbuffer_peek/read() functions
4) Unify vmbus_recvpacket()/vmbus_recvpacket_raw() functions
5) Eliminate hv_ringbuffer_peek().

Vitaly Kuznetsov (5):
  Drivers: hv: ring_buffer.c: fix comment style
  Drivers: hv: ring_buffer: remove stray smp_read_barrier_depends()
  Drivers: hv: ring_buffer: remove code duplication from
hv_ringbuffer_peek/read()
  Drivers: hv: remove code duplication between
vmbus_recvpacket()/vmbus_recvpacket_raw()
  Drivers: hv: ring_buffer: eliminate hv_ringbuffer_peek()

 drivers/hv/channel.c  |  81 -
 drivers/hv/hyperv_vmbus.h |  11 +--
 drivers/hv/ring_buffer.c  | 218 ++
 include/linux/hyperv.h|   2 -
 4 files changed, 83 insertions(+), 229 deletions(-)

-- 
2.4.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 1/5] Drivers: hv: ring_buffer.c: fix comment style

2015-12-08 Thread Vitaly Kuznetsov

Convert 6+-string comments repeating function names to normal kernel-style
comments and fix a couple of other comment style issues. No textual or
functional changes intended.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/hv/ring_buffer.c | 135 +--
 1 file changed, 26 insertions(+), 109 deletions(-)

diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 70a1a9a..7bca513 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -112,9 +112,7 @@ static bool hv_need_to_signal_on_read(u32 prev_write_sz,
u32 read_loc = rbi->ring_buffer->read_index;
u32 pending_sz = rbi->ring_buffer->pending_send_sz;
 
-   /*
-* If the other end is not blocked on write don't bother.
-*/
+   /* If the other end is not blocked on write don't bother. */
if (pending_sz == 0)
return false;
 
@@ -128,12 +126,7 @@ static bool hv_need_to_signal_on_read(u32 prev_write_sz,
return false;
 }
 
-/*
- * hv_get_next_write_location()
- *
- * Get the next write location for the specified ring buffer
- *
- */
+/* Get the next write location for the specified ring buffer. */
 static inline u32
 hv_get_next_write_location(struct hv_ring_buffer_info *ring_info)
 {
@@ -142,12 +135,7 @@ hv_get_next_write_location(struct hv_ring_buffer_info 
*ring_info)
return next;
 }
 
-/*
- * hv_set_next_write_location()
- *
- * Set the next write location for the specified ring buffer
- *
- */
+/* Set the next write location for the specified ring buffer. */
 static inline void
 hv_set_next_write_location(struct hv_ring_buffer_info *ring_info,
 u32 next_write_location)
@@ -155,11 +143,7 @@ hv_set_next_write_location(struct hv_ring_buffer_info 
*ring_info,
ring_info->ring_buffer->write_index = next_write_location;
 }
 
-/*
- * hv_get_next_read_location()
- *
- * Get the next read location for the specified ring buffer
- */
+/* Get the next read location for the specified ring buffer. */
 static inline u32
 hv_get_next_read_location(struct hv_ring_buffer_info *ring_info)
 {
@@ -169,10 +153,8 @@ hv_get_next_read_location(struct hv_ring_buffer_info 
*ring_info)
 }
 
 /*
- * hv_get_next_readlocation_withoffset()
- *
  * Get the next read location + offset for the specified ring buffer.
- * This allows the caller to skip
+ * This allows the caller to skip.
  */
 static inline u32
 hv_get_next_readlocation_withoffset(struct hv_ring_buffer_info *ring_info,
@@ -186,13 +168,7 @@ hv_get_next_readlocation_withoffset(struct 
hv_ring_buffer_info *ring_info,
return next;
 }
 
-/*
- *
- * hv_set_next_read_location()
- *
- * Set the next read location for the specified ring buffer
- *
- */
+/* Set the next read location for the specified ring buffer. */
 static inline void
 hv_set_next_read_location(struct hv_ring_buffer_info *ring_info,
u32 next_read_location)
@@ -201,12 +177,7 @@ hv_set_next_read_location(struct hv_ring_buffer_info 
*ring_info,
 }
 
 
-/*
- *
- * hv_get_ring_buffer()
- *
- * Get the start of the ring buffer
- */
+/* Get the start of the ring buffer. */
 static inline void *
 hv_get_ring_buffer(struct hv_ring_buffer_info *ring_info)
 {
@@ -214,25 +185,14 @@ hv_get_ring_buffer(struct hv_ring_buffer_info *ring_info)
 }
 
 
-/*
- *
- * hv_get_ring_buffersize()
- *
- * Get the size of the ring buffer
- */
+/* Get the size of the ring buffer. */
 static inline u32
 hv_get_ring_buffersize(struct hv_ring_buffer_info *ring_info)
 {
return ring_info->ring_datasize;
 }
 
-/*
- *
- * hv_get_ring_bufferindices()
- *
- * Get the read and write indices as u64 of the specified ring buffer
- *
- */
+/* Get the read and write indices as u64 of the specified ring buffer. */
 static inline u64
 hv_get_ring_bufferindices(struct hv_ring_buffer_info *ring_info)
 {
@@ -240,12 +200,8 @@ hv_get_ring_bufferindices(struct hv_ring_buffer_info 
*ring_info)
 }
 
 /*
- *
- * hv_copyfrom_ringbuffer()
- *
  * Helper routine to copy to source from ring buffer.
  * Assume there is enough room. Handles wrap-around in src case only!!
- *
  */
 static u32 hv_copyfrom_ringbuffer(
struct hv_ring_buffer_info  *ring_info,
@@ -277,12 +233,8 @@ static u32 hv_copyfrom_ringbuffer(
 
 
 /*
- *
- * hv_copyto_ringbuffer()
- *
  * Helper routine to copy from source to ring buffer.
  * Assume there is enough room. Handles wrap-around in dest case only!!
- *
  */
 static u32 hv_copyto_ringbuffer(
struct hv_ring_buffer_info  *ring_info,
@@ -308,13 +260,7 @@ static u32 hv_copyto_ringbuffer(
return start_write_offset;
 }
 
-/*
- *
- * hv_ringbuffer_get_debuginfo()
- *
- * Get various debug metrics for the specified ring buffer
- *
- */
+/* Get various debug metrics for the specified ring buffer. */
 void hv_ringbuffer_get_debuginfo(struct hv_ring_buffer_info *ring_info,
struct hv_ring_buffer_debug_info *debug_info)
 {
@@ -337,13 +283,7 @@ void

[PATCH v2 3/5] Drivers: hv: ring_buffer: remove code duplication from hv_ringbuffer_peek/read()

2015-12-08 Thread Vitaly Kuznetsov

hv_ringbuffer_peek() does the same as hv_ringbuffer_read() without
advancing the read index. The only functional change this patch brings
is moving hv_need_to_signal_on_read() call under the ring_lock but this
function is just a couple of comparisons.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/hv/ring_buffer.c | 68 ++--
 1 file changed, 25 insertions(+), 43 deletions(-)

diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 7bca513..07f9408 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -380,47 +380,9 @@ int hv_ringbuffer_write(struct hv_ring_buffer_info 
*outring_info,
return 0;
 }
 
-
-/* Read without advancing the read index. */
-int hv_ringbuffer_peek(struct hv_ring_buffer_info *Inring_info,
-  void *Buffer, u32 buflen)
-{
-   u32 bytes_avail_towrite;
-   u32 bytes_avail_toread;
-   u32 next_read_location = 0;
-   unsigned long flags;
-
-   spin_lock_irqsave(&Inring_info->ring_lock, flags);
-
-   hv_get_ringbuffer_availbytes(Inring_info,
-   &bytes_avail_toread,
-   &bytes_avail_towrite);
-
-   /* Make sure there is something to read */
-   if (bytes_avail_toread < buflen) {
-
-   spin_unlock_irqrestore(&Inring_info->ring_lock, flags);
-
-   return -EAGAIN;
-   }
-
-   /* Convert to byte offset */
-   next_read_location = hv_get_next_read_location(Inring_info);
-
-   next_read_location = hv_copyfrom_ringbuffer(Inring_info,
-   Buffer,
-   buflen,
-   next_read_location);
-
-   spin_unlock_irqrestore(&Inring_info->ring_lock, flags);
-
-   return 0;
-}
-
-
-/* Read and advance the read index. */
-int hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info, void *buffer,
-  u32 buflen, u32 offset, bool *signal)
+static inline int __hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info,
+  void *buffer, u32 buflen, u32 offset,
+  bool *signal, bool advance)
 {
u32 bytes_avail_towrite;
u32 bytes_avail_toread;
@@ -452,6 +414,9 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
*inring_info, void *buffer,
buflen,
next_read_location);
 
+   if (!advance)
+   goto out_unlock;
+
next_read_location = hv_copyfrom_ringbuffer(inring_info,
&prev_indices,
sizeof(u64),
@@ -467,9 +432,26 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
*inring_info, void *buffer,
/* Update the read index */
hv_set_next_read_location(inring_info, next_read_location);
 
-   spin_unlock_irqrestore(&inring_info->ring_lock, flags);
-
*signal = hv_need_to_signal_on_read(bytes_avail_towrite, inring_info);
 
+out_unlock:
+   spin_unlock_irqrestore(&inring_info->ring_lock, flags);
return 0;
 }
+
+/* Read from ring buffer without advancing the read index. */
+int hv_ringbuffer_peek(struct hv_ring_buffer_info *inring_info,
+  void *buffer, u32 buflen)
+{
+   return __hv_ringbuffer_read(inring_info, buffer, buflen,
+   0, NULL, false);
+}
+
+/* Read from ring buffer and advance the read index. */
+int hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info,
+  void *buffer, u32 buflen, u32 offset,
+  bool *signal)
+{
+   return __hv_ringbuffer_read(inring_info, buffer, buflen,
+   offset, signal, true);
+}
-- 
2.4.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 4/5] Drivers: hv: remove code duplication between vmbus_recvpacket()/vmbus_recvpacket_raw()

2015-12-08 Thread Vitaly Kuznetsov

vmbus_recvpacket() and vmbus_recvpacket_raw() are almost identical but
there are two discrepancies:
1) vmbus_recvpacket() doesn't propagate errors from hv_ringbuffer_read()
   which looks like it is not desired.
2) There is an error message printed in packetlen > bufferlen case in
   vmbus_recvpacket(). I'm removing it as it is usless for users to see
   such messages and /vmbus_recvpacket_raw() doesn't have it.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/hv/channel.c | 65 ++--
 1 file changed, 22 insertions(+), 43 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index c4dcab0..c72271d 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -881,8 +881,10 @@ EXPORT_SYMBOL_GPL(vmbus_sendpacket_multipagebuffer);
  *
  * Mainly used by Hyper-V drivers.
  */
-int vmbus_recvpacket(struct vmbus_channel *channel, void *buffer,
-   u32 bufferlen, u32 *buffer_actual_len, u64 *requestid)
+static inline int
+__vmbus_recvpacket(struct vmbus_channel *channel, void *buffer,
+  u32 bufferlen, u32 *buffer_actual_len, u64 *requestid,
+  bool raw)
 {
struct vmpacket_descriptor desc;
u32 packetlen;
@@ -900,27 +902,34 @@ int vmbus_recvpacket(struct vmbus_channel *channel, void 
*buffer,
return 0;
 
packetlen = desc.len8 << 3;
-   userlen = packetlen - (desc.offset8 << 3);
+   if (!raw)
+   userlen = packetlen - (desc.offset8 << 3);
+   else
+   userlen = packetlen;
 
*buffer_actual_len = userlen;
 
-   if (userlen > bufferlen) {
-
-   pr_err("Buffer too small - got %d needs %d\n",
-  bufferlen, userlen);
-   return -ETOOSMALL;
-   }
+   if (userlen > bufferlen)
+   return -ENOBUFS;
 
*requestid = desc.trans_id;
 
/* Copy over the packet to the user buffer */
ret = hv_ringbuffer_read(&channel->inbound, buffer, userlen,
-(desc.offset8 << 3), &signal);
+raw ? 0 : desc.offset8 << 3, &signal);
 
if (signal)
vmbus_setevent(channel);
 
-   return 0;
+   return ret;
+}
+
+int vmbus_recvpacket(struct vmbus_channel *channel, void *buffer,
+u32 bufferlen, u32 *buffer_actual_len,
+u64 *requestid)
+{
+   return __vmbus_recvpacket(channel, buffer, bufferlen,
+ buffer_actual_len, requestid, false);
 }
 EXPORT_SYMBOL(vmbus_recvpacket);
 
@@ -931,37 +940,7 @@ int vmbus_recvpacket_raw(struct vmbus_channel *channel, 
void *buffer,
  u32 bufferlen, u32 *buffer_actual_len,
  u64 *requestid)
 {
-   struct vmpacket_descriptor desc;
-   u32 packetlen;
-   int ret;
-   bool signal = false;
-
-   *buffer_actual_len = 0;
-   *requestid = 0;
-
-
-   ret = hv_ringbuffer_peek(&channel->inbound, &desc,
-sizeof(struct vmpacket_descriptor));
-   if (ret != 0)
-   return 0;
-
-
-   packetlen = desc.len8 << 3;
-
-   *buffer_actual_len = packetlen;
-
-   if (packetlen > bufferlen)
-   return -ENOBUFS;
-
-   *requestid = desc.trans_id;
-
-   /* Copy over the entire packet to the user buffer */
-   ret = hv_ringbuffer_read(&channel->inbound, buffer, packetlen, 0,
-&signal);
-
-   if (signal)
-   vmbus_setevent(channel);
-
-   return ret;
+   return __vmbus_recvpacket(channel, buffer, bufferlen,
+ buffer_actual_len, requestid, true);
 }
 EXPORT_SYMBOL_GPL(vmbus_recvpacket_raw);
-- 
2.4.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 2/5] Drivers: hv: ring_buffer: remove stray smp_read_barrier_depends()

2015-12-08 Thread Vitaly Kuznetsov

smp_read_barrier_depends() does nothing on almost all arcitectures
including x86 and having it in the beginning of
hv_get_ringbuffer_availbytes() does not provide any guarantees anyway.

Signed-off-by: Vitaly Kuznetsov 
---
 include/linux/hyperv.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 8fdc17b..1777dc8 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -141,8 +141,6 @@ hv_get_ringbuffer_availbytes(struct hv_ring_buffer_info 
*rbi,
 {
u32 read_loc, write_loc, dsize;
 
-   smp_read_barrier_depends();
-
/* Capture the read/write indices before they changed */
read_loc = rbi->ring_buffer->read_index;
write_loc = rbi->ring_buffer->write_index;
-- 
2.4.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 5/5] Drivers: hv: ring_buffer: eliminate hv_ringbuffer_peek()

2015-12-08 Thread Vitaly Kuznetsov

Currently, there is only one user for hv_ringbuffer_read()/
hv_ringbuffer_peak() functions and the usage of these functions is:
- insecure as we drop ring_lock between them, someone else (in theory
  only) can acquire it in between;
- non-optimal as we do a number of things (acquire/release the above
  mentioned lock, calculate available space on the ring, ...) twice and
  this path is performance-critical.

Remove hv_ringbuffer_peek() moving the logic from __vmbus_recvpacket() to
hv_ringbuffer_read().

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/hv/channel.c  | 30 ++
 drivers/hv/hyperv_vmbus.h | 11 +++-
 drivers/hv/ring_buffer.c  | 65 +++
 3 files changed, 42 insertions(+), 64 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index c72271d..a4c800d 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -886,37 +886,11 @@ __vmbus_recvpacket(struct vmbus_channel *channel, void 
*buffer,
   u32 bufferlen, u32 *buffer_actual_len, u64 *requestid,
   bool raw)
 {
-   struct vmpacket_descriptor desc;
-   u32 packetlen;
-   u32 userlen;
int ret;
bool signal = false;
 
-   *buffer_actual_len = 0;
-   *requestid = 0;
-
-
-   ret = hv_ringbuffer_peek(&channel->inbound, &desc,
-sizeof(struct vmpacket_descriptor));
-   if (ret != 0)
-   return 0;
-
-   packetlen = desc.len8 << 3;
-   if (!raw)
-   userlen = packetlen - (desc.offset8 << 3);
-   else
-   userlen = packetlen;
-
-   *buffer_actual_len = userlen;
-
-   if (userlen > bufferlen)
-   return -ENOBUFS;
-
-   *requestid = desc.trans_id;
-
-   /* Copy over the packet to the user buffer */
-   ret = hv_ringbuffer_read(&channel->inbound, buffer, userlen,
-raw ? 0 : desc.offset8 << 3, &signal);
+   ret = hv_ringbuffer_read(&channel->inbound, buffer, bufferlen,
+buffer_actual_len, requestid, &signal, raw);
 
if (signal)
vmbus_setevent(channel);
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 3782636..d5ee081 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -614,14 +614,9 @@ int hv_ringbuffer_write(struct hv_ring_buffer_info 
*ring_info,
struct kvec *kv_list,
u32 kv_count, bool *signal);
 
-int hv_ringbuffer_peek(struct hv_ring_buffer_info *ring_info, void *buffer,
-  u32 buflen);
-
-int hv_ringbuffer_read(struct hv_ring_buffer_info *ring_info,
-  void *buffer,
-  u32 buflen,
-  u32 offset, bool *signal);
-
+int hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info,
+  void *buffer, u32 buflen, u32 *buffer_actual_len,
+  u64 *requestid, bool *signal, bool raw);
 
 void hv_ringbuffer_get_debuginfo(struct hv_ring_buffer_info *ring_info,
struct hv_ring_buffer_debug_info *debug_info);
diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 07f9408..b53702c 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -380,30 +380,59 @@ int hv_ringbuffer_write(struct hv_ring_buffer_info 
*outring_info,
return 0;
 }
 
-static inline int __hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info,
-  void *buffer, u32 buflen, u32 offset,
-  bool *signal, bool advance)
+int hv_ringbuffer_read(struct hv_ring_buffer_info *inring_info,
+  void *buffer, u32 buflen, u32 *buffer_actual_len,
+  u64 *requestid, bool *signal, bool raw)
 {
u32 bytes_avail_towrite;
u32 bytes_avail_toread;
u32 next_read_location = 0;
u64 prev_indices = 0;
unsigned long flags;
+   struct vmpacket_descriptor desc;
+   u32 offset;
+   u32 packetlen;
+   int ret = 0;
 
if (buflen <= 0)
return -EINVAL;
 
spin_lock_irqsave(&inring_info->ring_lock, flags);
 
+   *buffer_actual_len = 0;
+   *requestid = 0;
+
hv_get_ringbuffer_availbytes(inring_info,
&bytes_avail_toread,
&bytes_avail_towrite);
 
/* Make sure there is something to read */
-   if (bytes_avail_toread < buflen) {
-   spin_unlock_irqrestore(&inring_info->ring_lock, flags);
+   if (bytes_avail_toread < sizeof(desc)) {
+   /*
+* No error is set when there is even no header, drivers are
+* supposed to analyze buffer_actual_len.
+*/
+   goto out_unlock;
+   }
 
-   return -EAGAIN;
+   next_read_location = hv_get_next_read_location(inr

Re: [PATCH v8 36/55] [media] davinci_vbpe: stop MEDIA_ENT_T_V4L2_SUBDEV abuse

2015-12-08 Thread Mauro Carvalho Chehab

Em Sun, 06 Dec 2015 03:52:01 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> Thank you for the patch.
> 
> On Sunday 30 August 2015 00:06:47 Mauro Carvalho Chehab wrote:
> > This driver is abusing MEDIA_ENT_T_V4L2_SUBDEV:
> > 
> > - it uses a hack to check if the remote entity is a subdev;
> 
> Same comment as for "omap4iss: stop MEDIA_ENT_T_V4L2_SUBDEV abuse", this 
> isn't 
> a hack.
> 
> > - it still uses the legacy entity subtype check macro, that
> >   will be removed soon.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > 
> > diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> > b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c index
> > b89a057b8b7e..7fd78329e3e1 100644
> > --- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> > +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> > @@ -1711,8 +1711,11 @@ ipipe_link_setup(struct media_entity *entity, const
> > struct media_pad *local, struct vpfe_device *vpfe_dev =
> > to_vpfe_device(ipipe);
> > u16 ipipeif_sink = vpfe_dev->vpfe_ipipeif.input;
> > 
> > -   switch (local->index | media_entity_type(remote->entity)) {
> > -   case IPIPE_PAD_SINK | MEDIA_ENT_T_V4L2_SUBDEV:
> > +   if (!is_media_entity_v4l2_subdev(remote->entity))
> > +   return -EINVAL;
> 
> You can drop the check (even though the implementation in the switch looks 
> dubious to me, but that's not your fault).

I prefer to keep the above check, as it shouldn't hurt. 

As I said on a previous comment on your reviews, if someone adds later
some non-V4L2 entities to the media pipeline where the DaVinci media
driver belongs, it could be a problem without the above check.

> 
> > +   switch (local->index) {
> > +   case IPIPE_PAD_SINK:
> > if (!(flags & MEDIA_LNK_FL_ENABLED)) {
> > ipipe->input = IPIPE_INPUT_NONE;
> > break;
> > @@ -1725,7 +1728,7 @@ ipipe_link_setup(struct media_entity *entity, const
> > struct media_pad *local, ipipe->input = IPIPE_INPUT_CCDC;
> > break;
> > 
> > -   case IPIPE_PAD_SOURCE | MEDIA_ENT_T_V4L2_SUBDEV:
> > +   case IPIPE_PAD_SOURCE:
> > /* out to RESIZER */
> > if (flags & MEDIA_LNK_FL_ENABLED)
> > ipipe->output = IPIPE_OUTPUT_RESIZER;
> > diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> > b/drivers/staging/media/davinci_vpfe/vpfe_video.c index
> > 9eef64e0f0ab..2dbf14b9bb5f 100644
> > --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> > +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> > @@ -88,7 +88,7 @@ vpfe_video_remote_subdev(struct vpfe_video_device *video,
> > u32 *pad) {
> > struct media_pad *remote = media_entity_remote_pad(&video->pad);
> > 
> > -   if (remote == NULL || remote->entity->type != MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!remote || !is_media_entity_v4l2_subdev(remote->entity))
> > return NULL;
> > if (pad)
> > *pad = remote->index;
> > @@ -243,8 +243,7 @@ static int vpfe_video_validate_pipeline(struct
> > vpfe_pipeline *pipe)
> > 
> > /* Retrieve the source format */
> > pad = media_entity_remote_pad(pad);
> > -   if (pad == NULL ||
> > -   pad->entity->type != MEDIA_ENT_T_V4L2_SUBDEV)
> > +   if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > break;
> > 
> > subdev = media_entity_to_v4l2_subdev(pad->entity);
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v8 37/55] [media] omap4iss: stop MEDIA_ENT_T_V4L2_SUBDEV abuse

2015-12-08 Thread Mauro Carvalho Chehab

Em Sun, 06 Dec 2015 03:46:28 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> Thank you for the patch.
> 
> On Sunday 30 August 2015 00:06:48 Mauro Carvalho Chehab wrote:
> > This driver is abusing MEDIA_ENT_T_V4L2_SUBDEV, as it uses a
> > hack to check if the remote entity is a subdev. Get rid of it.
> 
> While I agree with the idea of the patch I don't think this is a hack, it was 
> a totally valid implementation with the existing API.
> 
> > Signed-off-by: Mauro Carvalho Chehab 
> > 
> > diff --git a/drivers/staging/media/omap4iss/iss_ipipe.c
> > b/drivers/staging/media/omap4iss/iss_ipipe.c index
> > e1a7b7ba7362..eb91ec48a21e 100644
> > --- a/drivers/staging/media/omap4iss/iss_ipipe.c
> > +++ b/drivers/staging/media/omap4iss/iss_ipipe.c
> > @@ -447,8 +447,11 @@ static int ipipe_link_setup(struct media_entity
> > *entity, struct iss_ipipe_device *ipipe = v4l2_get_subdevdata(sd);
> > struct iss_device *iss = to_iss_device(ipipe);
> > 
> > -   switch (local->index | media_entity_type(remote->entity)) {
> > -   case IPIPE_PAD_SINK | MEDIA_ENT_T_V4L2_SUBDEV:
> > +   if (!is_media_entity_v4l2_subdev(remote->entity))
> > +   return -EINVAL;
> > +
> 
> Furthermore the ipipe entity is never connected to anything else than a 
> subdev, so you can remove this check completely.
> 
> I'd rewrite the subject line as "omap4iss: ipipe: Don't check entity type 
> needlessly during link setup" and update the commit message accordingly.


The same rationale as patch 36/55: if one would later add some other
subsystem to the pipeline, the check will be needed. So, better to have
the check here.

I'm changing the description of this patch to:

[media] omap4iss: change the logic that checks if an entity is a subdev

As we're getting rid of an specific number range for the V4L2 subdev,
we need to replace the check for MEDIA_ENT_T_V4L2_SUBDEV by a macro.

Signed-off-by: Mauro Carvalho Chehab 

> 
> > +   switch (local->index) {
> > +   case IPIPE_PAD_SINK:
> > /* Read from IPIPEIF. */
> > if (!(flags & MEDIA_LNK_FL_ENABLED)) {
> > ipipe->input = IPIPE_INPUT_NONE;
> > @@ -463,7 +466,7 @@ static int ipipe_link_setup(struct media_entity *entity,
> > 
> > break;
> > 
> > -   case IPIPE_PAD_SOURCE_VP | MEDIA_ENT_T_V4L2_SUBDEV:
> > +   case IPIPE_PAD_SOURCE_VP:
> > /* Send to RESIZER */
> > if (flags & MEDIA_LNK_FL_ENABLED) {
> > if (ipipe->output & ~IPIPE_OUTPUT_VP)
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: lustre: add __user attributes to llite/file.c

2015-12-08 Thread Wim de With

This fixes the following sparse warnings:

drivers/staging/lustre/lustre/llite/file.c:1310:38:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:1310:38:got struct 
ll_recreate_obj *
drivers/staging/lustre/lustre/llite/file.c:1328:35: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1328:35:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:1328:35:got struct lu_fid 
*
drivers/staging/lustre/lustre/llite/file.c:1475:35: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1475:35:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:1475:35:got struct 
lov_user_md_v1 *
drivers/staging/lustre/lustre/llite/file.c:1500:35: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1500:35:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:1500:35:got struct 
lov_user_md_v1 *lumv1p
drivers/staging/lustre/lustre/llite/file.c:1505:44: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1505:44:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:1505:44:got struct 
lov_user_md_v3 *lumv3p
drivers/staging/lustre/lustre/llite/file.c:1516:17: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1516:17:expected void const 
volatile [noderef] *
drivers/staging/lustre/lustre/llite/file.c:1516:17:got unsigned short 
*
drivers/staging/lustre/lustre/llite/file.c:1829:27: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1829:27:expected void [noderef] 
*to
drivers/staging/lustre/lustre/llite/file.c:1829:27:got void *
drivers/staging/lustre/lustre/llite/file.c:2214:24: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2214:24:expected void const 
volatile [noderef] *
drivers/staging/lustre/lustre/llite/file.c:2214:24:got int *
drivers/staging/lustre/lustre/llite/file.c:2221:21: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2221:21:expected void const 
volatile [noderef] *
drivers/staging/lustre/lustre/llite/file.c:2221:21:got int *
drivers/staging/lustre/lustre/llite/file.c:2245:43: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2245:43:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:2245:43:got char *
drivers/staging/lustre/lustre/llite/file.c:2275:24: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2275:24:expected void const 
volatile [noderef] *
drivers/staging/lustre/lustre/llite/file.c:2275:24:got int *
drivers/staging/lustre/lustre/llite/file.c:2292:35: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2292:35:expected void [noderef] 
*to
drivers/staging/lustre/lustre/llite/file.c:2292:35:got void *
drivers/staging/lustre/lustre/llite/file.c:2299:44: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2299:44:expected void [noderef] 
*arg
drivers/staging/lustre/lustre/llite/file.c:2299:44:got void *
drivers/staging/lustre/lustre/llite/file.c:2304:43: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2304:43:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:2304:43:got char *
drivers/staging/lustre/lustre/llite/file.c:2310:46: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2310:46:expected void [noderef] 
*to
drivers/staging/lustre/lustre/llite/file.c:2310:46:got char *
drivers/staging/lustre/lustre/llite/file.c:2323:21: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2323:21:expected void const 
volatile [noderef] *
drivers/staging/lustre/lustre/llite/file.c:2323:21:got int *
drivers/staging/lustre/lustre/llite/file.c:2350:35: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2350:35:expected void [noderef] 
*to
drivers/staging/lustre/lustre/llite/file.c:2350:35:got void *
drivers/staging/lustre/lustre/llite/file.c:2361:36: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2361:36:expected void const 
[noderef] *
drivers/staging/lustre/lustre/llite/file.c:2361:36:got char *
drivers/staging/lustre

Re: [PATCH v7 7/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs

2015-12-08 Thread Thomas Gleixner

On Sat, 5 Dec 2015, ja...@microsoft.com wrote:

> From: Jake Oshins 
> 
> This patch introduces a new driver which exposes a root PCI bus whenever a
> PCI Express device is passed through to a guest VM under Hyper-V. The
> device can be single- or multi-function. The interrupts for the devices
> are managed by an IRQ domain, implemented within the driver.
> 
> Signed-off-by: Jake Oshins 

For the irq related parts of this:

Reviewed-by: Thomas Gleixner 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v7 3/7] PCI: Make it possible to implement a PCI MSI IRQ Domain in a module.

2015-12-08 Thread Thomas Gleixner

On Sat, 5 Dec 2015, ja...@microsoft.com wrote:
> From: Jake Oshins 
> 
> The Linux kernel already has the concpet of IRQ domain, wherein a
> component can expose a set of IRQs which are managed by a particular
> interrupt controller chip or other subsystem. The PCI driver exposes
> the notion of an IRQ domain for Message-Signaled Interrupts (MSI) from
> PCI Express devices. This patch exposes the functions which are
> necessary for making an MSI IRQ domain within a module.
> 
> Signed-off-by: Jake Oshins 

As the reset of the series depends on this:

Reviewed-by: Thomas Gleixner 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: unisys: fix potential format string leak

2015-12-08 Thread Kees Cook

Since "name" is always used directly, force "%s" for the kthread
format string to avoid any potential format string leaks.

Signed-off-by: Kees Cook 
---
 drivers/staging/unisys/visorhba/visorhba_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c 
b/drivers/staging/unisys/visorhba/visorhba_main.c
index c119f20dfd44..89712144f804 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -167,7 +167,7 @@ static int visor_thread_start(struct visor_thread_info 
*thrinfo,
 {
/* used to stop the thread */
init_completion(&thrinfo->has_stopped);
-   thrinfo->task = kthread_run(threadfn, thrcontext, name);
+   thrinfo->task = kthread_run(threadfn, thrcontext, "%s", name);
if (IS_ERR(thrinfo->task)) {
thrinfo->id = 0;
return PTR_ERR(thrinfo->task);
-- 
1.9.1


-- 
Kees Cook
Chrome OS & Brillo Security
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 0/5] Clean up SDMA engine code

2015-12-08 Thread ira . weiny

From: Ira Weiny 

Various improvements to the SDMA engine code.

---
Changes from V1:
Fix off by one error in the last patch

Mitko Haralanov (5):
  staging/rdma/hfi1: Convert to use get_user_pages_fast
  staging/rdma/hfi1: Unconditionally clean-up SDMA queues
  staging/rdma/hfi1: Clean-up unnecessary goto statements
  staging/rdma/hfi1: Detect SDMA transmission error early
  staging/rdma/hfi1: Add page lock limit check for SDMA requests

 drivers/staging/rdma/hfi1/file_ops.c   |  11 +-
 drivers/staging/rdma/hfi1/hfi.h|   4 +-
 drivers/staging/rdma/hfi1/user_pages.c |  97 +++---
 drivers/staging/rdma/hfi1/user_sdma.c  | 319 +++--
 drivers/staging/rdma/hfi1/user_sdma.h  |   2 +
 5 files changed, 222 insertions(+), 211 deletions(-)

-- 
1.8.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 3/5] staging/rdma/hfi1: Clean-up unnecessary goto statements

2015-12-08 Thread ira . weiny

From: Mitko Haralanov 

Clean-up unnecessary goto statements based on feedback from the
mailing list on previous patch submissions.

Reviewed-by: Ira Weiny 
Signed-off-by: Mitko Haralanov 
---
 drivers/staging/rdma/hfi1/user_sdma.c | 37 +--
 1 file changed, 14 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/rdma/hfi1/user_sdma.c 
b/drivers/staging/rdma/hfi1/user_sdma.c
index 41408f82afe8..060c2200757d 100644
--- a/drivers/staging/rdma/hfi1/user_sdma.c
+++ b/drivers/staging/rdma/hfi1/user_sdma.c
@@ -505,15 +505,13 @@ int hfi1_user_sdma_process_request(struct file *fp, 
struct iovec *iovec,
   "[%u:%u:%u] First vector not big enough for header %lu/%lu",
   dd->unit, uctxt->ctxt, fd->subctxt,
   iovec[idx].iov_len, sizeof(info) + sizeof(req->hdr));
-   ret = -EINVAL;
-   goto done;
+   return -EINVAL;
}
ret = copy_from_user(&info, iovec[idx].iov_base, sizeof(info));
if (ret) {
hfi1_cdbg(SDMA, "[%u:%u:%u] Failed to copy info QW (%d)",
  dd->unit, uctxt->ctxt, fd->subctxt, ret);
-   ret = -EFAULT;
-   goto done;
+   return -EFAULT;
}
trace_hfi1_sdma_user_reqinfo(dd, uctxt->ctxt, fd->subctxt,
 (u16 *)&info);
@@ -521,15 +519,13 @@ int hfi1_user_sdma_process_request(struct file *fp, 
struct iovec *iovec,
hfi1_cdbg(SDMA, "[%u:%u:%u] Entry %u is in QUEUED state",
  dd->unit, uctxt->ctxt, fd->subctxt,
  info.comp_idx);
-   ret = -EBADSLT;
-   goto done;
+   return -EBADSLT;
}
if (!info.fragsize) {
hfi1_cdbg(SDMA,
  "[%u:%u:%u:%u] Request does not specify fragsize",
  dd->unit, uctxt->ctxt, fd->subctxt, info.comp_idx);
-   ret = -EINVAL;
-   goto done;
+   return -EINVAL;
}
/*
 * We've done all the safety checks that we can up to this point,
@@ -554,8 +550,7 @@ int hfi1_user_sdma_process_request(struct file *fp, struct 
iovec *iovec,
if (!info.npkts || req->data_iovs > MAX_VECTORS_PER_REQ) {
SDMA_DBG(req, "Too many vectors (%u/%u)", req->data_iovs,
 MAX_VECTORS_PER_REQ);
-   ret = -EINVAL;
-   goto done;
+   return -EINVAL;
}
/* Copy the header from the user buffer */
ret = copy_from_user(&req->hdr, iovec[idx].iov_base + sizeof(info),
@@ -782,10 +777,8 @@ static int user_sdma_send_pkts(struct user_sdma_request 
*req, unsigned maxpkts)
struct hfi1_user_sdma_pkt_q *pq = NULL;
struct user_sdma_iovec *iovec = NULL;
 
-   if (!req->pq) {
-   ret = -EINVAL;
-   goto done;
-   }
+   if (!req->pq)
+   return -EINVAL;
 
pq = req->pq;
 
@@ -795,7 +788,7 @@ static int user_sdma_send_pkts(struct user_sdma_request 
*req, unsigned maxpkts)
if (unlikely(req->seqnum == req->info.npkts)) {
if (!list_empty(&req->txps))
goto dosend;
-   goto done;
+   return ret;
}
 
if (!maxpkts || maxpkts > req->info.npkts - req->seqnum)
@@ -812,15 +805,13 @@ static int user_sdma_send_pkts(struct user_sdma_request 
*req, unsigned maxpkts)
 */
if (test_bit(SDMA_REQ_HAS_ERROR, &req->flags)) {
set_bit(SDMA_REQ_DONE_ERROR, &req->flags);
-   ret = -EFAULT;
-   goto done;
+   return -EFAULT;
}
 
tx = kmem_cache_alloc(pq->txreq_cache, GFP_KERNEL);
-   if (!tx) {
-   ret = -ENOMEM;
-   goto done;
-   }
+   if (!tx)
+   return -ENOMEM;
+
tx->flags = 0;
tx->req = req;
tx->busycount = 0;
@@ -1021,12 +1012,12 @@ dosend:
if (test_bit(SDMA_REQ_HAVE_AHG, &req->flags))
sdma_ahg_free(req->sde, req->ahg_idx);
}
-   goto done;
+   return ret;
+
 free_txreq:
sdma_txclean(pq->dd, &tx->txreq);
 free_tx:
kmem_cache_free(pq->txreq_cache, tx);
-done:
return ret;
 }
 
-- 
1.8.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 1/5] staging/rdma/hfi1: Convert to use get_user_pages_fast

2015-12-08 Thread ira . weiny

From: Mitko Haralanov 

Convert hfi1_get_user_pages() to use get_user_pages_fast(),
which is much fatster. The mm semaphore is still taken to
update the pinned page count but is for a much shorter
amount of time.

Reviewed-by: Ira Weiny 
Signed-off-by: Mitko Haralanov 
---
 drivers/staging/rdma/hfi1/file_ops.c   |  8 +--
 drivers/staging/rdma/hfi1/hfi.h|  4 +-
 drivers/staging/rdma/hfi1/user_pages.c | 97 +-
 3 files changed, 32 insertions(+), 77 deletions(-)

diff --git a/drivers/staging/rdma/hfi1/file_ops.c 
b/drivers/staging/rdma/hfi1/file_ops.c
index 22037ce984c8..76580030f514 100644
--- a/drivers/staging/rdma/hfi1/file_ops.c
+++ b/drivers/staging/rdma/hfi1/file_ops.c
@@ -1670,8 +1670,8 @@ static int exp_tid_setup(struct file *fp, struct 
hfi1_tid_info *tinfo)
 * Now that we know how many free RcvArray entries we have,
 * we can pin that many user pages.
 */
-   ret = hfi1_get_user_pages(vaddr + (mapped * PAGE_SIZE),
- pinned, pages);
+   ret = hfi1_acquire_user_pages(vaddr + (mapped * PAGE_SIZE),
+ pinned, true, pages);
if (ret) {
/*
 * We can't continue because the pages array won't be
@@ -1840,7 +1840,7 @@ static int exp_tid_free(struct file *fp, struct 
hfi1_tid_info *tinfo)
}
}
flush_wc();
-   hfi1_release_user_pages(pshadow, pcount);
+   hfi1_release_user_pages(pshadow, pcount, true);
clear_bit(bitidx, &uctxt->tidusemap[idx]);
map &= ~(1ULLtid_pg_list[tid] = NULL;
pci_unmap_page(dd->pcidev, phys, PAGE_SIZE, PCI_DMA_FROMDEVICE);
-   hfi1_release_user_pages(&p, 1);
+   hfi1_release_user_pages(&p, 1, true);
}
 }
 
diff --git a/drivers/staging/rdma/hfi1/hfi.h b/drivers/staging/rdma/hfi1/hfi.h
index 54ed6b36c1a7..467e1a9f8ed2 100644
--- a/drivers/staging/rdma/hfi1/hfi.h
+++ b/drivers/staging/rdma/hfi1/hfi.h
@@ -1551,8 +1551,8 @@ void hfi1_set_led_override(struct hfi1_pportdata *ppd, 
unsigned int val);
  */
 #define DEFAULT_RCVHDR_ENTSIZE 32
 
-int hfi1_get_user_pages(unsigned long, size_t, struct page **);
-void hfi1_release_user_pages(struct page **, size_t);
+int hfi1_acquire_user_pages(unsigned long, size_t, bool, struct page **);
+void hfi1_release_user_pages(struct page **, size_t, bool);
 
 static inline void clear_rcvhdrtail(const struct hfi1_ctxtdata *rcd)
 {
diff --git a/drivers/staging/rdma/hfi1/user_pages.c 
b/drivers/staging/rdma/hfi1/user_pages.c
index 9071afbd7bf4..692de658f0dc 100644
--- a/drivers/staging/rdma/hfi1/user_pages.c
+++ b/drivers/staging/rdma/hfi1/user_pages.c
@@ -49,59 +49,11 @@
  */
 
 #include 
+#include 
 #include 
 
 #include "hfi.h"
 
-static void __hfi1_release_user_pages(struct page **p, size_t num_pages,
- int dirty)
-{
-   size_t i;
-
-   for (i = 0; i < num_pages; i++) {
-   if (dirty)
-   set_page_dirty_lock(p[i]);
-   put_page(p[i]);
-   }
-}
-
-/*
- * Call with current->mm->mmap_sem held.
- */
-static int __hfi1_get_user_pages(unsigned long start_page, size_t num_pages,
-struct page **p)
-{
-   unsigned long lock_limit;
-   size_t got;
-   int ret;
-
-   lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
-
-   if (num_pages > lock_limit && !capable(CAP_IPC_LOCK)) {
-   ret = -ENOMEM;
-   goto bail;
-   }
-
-   for (got = 0; got < num_pages; got += ret) {
-   ret = get_user_pages(current, current->mm,
-start_page + got * PAGE_SIZE,
-num_pages - got, 1, 1,
-p + got, NULL);
-   if (ret < 0)
-   goto bail_release;
-   }
-
-   current->mm->pinned_vm += num_pages;
-
-   ret = 0;
-   goto bail;
-
-bail_release:
-   __hfi1_release_user_pages(p, got, 0);
-bail:
-   return ret;
-}
-
 /**
  * hfi1_map_page - a safety wrapper around pci_map_page()
  *
@@ -116,41 +68,44 @@ dma_addr_t hfi1_map_page(struct pci_dev *hwdev, struct 
page *page,
return phys;
 }
 
-/**
- * hfi1_get_user_pages - lock user pages into memory
- * @start_page: the start page
- * @num_pages: the number of pages
- * @p: the output page structures
- *
- * This function takes a given start page (page aligned user virtual
- * address) and pins it and the following specified number of pages.  For
- * now, num_pages is always 1, but that will probably change at some point
- * (because caller is doing expected sends on a single virtually contiguo

[PATCH v2 5/5] staging/rdma/hfi1: Add page lock limit check for SDMA requests

2015-12-08 Thread ira . weiny

From: Mitko Haralanov 

The driver pins pages on behalf of user processes in two
separate instances - when the process has submitted a
SDMA transfer and when the process programs an expected
receive buffer.

When pinning pages, the driver is required to observe the
locked page limit set by the system administrator and refuse
to lock more pages than allowed. Such a check was done for
expected receives but was missing from the SDMA transfer
code path.

This commit adds the missing check for SDMA transfers. As of
this commit, user SDMA or expected receive requests will be
rejected if the number of pages required to be pinned will
exceed the set limit.

Due to the fact that the driver needs to take the MM semaphore
in order to update the locked page count (which can sleep), this
cannot be done by the callback function as it [the callback] is
executed in interrupt context. Therefore, it is necessary to put
all the completed SDMA tx requests onto a separate list (txcmp) and
offload the actual clean-up and unpinning work to a workqueue.

Reviewed-by: Dennis Dalessandro 
Reviewed-by: Ira Weiny 
Signed-off-by: Mitko Haralanov 

---
Changes from V1:
Fix off by 1 error

 drivers/staging/rdma/hfi1/user_sdma.c | 276 --
 drivers/staging/rdma/hfi1/user_sdma.h |   2 +
 2 files changed, 169 insertions(+), 109 deletions(-)

diff --git a/drivers/staging/rdma/hfi1/user_sdma.c 
b/drivers/staging/rdma/hfi1/user_sdma.c
index 3033df5596f3..d3de771a0770 100644
--- a/drivers/staging/rdma/hfi1/user_sdma.c
+++ b/drivers/staging/rdma/hfi1/user_sdma.c
@@ -214,12 +214,6 @@ struct user_sdma_request {
 */
u8 omfactor;
/*
-* pointer to the user's task_struct. We are going to
-* get a reference to it so we can process io vectors
-* at a later time.
-*/
-   struct task_struct *user_proc;
-   /*
 * pointer to the user's mm_struct. We are going to
 * get a reference to it so it doesn't get freed
 * since we might not be in process context when we
@@ -245,9 +239,13 @@ struct user_sdma_request {
u16 tididx;
u32 sent;
u64 seqnum;
-   spinlock_t list_lock;
struct list_head txps;
+   spinlock_t txcmp_lock;  /* protect txcmp list */
+   struct list_head txcmp;
unsigned long flags;
+   /* status of the last txreq completed */
+   int status;
+   struct work_struct worker;
 };
 
 /*
@@ -260,6 +258,7 @@ struct user_sdma_txreq {
/* Packet header for the txreq */
struct hfi1_pkt_header hdr;
struct sdma_txreq txreq;
+   struct list_head list;
struct user_sdma_request *req;
struct {
struct user_sdma_iovec *vec;
@@ -282,10 +281,12 @@ struct user_sdma_txreq {
 static int user_sdma_send_pkts(struct user_sdma_request *, unsigned);
 static int num_user_pages(const struct iovec *);
 static void user_sdma_txreq_cb(struct sdma_txreq *, int, int);
+static void user_sdma_delayed_completion(struct work_struct *);
 static void user_sdma_free_request(struct user_sdma_request *);
 static int pin_vector_pages(struct user_sdma_request *,
struct user_sdma_iovec *);
-static void unpin_vector_pages(struct user_sdma_iovec *);
+static void unpin_vector_pages(struct user_sdma_request *,
+  struct user_sdma_iovec *);
 static int check_header_template(struct user_sdma_request *,
 struct hfi1_pkt_header *, u32, u32);
 static int set_txreq_header(struct user_sdma_request *,
@@ -391,6 +392,7 @@ int hfi1_user_sdma_alloc_queues(struct hfi1_ctxtdata 
*uctxt, struct file *fp)
pq->n_max_reqs = hfi1_sdma_comp_ring_size;
pq->state = SDMA_PKT_Q_INACTIVE;
atomic_set(&pq->n_reqs, 0);
+   init_waitqueue_head(&pq->wait);
 
iowait_init(&pq->busy, 0, NULL, defer_packet_queue,
activate_packet_queue);
@@ -451,26 +453,16 @@ int hfi1_user_sdma_free_queues(struct hfi1_filedata *fd)
  uctxt->ctxt, fd->subctxt);
pq = fd->pq;
if (pq) {
-   u16 i, j;
-
spin_lock_irqsave(&uctxt->sdma_qlock, flags);
if (!list_empty(&pq->list))
list_del_init(&pq->list);
spin_unlock_irqrestore(&uctxt->sdma_qlock, flags);
iowait_sdma_drain(&pq->busy);
-   if (pq->reqs) {
-   for (i = 0, j = 0; i < atomic_read(&pq->n_reqs) &&
-j < pq->n_max_reqs; j++) {
-   struct user_sdma_request *req = &pq->reqs[j];
-
-   if (test_bit(SDMA_REQ_IN_USE, &req->flags)) {
-   set_comp_state(req, ERROR, -ECOMM);
-   user_sdma_free_request(req);
-   i++;
-   }
-

[PATCH v2 2/5] staging/rdma/hfi1: Unconditionally clean-up SDMA queues

2015-12-08 Thread ira . weiny

From: Mitko Haralanov 

There is no need to cleck if the packet queue is allocated
when cleaning up a user context. The hfi1_user_sdma_free_queues()
function already does all the required checks.

Reviewed-by: Ira Weiny 
Signed-off-by: Mitko Haralanov 
---
 drivers/staging/rdma/hfi1/file_ops.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rdma/hfi1/file_ops.c 
b/drivers/staging/rdma/hfi1/file_ops.c
index 76580030f514..fd90fb658b5b 100644
--- a/drivers/staging/rdma/hfi1/file_ops.c
+++ b/drivers/staging/rdma/hfi1/file_ops.c
@@ -737,8 +737,7 @@ static int hfi1_file_close(struct inode *inode, struct file 
*fp)
 
flush_wc();
/* drain user sdma queue */
-   if (fdata->pq)
-   hfi1_user_sdma_free_queues(fdata);
+   hfi1_user_sdma_free_queues(fdata);
 
/*
 * Clear any left over, unhandled events so the next process that
-- 
1.8.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 4/5] staging/rdma/hfi1: Detect SDMA transmission error early

2015-12-08 Thread ira . weiny

From: Mitko Haralanov 

It is possible for an SDMA transmission error to happen
during the processing of an user SDMA transfer. In that
case it is better to detect it early and abort any further
attempts to send more packets.

Reviewed-by: Ira Weiny 
Signed-off-by: Mitko Haralanov 
---
 drivers/staging/rdma/hfi1/user_sdma.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/staging/rdma/hfi1/user_sdma.c 
b/drivers/staging/rdma/hfi1/user_sdma.c
index 060c2200757d..3033df5596f3 100644
--- a/drivers/staging/rdma/hfi1/user_sdma.c
+++ b/drivers/staging/rdma/hfi1/user_sdma.c
@@ -782,6 +782,12 @@ static int user_sdma_send_pkts(struct user_sdma_request 
*req, unsigned maxpkts)
 
pq = req->pq;
 
+   /* If tx completion has reported an error, we are done. */
+   if (test_bit(SDMA_REQ_HAS_ERROR, &req->flags)) {
+   set_bit(SDMA_REQ_DONE_ERROR, &req->flags);
+   return -EFAULT;
+   }
+
/*
 * Check if we might have sent the entire request already
 */
-- 
1.8.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 bis 12/25] mtd: nand: use the mtd instance embedded in struct nand_chip

2015-12-08 Thread Brian Norris

Hi Boris,

On Wed, Dec 02, 2015 at 09:50:01AM +0100, Boris Brezillon wrote:
> struct nand_chip now embeds an mtd device. Patch all drivers to make use
> of this mtd instance instead of using the instance embedded in their
> private struct or dynamically allocated.
> 
> Signed-off-by: Boris Brezillon 
> Cc: Julia Lawall 
> ---
> Most of those changes were generated with the coccinelle script added
> in commit c671312 "coccinelle: nand: detect and correct drivers embedding
> an mtd_info object"
> ---
> Changes since v2:
> - fix several compilation errors/warnings
> 
>  drivers/mtd/nand/ams-delta.c   | 13 ++--
>  drivers/mtd/nand/atmel_nand.c  | 13 ++--
>  drivers/mtd/nand/au1550nd.c| 19 ++---
>  drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h |  1 -
>  drivers/mtd/nand/bcm47xxnflash/main.c  |  8 ++-
>  drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c   |  2 +-
>  drivers/mtd/nand/bf5xx_nand.c  | 12 ++--
>  drivers/mtd/nand/brcmnand/brcmnand.c   | 13 ++--
>  drivers/mtd/nand/cafe_nand.c   |  8 +--
>  drivers/mtd/nand/cmx270_nand.c | 11 ++-

There's another error here, I think ^^^

>  drivers/mtd/nand/cs553x_nand.c | 13 ++--
>  drivers/mtd/nand/davinci_nand.c| 30 
>  drivers/mtd/nand/denali.c  | 68 ++
>  drivers/mtd/nand/denali.h  |  1 -
>  drivers/mtd/nand/diskonchip.c  | 11 ++-
>  drivers/mtd/nand/docg4.c   | 23 +++---
>  drivers/mtd/nand/fsl_elbc_nand.c   | 26 ---
>  drivers/mtd/nand/fsl_ifc_nand.c| 28 
>  drivers/mtd/nand/fsl_upm.c | 28 
>  drivers/mtd/nand/fsmc_nand.c   | 56 ---
>  drivers/mtd/nand/gpio.c| 20 +++---
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  2 +-
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 23 +++---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  1 -
>  drivers/mtd/nand/hisi504_nand.c| 13 ++--
>  drivers/mtd/nand/jz4740_nand.c |  9 ++-
>  drivers/mtd/nand/lpc32xx_mlc.c |  7 +-
>  drivers/mtd/nand/lpc32xx_slc.c |  7 +-
>  drivers/mtd/nand/mpc5121_nfc.c |  3 +-
>  drivers/mtd/nand/mxc_nand.c|  5 +-
>  drivers/mtd/nand/nandsim.c | 12 ++--
>  drivers/mtd/nand/ndfc.c| 24 ---
>  drivers/mtd/nand/nuc900_nand.c | 24 +++
>  drivers/mtd/nand/omap2.c   | 98 
> +++---
>  drivers/mtd/nand/orion_nand.c  |  4 +-
>  drivers/mtd/nand/pasemi_nand.c | 12 ++--
>  drivers/mtd/nand/plat_nand.c   | 15 ++--
>  drivers/mtd/nand/pxa3xx_nand.c | 33 -
>  drivers/mtd/nand/r852.c| 34 -
>  drivers/mtd/nand/r852.h|  1 -
>  drivers/mtd/nand/s3c2410.c | 23 +++---
>  drivers/mtd/nand/sh_flctl.c|  8 +--
>  drivers/mtd/nand/sharpsl.c | 22 +++---
>  drivers/mtd/nand/socrates_nand.c   |  5 +-
>  drivers/mtd/nand/sunxi_nand.c  | 13 ++--
>  drivers/mtd/nand/tmio_nand.c   | 10 +--
>  drivers/mtd/nand/txx9ndfmc.c   |  3 +-
>  drivers/mtd/nand/vf610_nfc.c   |  8 ++-
>  include/linux/mtd/sh_flctl.h   |  3 +-
>  49 files changed, 432 insertions(+), 394 deletions(-)
> 

...

> diff --git a/drivers/mtd/nand/cmx270_nand.c b/drivers/mtd/nand/cmx270_nand.c
> index 43bded6..84d027e 100644
> --- a/drivers/mtd/nand/cmx270_nand.c
> +++ b/drivers/mtd/nand/cmx270_nand.c
> @@ -160,10 +160,8 @@ static int __init cmx270_init(void)
>   gpio_direction_input(GPIO_NAND_RB);
>  
>   /* Allocate memory for MTD device structure and private data */
> - cmx270_nand_mtd = kzalloc(sizeof(struct mtd_info) +
> -   sizeof(struct nand_chip),
> -   GFP_KERNEL);
> - if (!cmx270_nand_mtd) {
> + this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
> + if (!this) {
>   ret = -ENOMEM;
>   goto err_kzalloc;
>   }
> @@ -175,8 +173,7 @@ static int __init cmx270_init(void)
>   goto err_ioremap;
>   }
>  
> - /* Get pointer to private data */
> - this = (struct nand_chip *)(&cmx270_nand_mtd[1]);
> + cmx270_nand_mtd = nand_to_mtd(this);

So, you make cmx270_nand_mtd no longer kzalloc()'d, but I still see the
cmx270_init() function end with:

err_scan:
iounmap(cmx270_nand_io);
err_ioremap:
kfree(cmx270_nand_mtd);  <- *** this! ***
err_kzalloc:
gpio_free(GPIO_NAND_RB);
err_gpio_request:
gpio_free(GPIO_NAND_CS);

return ret;

}

I have a feel

Re: [PATCH v2 00/13] staging/rdma/hfi1: Driver cleanup and misc fixes

2015-12-08 Thread Jubin John

Hi Greg,

Is this patch series still in your queue? I just wanted to make sure it
didn't get dropped.

Thanks,
Jubin John
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 00/25] mtd: nand: refactor the NAND subsystem (part 1)

2015-12-08 Thread Brian Norris

Hi,

On Tue, Dec 01, 2015 at 12:02:57PM +0100, Boris Brezillon wrote:
> Hello,
> 
> This huge series aims at clarifying the relationship between the mtd and
> nand_chip structures and hiding NAND framework internals to NAND
> controller drivers.
> 
> The first part of the series provide an mtd_to_nand() helper to hide the
> way mtd and nand_chip are linked together.
> 
> The second part of the series embeds the mtd structure into the nand_chip
> one so that NAND controller drivers don't have to bother allocating the
> MTD device and linking it with the NAND chip.
> 
> The last part of the series hides accesses to the chip->priv field behind
> two helper functions.
> 
> This allows removal of some of the boilerplate code done in all NAND
> controller drivers, but most importantly, it unifies a bit the way NAND
> chip structures are instantiated (even though we still have two different
> kinds of drivers: those embedding the nand_chip struct into their private
> nand chip representation, and those allocating two different structures
> and linking them together with the chip->priv field).
> 
> As said in the title, this refactoring is only the first step. I plan to
> rework the NAND controller / NAND chip separation for pretty much the same
> reasons: clarifying the separation between the two concepts, and getting
> rid of more boilerplate code in NAND controller drivers.
> 
> Stay tuned ;-).
> 
> Best Regards,
> 
> Boris
> 
> Changes since v1:
> - dropped already applied patches
> - fixed some typos
> - manually fixed some modifications omitted by the coccinelle scripts
> - manually reworked modifactions done by coccinelle scripts to improve
>   readability and fix coding style issues
> 
> Boris Brezillon (25):
>   ARM: nand: make use of mtd_to_nand() where appropriate

I've sent this (+ the introduction of mtd_to_nand()) in a pull request
to arm-soc, as well as to l2-mtd.git.

>   blackfin: nand: make use of mtd_to_nand() where appropriate
>   cris: nand: make use of mtd_to_nand() where appropriate
>   mips: nand: make use of mtd_to_nand() where appropriate

I've based these on v4.4-rc1 and brought them into l2-mtd.git, in case
any arch/{blackfin,cris,mips}/ people want to pull them in too.

>   sh: nand: make use of mtd_to_nand() where appropriate
>   mtd: nand: make use of mtd_to_nand() in NAND core code
>   mtd: nand: make use of mtd_to_nand() in NAND drivers
>   staging: mt29f_spinand: make use of mtd_to_nand()
>   mtd: nand: embed an mtd_info structure into nand_chip
>   mtd: nand: add nand_to_mtd() helper

Pulled the rest up to here into l2-mtd.git.

>   coccinelle: nand: detect and correct drivers embedding an mtd_info
> object

I believe Julia had comments on this. That probably would go through the
kbuild tree in the end anyway (?).

>   mtd: nand: use the mtd instance embedded in struct nand_chip

There's still at least one problem in this patch (commented on the
patch). It touches a lot of drivers, so any extra review would be great.

>   mtd: nand: update the documentation to reflect framework changes
>   staging: mt29f_spinand: use the mtd instance embedded in struct
> nand_chip
>   cris: nand: use the mtd instance embedded in struct nand_chip
>   mtd: nand: update mtd_to_nand()
>   mtd: nand: remove useless mtd->priv = chip assignments
>   cris: nand: remove useless mtd->priv = chip assignments
>   staging: mt29f_spinand: remove useless mtd->priv = chip assignment
>   mtd: nand: simplify nand_dt_init() usage
>   mtd: nand: kill the chip->flash_node field
>   mtd: nand: add helpers to access ->priv
>   ARM: make use of nand_set/get_controller_data() helpers
>   mtd: nand: make use of nand_set/get_controller_data() helpers
>   staging: mt29f_spinand: make use of nand_set/get_controller_data()
> helpers

All the rest look good to me. I'll wait until I get a good copy of patch
12 before taking them.

Brian

>  Documentation/DocBook/mtdnand.tmpl |  31 +++---
>  arch/arm/mach-ep93xx/snappercl15.c |   4 +-
>  arch/arm/mach-ep93xx/ts72xx.c  |   4 +-
>  arch/arm/mach-imx/mach-qong.c  |   2 +-
>  arch/arm/mach-ixp4xx/ixdp425-setup.c   |   6 +-
>  arch/arm/mach-omap1/board-nand.c   |   2 +-
>  arch/arm/mach-orion5x/ts78xx-setup.c   |   6 +-
>  arch/arm/mach-pxa/balloon3.c   |   2 +-
>  arch/arm/mach-pxa/em-x270.c|   2 +-
>  arch/arm/mach-pxa/palmtx.c |   2 +-
>  arch/blackfin/mach-bf537/boards/stamp.c|   2 +-
>  arch/blackfin/mach-bf561/boards/acvilon.c  |   2 +-
>  arch/cris/arch-v32/drivers/mach-a3/nandflash.c |   8 +-
>  arch/cris/arch-v32/drivers/mach-fs/nandflash.c |   8 +-
>  arch/mips/alchemy/devboards/db1200.c   |   2 +-
>  arch/mips/alchemy/devboards/db1300.c   |   2 +-
>  arch/mips/alchemy/devboards/db1550.c   |   2 +-
>  arch/mips/pnx833x/common/platform.c|   2 +-
>  arch/mips/rb532/devices.c

Re: [PATCH] staging: lustre: add __user attributes to llite/file.c

2015-12-08 Thread Greg KH

On Tue, Dec 08, 2015 at 09:34:16PM +0100, Wim de With wrote:
> This fixes the following sparse warnings:
> 
> drivers/staging/lustre/lustre/llite/file.c:1310:38:expected void const 
> [noderef] *from
> drivers/staging/lustre/lustre/llite/file.c:1310:38:got struct 
> ll_recreate_obj *
> drivers/staging/lustre/lustre/llite/file.c:1328:35: warning: incorrect type 
> in argument 2 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:1328:35:expected void const 
> [noderef] *from
> drivers/staging/lustre/lustre/llite/file.c:1328:35:got struct lu_fid 
> *
> drivers/staging/lustre/lustre/llite/file.c:1475:35: warning: incorrect type 
> in argument 2 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:1475:35:expected void const 
> [noderef] *from
> drivers/staging/lustre/lustre/llite/file.c:1475:35:got struct 
> lov_user_md_v1 *
> drivers/staging/lustre/lustre/llite/file.c:1500:35: warning: incorrect type 
> in argument 2 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:1500:35:expected void const 
> [noderef] *from
> drivers/staging/lustre/lustre/llite/file.c:1500:35:got struct 
> lov_user_md_v1 *lumv1p
> drivers/staging/lustre/lustre/llite/file.c:1505:44: warning: incorrect type 
> in argument 2 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:1505:44:expected void const 
> [noderef] *from
> drivers/staging/lustre/lustre/llite/file.c:1505:44:got struct 
> lov_user_md_v3 *lumv3p
> drivers/staging/lustre/lustre/llite/file.c:1516:17: warning: incorrect type 
> in argument 1 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:1516:17:expected void const 
> volatile [noderef] *
> drivers/staging/lustre/lustre/llite/file.c:1516:17:got unsigned short 
> *
> drivers/staging/lustre/lustre/llite/file.c:1829:27: warning: incorrect type 
> in argument 1 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:1829:27:expected void 
> [noderef] *to
> drivers/staging/lustre/lustre/llite/file.c:1829:27:got void *
> drivers/staging/lustre/lustre/llite/file.c:2214:24: warning: incorrect type 
> in argument 1 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:2214:24:expected void const 
> volatile [noderef] *
> drivers/staging/lustre/lustre/llite/file.c:2214:24:got int *
> drivers/staging/lustre/lustre/llite/file.c:2221:21: warning: incorrect type 
> in argument 1 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:2221:21:expected void const 
> volatile [noderef] *
> drivers/staging/lustre/lustre/llite/file.c:2221:21:got int *
> drivers/staging/lustre/lustre/llite/file.c:2245:43: warning: incorrect type 
> in argument 2 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:2245:43:expected void const 
> [noderef] *from
> drivers/staging/lustre/lustre/llite/file.c:2245:43:got char *
> drivers/staging/lustre/lustre/llite/file.c:2275:24: warning: incorrect type 
> in argument 1 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:2275:24:expected void const 
> volatile [noderef] *
> drivers/staging/lustre/lustre/llite/file.c:2275:24:got int *
> drivers/staging/lustre/lustre/llite/file.c:2292:35: warning: incorrect type 
> in argument 1 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:2292:35:expected void 
> [noderef] *to
> drivers/staging/lustre/lustre/llite/file.c:2292:35:got void *
> drivers/staging/lustre/lustre/llite/file.c:2299:44: warning: incorrect type 
> in argument 2 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:2299:44:expected void 
> [noderef] *arg
> drivers/staging/lustre/lustre/llite/file.c:2299:44:got void *
> drivers/staging/lustre/lustre/llite/file.c:2304:43: warning: incorrect type 
> in argument 2 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:2304:43:expected void const 
> [noderef] *from
> drivers/staging/lustre/lustre/llite/file.c:2304:43:got char *
> drivers/staging/lustre/lustre/llite/file.c:2310:46: warning: incorrect type 
> in argument 1 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:2310:46:expected void 
> [noderef] *to
> drivers/staging/lustre/lustre/llite/file.c:2310:46:got char *
> drivers/staging/lustre/lustre/llite/file.c:2323:21: warning: incorrect type 
> in argument 1 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:2323:21:expected void const 
> volatile [noderef] *
> drivers/staging/lustre/lustre/llite/file.c:2323:21:got int *
> drivers/staging/lustre/lustre/llite/file.c:2350:35: warning: incorrect type 
> in argument 1 (different address spaces)
> drivers/staging/lustre/lustre/llite/file.c:2350:35:expected void 
> [noderef] *to
> drivers/staging/lustre/lustre/llite/file.c:2350:35:got void *
> drivers/staging/lustre/lustre/llite/file.c:2361:3

RE: [PATCH v2] storvsc: add logging for error/warning messages

2015-12-08 Thread KY Srinivasan



> -Original Message-
> From: Long Li [mailto:lon...@microsoft.com]
> Sent: Friday, December 4, 2015 12:07 AM
> To: KY Srinivasan ; Haiyang Zhang
> ; James E.J. Bottomley 
> Cc: de...@linuxdriverproject.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Long Li 
> Subject: [PATCH v2] storvsc: add logging for error/warning messages
> 
> Introduce a logging level for storvsc to log certain error/warning messages.
> Those messages are helpful in some environments, e.g. Microsoft Azure, for
> customer support and troubleshooting purposes.
> 
> Signed-off-by: Long Li 
Reviewed-by : K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 

> ---
>  drivers/scsi/storvsc_drv.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 40c43ae..f46ed2c 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -164,6 +164,26 @@ static int sense_buffer_size =
> PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
>  */
>  static int vmstor_proto_version;
> 
> +#define STORVSC_LOGGING_NONE 0
> +#define STORVSC_LOGGING_ERROR1
> +#define STORVSC_LOGGING_WARN 2
> +
> +static int logging_level = STORVSC_LOGGING_ERROR;
> +module_param(logging_level, int, S_IRUGO|S_IWUSR);
> +MODULE_PARM_DESC(logging_level,
> + "Logging level, 0 - None, 1 - Error (default), 2 - Warning.");
> +
> +static inline bool do_logging(int level)
> +{
> + return logging_level >= level;
> +}
> +
> +#define storvsc_log(dev, level, fmt, ...)\
> +do { \
> + if (do_logging(level))  \
> + dev_warn(&(dev)->device, fmt, ##__VA_ARGS__);   \
> +} while (0)
> +
>  struct vmscsi_win8_extension {
>   /*
>* The following were added in Windows 8
> @@ -1185,7 +1205,8 @@ static void storvsc_command_completion(struct
> storvsc_cmd_request *cmd_request)
> 
>   if (scmnd->result) {
>   if (scsi_normalize_sense(scmnd->sense_buffer,
> - SCSI_SENSE_BUFFERSIZE, &sense_hdr))
> + SCSI_SENSE_BUFFERSIZE, &sense_hdr) &&
> + do_logging(STORVSC_LOGGING_ERROR))
>   scsi_print_sense_hdr(scmnd->device, "storvsc",
>&sense_hdr);
>   }
> @@ -1239,6 +1260,13 @@ static void storvsc_on_io_completion(struct
> hv_device *device,
>   stor_pkt->vm_srb.sense_info_length =
>   vstor_packet->vm_srb.sense_info_length;
> 
> + if (vstor_packet->vm_srb.scsi_status != 0 ||
> + vstor_packet->vm_srb.srb_status != SRB_STATUS_SUCCESS)
> + storvsc_log(device, STORVSC_LOGGING_WARN,
> + "cmd 0x%x scsi status 0x%x srb status 0x%x\n",
> + stor_pkt->vm_srb.cdb[0],
> + vstor_packet->vm_srb.scsi_status,
> + vstor_packet->vm_srb.srb_status);
> 
>   if ((vstor_packet->vm_srb.scsi_status & 0xFF) == 0x02) {
>   /* CHECK_CONDITION */
> @@ -1246,6 +1274,10 @@ static void storvsc_on_io_completion(struct
> hv_device *device,
>   SRB_STATUS_AUTOSENSE_VALID) {
>   /* autosense data available */
> 
> + storvsc_log(device, STORVSC_LOGGING_WARN,
> + "stor pkt %p autosense data valid - len
> %d\n",
> + request, vstor_packet-
> >vm_srb.sense_info_length);
> +
>   memcpy(request->cmd->sense_buffer,
>  vstor_packet->vm_srb.sense_data,
>  vstor_packet->vm_srb.sense_info_length);
> --
> 1.8.5.6

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: speakup: varhandlers: cleanup of function spk_get_punc_var

2015-12-08 Thread Sudip Mukherjee

On Mon, Dec 07, 2015 at 06:35:11PM +0530, Saurabh Sengar wrote:
> This patch does the following:
> * changed the complicated if statements to simple case statements
> * in case of E_DEFAULT, no need to return error as ERESTART,
> because this is the user asked for. Hence function should return success.
> * ret variable is 0 always, hence removed it.
> * removed one ternary operator, as it was always returning the status value 
> only,
> and hence removed the status variable too

That becomes 4 different changes. Please break them into separate
patches.

regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: nvec: fix block comments

2015-12-08 Thread Simon Guinot

This patch fixes a couple of checkpatch warnings about block comments.

Signed-off-by: Simon Guinot 
---
 drivers/staging/nvec/nvec.c   |  6 --
 drivers/staging/nvec/nvec_power.c | 14 +-
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 802c9597d421..cb0927ddd78f 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -508,8 +508,10 @@ static void nvec_rx_completed(struct nvec_chip *nvec)
 
spin_lock(&nvec->rx_lock);
 
-   /* add the received data to the work list
-  and move the ring buffer pointer to the next entry */
+   /*
+* Add the received data to the work list and move the ring buffer
+* pointer to the next entry.
+*/
list_add_tail(&nvec->rx->node, &nvec->rx_data);
 
spin_unlock(&nvec->rx_lock);
diff --git a/drivers/staging/nvec/nvec_power.c 
b/drivers/staging/nvec/nvec_power.c
index 04a7402ae2df..b4a0545e8806 100644
--- a/drivers/staging/nvec/nvec_power.c
+++ b/drivers/staging/nvec/nvec_power.c
@@ -207,8 +207,10 @@ static int nvec_power_bat_notifier(struct notifier_block 
*nb,
case TYPE:
memcpy(power->bat_type, &res->plc, res->length - 2);
power->bat_type[res->length - 2] = '\0';
-   /* this differs a little from the spec
-  fill in more if you find some */
+   /*
+* This differs a little from the spec fill in more if you find
+* some.
+*/
if (!strncmp(power->bat_type, "Li", 30))
power->bat_type_enum = POWER_SUPPLY_TECHNOLOGY_LION;
else
@@ -356,12 +358,14 @@ static void nvec_power_poll(struct work_struct *work)
if (counter >= ARRAY_SIZE(bat_iter))
counter = 0;
 
-/* AC status via sys req */
+   /* AC status via sys req */
nvec_write_async(power->nvec, buf, 2);
msleep(100);
 
-/* select a battery request function via round robin
-   doing it all at once seems to overload the power supply */
+   /*
+* Select a battery request function via round robin doing it all at
+* once seems to overload the power supply.
+*/
buf[0] = NVEC_BAT;
buf[1] = bat_iter[counter++];
nvec_write_async(power->nvec, buf, 2);
-- 
2.1.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

39 matches

Mail list logo