RE: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Hi Romain, > -Original Message- > From: Romain Perier [mailto:romain.per...@gmail.com] > Sent: Monday, January 7, 2019 3:56 PM > To: Naga Sureshkumar Relli > Cc: Miquel Raynal ; Boris Brezillon > ; linux-...@lists.infradead.org; > peterpand...@micron.com; > linux-kernel@vger.kernel.org > Subject: Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm > pl353 > smc nand interface > > Hi, > > Le mer. 2 janv. 2019 à 10:23, Naga Sureshkumar Relli a > écrit : > > > > Hi, > > > > > -Original Message- > > > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] > > > Sent: Wednesday, January 2, 2019 2:04 PM > > > To: Romain Perier > > > Cc: Naga Sureshkumar Relli ; Boris Brezillon > > > ; linux-...@lists.infradead.org; > > > peterpand...@micron.com; linux-kernel@vger.kernel.org > > > Subject: Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver > > > for arm pl353 smc nand interface > > > > > > Hi Romain, > > > > > > Switching Boris address. > > > > > > Romain Perier wrote on Fri, 21 Dec 2018 > > > 10:17:50 +0100: > > > > > > > Hello, > > > > > > > > I have rebased this patch onto 4.19.11. I use it on a > > > > Zynq7000-based board with a NAND chip Micron MT29F4G08ABADAH4, since ~2 > weeks now. > > > > The only problem I have to report is that when I boot with an > > > > unchanged driver on my board, I get the following logs: > > > > > > > > [1.988797] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc > > > > [1.995184] nand: Micron MT29F4G08ABADAH4 > > > > [1.999187] nand: 512 MiB, SLC, erase size: 128 KiB, page size: > > > > 2048, OOB size: 64 > > > > [2.402661] nand: timeout while waiting for chip to become ready > > > > [2.408665] nand: timing mode 5 not acknowledged by the NAND chip > > > > [2.416251] Bad block table not found for chip 0 > > > > [2.422278] Bad block table not found for chip 0 > > > > [2.426903] Scanning device for bad blocks > > > > [2.431024] Bad eraseblock 0 at 0x > > > > [2.435509] Bad eraseblock 1 at 0x0002 > > > > [2.439978] Bad eraseblock 2 at 0x0004 > > > > [2.65] Bad eraseblock 3 at 0x0006 > > > > [2.448936] Bad eraseblock 4 at 0x0008 > > > > [2.453423] Bad eraseblock 5 at 0x000a > > > > [2.457893] Bad eraseblock 6 at 0x000c > > > > [2.462354] Bad eraseblock 7 at 0x000e > > > > [2.466841] Bad eraseblock 8 at 0x0010 > > > > [2.471304] Bad eraseblock 9 at 0x0012 > > > > [2.475793] Bad eraseblock 10 at 0x0014 > > > > [2.480349] Bad eraseblock 11 at 0x0016 > > > > > > > > [...] > > > > > > > > > > > > After investigation, it seems that during the nand_scan phase, the > > > > NAND subsystem tests different timing modes on the NAND chip (mode > > > > 0 seems to be apply during reset, and then it tries to detect the > > > > best mode supported by the NAND chip). Only the mode 0 works here, > > > > trying the use the mode 5 resuls in an error (as you can see in > > > > the log) and a bad BBT detection. Both modes are supported by the > > > > NAND chip. In order to fix this, I had to put the nfc timing into > > > > the device node of the nfc, inside the DT > > > (that's not a real fix, ihmo). > > > > > > Thanks for testing! Indeed, the ->setup_data_interface() callback should > > > be fixed. > > Ok, let me check. > > Meanwhile, can you share the timings that you put inside the DT? > > Sure, I have simply added an array in the DT: > > pl353,nand-controller-timings=<4 4 2 2 1 1 2>; But the below values are not matching with sdr mode 5 timings. The value at index 3, represents tWP_min and as per SDR mode5 timings this value is 1 (expressed in clock cycles). And also value at index 1 represents tWC_min and as per SDR mode5 timings this value is 2. I will also cross check the setup_data_interface() hook. Miqual, this version of driver is rebased on top of 4.19, I will send next version on top of 4.20 Thanks, Naga Sureshkumar Relli > > Then, I pass this array directly to pl353_smc_set_cycles(). (I got these > value from the hdf > originally, then I ported the
Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Hi,
Le mer. 2 janv. 2019 à 10:23, Naga Sureshkumar Relli
a écrit :
>
> Hi,
>
> > -Original Message-
> > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> > Sent: Wednesday, January 2, 2019 2:04 PM
> > To: Romain Perier
> > Cc: Naga Sureshkumar Relli ; Boris Brezillon
> > ; linux-...@lists.infradead.org;
> > peterpand...@micron.com;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for
> > arm pl353
> > smc nand interface
> >
> > Hi Romain,
> >
> > Switching Boris address.
> >
> > Romain Perier wrote on Fri, 21 Dec 2018
> > 10:17:50 +0100:
> >
> > > Hello,
> > >
> > > I have rebased this patch onto 4.19.11. I use it on a Zynq7000-based
> > > board with a NAND chip Micron MT29F4G08ABADAH4, since ~2 weeks now.
> > > The only problem I have to report is that when I boot with an
> > > unchanged driver on my board, I get the following logs:
> > >
> > > [1.988797] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
> > > [1.995184] nand: Micron MT29F4G08ABADAH4
> > > [1.999187] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048,
> > > OOB size: 64
> > > [2.402661] nand: timeout while waiting for chip to become ready
> > > [2.408665] nand: timing mode 5 not acknowledged by the NAND chip
> > > [2.416251] Bad block table not found for chip 0
> > > [2.422278] Bad block table not found for chip 0
> > > [2.426903] Scanning device for bad blocks
> > > [2.431024] Bad eraseblock 0 at 0x
> > > [2.435509] Bad eraseblock 1 at 0x0002
> > > [2.439978] Bad eraseblock 2 at 0x0004
> > > [2.65] Bad eraseblock 3 at 0x0006
> > > [2.448936] Bad eraseblock 4 at 0x0008
> > > [2.453423] Bad eraseblock 5 at 0x000a
> > > [2.457893] Bad eraseblock 6 at 0x000c
> > > [2.462354] Bad eraseblock 7 at 0x000e
> > > [2.466841] Bad eraseblock 8 at 0x0010
> > > [2.471304] Bad eraseblock 9 at 0x0012
> > > [2.475793] Bad eraseblock 10 at 0x0014
> > > [2.480349] Bad eraseblock 11 at 0x0016
> > >
> > > [...]
> > >
> > >
> > > After investigation, it seems that during the nand_scan phase, the
> > > NAND subsystem tests different timing modes on the NAND chip (mode 0
> > > seems to be apply during reset, and then it tries to detect the best
> > > mode supported by the NAND chip). Only the mode 0 works here, trying
> > > the use the mode 5 resuls in an error (as you can see in the log) and
> > > a bad BBT detection. Both modes are supported by the NAND chip. In
> > > order to fix this, I had to put the nfc timing into the device node of
> > > the nfc, inside the DT
> > (that's not a real fix, ihmo).
> >
> > Thanks for testing! Indeed, the ->setup_data_interface() callback should be
> > fixed.
> Ok, let me check.
> Meanwhile, can you share the timings that you put inside the DT?
Sure, I have simply added an array in the DT:
pl353,nand-controller-timings=<4 4 2 2 1 1 2>;
Then, I pass this array directly to pl353_smc_set_cycles(). (I got
these value from the hdf originally, then
I ported the DT to a mainline format, written by hand).
Hope this helps,
Regards,
Romain
> >
> > > Except this, everything is working as expected. Everything is stable
> > > with correct performances.
> > >
> > > If I can provide more informations, feel free to ask.
> >
> > [...]
> >
> > > > +static int pl353_setup_data_interface(struct mtd_info *mtd, int csline,
> > > > +const struct nand_data_interface
> > > > *conf) {
> > > > + struct nand_chip *chip = mtd_to_nand(mtd);
> > > > + struct pl353_nand_controller *xnfc =
> > > > + container_of(chip, struct pl353_nand_controller, chip);
> > > > + const struct nand_sdr_timings *sdr;
> > > > + u32 timings[7], mckperiodps;
> > > > +
> > > > + if (csline == NAND_DATA_IFACE_CHECK_ONLY)
> > > > + return 0;
> > > > +
> > > > + sdr = nand_get_sdr_timings(conf);
> > > > + if (IS_ERR(sdr))
> > > > + return PTR_ERR(sdr);
> > > > +
> > > > + /*
> > > > + * SDR timings are given in pico-seconds while NFC timings must be
> > &g
RE: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Hi,
> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Wednesday, January 2, 2019 2:04 PM
> To: Romain Perier
> Cc: Naga Sureshkumar Relli ; Boris Brezillon
> ; linux-...@lists.infradead.org;
> peterpand...@micron.com;
> linux-kernel@vger.kernel.org
> Subject: Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm
> pl353
> smc nand interface
>
> Hi Romain,
>
> Switching Boris address.
>
> Romain Perier wrote on Fri, 21 Dec 2018
> 10:17:50 +0100:
>
> > Hello,
> >
> > I have rebased this patch onto 4.19.11. I use it on a Zynq7000-based
> > board with a NAND chip Micron MT29F4G08ABADAH4, since ~2 weeks now.
> > The only problem I have to report is that when I boot with an
> > unchanged driver on my board, I get the following logs:
> >
> > [1.988797] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
> > [1.995184] nand: Micron MT29F4G08ABADAH4
> > [1.999187] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048,
> > OOB size: 64
> > [2.402661] nand: timeout while waiting for chip to become ready
> > [2.408665] nand: timing mode 5 not acknowledged by the NAND chip
> > [2.416251] Bad block table not found for chip 0
> > [2.422278] Bad block table not found for chip 0
> > [2.426903] Scanning device for bad blocks
> > [2.431024] Bad eraseblock 0 at 0x
> > [2.435509] Bad eraseblock 1 at 0x0002
> > [2.439978] Bad eraseblock 2 at 0x0004
> > [2.65] Bad eraseblock 3 at 0x0006
> > [2.448936] Bad eraseblock 4 at 0x0008
> > [2.453423] Bad eraseblock 5 at 0x000a
> > [2.457893] Bad eraseblock 6 at 0x000c
> > [2.462354] Bad eraseblock 7 at 0x000e
> > [2.466841] Bad eraseblock 8 at 0x0010
> > [2.471304] Bad eraseblock 9 at 0x0012
> > [2.475793] Bad eraseblock 10 at 0x0014
> > [2.480349] Bad eraseblock 11 at 0x0016
> >
> > [...]
> >
> >
> > After investigation, it seems that during the nand_scan phase, the
> > NAND subsystem tests different timing modes on the NAND chip (mode 0
> > seems to be apply during reset, and then it tries to detect the best
> > mode supported by the NAND chip). Only the mode 0 works here, trying
> > the use the mode 5 resuls in an error (as you can see in the log) and
> > a bad BBT detection. Both modes are supported by the NAND chip. In
> > order to fix this, I had to put the nfc timing into the device node of the
> > nfc, inside the DT
> (that's not a real fix, ihmo).
>
> Thanks for testing! Indeed, the ->setup_data_interface() callback should be
> fixed.
Ok, let me check.
Meanwhile, can you share the timings that you put inside the DT?
>
> > Except this, everything is working as expected. Everything is stable
> > with correct performances.
> >
> > If I can provide more informations, feel free to ask.
>
> [...]
>
> > > +static int pl353_setup_data_interface(struct mtd_info *mtd, int csline,
> > > +const struct nand_data_interface *conf) {
> > > + struct nand_chip *chip = mtd_to_nand(mtd);
> > > + struct pl353_nand_controller *xnfc =
> > > + container_of(chip, struct pl353_nand_controller, chip);
> > > + const struct nand_sdr_timings *sdr;
> > > + u32 timings[7], mckperiodps;
> > > +
> > > + if (csline == NAND_DATA_IFACE_CHECK_ONLY)
> > > + return 0;
> > > +
> > > + sdr = nand_get_sdr_timings(conf);
> > > + if (IS_ERR(sdr))
> > > + return PTR_ERR(sdr);
> > > +
> > > + /*
> > > + * SDR timings are given in pico-seconds while NFC timings must be
> > > + * expressed in NAND controller clock cycles.
> > > + */
> > > + mckperiodps = NSEC_PER_SEC / clk_get_rate(xnfc->mclk);
> > > + mckperiodps *= 1000;
> > > + if (sdr->tRC_min <= 2)
> > > + /*
> > > + * PL353 SMC needs one extra read cycle in SDR Mode 5
> > > + * This is not written anywhere in the datasheet but
> > > + * the results observed during testing.
> > > + */
> > > + timings[0] = DIV_ROUND_UP(sdr->tRC_min, mckperiodps) + 1;
> > > + else
> > > + timings[0] = DIV_ROUND_UP(sdr->tRC_min, mckperiodps);
> > > +
> > > + timings[1] = DIV_ROUND_UP(sdr->tWC_min, mckperiodps);
> > > + /*
> > > + * For all SDR mode
Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Hi Romain,
Switching Boris address.
Romain Perier wrote on Fri, 21 Dec 2018
10:17:50 +0100:
> Hello,
>
> I have rebased this patch onto 4.19.11. I use it on a Zynq7000-based
> board with a NAND chip Micron MT29F4G08ABADAH4, since ~2 weeks now.
> The only problem I have to report is that when I boot with an unchanged
> driver on my board, I get the following logs:
>
> [1.988797] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
> [1.995184] nand: Micron MT29F4G08ABADAH4
> [1.999187] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB
> size: 64
> [2.402661] nand: timeout while waiting for chip to become ready
> [2.408665] nand: timing mode 5 not acknowledged by the NAND chip
> [2.416251] Bad block table not found for chip 0
> [2.422278] Bad block table not found for chip 0
> [2.426903] Scanning device for bad blocks
> [2.431024] Bad eraseblock 0 at 0x
> [2.435509] Bad eraseblock 1 at 0x0002
> [2.439978] Bad eraseblock 2 at 0x0004
> [2.65] Bad eraseblock 3 at 0x0006
> [2.448936] Bad eraseblock 4 at 0x0008
> [2.453423] Bad eraseblock 5 at 0x000a
> [2.457893] Bad eraseblock 6 at 0x000c
> [2.462354] Bad eraseblock 7 at 0x000e
> [2.466841] Bad eraseblock 8 at 0x0010
> [2.471304] Bad eraseblock 9 at 0x0012
> [2.475793] Bad eraseblock 10 at 0x0014
> [2.480349] Bad eraseblock 11 at 0x0016
>
> [...]
>
>
> After investigation, it seems that during the nand_scan phase, the NAND
> subsystem tests different timing modes on the NAND chip (mode 0 seems to be
> apply during reset, and then it tries to detect the best mode supported by the
> NAND chip). Only the mode 0 works here, trying the use the mode 5 resuls in an
> error (as you can see in the log) and a bad BBT detection. Both modes are
> supported by the NAND chip. In order to fix this, I had to put the nfc timing
> into the device node of the nfc, inside the DT (that's not a real fix, ihmo).
Thanks for testing! Indeed, the ->setup_data_interface() callback should be
fixed.
> Except this, everything is working as expected. Everything is stable with
> correct
> performances.
>
> If I can provide more informations, feel free to ask.
[...]
> > +static int pl353_setup_data_interface(struct mtd_info *mtd, int csline,
> > + const struct nand_data_interface *conf)
> > +{
> > + struct nand_chip *chip = mtd_to_nand(mtd);
> > + struct pl353_nand_controller *xnfc =
> > + container_of(chip, struct pl353_nand_controller, chip);
> > + const struct nand_sdr_timings *sdr;
> > + u32 timings[7], mckperiodps;
> > +
> > + if (csline == NAND_DATA_IFACE_CHECK_ONLY)
> > + return 0;
> > +
> > + sdr = nand_get_sdr_timings(conf);
> > + if (IS_ERR(sdr))
> > + return PTR_ERR(sdr);
> > +
> > + /*
> > +* SDR timings are given in pico-seconds while NFC timings must be
> > +* expressed in NAND controller clock cycles.
> > +*/
> > + mckperiodps = NSEC_PER_SEC / clk_get_rate(xnfc->mclk);
> > + mckperiodps *= 1000;
> > + if (sdr->tRC_min <= 2)
> > + /*
> > +* PL353 SMC needs one extra read cycle in SDR Mode 5
> > +* This is not written anywhere in the datasheet but
> > +* the results observed during testing.
> > +*/
> > + timings[0] = DIV_ROUND_UP(sdr->tRC_min, mckperiodps) + 1;
> > + else
> > + timings[0] = DIV_ROUND_UP(sdr->tRC_min, mckperiodps);
> > +
> > + timings[1] = DIV_ROUND_UP(sdr->tWC_min, mckperiodps);
> > + /*
> > +* For all SDR modes, PL353 SMC needs tREA max value as 1,
> > +* Results observed during testing.
> > +*/
> > + timings[2] = PL353_TREA_MAX_VALUE;
> > + timings[3] = DIV_ROUND_UP(sdr->tWP_min, mckperiodps);
> > + timings[4] = DIV_ROUND_UP(sdr->tCLR_min, mckperiodps);
> > + timings[5] = DIV_ROUND_UP(sdr->tAR_min, mckperiodps);
> > + timings[6] = DIV_ROUND_UP(sdr->tRR_min, mckperiodps);
> > + pl353_smc_set_cycles(timings);
> > +
> > + return 0;
> > +}
>
> If I hack this function in order to limit the timings only to mode 0,
> everything works. Otherwise it hangs when it tries to apply mode 5.
>
Maybe Naga is not using a chip compatible with mode 5 and did not ran
into this issue?
Thanks,
Miquèl
Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Hello, I have rebased this patch onto 4.19.11. I use it on a Zynq7000-based board with a NAND chip Micron MT29F4G08ABADAH4, since ~2 weeks now. The only problem I have to report is that when I boot with an unchanged driver on my board, I get the following logs: [1.988797] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc [1.995184] nand: Micron MT29F4G08ABADAH4 [1.999187] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [2.402661] nand: timeout while waiting for chip to become ready [2.408665] nand: timing mode 5 not acknowledged by the NAND chip [2.416251] Bad block table not found for chip 0 [2.422278] Bad block table not found for chip 0 [2.426903] Scanning device for bad blocks [2.431024] Bad eraseblock 0 at 0x [2.435509] Bad eraseblock 1 at 0x0002 [2.439978] Bad eraseblock 2 at 0x0004 [2.65] Bad eraseblock 3 at 0x0006 [2.448936] Bad eraseblock 4 at 0x0008 [2.453423] Bad eraseblock 5 at 0x000a [2.457893] Bad eraseblock 6 at 0x000c [2.462354] Bad eraseblock 7 at 0x000e [2.466841] Bad eraseblock 8 at 0x0010 [2.471304] Bad eraseblock 9 at 0x0012 [2.475793] Bad eraseblock 10 at 0x0014 [2.480349] Bad eraseblock 11 at 0x0016 [...] After investigation, it seems that during the nand_scan phase, the NAND subsystem tests different timing modes on the NAND chip (mode 0 seems to be apply during reset, and then it tries to detect the best mode supported by the NAND chip). Only the mode 0 works here, trying the use the mode 5 resuls in an error (as you can see in the log) and a bad BBT detection. Both modes are supported by the NAND chip. In order to fix this, I had to put the nfc timing into the device node of the nfc, inside the DT (that's not a real fix, ihmo). Except this, everything is working as expected. Everything is stable with correct performances. If I can provide more informations, feel free to ask. On Tue, Aug 07, 2018 at 11:10:14AM +0530, Naga Sureshkumar Relli wrote: > Add driver for arm pl353 static memory controller nand interface with > HW ECC support. This controller is used in Xilinx Zynq SoC for > interfacing the NAND flash memory. > > Signed-off-by: Naga Sureshkumar Relli Tested-by: Romain Perier > --- > Changes in v12: > - Rebased the driver on top of v4.19 nand tree > - Removed nand_scan_ident() and nand_scan_tail(), and added > nand_controller_ops >with ->attach_chip() and used nand_scan() instead. > - Renamed pl353_nand_info structure to pl353_nand_controller > - Renamed nand_base and nandaddr in pl353_nand_controller to 'regs' and > 'buf_addr' > - Added new API pl353_wait_for_ecc_done() to wait for ecc done and call it > from >pl353_nand_write_page_hwecc() and pl353_nand_read_page_hwecc() > - Defined new macro for max ECC blocks > - Added return value check for ecc.calculate() > - Renamed pl353_nand_cmd_function() to pl353_nand_exec_op_cmd() > - Added x16 bus-width support > - The dependent driver pl353-smc is already reviewed and hence dropped the >smc driver > Changes in v11: > - Removed Documentation patch and added the required info in driver as >per Boris comments. > - Removed unwanted variables from pl353_nand_info as per Miquel comments > - Removed IO_ADDR_R/W. > - Replaced onhot() with hweight32() > - Defined macros for static values in function pl353_nand_correct_data() > - Removed all unnecessary delays > - Used nand_wait_ready() where ever is required > - Modifed the pl353_setup_data_interface() logic as per Miquel comments. > - Taken array instead of 7 values in pl353_setup_data_interface() and pass >it to smc driver. > - Added check to collect the return value of mtd_device_register(). > Changes in 10: > - Typos correction like nand to NAND and soc to SOC etc.. > - Defined macros for the values in pl353_nand_calculate_hwecc() > - Modifed ecc_status from int to char in pl353_nand_calculate_hwecc() > - Changed the return type form int to bool to the function >onehot() > - Removed udelay(1000) in pl353_cmd_function, as it is not required > - Dropped ecc->hwctl = NULL in pl353_ecc_init() > - Added an error message in pl353_ecc_init(), when there is no matching >oobsize > - Changed the variable from xnand to xnfc > - Added logic to get mtd->name from DT, if it is specified in DT > Changes in v9: > - Addressed the below comments given by Miquel > - instead of using pl353_nand_write32, use directly writel_relaxed > - Fixed check patch warnings > - Renamed write_buf/read_buf to write_data_op/read_data_op > - use BIT macro instead of 1 << nr > - Use NAND_ROW_ADDR_3 flag > - Use nand_wait_ready() > - Removed swecc functions > - Use address cycles as per size, instead of reading it from Parameter page > - Instead of writing too many patterns, use optional property > Changes in v8: > - Added
Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Hi Helmut, Helmut Grohne wrote on Mon, 5 Nov 2018 09:40:43 +0100: > On Tue, Aug 07, 2018 at 11:10:14AM +0530, Naga Sureshkumar Relli wrote: > > Add driver for arm pl353 static memory controller nand interface with > > HW ECC support. This controller is used in Xilinx Zynq SoC for > > interfacing the NAND flash memory. > > > > Signed-off-by: Naga Sureshkumar Relli > > --- > > Changes in v12: > > I attempted to apply this v12 together with the v11 of pl353-smc (which seems > to be the latest version) onto a vanilla v4.19 kernel tree. Application was > smooth and a build was without errors. During boot, my dmesg was spammed with > lots of repetitions of this: > > [5.816275] [ cut here ] > [5.820981] WARNING: CPU: 0 PID: 1 at > .../linux/drivers/mtd/nand/raw/nand_base.c:2773 > nand_subop_get_data_len+0x60/0xa4 > [5.836868] Modules linked in: > [5.836912] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW > 4.19.0-dirty #3 > [5.836929] Hardware name: Xilinx Zynq Platform > [5.836943] Backtrace: > [5.836981] [] (dump_backtrace) from [] > (show_stack+0x20/0x24) > [5.837004] r7:c062e618 r6: r5:600f0013 r4:c062e618 > [5.837027] [] (show_stack) from [] > (dump_stack+0xac/0xd8) > [5.837055] [] (dump_stack) from [] > (__warn+0x118/0x130) > [5.837079] r10: r9:c0270be8 r8:0ad5 r7:c0550358 r6:0009 > r5: > [5.837097] r4: r3:de4c6000 > [5.837122] [] (__warn) from [] > (warn_slowpath_null+0x50/0x58) > [5.837146] r9:de4c78c5 r8:da4d1010 r7:de4c78f8 r6:c0270be8 r5:0ad5 > r4:c0550358 > [5.837173] [] (warn_slowpath_null) from [] > (nand_subop_get_data_len+0x60/0xa4) > [5.837192] r6:003c r5:0003 r4:de4c7870 > [5.837217] [] (nand_subop_get_data_len) from [] > (pl353_nand_exec_op_cmd+0x60/0x314) > [5.837238] r7:de4c78f8 r6:003c r5:de4c7870 r4:0003 > [5.837262] [] (pl353_nand_exec_op_cmd) from [] > (nand_op_parser_exec_op+0x484/0x4e8) > [5.837285] r10:0002 r9:0014 r8:de4c790c r7:0004 r6:c0634260 > r5:c052cc44 > [5.837301] r4:c0620bcc > [5.837325] [] (nand_op_parser_exec_op) from [] > (pl353_nfc_exec_op+0x24/0x2c) > [5.837348] r10:de4c7a18 r9:0080 r8:03463678 r7:89705f41 r6:36b4a597 > r5:de4c78d0 > [5.837364] r4:da4d1010 > [5.837387] [] (pl353_nfc_exec_op) from [] > (nand_erase_op+0x150/0x1f0) > [5.837411] [] (nand_erase_op) from [] > (single_erase+0x28/0x2c) > [5.837434] r9:e08c1000 r8:0006 r7:0040 r6:0001 r5:0001ff80 > r4:da4d1010 > [5.837459] [] (single_erase) from [] > (nand_erase_nand+0x1f8/0x3f8) > [5.837484] [] (nand_erase_nand) from [] > (write_bbt+0x30c/0x748) > [5.837508] r10:0006 r9:e08c1000 r8:0006 r7:0002 r6:da4d1010 > r5: > [5.837524] r4:0ffc > [5.837549] [] (write_bbt) from [] > (nand_create_bbt+0x30c/0x6d0) > [5.837572] r10:c061fd2c r9:c061fce8 r8: r7:c061fd2c r6: > r5:0003 > [5.837587] r4: > [5.837614] [] (nand_create_bbt) from [] > (nand_scan_with_ids+0x1248/0x1e74) > [5.837636] r10:c0620524 r9:0004 r8:0001 r7:0004 r6:da4d1378 > r5:0001 > [5.837652] r4:da4d1010 > [5.837676] [] (nand_scan_with_ids) from [] > (pl353_nand_probe+0x144/0x208) > [5.837699] r10: r9:c0620ae0 r8:c0633ba0 r7: r6:da4d8e10 > r5:da4d8e00 > [5.837715] r4:da4d1010 > [5.837738] [] (pl353_nand_probe) from [] > (platform_drv_probe+0x44/0x7c) > [5.837757] r6:c0e0205c r5:c0620ae0 r4:da4d8e10 > [5.837783] [] (platform_drv_probe) from [] > (really_probe+0x27c/0x408) > [5.837801] r5:da4d8e10 r4:c0e02058 > [5.837827] [] (really_probe) from [] > (driver_probe_device+0x138/0x198) > [5.837850] r10: r9: r8:c0e02014 r7:0001 r6:de4c7c70 > r5:c0620ae0 > [5.837865] r4:da4d8e10 > [5.837891] [] (driver_probe_device) from [] > (__device_attach_driver+0xc8/0x144) > [5.837913] r9: r8:c0e02014 r6:de4c7c70 r5:da4d8e10 r4:c0620ae0 > [5.837938] [] (__device_attach_driver) from [] > (bus_for_each_drv+0x70/0xa4) > [5.837958] r7:0001 r6:c0251f0c r5:de4c7c70 r4: > [5.837982] [] (bus_for_each_drv) from [] > (__device_attach+0xb0/0x11c) > [5.838001] r6:c061e8d0 r5:da4d8e44 r4:da4d8e10 > [5.838027] [] (__device_attach) from [] > (device_initial_probe+0x1c/0x20) > [5.838047] r7:da4d8e10 r6:c061e8d0 r5:da4d8e10 r4:da4d8e18 > [5.838073] [] (device_initial_probe) from [] > (bus_probe_device+0x98/0xa0) > [5.838097] [] (bus_probe_device) from [] > (device_add+0x380/0x5dc) > [5.838117] r7:da4d8e10 r6:de595e00 r5: r4:da4d8e18 > [5.838142] [] (device_add) from [] > (of_device_add+0x44/0x4c) > [5.838164] r10:c0563da4 r9:dfbf0a70 r8:dfbf0ac0 r7: r6:de595e00 > r5: > [5.838180] r4:da4d8e00 > [5.838205] []
Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Hi Helmut, Helmut Grohne wrote on Mon, 5 Nov 2018 09:40:43 +0100: > On Tue, Aug 07, 2018 at 11:10:14AM +0530, Naga Sureshkumar Relli wrote: > > Add driver for arm pl353 static memory controller nand interface with > > HW ECC support. This controller is used in Xilinx Zynq SoC for > > interfacing the NAND flash memory. > > > > Signed-off-by: Naga Sureshkumar Relli > > --- > > Changes in v12: > > I attempted to apply this v12 together with the v11 of pl353-smc (which seems > to be the latest version) onto a vanilla v4.19 kernel tree. Application was > smooth and a build was without errors. During boot, my dmesg was spammed with > lots of repetitions of this: > > [5.816275] [ cut here ] > [5.820981] WARNING: CPU: 0 PID: 1 at > .../linux/drivers/mtd/nand/raw/nand_base.c:2773 > nand_subop_get_data_len+0x60/0xa4 > [5.836868] Modules linked in: > [5.836912] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW > 4.19.0-dirty #3 > [5.836929] Hardware name: Xilinx Zynq Platform > [5.836943] Backtrace: > [5.836981] [] (dump_backtrace) from [] > (show_stack+0x20/0x24) > [5.837004] r7:c062e618 r6: r5:600f0013 r4:c062e618 > [5.837027] [] (show_stack) from [] > (dump_stack+0xac/0xd8) > [5.837055] [] (dump_stack) from [] > (__warn+0x118/0x130) > [5.837079] r10: r9:c0270be8 r8:0ad5 r7:c0550358 r6:0009 > r5: > [5.837097] r4: r3:de4c6000 > [5.837122] [] (__warn) from [] > (warn_slowpath_null+0x50/0x58) > [5.837146] r9:de4c78c5 r8:da4d1010 r7:de4c78f8 r6:c0270be8 r5:0ad5 > r4:c0550358 > [5.837173] [] (warn_slowpath_null) from [] > (nand_subop_get_data_len+0x60/0xa4) > [5.837192] r6:003c r5:0003 r4:de4c7870 > [5.837217] [] (nand_subop_get_data_len) from [] > (pl353_nand_exec_op_cmd+0x60/0x314) > [5.837238] r7:de4c78f8 r6:003c r5:de4c7870 r4:0003 > [5.837262] [] (pl353_nand_exec_op_cmd) from [] > (nand_op_parser_exec_op+0x484/0x4e8) > [5.837285] r10:0002 r9:0014 r8:de4c790c r7:0004 r6:c0634260 > r5:c052cc44 > [5.837301] r4:c0620bcc > [5.837325] [] (nand_op_parser_exec_op) from [] > (pl353_nfc_exec_op+0x24/0x2c) > [5.837348] r10:de4c7a18 r9:0080 r8:03463678 r7:89705f41 r6:36b4a597 > r5:de4c78d0 > [5.837364] r4:da4d1010 > [5.837387] [] (pl353_nfc_exec_op) from [] > (nand_erase_op+0x150/0x1f0) > [5.837411] [] (nand_erase_op) from [] > (single_erase+0x28/0x2c) > [5.837434] r9:e08c1000 r8:0006 r7:0040 r6:0001 r5:0001ff80 > r4:da4d1010 > [5.837459] [] (single_erase) from [] > (nand_erase_nand+0x1f8/0x3f8) > [5.837484] [] (nand_erase_nand) from [] > (write_bbt+0x30c/0x748) > [5.837508] r10:0006 r9:e08c1000 r8:0006 r7:0002 r6:da4d1010 > r5: > [5.837524] r4:0ffc > [5.837549] [] (write_bbt) from [] > (nand_create_bbt+0x30c/0x6d0) > [5.837572] r10:c061fd2c r9:c061fce8 r8: r7:c061fd2c r6: > r5:0003 > [5.837587] r4: > [5.837614] [] (nand_create_bbt) from [] > (nand_scan_with_ids+0x1248/0x1e74) > [5.837636] r10:c0620524 r9:0004 r8:0001 r7:0004 r6:da4d1378 > r5:0001 > [5.837652] r4:da4d1010 > [5.837676] [] (nand_scan_with_ids) from [] > (pl353_nand_probe+0x144/0x208) > [5.837699] r10: r9:c0620ae0 r8:c0633ba0 r7: r6:da4d8e10 > r5:da4d8e00 > [5.837715] r4:da4d1010 > [5.837738] [] (pl353_nand_probe) from [] > (platform_drv_probe+0x44/0x7c) > [5.837757] r6:c0e0205c r5:c0620ae0 r4:da4d8e10 > [5.837783] [] (platform_drv_probe) from [] > (really_probe+0x27c/0x408) > [5.837801] r5:da4d8e10 r4:c0e02058 > [5.837827] [] (really_probe) from [] > (driver_probe_device+0x138/0x198) > [5.837850] r10: r9: r8:c0e02014 r7:0001 r6:de4c7c70 > r5:c0620ae0 > [5.837865] r4:da4d8e10 > [5.837891] [] (driver_probe_device) from [] > (__device_attach_driver+0xc8/0x144) > [5.837913] r9: r8:c0e02014 r6:de4c7c70 r5:da4d8e10 r4:c0620ae0 > [5.837938] [] (__device_attach_driver) from [] > (bus_for_each_drv+0x70/0xa4) > [5.837958] r7:0001 r6:c0251f0c r5:de4c7c70 r4: > [5.837982] [] (bus_for_each_drv) from [] > (__device_attach+0xb0/0x11c) > [5.838001] r6:c061e8d0 r5:da4d8e44 r4:da4d8e10 > [5.838027] [] (__device_attach) from [] > (device_initial_probe+0x1c/0x20) > [5.838047] r7:da4d8e10 r6:c061e8d0 r5:da4d8e10 r4:da4d8e18 > [5.838073] [] (device_initial_probe) from [] > (bus_probe_device+0x98/0xa0) > [5.838097] [] (bus_probe_device) from [] > (device_add+0x380/0x5dc) > [5.838117] r7:da4d8e10 r6:de595e00 r5: r4:da4d8e18 > [5.838142] [] (device_add) from [] > (of_device_add+0x44/0x4c) > [5.838164] r10:c0563da4 r9:dfbf0a70 r8:dfbf0ac0 r7: r6:de595e00 > r5: > [5.838180] r4:da4d8e00 > [5.838205] []
Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
On Tue, Aug 07, 2018 at 11:10:14AM +0530, Naga Sureshkumar Relli wrote: > Add driver for arm pl353 static memory controller nand interface with > HW ECC support. This controller is used in Xilinx Zynq SoC for > interfacing the NAND flash memory. > > Signed-off-by: Naga Sureshkumar Relli > --- > Changes in v12: I attempted to apply this v12 together with the v11 of pl353-smc (which seems to be the latest version) onto a vanilla v4.19 kernel tree. Application was smooth and a build was without errors. During boot, my dmesg was spammed with lots of repetitions of this: [5.816275] [ cut here ] [5.820981] WARNING: CPU: 0 PID: 1 at .../linux/drivers/mtd/nand/raw/nand_base.c:2773 nand_subop_get_data_len+0x60/0xa4 [5.836868] Modules linked in: [5.836912] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 4.19.0-dirty #3 [5.836929] Hardware name: Xilinx Zynq Platform [5.836943] Backtrace: [5.836981] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [5.837004] r7:c062e618 r6: r5:600f0013 r4:c062e618 [5.837027] [] (show_stack) from [] (dump_stack+0xac/0xd8) [5.837055] [] (dump_stack) from [] (__warn+0x118/0x130) [5.837079] r10: r9:c0270be8 r8:0ad5 r7:c0550358 r6:0009 r5: [5.837097] r4: r3:de4c6000 [5.837122] [] (__warn) from [] (warn_slowpath_null+0x50/0x58) [5.837146] r9:de4c78c5 r8:da4d1010 r7:de4c78f8 r6:c0270be8 r5:0ad5 r4:c0550358 [5.837173] [] (warn_slowpath_null) from [] (nand_subop_get_data_len+0x60/0xa4) [5.837192] r6:003c r5:0003 r4:de4c7870 [5.837217] [] (nand_subop_get_data_len) from [] (pl353_nand_exec_op_cmd+0x60/0x314) [5.837238] r7:de4c78f8 r6:003c r5:de4c7870 r4:0003 [5.837262] [] (pl353_nand_exec_op_cmd) from [] (nand_op_parser_exec_op+0x484/0x4e8) [5.837285] r10:0002 r9:0014 r8:de4c790c r7:0004 r6:c0634260 r5:c052cc44 [5.837301] r4:c0620bcc [5.837325] [] (nand_op_parser_exec_op) from [] (pl353_nfc_exec_op+0x24/0x2c) [5.837348] r10:de4c7a18 r9:0080 r8:03463678 r7:89705f41 r6:36b4a597 r5:de4c78d0 [5.837364] r4:da4d1010 [5.837387] [] (pl353_nfc_exec_op) from [] (nand_erase_op+0x150/0x1f0) [5.837411] [] (nand_erase_op) from [] (single_erase+0x28/0x2c) [5.837434] r9:e08c1000 r8:0006 r7:0040 r6:0001 r5:0001ff80 r4:da4d1010 [5.837459] [] (single_erase) from [] (nand_erase_nand+0x1f8/0x3f8) [5.837484] [] (nand_erase_nand) from [] (write_bbt+0x30c/0x748) [5.837508] r10:0006 r9:e08c1000 r8:0006 r7:0002 r6:da4d1010 r5: [5.837524] r4:0ffc [5.837549] [] (write_bbt) from [] (nand_create_bbt+0x30c/0x6d0) [5.837572] r10:c061fd2c r9:c061fce8 r8: r7:c061fd2c r6: r5:0003 [5.837587] r4: [5.837614] [] (nand_create_bbt) from [] (nand_scan_with_ids+0x1248/0x1e74) [5.837636] r10:c0620524 r9:0004 r8:0001 r7:0004 r6:da4d1378 r5:0001 [5.837652] r4:da4d1010 [5.837676] [] (nand_scan_with_ids) from [] (pl353_nand_probe+0x144/0x208) [5.837699] r10: r9:c0620ae0 r8:c0633ba0 r7: r6:da4d8e10 r5:da4d8e00 [5.837715] r4:da4d1010 [5.837738] [] (pl353_nand_probe) from [] (platform_drv_probe+0x44/0x7c) [5.837757] r6:c0e0205c r5:c0620ae0 r4:da4d8e10 [5.837783] [] (platform_drv_probe) from [] (really_probe+0x27c/0x408) [5.837801] r5:da4d8e10 r4:c0e02058 [5.837827] [] (really_probe) from [] (driver_probe_device+0x138/0x198) [5.837850] r10: r9: r8:c0e02014 r7:0001 r6:de4c7c70 r5:c0620ae0 [5.837865] r4:da4d8e10 [5.837891] [] (driver_probe_device) from [] (__device_attach_driver+0xc8/0x144) [5.837913] r9: r8:c0e02014 r6:de4c7c70 r5:da4d8e10 r4:c0620ae0 [5.837938] [] (__device_attach_driver) from [] (bus_for_each_drv+0x70/0xa4) [5.837958] r7:0001 r6:c0251f0c r5:de4c7c70 r4: [5.837982] [] (bus_for_each_drv) from [] (__device_attach+0xb0/0x11c) [5.838001] r6:c061e8d0 r5:da4d8e44 r4:da4d8e10 [5.838027] [] (__device_attach) from [] (device_initial_probe+0x1c/0x20) [5.838047] r7:da4d8e10 r6:c061e8d0 r5:da4d8e10 r4:da4d8e18 [5.838073] [] (device_initial_probe) from [] (bus_probe_device+0x98/0xa0) [5.838097] [] (bus_probe_device) from [] (device_add+0x380/0x5dc) [5.838117] r7:da4d8e10 r6:de595e00 r5: r4:da4d8e18 [5.838142] [] (device_add) from [] (of_device_add+0x44/0x4c) [5.838164] r10:c0563da4 r9:dfbf0a70 r8:dfbf0ac0 r7: r6:de595e00 r5: [5.838180] r4:da4d8e00 [5.838205] [] (of_device_add) from [] (of_platform_device_create_pdata+0xa0/0xd0) [5.838229] [] (of_platform_device_create_pdata) from [] (of_platform_device_create+0x20/0x24) [5.838252] r9:dfbf0a70 r8:dfbf0780 r7:c0470470 r6:ddfe9f50 r5: r4:de595e00 [5.838280] [] (of_platform_device_create)
Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
On Tue, Aug 07, 2018 at 11:10:14AM +0530, Naga Sureshkumar Relli wrote: > Add driver for arm pl353 static memory controller nand interface with > HW ECC support. This controller is used in Xilinx Zynq SoC for > interfacing the NAND flash memory. > > Signed-off-by: Naga Sureshkumar Relli > --- > Changes in v12: I attempted to apply this v12 together with the v11 of pl353-smc (which seems to be the latest version) onto a vanilla v4.19 kernel tree. Application was smooth and a build was without errors. During boot, my dmesg was spammed with lots of repetitions of this: [5.816275] [ cut here ] [5.820981] WARNING: CPU: 0 PID: 1 at .../linux/drivers/mtd/nand/raw/nand_base.c:2773 nand_subop_get_data_len+0x60/0xa4 [5.836868] Modules linked in: [5.836912] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 4.19.0-dirty #3 [5.836929] Hardware name: Xilinx Zynq Platform [5.836943] Backtrace: [5.836981] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [5.837004] r7:c062e618 r6: r5:600f0013 r4:c062e618 [5.837027] [] (show_stack) from [] (dump_stack+0xac/0xd8) [5.837055] [] (dump_stack) from [] (__warn+0x118/0x130) [5.837079] r10: r9:c0270be8 r8:0ad5 r7:c0550358 r6:0009 r5: [5.837097] r4: r3:de4c6000 [5.837122] [] (__warn) from [] (warn_slowpath_null+0x50/0x58) [5.837146] r9:de4c78c5 r8:da4d1010 r7:de4c78f8 r6:c0270be8 r5:0ad5 r4:c0550358 [5.837173] [] (warn_slowpath_null) from [] (nand_subop_get_data_len+0x60/0xa4) [5.837192] r6:003c r5:0003 r4:de4c7870 [5.837217] [] (nand_subop_get_data_len) from [] (pl353_nand_exec_op_cmd+0x60/0x314) [5.837238] r7:de4c78f8 r6:003c r5:de4c7870 r4:0003 [5.837262] [] (pl353_nand_exec_op_cmd) from [] (nand_op_parser_exec_op+0x484/0x4e8) [5.837285] r10:0002 r9:0014 r8:de4c790c r7:0004 r6:c0634260 r5:c052cc44 [5.837301] r4:c0620bcc [5.837325] [] (nand_op_parser_exec_op) from [] (pl353_nfc_exec_op+0x24/0x2c) [5.837348] r10:de4c7a18 r9:0080 r8:03463678 r7:89705f41 r6:36b4a597 r5:de4c78d0 [5.837364] r4:da4d1010 [5.837387] [] (pl353_nfc_exec_op) from [] (nand_erase_op+0x150/0x1f0) [5.837411] [] (nand_erase_op) from [] (single_erase+0x28/0x2c) [5.837434] r9:e08c1000 r8:0006 r7:0040 r6:0001 r5:0001ff80 r4:da4d1010 [5.837459] [] (single_erase) from [] (nand_erase_nand+0x1f8/0x3f8) [5.837484] [] (nand_erase_nand) from [] (write_bbt+0x30c/0x748) [5.837508] r10:0006 r9:e08c1000 r8:0006 r7:0002 r6:da4d1010 r5: [5.837524] r4:0ffc [5.837549] [] (write_bbt) from [] (nand_create_bbt+0x30c/0x6d0) [5.837572] r10:c061fd2c r9:c061fce8 r8: r7:c061fd2c r6: r5:0003 [5.837587] r4: [5.837614] [] (nand_create_bbt) from [] (nand_scan_with_ids+0x1248/0x1e74) [5.837636] r10:c0620524 r9:0004 r8:0001 r7:0004 r6:da4d1378 r5:0001 [5.837652] r4:da4d1010 [5.837676] [] (nand_scan_with_ids) from [] (pl353_nand_probe+0x144/0x208) [5.837699] r10: r9:c0620ae0 r8:c0633ba0 r7: r6:da4d8e10 r5:da4d8e00 [5.837715] r4:da4d1010 [5.837738] [] (pl353_nand_probe) from [] (platform_drv_probe+0x44/0x7c) [5.837757] r6:c0e0205c r5:c0620ae0 r4:da4d8e10 [5.837783] [] (platform_drv_probe) from [] (really_probe+0x27c/0x408) [5.837801] r5:da4d8e10 r4:c0e02058 [5.837827] [] (really_probe) from [] (driver_probe_device+0x138/0x198) [5.837850] r10: r9: r8:c0e02014 r7:0001 r6:de4c7c70 r5:c0620ae0 [5.837865] r4:da4d8e10 [5.837891] [] (driver_probe_device) from [] (__device_attach_driver+0xc8/0x144) [5.837913] r9: r8:c0e02014 r6:de4c7c70 r5:da4d8e10 r4:c0620ae0 [5.837938] [] (__device_attach_driver) from [] (bus_for_each_drv+0x70/0xa4) [5.837958] r7:0001 r6:c0251f0c r5:de4c7c70 r4: [5.837982] [] (bus_for_each_drv) from [] (__device_attach+0xb0/0x11c) [5.838001] r6:c061e8d0 r5:da4d8e44 r4:da4d8e10 [5.838027] [] (__device_attach) from [] (device_initial_probe+0x1c/0x20) [5.838047] r7:da4d8e10 r6:c061e8d0 r5:da4d8e10 r4:da4d8e18 [5.838073] [] (device_initial_probe) from [] (bus_probe_device+0x98/0xa0) [5.838097] [] (bus_probe_device) from [] (device_add+0x380/0x5dc) [5.838117] r7:da4d8e10 r6:de595e00 r5: r4:da4d8e18 [5.838142] [] (device_add) from [] (of_device_add+0x44/0x4c) [5.838164] r10:c0563da4 r9:dfbf0a70 r8:dfbf0ac0 r7: r6:de595e00 r5: [5.838180] r4:da4d8e00 [5.838205] [] (of_device_add) from [] (of_platform_device_create_pdata+0xa0/0xd0) [5.838229] [] (of_platform_device_create_pdata) from [] (of_platform_device_create+0x20/0x24) [5.838252] r9:dfbf0a70 r8:dfbf0780 r7:c0470470 r6:ddfe9f50 r5: r4:de595e00 [5.838280] [] (of_platform_device_create)
