Re: [oselas] Mini2440 boot failure on kernel 3.7-rc1

[Brian Norris]

On 11/13/2012 01:29 PM, Sylwester Nawrocki wrote:
 On 11/13/2012 08:54 AM, Brian Norris wrote:
 On Mon, Nov 12, 2012 at 3:18 PM, Sylwester Nawrocki
 Can you please list a full 8-byte string of id_data[]? This will be
 very helpful. I know of at least one solution that will fix your
 problem, but I need to know your full ID to help lay this issue to
 rest for good.
 
 Indeed, I wish there was good hardware documentation, still it seems
 an exception rather than a rule for some hardware vendors...
 
 Here is my id_data[] dump:
 
 ec, f1, 00, 95, 40, ec, ec, f1
 
 Looks a bit strange, I hope you know how to handle this. :)

Well, sort of. I could add yet another quirk: that some 5-byte IDs
have the manufacturer ID repeated twice (0xEC 0xEC). In fact, I just got
another report of a similar (stupid) ID.

But I have a more reasonable change. It's disappointing, but I'll have to
do a partial revert of my previous commits, dropping support for some of
the newest SLC in favor of not breaking the old. I'll have to try to get
in contact with Samsung if I'm ever going to support the newest stuff.

Please try my diff (below), on top of the patch from:

http://lists.infradead.org/pipermail/linux-mtd/2012-October/044356.html

 OK. BTW, is this comment in drivers/mtd/nand_base.c
 
 /*
   * nand_id_has_period - Check if an ID string has a given wraparound 
 period
   ...
   * specific repetition interval period (e.g., {0x20,0x01,0x7F,0x20} has a
   * period of 2). This is a helper function for nand_id_len(). Returns 
 non-zero
   ...
 
 correct ? Shouldn't it be has a period of 3 ? Since there are 3 different
 values and then it repeats starting with 0x20 ?

Yes, good eye. I also noticed my typo when re-reviewing this code just now. 
I'll fix this for the 3.8 cycle.

Brian

---
 drivers/mtd/nand/nand_base.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index d5ece6e..1a03b7f 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2990,6 +2990,7 @@ static void nand_decode_ext_id(struct mtd_info *mtd, 
struct nand_chip *chip,
 * ID to decide what to do.
 */
