Hi Boris, > > > > > > Then fill-in these two hooks from the manufacturer code, without > > the > > > > > > postponed init. > > > > > > > > > > > > > > > > But in the final of nand_scan_tail(), mtd->_lock/_unlock will be > > > > > filled by NULL, right ? > > > > > > > > The NAND core should set mtd->_lock/_unlock() to NAND specific hooks > > so > > > > that the MTD layer is abstracted and and drivers do not see it. Then, > > > > in the NAND helper, either there is no specific hook defined by a > > > > manufacturer driver and you return -ENOTSUPP, or you execute the > > > > defined hook. > > > > > > okay, patch specific manufacturer _lock/_unlock driver > > > in nand_manufacturer_init(); > > > > > > and in the final of nand_scan_tail() > > > if (!mtd->_lock) > > > mtd->_lock = NULL; > > > if (!mtd->_unlock) > > > mtd->_unlock = NULL; > > > > > > I'm still considering of post_init() in nand_scan_tail() for > > MTD layer default call-back function replacement because > > there would be more call-back functions need it. > > i.e., > > MTD->_lock/_unlokc > > MTD->_suspend/_resume > > Again, that's something that needs to be abstracted so that both the > NAND manufacturer driver and the NAND controller driver can take > appropriate actions on suspend/resume operations. > > > NTD->_point/_unpoint > > ->_point/_unpoint() are irrelevant for a NAND chip. > > > ... > > > > > > actually, my patch series are including MTD->_locl/_unlock and > > MTD->_suspend/_resume. how do you think ? > > Miquel was suggesting to add nand_chip->{lock,unlock,is_locked}() > methods that would be implemented by the NAND manufacturer drivers, and > have generic wrappers implemented in nand_base.c: > > static int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len) > { > struct nand_chip *chip = mtd_to_nand(mtd); > > if (!chip->lock) > return -ENOTSUPP; > > return chip->lock(chip, ofs, len); > } > > ... > > If you do that, you won't need this post_init() hook. got it, but ... user space program flash_lock/flash_unlock are calling mtd_lock() & mtd_unlock(). i.e., int mtd_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len) { if (!mtd->_lock) return -EOPNOTSUPP; if (ofs < 0 || ofs >= mtd->size || len > mtd->size - ofs) return -EINVAL; if (!len) return 0; return mtd->_lock(mtd, ofs, len); } thanks for your time & comments. Mason CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. ===================================================================== ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. ===================================================================== ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/