if (id_len == 6  id_data[0] == NAND_MFR_SAMSUNG 
+   (chip-cellinfo  NAND_CI_CELLTYPE_MSK) 
id_data[5] != 0x00) {
/* Calc pagesize */
mtd-writesize = 2048  (extid  0x03);

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

Re: [PATCH] mtd: s3c2410: Move to clk_prepare_enable/clk_disable_unprepare

[Brian Norris]

On Mon, Jun 30, 2014 at 10:12:16PM +0300, Vasily Khoruzhick wrote:
 Use clk_prepare_enable/clk_disable_unprepare to make the driver
 work properly with common clock framework.
 
 Signed-off-by: Vasily Khoruzhick anars...@gmail.com

Pushed to l2-mtd.git. Thanks!

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

Re: [PATCH 14/17] mtd: onenand: remove s5pc100 related onenand codes

[Brian Norris]

+ linux-mtd (please CC for anything driver/mtd/*; see MAINTAINERS)

On Tue, Jul 01, 2014 at 06:32:24AM +0900, Kukjin Kim wrote:
 This patch removes s5pc100 related onenand codes because of no more
 support for S5PC100 SoC in mainline.
 
 Signed-off-by: Kukjin Kim kgene@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Cc: David Woodhouse dw...@infradead.org
 Cc: Brian Norris computersforpe...@gmail.com
 ---
  drivers/mtd/onenand/Kconfig   |4 ++--
  drivers/mtd/onenand/samsung.c |   25 +
  2 files changed, 3 insertions(+), 26 deletions(-)
 
 diff --git a/drivers/mtd/onenand/Kconfig b/drivers/mtd/onenand/Kconfig
 index ab26072..dcae2f6 100644
 --- a/drivers/mtd/onenand/Kconfig
 +++ b/drivers/mtd/onenand/Kconfig
 @@ -32,10 +32,10 @@ config MTD_ONENAND_OMAP2
  
  config MTD_ONENAND_SAMSUNG
  tristate OneNAND on Samsung SOC controller support
 -depends on ARCH_S3C64XX || ARCH_S5PC100 || ARCH_S5PV210 || 
 ARCH_EXYNOS4
 +depends on ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS4
  help
Support for a OneNAND flash device connected to an Samsung SOC.
 -  S3C64XX/S5PC100 use command mapping method.
 +  S3C64XX uses command mapping method.
S5PC110/S5PC210 use generic OneNAND method.
  
  config MTD_ONENAND_OTP
 diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
 index efb819c..19cfb97 100644
 --- a/drivers/mtd/onenand/samsung.c
 +++ b/drivers/mtd/onenand/samsung.c
 @@ -10,7 +10,7 @@
   * published by the Free Software Foundation.
   *
   * Implementation:
 - *   S3C64XX and S5PC100: emulate the pseudo BufferRAM
 + *   S3C64XX: emulate the pseudo BufferRAM
   *   S5PC110: use DMA
   */
  
 @@ -32,7 +32,6 @@
  enum soc_type {
   TYPE_S3C6400,
   TYPE_S3C6410,
 - TYPE_S5PC100,
   TYPE_S5PC110,
  };
  
 @@ -59,7 +58,6 @@ enum soc_type {
  #define MAP_11   (0x3)
  
  #define S3C64XX_CMD_MAP_SHIFT24
 -#define S5PC100_CMD_MAP_SHIFT26
  
  #define S3C6400_FBA_SHIFT10
  #define S3C6400_FPA_SHIFT4
 @@ -69,10 +67,6 @@ enum soc_type {
  #define S3C6410_FPA_SHIFT6
  #define S3C6410_FSA_SHIFT4
  
 -#define S5PC100_FBA_SHIFT13
 -#define S5PC100_FPA_SHIFT7
 -#define S5PC100_FSA_SHIFT5
 -
  /* S5PC110 specific definitions */
  #define S5PC110_DMA_SRC_ADDR 0x400
  #define S5PC110_DMA_SRC_CFG  0x404
 @@ -195,11 +189,6 @@ static unsigned int s3c64xx_cmd_map(unsigned type, 
 unsigned val)
   return (type  S3C64XX_CMD_MAP_SHIFT) | val;
  }
  
 -static unsigned int s5pc1xx_cmd_map(unsigned type, unsigned val)
 -{
 - return (type  S5PC100_CMD_MAP_SHIFT) | val;
 -}
 -
  static unsigned int s3c6400_mem_addr(int fba, int fpa, int fsa)
  {
   return (fba  S3C6400_FBA_SHIFT) | (fpa  S3C6400_FPA_SHIFT) |
 @@ -212,12 +201,6 @@ static unsigned int s3c6410_mem_addr(int fba, int fpa, 
 int fsa)
   (fsa  S3C6410_FSA_SHIFT);
  }
  
 -static unsigned int s5pc100_mem_addr(int fba, int fpa, int fsa)
 -{
 - return (fba  S5PC100_FBA_SHIFT) | (fpa  S5PC100_FPA_SHIFT) |
 - (fsa  S5PC100_FSA_SHIFT);
 -}
 -
  static void s3c_onenand_reset(void)
  {
   unsigned long timeout = 0x1;
 @@ -835,9 +818,6 @@ static void s3c_onenand_setup(struct mtd_info *mtd)
   } else if (onenand-type == TYPE_S3C6410) {
   onenand-mem_addr = s3c6410_mem_addr;
   onenand-cmd_map = s3c64xx_cmd_map;
 - } else if (onenand-type == TYPE_S5PC100) {
 - onenand-mem_addr = s5pc100_mem_addr;
 - onenand-cmd_map = s5pc1xx_cmd_map;
   } else if (onenand-type == TYPE_S5PC110) {
   /* Use generic onenand functions */
   this-read_bufferram = s5pc110_read_bufferram;
 @@ -,9 +1091,6 @@ static struct platform_device_id 
 s3c_onenand_driver_ids[] = {
   .name   = s3c6410-onenand,
   .driver_data= TYPE_S3C6410,
   }, {
 - .name   = s5pc100-onenand,
 - .driver_data= TYPE_S5PC100,
 - }, {
   .name   = s5pc110-onenand,
   .driver_data= TYPE_S5PC110,
   }, { },
 -- 
 1.7.10.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/20] mtd: s3c2410: fix misspelling of current function in string

[Brian Norris]

On Mon, Dec 08, 2014 at 10:16:37AM +0100, Richard Weinberger wrote:
 Am 08.12.2014 um 08:11 schrieb Julia Lawall:
  diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
  index 35aef5e..0a9c41f 100644
  --- a/drivers/mtd/nand/s3c2410.c
  +++ b/drivers/mtd/nand/s3c2410.c
  @@ -948,7 +948,7 @@ static int s3c24xx_nand_probe(struct platform_device 
  *pdev)
 
  cpu_type = platform_get_device_id(pdev)-driver_data;
 
  -   pr_debug(s3c2410_nand_probe(%p)\n, pdev);
  +   pr_debug(%s(%p)\n, __func__, pdev);
 
  I think we can drop the line completely.
  We have ftrace to trace function calls...
  
  Should the initialised ok at the end of the function be remove as well?
  
  Will it be confusing if this cleanup is done in this function, but not in 
  others where it may be useful?  Perhaps s3c2410_nand_update_chip, for 
  example?
 
 Hmm, this driver seems to have a lot of debugging printks().
 IMHO we can remove them.
 Let's see what Brain says.

I'm a little late for this one, but I can apply this instead:

From: Brian Norris computersforpe...@gmail.com
Date: Fri, 6 Feb 2015 03:25:28 -0800
Subject: [PATCH] mtd: s3c2410: drop useless / misspelled debug prints

s3c2410_nand_probe is not the name of the function.

These prints have little utility, so let's just kill them.

Reported-by: Julia Lawall julia.law...@lip6.fr
Signed-off-by: Brian Norris computersforpe...@gmail.com
---
 drivers/mtd/nand/s3c2410.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
index 35aef5edb588..0e02be47ce1d 100644
--- a/drivers/mtd/nand/s3c2410.c
+++ b/drivers/mtd/nand/s3c2410.c
@@ -948,8 +948,6 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
 
cpu_type = platform_get_device_id(pdev)-driver_data;
 
-   pr_debug(s3c2410_nand_probe(%p)\n, pdev);
-
info = devm_kzalloc(pdev-dev, sizeof(*info), GFP_KERNEL);
if (info == NULL) {
err = -ENOMEM;
@@ -1045,7 +1043,6 @@ static int s3c24xx_nand_probe(struct platform_device 
*pdev)
s3c2410_nand_clk_set_state(info, CLOCK_SUSPEND);
}
 
-   pr_debug(initialised ok\n);
return 0;
 
  exit_error:
-- 
2.3.0

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

Re: [PATCH 04/11] mtd: ofpart: do not fail probe when no partitions exist

[Brian Norris]

On Wed, Jun 03, 2015 at 09:26:40PM -, Michal Suchanek wrote:
 On Exynos it is necessary to set SPI controller parameters that apply to
 a SPI slave in a DT subnode of the slave device. The ofpart code returns
 an error when there are subnodes of the SPI flash but no partitions are
 found. Change this condition to a warning so that flash without
 partitions can be accessed on Exynos.

So judging by the subsequent discussion, you're looking at handling
nodes like this:

flash@... {
compatible = m25p80;
...

controller-data {
samsung,spi-feedback-delay = 0;
};
};

Now, I'm not a real fan of this controller-data node in the first place
(did that binding get reviewed?). But this is especially bad since
we now have collisions on what to do with subnodes that don't have a
compatible property. By legacy, ofpart has already claimed ownership of
subnodes of an MTD node, where the subnode does not have a compatible
property. See Documentation/devicetree/bindings/mtd/partition.txt:

  NOTE: if the sub-node has a compatible string, then it is not a
  partition.

So it seems the natural solution is to just define a proper
compatibile property for this subnode, and ofpart.c will naturally
handle this. See:

commit e79265ba6bdb31437bd4c3e7911950f9d1262a07
Author: Josh Wu josh...@atmel.com
Date:   Mon Aug 5 19:14:38 2013 +0800

mtd: ofpart: add compatible check for child nodes



Brian

 Signed-off-by: Michal Suchanek hramr...@gmail.com
 ---
  drivers/mtd/ofpart.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
 index aa26c32..a29d29f 100644
 --- a/drivers/mtd/ofpart.c
 +++ b/drivers/mtd/ofpart.c
 @@ -94,10 +94,10 @@ static int parse_ofpart_partitions(struct mtd_info 
 *master,
  
   if (!i) {
   of_node_put(pp);
 - pr_err(No valid partition found on %s\n, node-full_name);
 + pr_warn(No valid partition found on %s\n, node-full_name);
   kfree(*pparts);
   *pparts = NULL;
 - return -EINVAL;
 + return 0;
   }
  
   return nr_parts;
 -- 
 2.1.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data

[Brian Norris]

On Wed, Jul 29, 2015 at 06:19:24PM +0200, Michal Suchanek wrote:
 On 29 July 2015 at 16:00, Mark Brown broo...@kernel.org wrote:
  On Wed, Jul 29, 2015 at 12:19:57PM +0200, Michal Suchanek wrote:
 
  Please use subject lines matching the style for the subsytsem so people
  can spot that the patch is in some way relevant.
 
  The controller-data subnode has no compatible. This can lead to other
  drivers getting confused by it. Add a compatible to make devicetreee
  unambiguous.
 
  I can't tell from this commit message what the issue you're trying to
  fix is, sorry.  Nodes without compatible strings are entirely normal and
  don't need compatible strings.  It sounds like a bug in whatever other
  driver is becoming confused.
 
 The driver that gets confused is ofpart.
 
 The two-line patch to allow it to just ignore controller-data has been
 rejected on the basis that s3c64xx should use a compatible string

It wasn't outright rejected, but it was questioned.

 because ofpart monopolizes all nodes without compatible which are
 children of a mtd device. Devicetrees containing such nodes that are
 not partitions are presumably invalid and should be rejected when
 ofpart is compiled into the kernel.

That characterization is currently correct. I'm not a fan of what ofpart
does in the first place; I'd really like it if its binding was written
in a way that made it more precise, but we have to live with what we
have.

I also didn't like that you were designing your system such that we were
now keying off the fact that your node has no 'reg' property. This
seemed awfully fragile. (Admittedly, so is ofpart.c.)

All in all, if you have better suggestions, I'm all ears. (At first
glance, I'm liking your patch 1 to help disambiguate both MTD partitions
and the 'controller-data' node going forward.)

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

Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

[Brian Norris]

On Wed, Jul 15, 2015 at 07:15:50PM +0200, Marek Vasut wrote:
 On Wednesday, July 15, 2015 at 05:59:46 PM, Brian Norris wrote:
  1. Fix up the SPI driver so that it knows how to break large SPI
  transfers up into smaller segments that its constituent hardware (DMA
  controllers, fast clocks, etc.) can handle.

BTW, Mark Brown already commented on this approach:

http://lists.infradead.org/pipermail/linux-mtd/2015-May/059364.html

I quote:

| With modern drivers using transfer_one() where we have control of the
| chip select we do also have the ability to add support to the core for
| chopping large transfers up into smaller ones that the hardware can
| handle transparently.  That won't for everything though since it depends
| on us being able to manually control the chip select which not all
| hardware can do.

 I think this might actually be easier -- just do a transfer where you
 don't toggle CS and just stops the clock at the last bit, then do another
 (multiple) transfers which don't toggle CS at all, then finally do a
 transfer which toggles a CS at the end.

Sounds OK to me. And as Mark noted, this could probably be done in the
core. I suppose Mark could suggest whether the most expedient path is to
hack the buggy driver to do this, or whether reworking the SPI core to
have the appropriate spi_master field(s) (and caveats) to support this.

 This should be pretty trivial
 to do and I think for example spi-mxs.c does this.

I don't think spi-mxs.c really does this; it chooses between PIO and DMA
based on length, but with either option, it runs through each SPI
transfer in one go. You might be confused by the fact that this driver
implements -transfer_one_message instead of -transfer_one, so it has
to loop through all transfers in the message.

(IIUC, spi-mxs.c could easily be rewritten to use -transfer, and some
of that not-too-complicated boilerplate could be killed off.)

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

Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

[Brian Norris]

Hi Michal,

On Wed, Jul 15, 2015 at 01:52:27PM +0200, Marek Vasut wrote:
 The problem is, if you add a new DT binding, you'd have to support it
 forever, no matter how bad idea that binding turned out to be.

Agreed, and a solid NAK to this patch. I could have sworn I gave such a
response when this was originally being discussed a month ago.

AFAICT, you have one of two general approaches available to you:

1. Fix up the SPI driver so that it knows how to break large SPI
transfers up into smaller segments that its constituent hardware (DMA
controllers, fast clocks, etc.) can handle.

2. Utilize/create a parameter within the SPI subsystem to communicate
that the SPI master has a limited max transfer size (notably: NOT a
per-device DT property, but a SPI API property), and modify SPI device
drivers (like m25p80) to honor it. Mark Brown seemed open to this, and I
thought he suggested it somewhere.

It is most definitely wrong to put this information solely in the slave
device DT (i.e., for the flash), when it is not a property of the flash
device at all. It's a property of the SPI master and/or its clocks and
DMA controllers.

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

Re: [PATCH 14/27] mtd: nand: use the mtd instance embedded in struct nand_chip

[Brian Norris]

Hi Boris,

On Mon, Nov 16, 2015 at 02:37:47PM +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 generate with this coccinelle script:
> http://code.bulix.org/5vxuih-89429

I appreciate that this patch is mostly autogenerated (a good thing for
preventing errors!), but there are some issues that I don't think play
out very well stylistically. Hopefully the cocci script can be improved
to handle some of this?

I'll try to point out a few snippets below.

Also, in case others are interested in reviewing your cocci script
directly, it might be better to paste it inline than to link to it.
Given the size of the patch, I don't think people would mind a few dozen
extra lines to show how it wsa generated. Or maybe stick some in the
cover letter too, if you end up reusing them in several patches.

> ---
>  drivers/mtd/nand/ams-delta.c   | 13 ++--
>  drivers/mtd/nand/atmel_nand.c  | 11 ++-
>  drivers/mtd/nand/au1550nd.c| 18 ++---
>  drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h |  1 -
>  drivers/mtd/nand/bcm47xxnflash/main.c  |  7 +-
>  drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c   |  2 +-
>  drivers/mtd/nand/bf5xx_nand.c  | 14 ++--
>  drivers/mtd/nand/brcmnand/brcmnand.c   | 11 ++-
>  drivers/mtd/nand/cafe_nand.c   | 10 +--
>  drivers/mtd/nand/cmx270_nand.c | 11 ++-
>  drivers/mtd/nand/cs553x_nand.c | 13 ++--
>  drivers/mtd/nand/davinci_nand.c| 25 +++
>  drivers/mtd/nand/denali.c  | 61 +
>  drivers/mtd/nand/denali.h  |  1 -
>  drivers/mtd/nand/diskonchip.c  | 11 ++-
>  drivers/mtd/nand/docg4.c   | 18 +++--
>  drivers/mtd/nand/fsl_elbc_nand.c   | 22 +++---
>  drivers/mtd/nand/fsl_ifc_nand.c| 23 +++
>  drivers/mtd/nand/fsl_upm.c | 26 +++
>  drivers/mtd/nand/fsmc_nand.c   | 59 +---
>  drivers/mtd/nand/gpio.c| 16 ++---
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  2 +-
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 20 +++---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  1 -
>  drivers/mtd/nand/hisi504_nand.c| 11 ++-
>  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| 22 +++---
>  drivers/mtd/nand/nuc900_nand.c | 21 +++---
>  drivers/mtd/nand/omap2.c   | 94 
> +++---
>  drivers/mtd/nand/orion_nand.c  |  4 +-
>  drivers/mtd/nand/pasemi_nand.c | 14 ++--
>  drivers/mtd/nand/plat_nand.c   | 14 ++--
>  drivers/mtd/nand/pxa3xx_nand.c | 33 -

^^ BTW, this file already has a few conflicts. Sorry :(

I'll try to keep any eye out for things like this once we're close to
being able to apply something like this, so I don't merge unnecessary
churn. But for now, I hope we can review this series, and it won't be
too much work to rebase/resend once the bigger things have been worked
out.

>  drivers/mtd/nand/r852.c| 34 --
>  drivers/mtd/nand/r852.h|  1 -
>  drivers/mtd/nand/s3c2410.c | 19 +++---
>  drivers/mtd/nand/sh_flctl.c|  8 +--
>  drivers/mtd/nand/sharpsl.c | 18 ++---
>  drivers/mtd/nand/socrates_nand.c   |  5 +-
>  drivers/mtd/nand/sunxi_nand.c  | 13 ++--
>  drivers/mtd/nand/tmio_nand.c   |  7 +-
>  drivers/mtd/nand/txx9ndfmc.c   |  3 +-
>  drivers/mtd/nand/vf610_nfc.c   |  5 +-
>  include/linux/mtd/sh_flctl.h   |  3 +-
>  49 files changed, 383 insertions(+), 385 deletions(-)
> 

...

> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
> index f8aac0a..51748b4 100644
> --- a/drivers/mtd/nand/atmel_nand.c
> +++ b/drivers/mtd/nand/atmel_nand.c

...

> @@ -318,7 +317,7 @@ static int nfc_set_sram_bank(struct atmel_nand_host 
> *host, unsigned int bank)
>  
>   if (bank) {
>   /* Only for a 2k-page or lower flash, NFC can handle 2 banks */
> - if (host->mtd.writesize > 2048)
> + if 

Re: [PATCH 18/27] mtd: nand: update mtd_to_nand()

[Brian Norris]

On Mon, Nov 16, 2015 at 02:37:51PM +0100, Boris Brezillon wrote:
> Now that all drivers are using the mtd instance embedded in the nand_chip

Do you have a script that verifies this? I thought you did at some
point, and it'd be nice to note it, so I can also use it to verify
things once it gets applied.

> struct we can safely update the mtd_to_nand_chip() implementation to use

Nit: s/mtd_to_nand_chip/mtd_to_nand/

> the container_of macro instead of returning the content of mtd->priv.
> This will allow us to remove mtd->priv = chip assignments done in all
> NAND controller drivers.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  include/linux/mtd/nand.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 8ec071e..873646d 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -734,7 +734,7 @@ static inline struct device_node 
> *nand_get_flash_node(struct nand_chip *chip)
>  
>  static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
>  {
> - return mtd->priv;
> + return container_of(mtd, struct nand_chip, mtd);
>  }
>  
>  static inline struct mtd_info *nand_to_mtd(struct nand_chip *chip)
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 10/17] phy: Add driver for rockchip Display Port PHY

[Brian Norris]

Hi Yakir,

On Wed, Nov 04, 2015 at 08:48:38AM +0800, Yakir Yang wrote:
> On 11/03/2015 12:38 PM, Brian Norris wrote:
> >On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:
> >(FYI, I came across this by inspection when comparing Heiko's
> >'somewhat-stable' branch [1] with this series. The former brings up eDP
> >fine on veyron-jaq, whereas this one doesn't yet, even with the above
> >change. Still debugging the issue.)
> 
> Hmm... I'm not sure whether your eDP screen have the hotplug signal, so I

I believe hotplug is hooked up but...

> think you can try to add "analogix,force-hpd" flag into
> rk3288-veyron-jaq.dts
> 
>  {
> analogix,need-force-hpd;
> }

...already tried, just in case. No luck.

> If that changes couldn't fix the problem, guess you may need max the panel
> power up delay time which pointed by Heiko. Like:
> 
> Thanks,
> - Yakir
> 
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 4fa5f69..546a506 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -82,6 +82,13 @@ static int analogix_dp_detect_hpd(struct
> analogix_dp_device *dp)
>  */
> dev_dbg(dp->dev, "failed to get hpd plug status, try to
> force hpd\n");
> 
> +   /*
> +* Hotplug signal would indicate the right time to operate
> +* panel after poweron, but if the hotplug is missing, then
> +* panel would need wait hundreds of milliseconds at here.
> +*/
> +   mdelay(100);
> +
> analogix_dp_force_hpd(dp);
> 
> if (analogix_dp_get_plug_in_status(dp) != 0) {

I'll give that a try. Per Heiko's suggestion, I've already hacked around
with adding delays in the regulator node, but this could give slightly
different behavior. I doubt it'll help, but I'll let you know if it
does.

Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 10/17] phy: Add driver for rockchip Display Port PHY

[Brian Norris]

Hi Yakir,

On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:
> Add phy driver for the Rockchip DisplayPort PHY module. This
> is required to get DisplayPort working in Rockchip SoCs.
> 
> Reviewed-by: Heiko Stuebner 
> Signed-off-by: Yakir Yang 
> ---
...
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..f3e0058
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,151 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GRF_SOC_CON12   0x0274
> +
> +#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(4)
> +#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)

Why are the above two macros the same? Judging by the RK3288 manual and
other downstream drivers, it seems like you want the _MASK one to be
shifted left by 16 (i.e., BIT(20)).

> +
> +#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)
> +#define GRF_EDP_PHY_SIDDQ_ON0
> +#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
> +

...

> + ret = regmap_write(dp->grf, GRF_SOC_CON12, GRF_EDP_REF_CLK_SEL_INTER |
> +GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK);

IOW, the above is writing:

BIT(4) | BIT(4)

whereas I think you want:

BIT(4) | BIT(20)

> + if (ret != 0) {
> + dev_err(dp->dev, "Could not config GRF edp ref clk: %d\n", ret);
> + return ret;
> + }
> +

...

(FYI, I came across this by inspection when comparing Heiko's
'somewhat-stable' branch [1] with this series. The former brings up eDP
fine on veyron-jaq, whereas this one doesn't yet, even with the above
change. Still debugging the issue.)

Brian

[1] https://github.com/mmind/linux-rockchip/tree/devel/somewhat-stable
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 10/17] phy: Add driver for rockchip Display Port PHY

[Brian Norris]

Hi,

A few updates:

On Tue, Nov 03, 2015 at 05:13:48PM -0800, Brian Norris wrote:
> On Wed, Nov 04, 2015 at 08:48:38AM +0800, Yakir Yang wrote:
> > On 11/03/2015 12:38 PM, Brian Norris wrote:
> > >On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:
> > >(FYI, I came across this by inspection when comparing Heiko's
> > >'somewhat-stable' branch [1] with this series. The former brings up eDP
> > >fine on veyron-jaq, whereas this one doesn't yet, even with the above
> > >change. Still debugging the issue.)

Some time after the above comment, I managed to kill the panel on my
Jaq :( I think the wiring around the hinge was a bit flaky, and it
finally went out for good.

> > Hmm... I'm not sure whether your eDP screen have the hotplug signal, so I
> 
> I believe hotplug is hooked up but...
> 
> > think you can try to add "analogix,force-hpd" flag into
> > rk3288-veyron-jaq.dts
> > 
> >  {
> > analogix,need-force-hpd;
> > }
> 
> ...already tried, just in case. No luck.

However, now when testing a different Jaq device, now this series +
Heiko's DTS updates + the "analogix,force-hpd" (i.e., [1]) works fine,
modulo a few log warnings, some of which are probably expected (for
instance, I believe the EDID is known not-so-helpful). Snippets:

[3.170176] rockchip-dp ff97.dp: AUX CH command reply failed!
[3.178058] rockchip-dp ff97.dp: AUX CH command reply failed!
[3.184166] rockchip-dp ff97.dp: unable to handle edid

and later:

[3.953300] rockchip-dp ff97.dp: EDID data does not include any 
extensions.
[3.966731] rockchip-dp ff97.dp: EDID data does not include any 
extensions.
[3.979409] rockchip-dp ff97.dp: EDID data does not include any 
extensions.
[3.998730] rockchip-dp ff97.dp: Link Training Clock Recovery success
[4.007046] rockchip-dp ff97.dp: Link Training success!
[4.115040] rockchip-dp ff97.dp: Timeout of video streamclk ok
[4.121211] rockchip-dp ff97.dp: unable to config video
[4.127616] rockchip-dp ff97.dp: EDID data does not include any 
extensions.


So, I'll chalk that earlier failure up to a hardware failure (or
possibly a still yet-undiagnosed hardware difference; my new Jaq has
some small differences from the previous unit).

Also, it's still not real clear why HPD isn't working upstream (and we
have to use the "force-hpd" property), when it appears to work on our
downstream Chrome OS tree.

Finally, I'll leave you with some small bits I've noticed from exploring
this issue on Jaq:

 * The Chrome OS driver for this IP has a much longer timeout in (the
   equivalent of) analogix_dp_detect_hpd; it polls in 10-20 ms intervals
   (rather than 10-11 us) and takes something around 60 to 120 ms to
   notice the panel.
 * AFAICT, the Chrome OS driver never actually used the HPD interrupt;
   it was only polling the HPD status bit. So I can't claim that the
   functionality that Yakir is supporting here has ever been tested on
   these platforms. (Now, I'm not sure this is extremely important,
   since we still can fall back to polled status checks; see
   drm_kms_helper_poll_init().)

That's all I've got for now.

Regards,
Brian

[1] https://github.com/mmind/linux-rockchip/commits/tmp/analogixdp-veyron

plus this diff:

diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts 
b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
index 5c97e3153526..e77ae4c5531e 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
@@ -88,6 +88,18 @@
};
 };
 
+ {
+   power-supply = <_regulator>;
+};
+
+ {
+   power-supply = <_regulator>;
+};
+
+ {
+   analogix,need-force-hpd;
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_int_l _1 _2>;
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
index c82c22f3d0e1..994189f49db5 100644
--- a/drivers/phy/phy-rockchip-dp.c
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -22,7 +22,7 @@
 
 #define GRF_SOC_CON12   0x0274
 
-#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(4)
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(20)
 #define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
 
 #define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Brian Norris]

On Tue, Dec 01, 2015 at 12:03:14PM +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 
> ---
> Patch generated with the following coccinelle script:
> 
> ---8<
> virtual patch
> 
> @@
> struct mtd_info m;
> struct mtd_info *mp;
> struct nand_chip *c;
> @@
> (
> -(m).priv = c;
> |
> -(mp)->priv = c;
> |
> -(mp)->priv = (void *)c;
> )
> ---8<
> ---

...

> diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> index 3f29734..ed4184c 100644
> --- a/drivers/mtd/nand/s3c2410.c
> +++ b/drivers/mtd/nand/s3c2410.c
> @@ -834,7 +834,6 @@ static void s3c2410_nand_init_chip(struct 
> s3c2410_nand_info *info,
>   chip->IO_ADDR_R = chip->IO_ADDR_W;
>  
>   nmtd->info = info;
> - mtd->priv  = chip;

After this one, we have:

drivers/mtd/nand/s3c2410.c: In function ‘s3c2410_nand_init_chip’:
drivers/mtd/nand/s3c2410.c:791:19: warning: unused variable ‘mtd’ 
[-Wunused-variable]


>   nmtd->set  = set;
>  
>  #ifdef CONFIG_MTD_NAND_S3C2410_HWECC
 
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Brian Norris]

Hi Boris,

On Tue, Dec 01, 2015 at 12:03:09PM +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"
> ---
>  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 ++-
>  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   | 16 ++---
>  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 | 20 +++---
>  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 +++---

^^ some errors in this one

>  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, 426 insertions(+), 390 deletions(-)
> 

[...]

> diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> index e658b29..3f29734 100644
> --- a/drivers/mtd/nand/s3c2410.c
> +++ b/drivers/mtd/nand/s3c2410.c
> @@ -104,7 +104,6 @@ struct s3c2410_nand_info;
>   * @scan_res: The result from calling nand_scan_ident().
>  */
>  struct s3c2410_nand_mtd {
> - struct mtd_info mtd;
>   struct nand_chipchip;
>   struct s3c2410_nand_set *set;
>   struct s3c2410_nand_info*info;
> @@ -168,7 +167,8 @@ struct s3c2410_nand_info {
>  
>  static struct s3c2410_nand_mtd *s3c2410_nand_mtd_toours(struct mtd_info *mtd)
>  {
> - return container_of(mtd, struct s3c2410_nand_mtd, mtd);
> + return container_of(mtd_to_nand(mtd), struct s3c2410_nand_mtd,
> + chip);
>  }
>  
>  static struct s3c2410_nand_info *s3c2410_nand_mtd_toinfo(struct mtd_info 
> *mtd)
> @@ -745,7 +745,7 @@ static int s3c24xx_nand_remove(struct platform_device 
> *pdev)
>  
>   for (mtdno = 0; mtdno < info->mtd_count; mtdno++, ptr++) {
>   pr_debug("releasing mtd %d (%p)\n", mtdno, ptr);
> - nand_release(>mtd);
> + nand_release(nand_to_mtd(>chip));
>   }
>   }
>  
> @@ -762,9 +762,11 @@ static int s3c2410_nand_add_partition(struct 
> 

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

[Brian Norris]

On Tue, Dec 01, 2015 at 12:03:09PM +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"
> ---
>  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 ++-
>  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   | 16 ++---

^^ some errors here too

>  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 | 20 +++---
>  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, 426 insertions(+), 390 deletions(-)
> 

...

> diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
> index da93d7f..f8d5e27 100644
> --- a/drivers/mtd/nand/docg4.c
> +++ b/drivers/mtd/nand/docg4.c
> @@ -1305,14 +1305,13 @@ static int __init probe_docg4(struct platform_device 
> *pdev)
>   return -EIO;
>   }
>  
> - len = sizeof(struct mtd_info) + sizeof(struct nand_chip) +
> - sizeof(struct docg4_priv);
> - mtd = kzalloc(len, GFP_KERNEL);
> - if (mtd == NULL) {
> + len = sizeof(struct nand_chip) + sizeof(struct docg4_priv);
> + nand = kzalloc(len, GFP_KERNEL);
> + if (nand == NULL) {
>   retval = -ENOMEM;
>   goto fail;
>   }
> - nand = (struct nand_chip *) (mtd + 1);
> + mtd = nand_to_mtd(nand);
>   doc = (struct docg4_priv *) (nand + 1);
>   mtd->priv = nand;
>   nand->priv = doc;
> @@ -1355,13 +1354,12 @@ static int __init probe_docg4(struct platform_device 
> *pdev)
>  
>   fail:
>   iounmap(virtadr);
> - if (mtd) {
> + if (nand) {
>   /* re-declarations avoid compiler warning */
> - struct nand_chip *nand = mtd_to_nand(mtd);
>   struct docg4_priv *doc = nand->priv;
>   nand_release(mtd); /* deletes partitions and mtd devices */

drivers/mtd/nand/docg4.c: In function ‘probe_docg4’:

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

[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 *)(_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:

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

[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 v4 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Brian Norris]

Hi Boris,

On Fri, Dec 11, 2015 at 11:03:05PM +0100, Boris Brezillon wrote:
> On Thu, 10 Dec 2015 16:40:08 -0800
> Brian Norris <computersforpe...@gmail.com> wrote:
> > On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> > > Unregister the NAND device from the NAND subsystem when removing a denali
> > > NAND controller, otherwise the MTD attached to the NAND device is still
> > > exposed by the MTD layer, and accesses to this device will likely crash
> > > the system.
> > > 
> > > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> > > Cc: <sta...@vger.kernel.org> #3.8+
> > 
> > Does this follow these rules, from
> > Documentation/stable_kernel_rules.txt?
> > 
> >  - It must be obviously correct and tested.
> > 
> >  - It must fix a real bug that bothers people (not a, "This could be a
> >problem..." type thing).
> 
> Sorry to bring the "stable or not stable (that is the question :-))"
> debate back, but after thinking a bit more about the implications of
> this missing nand_release() call, I think it is worth backporting the
> fix to all stable kernels.
> The reason is, it can potentially introduce a security hole, because if
> the mtd device is not unregister but the underlying mtd object is freed
> and the kernel reuses the same memory region for a different object,
> the MTD layer will possibly call one of the mtd->_method() function,
> and this field might point to another completely different function.
> 
> You'll say that denali devices are probably never removed and this is
> the reason why people have never seen this problem before, which would
> be a good reason to not bother backporting the patch.
> But, given that the driver can be compiled as a module (the user can
> possibly load/unload it, which will in turn create/destroy the
> NAND/MTD device), and that the denali controller can be exposed through
> a PCI bus (which, AFAIK is hotpluggable), I really think this fix
> should be sent to stable.

That's all well and good, but still nobody has told me they've tested
this.

I've pushed your v5 (+ comments, + ack) to l2-mtd.git. If it gets
testing and this request is made again at that point, we can easily send
it to stable after it hits Linus' tree. See option 2 in
Documentation/stable_kernel_rules.txt. You can even send the email
yourself, just CC me and anyone else relevant. I'll ack it if it's been
tested.

Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Brian Norris]

On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> Unregister the NAND device from the NAND subsystem when removing a denali
> NAND controller, otherwise the MTD attached to the NAND device is still
> exposed by the MTD layer, and accesses to this device will likely crash
> the system.
> 
> Signed-off-by: Boris Brezillon 
> Cc:  #3.8+

Does this follow these rules, from
Documentation/stable_kernel_rules.txt?

 - It must be obviously correct and tested.

 - It must fix a real bug that bothers people (not a, "This could be a
   problem..." type thing).

> Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
> ---
>  drivers/mtd/nand/denali.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index 67eb2be..8feece3 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -1622,6 +1622,7 @@ EXPORT_SYMBOL(denali_init);
>  /* driver exit point */
>  void denali_remove(struct denali_nand_info *denali)
>  {
> + nand_release(>mtd);
>   denali_irq_cleanup(denali->irq, denali);
>   dma_unmap_single(denali->dev, denali->buf.dma_buf,
>denali->mtd.writesize + denali->mtd.oobsize,

It feels a bit odd to allow usage of MTD fields after it has been
unregistered. Maybe precompute this before the nand_release()?

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

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

[Brian Norris]

Hi,

On Thu, Dec 10, 2015 at 08:59:44AM +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 (patch 1 to 4) is a set of fixes/simple
> reworks easing the migration to mtd_to_nand().
> 
> 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

Thanks a lot for all the work here! Nice cleanups. I think I've pushed
everything correctly to l2-mtd.git. Please verify that things look sane
to you, if possible. There were a few v5's thrown in after the fact, as
well as other cleanups that required apply-conflicts.

I'll summarize below anything I remember that's changed since the cover
letter, for posterity.

> Changes since v3:
> - fix some bugs introduced when migrating to nand_to_mtd()
> - split the huge commit switching all drivers to nand_to_mtd() into several
>   commits (one per driver) to ease review and integration
> - add a simple fixes/reworks at the beginning of the series (mainly to
>   ease migration to nand_to_mtd())
> - drop already applied patches.
> 
> Changes since v2:
> - fix some build warnings/erros
> 
> 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
> 
> *** BLURB HERE ***

Nice blurb :)

> 
> Boris Brezillon (58):
>   mtd: nand: denali: add missing nand_release() call in denali_remove()

You sent v5 of this, and I added in the comment that was
written/requested afterward. That caused some small conflicts later.

>   mtd: nand: fsmc: create and use mtd_to_fsmc()
>   mtd: nand: nuc900: create and use mtd_to_nuc900()
>   mtd: nand: omap2: create and use mtd_to_omap()
>   mtd: nand: ams-delta: use the mtd instance embedded in struct
> nand_chip
>   mtd: nand: atmel: use the mtd instance embedded in struct nand_chip
>   mtd: nand: au1550nd: use the mtd instance embedded in struct nand_chip
>   mtd: nand: bcm47xx: use the mtd instance embedded in struct nand_chip
>   mtd: nand: bf5xx: use the mtd instance embedded in struct nand_chip
>   mtd: nand: brcm: use the mtd instance embedded in struct nand_chip
>   mtd: nand: cafe: use the mtd instance embedded in struct nand_chip
>   mtd: nand: cmx270: use the mtd instance embedded in struct nand_chip

^^ I dropped one comment in this one

>   mtd: nand: cs553x: use the mtd instance embedded in struct nand_chip
>   mtd: nand: davinci: use the mtd instance embedded in struct nand_chip
>   mtd: nand: denali: use the mtd instance embedded in struct nand_chip

You sent v5, but there were still trivial conflicts.

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

I cleaned some things up after this one, causing more trivial conflicts
later in the controller_data accessor patches.

>   mtd: nand: fsl_elbc: use the mtd instance embedded in struct nand_chip
>   mtd: nand: fsl_ifc: use the mtd instance embedded in struct nand_chip
>   mtd: nand: fsl_upm: use the mtd instance embedded in struct nand_chip
>   mtd: nand: fsmc: use the mtd instance embedded in struct nand_chip
>   mtd: nand: gpio: use the mtd instance embedded in struct nand_chip
>   mtd: nand: gpmi: use the mtd instance embedded in struct nand_chip
>   mtd: nand: hisi504: use the mtd instance embedded in struct nand_chip
>   mtd: nand: jz4740: use the mtd instance embedded in struct nand_chip
>   mtd: nand: lpc32xx: use the mtd instance embedded in struct nand_chip
>   mtd: nand: mpc5121: use the mtd instance embedded in struct nand_chip
>   mtd: nand: mxc: use the mtd instance embedded in struct nand_chip
>   mtd: nand: nandsim: use the mtd instance embedded in struct nand_chip
>   mtd: nand: ndfc: 

Re: [PATCH v4 55/58] mtd: nand: add helpers to access ->priv

[Brian Norris]

Hi Boris,

On Thu, Dec 10, 2015 at 09:00:39AM +0100, Boris Brezillon wrote:
> Add two helpers to access the field reserved for private controller data.
> This makes it clearer what this field is reserved for and ease future
> refactoring.

I agree with the refactoring part, but I'm not sure about the name. Is
it really "controller" data? That sounds like something that has 1
instance per controller. But the way this is sometimes used, we get 1
instance per NAND chip, and there may be more than one NAND chip per
controller.

So at the moment, this is more like opaque "driver data", like
dev_{get,set}_drvdata(), which doesn't really have a prescribed use --
it's up to the driver.

Notably, we already have a (sort of) 1-per-controler-instance field:
struct nand_hw_control (I notice we have both the 'controller' and
'hwcontrol' fields in nand_chip; that's pretty ugly too...). Those don't
have private data fields, but we could of course extend that if we
really want "controller" data.

Anyway, I don't feel like this question is resolved well enough to say
that we should go change all drivers to use these accessors. I know you
have bigger plans for putting more "controller" infrastructure into the
core drivers/mtd/nand/ code, so I'd like to see how that fits in here.

(If we're going to discuss this much more, I'd suggest a smaller CC
list. I'm mostly putting this here to show why I'm not taking the last
4 patches right now.)

Regards,
Brian

> Signed-off-by: Boris Brezillon 
> ---
>  include/linux/mtd/nand.h | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 2bee2e4..4aed4b2 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -739,6 +739,16 @@ static inline struct mtd_info *nand_to_mtd(struct 
> nand_chip *chip)
>   return >mtd;
>  }
>  
> +static inline void *nand_get_controller_data(struct nand_chip *chip)
> +{
> + return chip->priv;
> +}
> +
> +static inline void nand_set_controller_data(struct nand_chip *chip, void 
> *priv)
> +{
> + chip->priv = priv;
> +}
> +
>  /*
>   * NAND Flash Manufacturer ID Codes
>   */
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/27] mtd: nand: fix drivers abusing mtd->priv

[Brian Norris]

On Mon, Nov 16, 2015 at 02:37:34PM +0100, Boris Brezillon wrote:
> The ->priv field of the mtd_info object attached to a nand_chip device
> should point to the nand_chip device. The pxa and cafe drivers are
> assigning this field their own private structure, which works fine as long
> as the nand_chip field is the first one in the driver private struct but
> seems a bit fragile.
> Fix that by setting mtd->priv to point the nand_chip field and assigning
> chip->priv to the private structure head.
> 
> Signed-off-by: Boris Brezillon 

Applied to l2-mtd.git
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/27] mtd: nand: update examples in the documentation to use mtd_to_nand()

[Brian Norris]

On Mon, Nov 16, 2015 at 02:37:36PM +0100, Boris Brezillon wrote:
> mtd_to_nand() has been introduced to hide accesses to mtd->priv.
> All NAND controller drivers should use it instead of directly accessing
> the ->priv field.
> 
> Signed-off-by: Boris Brezillon 

Pushed to l2-mtd.git
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/27] mtd: nand: add an mtd_to_nand() helper

[Brian Norris]

On Mon, Nov 16, 2015 at 02:37:35PM +0100, Boris Brezillon wrote:
> Some drivers are retrieving the nand_chip pointer using the container_of
> macro on a struct wrapping both the nand_chip and the mtd_info struct while
> the standard way of retrieving this pointer is through mtd->priv.
> Provide an helper to do that.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  include/linux/mtd/nand.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 4f7c9b9..056d165 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -730,6 +730,11 @@ static inline struct device_node 
> *nand_get_flash_node(struct nand_chip *chip)
>   return chip->flash_node;
>  }
>  
> +static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
> +{
> + return mtd->priv;
> +}
> +

Pushed this patch to l2-mtd.git, though I rebased it directly onto
4.4-rc1 and then merged it in. That way, if any other subsystems want to
start using this in the 4.5 -next cycle (e.g., for patches 4-8), they
can pull it in without taking the rest of MTD.

I can push this to a separate branch or signed tag, if anyone wants.

Or, I can take the arch/ patches via MTD, if that's a better option.

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