| Message ID | 20210522205136.19465-1-han.xu@nxp.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] mtd: nand: raw: gpmi: new bch geometry settings | expand |
On 22/05/2021 22.51, Han Xu wrote: > The code change updates the gpmi driver bch geometry settings, the NAND > chips required minimum ecc strength and step size will be the default > value. It also proposes a new way to set bch geometry for large oob NAND > and provides an option to keep the legacy bch geometry setting for > backward compatibility. This will break all existing devicetree's. (this happened to us with the same style already merged u-boot patch) > > - For the legacy bch geometry settings > The driver uses legacy bch geometry settings if explicitly enabled it in > DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old > that do NOT provide any required ecc info. NAND's are providing the minimum required ecc, the now legacy method actually gives more ecc bits and quite cheap when using hw ecc. > > The legacy_set_geometry() sets the data chunk size(step_size) larger > than oob size to make sure BBM locates in data chunk, then set the > maximum ecc stength oob can hold. It always use unbalanced ECC layout, > which ecc0 will cover both meta and data0 chunk. > > This algorithm can NOT provide strong enough ecc for some NAND chips, > such as some 8K+744 MLC NAND. We still leave it here just for backward > compatibility and als for some quite old version NAND chips support. It > should be en/disabled in both u-boot and kernel at the same time. > > - For the large oob bch geometry settings > This type of setting will be used for NAND chips, which oob size is > larger than 1024B OR NAND required step size is small than oob size, > the general idea is, > > 1.Try all ECC strength from the minimum value required by NAND chip > to the maximum one that works, any ECC makes the BBM locate in > data chunk can be eligible. > > 2.If none of them works, using separate ECC for meta, which will add > one extra ecc with the same ECC strength as other data chunks. > This extra ECC can guarantee BBM located in data chunk, also we > need to check if oob can afford it. > > - For all other common cases > set the bch geometry by chip required strength and step size, which uses > the minimum ecc strength chip required. > > Signed-off-by: Han Xu <han.xu@nxp.com> One further point, u-boot older than v2020.04 will not be aligned with the way ecc bits is calculated with this patch applied(without the legacy option set). It's quite a mess :/ I would recommend to use the legacy mode as default, and add the new style as "modern" option. (Also in u-boot) /Sean
On 21/05/23 07:44PM, Sean Nyekjaer wrote: > On 22/05/2021 22.51, Han Xu wrote: > > The code change updates the gpmi driver bch geometry settings, the NAND > > chips required minimum ecc strength and step size will be the default > > value. It also proposes a new way to set bch geometry for large oob NAND > > and provides an option to keep the legacy bch geometry setting for > > backward compatibility. > > This will break all existing devicetree's. (this happened to us with the same style already merged u-boot patch) > > > > > - For the legacy bch geometry settings > > The driver uses legacy bch geometry settings if explicitly enabled it in > > DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old > > that do NOT provide any required ecc info. > > NAND's are providing the minimum required ecc, the now legacy method > actually gives more ecc bits and quite cheap when using hw ecc. > > > > > The legacy_set_geometry() sets the data chunk size(step_size) larger > > than oob size to make sure BBM locates in data chunk, then set the > > maximum ecc stength oob can hold. It always use unbalanced ECC layout, > > which ecc0 will cover both meta and data0 chunk. > > > > This algorithm can NOT provide strong enough ecc for some NAND chips, > > such as some 8K+744 MLC NAND. We still leave it here just for backward > > compatibility and als for some quite old version NAND chips support. It > > should be en/disabled in both u-boot and kernel at the same time. > > > > - For the large oob bch geometry settings > > This type of setting will be used for NAND chips, which oob size is > > larger than 1024B OR NAND required step size is small than oob size, > > the general idea is, > > > > 1.Try all ECC strength from the minimum value required by NAND chip > > to the maximum one that works, any ECC makes the BBM locate in > > data chunk can be eligible. > > > > 2.If none of them works, using separate ECC for meta, which will add > > one extra ecc with the same ECC strength as other data chunks. > > This extra ECC can guarantee BBM located in data chunk, also we > > need to check if oob can afford it. > > > > - For all other common cases > > set the bch geometry by chip required strength and step size, which uses > > the minimum ecc strength chip required. > > > > Signed-off-by: Han Xu <han.xu@nxp.com> > > One further point, u-boot older than v2020.04 will not be aligned with the way ecc bits is > calculated with this patch applied(without the legacy option set). > > It's quite a mess :/ > I would recommend to use the legacy mode as default, and add the new style as "modern" option. > (Also in u-boot) > > /Sean Hi Sean, I know this change brings mess but the legacy way is wrong. The way it determine the data chunk size is arbitrary, take any 8K + 448 (not 744, typo in previous comments) Micron NAND chips as example, the legacy way can only provide 16bit ecc since data chunk size is set to 512B, but 24b/1K is required by NAND chips. According to the A/B X/Y ecc requirement, this is not acceptable. The new implementation might get weak ecc than legacy way in some cases but it is safety guaranteed. This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes the driver behaviors and makes totally different output compared with older versions. I know changes bring mess but we have to accept it at some point rather than keep compromising to the wrong way. The change has been in NXP kernel fork for a while, so quite a few customers are using this bch geometry settings. I hope it can be upstreamed, any other things I can do may mitigate the imapact?
Hi Han, Han Xu <han.xu@nxp.com> wrote on Tue, 25 May 2021 14:13:08 -0500: > On 21/05/23 07:44PM, Sean Nyekjaer wrote: > > On 22/05/2021 22.51, Han Xu wrote: > > > The code change updates the gpmi driver bch geometry settings, the NAND > > > chips required minimum ecc strength and step size will be the default > > > value. It also proposes a new way to set bch geometry for large oob NAND > > > and provides an option to keep the legacy bch geometry setting for > > > backward compatibility. > > > > This will break all existing devicetree's. (this happened to us with the same style already merged u-boot patch) > > > > > > > > - For the legacy bch geometry settings > > > The driver uses legacy bch geometry settings if explicitly enabled it in > > > DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old > > > that do NOT provide any required ecc info. > > > > NAND's are providing the minimum required ecc, the now legacy method > > actually gives more ecc bits and quite cheap when using hw ecc. > > > > > > > > The legacy_set_geometry() sets the data chunk size(step_size) larger > > > than oob size to make sure BBM locates in data chunk, then set the > > > maximum ecc stength oob can hold. It always use unbalanced ECC layout, > > > which ecc0 will cover both meta and data0 chunk. > > > > > > This algorithm can NOT provide strong enough ecc for some NAND chips, > > > such as some 8K+744 MLC NAND. We still leave it here just for backward > > > compatibility and als for some quite old version NAND chips support. It > > > should be en/disabled in both u-boot and kernel at the same time. > > > > > > - For the large oob bch geometry settings > > > This type of setting will be used for NAND chips, which oob size is > > > larger than 1024B OR NAND required step size is small than oob size, > > > the general idea is, > > > > > > 1.Try all ECC strength from the minimum value required by NAND chip > > > to the maximum one that works, any ECC makes the BBM locate in > > > data chunk can be eligible. > > > > > > 2.If none of them works, using separate ECC for meta, which will add > > > one extra ecc with the same ECC strength as other data chunks. > > > This extra ECC can guarantee BBM located in data chunk, also we > > > need to check if oob can afford it. > > > > > > - For all other common cases > > > set the bch geometry by chip required strength and step size, which uses > > > the minimum ecc strength chip required. > > > > > > Signed-off-by: Han Xu <han.xu@nxp.com> > > > > One further point, u-boot older than v2020.04 will not be aligned with the way ecc bits is > > calculated with this patch applied(without the legacy option set). > > > > It's quite a mess :/ > > I would recommend to use the legacy mode as default, and add the new style as "modern" option. > > (Also in u-boot) > > > > /Sean > > > Hi Sean, > > I know this change brings mess but the legacy way is wrong. The way it determine > the data chunk size is arbitrary, Yes, that's always the case: all default choices are arbitrary in the Linux kernel, there is actually a lot of logic provided by the core to handle that, unless the user requires something specific. > take any 8K + 448 (not 744, typo in previous > comments) Micron NAND chips as example, the legacy way can only provide 16bit > ecc since data chunk size is set to 512B, but 24b/1K is required by NAND chips. This means a strength of 32 bits per kilobyte of data vs 24 bits per kilobyte. > According to the A/B X/Y ecc requirement, this is not acceptable. What you call the legacy way is even better, the only situation where it may be an issue is if the NAND chip does not feature enough OOB bytes to store the ECC codes, which does not seem to be your primary concern here. > The new implementation might get weak ecc than legacy way in some cases but it > is safety guaranteed. What does "safety guaranteed" means? > This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes > the driver behaviors and makes totally different output compared with older > versions. I know changes bring mess but we have to accept it at some point > rather than keep compromising to the wrong way. How is this an argument? I am usually in favor of moving forward when there is a real justification, but this does not seem the case, unless I am understanding it all the wrong way. > The change has been in NXP kernel fork for a while, so quite a few customers are > using this bch geometry settings. I hope it can be upstreamed, any other things > I can do may mitigate the imapact? You are well aware of the upstreaming process, trying to merge something locally, making it used and then complaining because not upstreaming it would break your customers really is your own responsibility. IMHO the solutions are: - the current (mainline) default will remain the standard for geometries which are already widely supported - if there are new geometries that must be supported and do not fit because of the "legacy" logic, then you may detect that and try to fallback to the "modern" way of calculating the ECC parameters (or even jump directly to the modern way if the geometry really is not currently supported officially) - if your customers want a specific chunk size/strength when rebasing on top of a mainline kernel there are DT properties which do that anyway - follow Sean advice: introduce a property requesting to use the 'modern' or 'legacy' logic (with a better name than modern) but first check with Rob that this if valid. Thanks, Miquèl
On 21/05/26 09:41AM, Miquel Raynal wrote: > Hi Han, > > Han Xu <han.xu@nxp.com> wrote on Tue, 25 May 2021 14:13:08 -0500: > > > On 21/05/23 07:44PM, Sean Nyekjaer wrote: > > > On 22/05/2021 22.51, Han Xu wrote: > > > > The code change updates the gpmi driver bch geometry settings, the NAND > > > > chips required minimum ecc strength and step size will be the default > > > > value. It also proposes a new way to set bch geometry for large oob NAND > > > > and provides an option to keep the legacy bch geometry setting for > > > > backward compatibility. > > > > > > This will break all existing devicetree's. (this happened to us with the same style already merged u-boot patch) > > > > > > > > > > > - For the legacy bch geometry settings > > > > The driver uses legacy bch geometry settings if explicitly enabled it in > > > > DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old > > > > that do NOT provide any required ecc info. > > > > > > NAND's are providing the minimum required ecc, the now legacy method > > > actually gives more ecc bits and quite cheap when using hw ecc. > > > > > > > > > > > The legacy_set_geometry() sets the data chunk size(step_size) larger > > > > than oob size to make sure BBM locates in data chunk, then set the > > > > maximum ecc stength oob can hold. It always use unbalanced ECC layout, > > > > which ecc0 will cover both meta and data0 chunk. > > > > > > > > This algorithm can NOT provide strong enough ecc for some NAND chips, > > > > such as some 8K+744 MLC NAND. We still leave it here just for backward > > > > compatibility and als for some quite old version NAND chips support. It > > > > should be en/disabled in both u-boot and kernel at the same time. > > > > > > > > - For the large oob bch geometry settings > > > > This type of setting will be used for NAND chips, which oob size is > > > > larger than 1024B OR NAND required step size is small than oob size, > > > > the general idea is, > > > > > > > > 1.Try all ECC strength from the minimum value required by NAND chip > > > > to the maximum one that works, any ECC makes the BBM locate in > > > > data chunk can be eligible. > > > > > > > > 2.If none of them works, using separate ECC for meta, which will add > > > > one extra ecc with the same ECC strength as other data chunks. > > > > This extra ECC can guarantee BBM located in data chunk, also we > > > > need to check if oob can afford it. > > > > > > > > - For all other common cases > > > > set the bch geometry by chip required strength and step size, which uses > > > > the minimum ecc strength chip required. > > > > > > > > Signed-off-by: Han Xu <han.xu@nxp.com> > > > > > > One further point, u-boot older than v2020.04 will not be aligned with the way ecc bits is > > > calculated with this patch applied(without the legacy option set). > > > > > > It's quite a mess :/ > > > I would recommend to use the legacy mode as default, and add the new style as "modern" option. > > > (Also in u-boot) > > > > > > /Sean > > > > > > Hi Sean, > > > > I know this change brings mess but the legacy way is wrong. The way it determine > > the data chunk size is arbitrary, > > Yes, that's always the case: all default choices are arbitrary in the > Linux kernel, there is actually a lot of logic provided by the core to > handle that, unless the user requires something specific. > > > take any 8K + 448 (not 744, typo in previous > > comments) Micron NAND chips as example, the legacy way can only provide 16bit > > ecc since data chunk size is set to 512B, but 24b/1K is required by NAND chips. > > This means a strength of 32 bits per kilobyte of data vs 24 bits per > kilobyte. > > > According to the A/B X/Y ecc requirement, this is not acceptable. > > What you call the legacy way is even better, the only situation where > it may be an issue is if the NAND chip does not feature enough OOB > bytes to store the ECC codes, which does not seem to be your primary > concern here. Hi Miquel, The legacy ecc strength is fine or even better by average, but it doesn't meet the requirement #2 (1) A / B >= X / Y (2) A >= X that's my primary concern. > > > The new implementation might get weak ecc than legacy way in some cases but it > > is safety guaranteed. > > What does "safety guaranteed" means? set minimum ecc required by nand chip at least meet all requirements > > > This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes > > the driver behaviors and makes totally different output compared with older > > versions. I know changes bring mess but we have to accept it at some point > > rather than keep compromising to the wrong way. > > How is this an argument? I am usually in favor of moving forward when > there is a real justification, but this does not seem the case, unless > I am understanding it all the wrong way. > > > The change has been in NXP kernel fork for a while, so quite a few customers are > > using this bch geometry settings. I hope it can be upstreamed, any other things > > I can do may mitigate the imapact? > > You are well aware of the upstreaming process, trying to merge > something locally, making it used and then complaining because not > upstreaming it would break your customers really is your own > responsibility. Sorry I understand I should try upstreaming it early, so I am still looking for a chance to avoid further divergence. > > IMHO the solutions are: > - the current (mainline) default will remain the standard for > geometries which are already widely supported > - if there are new geometries that must be supported and do not fit > because of the "legacy" logic, then you may detect that and try > to fallback to the "modern" way of calculating the ECC > parameters (or even jump directly to the modern way if the geometry > really is not currently supported officially) > - if your customers want a specific chunk size/strength when > rebasing on top of a mainline kernel there are DT properties which do > that anyway > - follow Sean advice: introduce a property requesting to use the > 'modern' or 'legacy' logic (with a better name than modern) but first > check with Rob that this if valid. > > Thanks, > Miquèl
Hi Han, Han Xu <han.xu@nxp.com> wrote on Wed, 26 May 2021 09:17:00 -0500: > On 21/05/26 09:41AM, Miquel Raynal wrote: > > Hi Han, > > > > Han Xu <han.xu@nxp.com> wrote on Tue, 25 May 2021 14:13:08 -0500: > > > > > On 21/05/23 07:44PM, Sean Nyekjaer wrote: > > > > On 22/05/2021 22.51, Han Xu wrote: > > > > > The code change updates the gpmi driver bch geometry settings, the NAND > > > > > chips required minimum ecc strength and step size will be the default > > > > > value. It also proposes a new way to set bch geometry for large oob NAND > > > > > and provides an option to keep the legacy bch geometry setting for > > > > > backward compatibility. > > > > > > > > This will break all existing devicetree's. (this happened to us with the same style already merged u-boot patch) > > > > > > > > > > > > > > - For the legacy bch geometry settings > > > > > The driver uses legacy bch geometry settings if explicitly enabled it in > > > > > DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old > > > > > that do NOT provide any required ecc info. > > > > > > > > NAND's are providing the minimum required ecc, the now legacy method > > > > actually gives more ecc bits and quite cheap when using hw ecc. > > > > > > > > > > > > > > The legacy_set_geometry() sets the data chunk size(step_size) larger > > > > > than oob size to make sure BBM locates in data chunk, then set the > > > > > maximum ecc stength oob can hold. It always use unbalanced ECC layout, > > > > > which ecc0 will cover both meta and data0 chunk. > > > > > > > > > > This algorithm can NOT provide strong enough ecc for some NAND chips, > > > > > such as some 8K+744 MLC NAND. We still leave it here just for backward > > > > > compatibility and als for some quite old version NAND chips support. It > > > > > should be en/disabled in both u-boot and kernel at the same time. > > > > > > > > > > - For the large oob bch geometry settings > > > > > This type of setting will be used for NAND chips, which oob size is > > > > > larger than 1024B OR NAND required step size is small than oob size, > > > > > the general idea is, > > > > > > > > > > 1.Try all ECC strength from the minimum value required by NAND chip > > > > > to the maximum one that works, any ECC makes the BBM locate in > > > > > data chunk can be eligible. > > > > > > > > > > 2.If none of them works, using separate ECC for meta, which will add > > > > > one extra ecc with the same ECC strength as other data chunks. > > > > > This extra ECC can guarantee BBM located in data chunk, also we > > > > > need to check if oob can afford it. > > > > > > > > > > - For all other common cases > > > > > set the bch geometry by chip required strength and step size, which uses > > > > > the minimum ecc strength chip required. > > > > > > > > > > Signed-off-by: Han Xu <han.xu@nxp.com> > > > > > > > > One further point, u-boot older than v2020.04 will not be aligned with the way ecc bits is > > > > calculated with this patch applied(without the legacy option set). > > > > > > > > It's quite a mess :/ > > > > I would recommend to use the legacy mode as default, and add the new style as "modern" option. > > > > (Also in u-boot) > > > > > > > > /Sean > > > > > > > > > Hi Sean, > > > > > > I know this change brings mess but the legacy way is wrong. The way it determine > > > the data chunk size is arbitrary, > > > > Yes, that's always the case: all default choices are arbitrary in the > > Linux kernel, there is actually a lot of logic provided by the core to > > handle that, unless the user requires something specific. > > > > > take any 8K + 448 (not 744, typo in previous > > > comments) Micron NAND chips as example, the legacy way can only provide 16bit > > > ecc since data chunk size is set to 512B, but 24b/1K is required by NAND chips. > > > > This means a strength of 32 bits per kilobyte of data vs 24 bits per > > kilobyte. > > > > > According to the A/B X/Y ecc requirement, this is not acceptable. > > > > What you call the legacy way is even better, the only situation where > > it may be an issue is if the NAND chip does not feature enough OOB > > bytes to store the ECC codes, which does not seem to be your primary > > concern here. > > Hi Miquel, > > The legacy ecc strength is fine or even better by average, but it doesn't meet > the requirement #2 > > (1) A / B >= X / Y > (2) A >= X > > that's my primary concern. I understand that (2) might be ideal to meet but is breaking all the boards that use this driver really worth the trouble? Short answer: no. So we need to adapt the calculation for new boards/new flash chips/certain geometries at most. > > > The new implementation might get weak ecc than legacy way in some cases but it > > > is safety guaranteed. > > > > What does "safety guaranteed" means? > > set minimum ecc required by nand chip at least meet all requirements > > > > > > This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes > > > the driver behaviors and makes totally different output compared with older > > > versions. I know changes bring mess but we have to accept it at some point > > > rather than keep compromising to the wrong way. > > > > How is this an argument? I am usually in favor of moving forward when > > there is a real justification, but this does not seem the case, unless > > I am understanding it all the wrong way. > > > > > The change has been in NXP kernel fork for a while, so quite a few customers are > > > using this bch geometry settings. I hope it can be upstreamed, any other things > > > I can do may mitigate the imapact? > > > > You are well aware of the upstreaming process, trying to merge > > something locally, making it used and then complaining because not > > upstreaming it would break your customers really is your own > > responsibility. > > Sorry I understand I should try upstreaming it early, so I am still looking for > a chance to avoid further divergence. > > > > > IMHO the solutions are: > > - the current (mainline) default will remain the standard for > > geometries which are already widely supported > > - if there are new geometries that must be supported and do not fit > > because of the "legacy" logic, then you may detect that and try > > to fallback to the "modern" way of calculating the ECC > > parameters (or even jump directly to the modern way if the geometry > > really is not currently supported officially) > > - if your customers want a specific chunk size/strength when > > rebasing on top of a mainline kernel there are DT properties which do > > that anyway > > - follow Sean advice: introduce a property requesting to use the > > 'modern' or 'legacy' logic (with a better name than modern) but first > > check with Rob that this if valid. Another hint: please check the core helpers and use them instead of trying to re-invent the wheel: normally just describing the engine capabilities and calling a single helper should do the trick. But this 'new' calculation should only apply to eg. MLC devices or devices with specific geometries, not to all devices. Thanks, Miquèl
On Wed, May 26, 2021 at 05:31:23PM +0200, Miquel Raynal wrote: > Hi Han, > [ ... ] > > I understand that (2) might be ideal to meet but is breaking all the > boards that use this driver really worth the trouble? > > Short answer: no. So we need to adapt the calculation for new > boards/new flash chips/certain geometries at most. > > > > > The new implementation might get weak ecc than legacy way in some cases but it > > > > is safety guaranteed. > > > > > > What does "safety guaranteed" means? > > > > set minimum ecc required by nand chip at least meet all requirements > > > > > > > > > This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes > > > > the driver behaviors and makes totally different output compared with older > > > > versions. I know changes bring mess but we have to accept it at some point > > > > rather than keep compromising to the wrong way. > > > > > > How is this an argument? I am usually in favor of moving forward when > > > there is a real justification, but this does not seem the case, unless > > > I am understanding it all the wrong way. > > > > > > > The change has been in NXP kernel fork for a while, so quite a few customers are > > > > using this bch geometry settings. I hope it can be upstreamed, any other things > > > > I can do may mitigate the imapact? > > > > > > You are well aware of the upstreaming process, trying to merge > > > something locally, making it used and then complaining because not > > > upstreaming it would break your customers really is your own > > > responsibility. > > > > Sorry I understand I should try upstreaming it early, so I am still looking for > > a chance to avoid further divergence. > > > > > > > > IMHO the solutions are: > > > - the current (mainline) default will remain the standard for > > > geometries which are already widely supported > > > - if there are new geometries that must be supported and do not fit > > > because of the "legacy" logic, then you may detect that and try > > > to fallback to the "modern" way of calculating the ECC > > > parameters (or even jump directly to the modern way if the geometry > > > really is not currently supported officially) > > > - if your customers want a specific chunk size/strength when > > > rebasing on top of a mainline kernel there are DT properties which do > > > that anyway > > > - follow Sean advice: introduce a property requesting to use the > > > 'modern' or 'legacy' logic (with a better name than modern) but first > > > check with Rob that this if valid. > > Another hint: please check the core helpers and use them instead of > trying to re-invent the wheel: normally just describing the engine > capabilities and calling a single helper should do the trick. But this > 'new' calculation should only apply to eg. MLC devices or devices with > specific geometries, not to all devices. > > Thanks, > Miquèl Hi Han, Is this something you are working on? If not I really think we need to revert the changes to u-boot, to allign vanilla u-boot and kernel. /Sean
On 21/07/05 12:46PM, Sean Nyekjaer wrote: > On Wed, May 26, 2021 at 05:31:23PM +0200, Miquel Raynal wrote: > > Hi Han, > > > > [ ... ] > > > > > I understand that (2) might be ideal to meet but is breaking all the > > boards that use this driver really worth the trouble? > > > > Short answer: no. So we need to adapt the calculation for new > > boards/new flash chips/certain geometries at most. > > > > > > > The new implementation might get weak ecc than legacy way in some cases but it > > > > > is safety guaranteed. > > > > > > > > What does "safety guaranteed" means? > > > > > > set minimum ecc required by nand chip at least meet all requirements > > > > > > > > > > > > This reminds me the gpmi raw access mode changes in kernel 3.19, it also changes > > > > > the driver behaviors and makes totally different output compared with older > > > > > versions. I know changes bring mess but we have to accept it at some point > > > > > rather than keep compromising to the wrong way. > > > > > > > > How is this an argument? I am usually in favor of moving forward when > > > > there is a real justification, but this does not seem the case, unless > > > > I am understanding it all the wrong way. > > > > > > > > > The change has been in NXP kernel fork for a while, so quite a few customers are > > > > > using this bch geometry settings. I hope it can be upstreamed, any other things > > > > > I can do may mitigate the imapact? > > > > > > > > You are well aware of the upstreaming process, trying to merge > > > > something locally, making it used and then complaining because not > > > > upstreaming it would break your customers really is your own > > > > responsibility. > > > > > > Sorry I understand I should try upstreaming it early, so I am still looking for > > > a chance to avoid further divergence. > > > > > > > > > > > IMHO the solutions are: > > > > - the current (mainline) default will remain the standard for > > > > geometries which are already widely supported > > > > - if there are new geometries that must be supported and do not fit > > > > because of the "legacy" logic, then you may detect that and try > > > > to fallback to the "modern" way of calculating the ECC > > > > parameters (or even jump directly to the modern way if the geometry > > > > really is not currently supported officially) > > > > - if your customers want a specific chunk size/strength when > > > > rebasing on top of a mainline kernel there are DT properties which do > > > > that anyway > > > > - follow Sean advice: introduce a property requesting to use the > > > > 'modern' or 'legacy' logic (with a better name than modern) but first > > > > check with Rob that this if valid. > > > > Another hint: please check the core helpers and use them instead of > > trying to re-invent the wheel: normally just describing the engine > > capabilities and calling a single helper should do the trick. But this > > 'new' calculation should only apply to eg. MLC devices or devices with > > specific geometries, not to all devices. > > > > Thanks, > > Miquèl > > Hi Han, > > Is this something you are working on? > If not I really think we need to revert the changes to u-boot, to allign > vanilla u-boot and kernel. I will send patches for both kernel and u-boot to use legacy bch scheme by default, and add some code to treat few MLC nand chips as corner cases. > > /Sean
diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c index 4d08e4ab5c1b..bb061205679d 100644 --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c @@ -218,7 +218,8 @@ static void gpmi_dump_info(struct gpmi_nand_data *this) "ECC Strength : %u\n" "Page Size in Bytes : %u\n" "Metadata Size in Bytes : %u\n" - "ECC Chunk Size in Bytes: %u\n" + "ECC Chunk0 Size in Bytes: %u\n" + "ECC Chunkn Size in Bytes: %u\n" "ECC Chunk Count : %u\n" "Payload Size in Bytes : %u\n" "Auxiliary Size in Bytes: %u\n" @@ -229,7 +230,8 @@ static void gpmi_dump_info(struct gpmi_nand_data *this) geo->ecc_strength, geo->page_size, geo->metadata_size, - geo->ecc_chunk_size, + geo->ecc_chunk0_size, + geo->ecc_chunkn_size, geo->ecc_chunk_count, geo->payload_size, geo->auxiliary_size, @@ -251,6 +253,37 @@ static inline bool gpmi_check_ecc(struct gpmi_nand_data *this) return geo->ecc_strength <= this->devdata->bch_max_ecc_strength; } +static inline bool bbm_in_data_chunk(struct gpmi_nand_data *this, + unsigned int *chunk_num) +{ + struct bch_geometry *geo = &this->bch_geometry; + struct nand_chip *chip = &this->nand; + struct mtd_info *mtd = nand_to_mtd(chip); + unsigned int i, j; + + if (geo->ecc_chunk0_size != geo->ecc_chunkn_size) { + dev_err(this->dev, "The size of chunk0 must equal to chunkn\n"); + return false; + } + + i = (mtd->writesize * 8 - geo->metadata_size * 8) / + (geo->gf_len * geo->ecc_strength + + geo->ecc_chunkn_size * 8); + + j = (mtd->writesize * 8 - geo->metadata_size * 8) - + (geo->gf_len * geo->ecc_strength + + geo->ecc_chunkn_size * 8) * i; + + if (j < geo->ecc_chunkn_size * 8) { + *chunk_num = i+1; + dev_dbg(this->dev, "Set ecc to %d and bbm in chunk %d\n", + geo->ecc_strength, *chunk_num); + return true; + } + + return false; +} + /* * If we can get the ECC information from the nand chip, we do not * need to calculate them ourselves. @@ -280,13 +313,14 @@ static int set_geometry_by_ecc_info(struct gpmi_nand_data *this, nanddev_get_ecc_requirements(&chip->base)->step_size); return -EINVAL; } - geo->ecc_chunk_size = ecc_step; + geo->ecc_chunk0_size = ecc_step; + geo->ecc_chunkn_size = ecc_step; geo->ecc_strength = round_up(ecc_strength, 2); if (!gpmi_check_ecc(this)) return -EINVAL; /* Keep the C >= O */ - if (geo->ecc_chunk_size < mtd->oobsize) { + if (geo->ecc_chunkn_size < mtd->oobsize) { dev_err(this->dev, "unsupported nand chip. ecc size: %d, oob size : %d\n", ecc_step, mtd->oobsize); @@ -296,7 +330,7 @@ static int set_geometry_by_ecc_info(struct gpmi_nand_data *this, /* The default value, see comment in the legacy_set_geometry(). */ geo->metadata_size = 10; - geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunk_size; + geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunkn_size; /* * Now, the NAND chip with 2K page(data chunk is 512byte) shows below: @@ -399,6 +433,132 @@ static inline int get_ecc_strength(struct gpmi_nand_data *this) return round_down(ecc_strength, 2); } +static int set_geometry_for_large_oob(struct gpmi_nand_data *this) +{ + struct bch_geometry *geo = &this->bch_geometry; + struct nand_chip *chip = &this->nand; + struct mtd_info *mtd = nand_to_mtd(chip); + const struct nand_ecc_props *requirements = + nanddev_get_ecc_requirements(&chip->base); + unsigned int block_mark_bit_offset; + unsigned int max_ecc; + unsigned int bbm_chunk; + unsigned int i; + + /* sanity check for the minimum ecc nand required */ + if (!(requirements->strength > 0 && + requirements->step_size > 0)) + return -EINVAL; + geo->ecc_strength = requirements->strength; + + /* check if platform can support this nand */ + if (!gpmi_check_ecc(this)) { + dev_err(this->dev, + "unsupported NAND chip, minimum ecc required %d\n", + geo->ecc_strength); + return -EINVAL; + } + + /* calculate the maximum ecc platform can support*/ + geo->metadata_size = 10; + geo->gf_len = 14; + geo->ecc_chunk0_size = 1024; + geo->ecc_chunkn_size = 1024; + geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunkn_size; + max_ecc = min(get_ecc_strength(this), + this->devdata->bch_max_ecc_strength); + + /* search a supported ecc strength that makes bbm */ + /* located in data chunk */ + geo->ecc_strength = requirements->strength; + while (!(geo->ecc_strength > max_ecc)) { + if (bbm_in_data_chunk(this, &bbm_chunk)) + goto geo_setting; + geo->ecc_strength += 2; + } + + /* if none of them works, keep using the minimum ecc */ + /* nand required but changing ecc page layout */ + geo->ecc_strength = requirements->strength; + /* add extra ecc for meta data */ + geo->ecc_chunk0_size = 0; + geo->ecc_chunk_count = (mtd->writesize / geo->ecc_chunkn_size) + 1; + geo->ecc_for_meta = 1; + /* check if oob can afford this extra ecc chunk */ + if (mtd->oobsize * 8 < geo->metadata_size * 8 + + geo->gf_len * geo->ecc_strength * geo->ecc_chunk_count) { + dev_err(this->dev, "unsupported NAND chip with new layout\n"); + return -EINVAL; + } + + /* calculate in which chunk bbm located */ + bbm_chunk = (mtd->writesize * 8 - geo->metadata_size * 8 - + geo->gf_len * geo->ecc_strength) / + (geo->gf_len * geo->ecc_strength + + geo->ecc_chunkn_size * 8) + 1; + +geo_setting: + + geo->page_size = mtd->writesize + geo->metadata_size + + (geo->gf_len * geo->ecc_strength * geo->ecc_chunk_count) / 8; + geo->payload_size = mtd->writesize; + + /* + * The auxiliary buffer contains the metadata and the ECC status. The + * metadata is padded to the nearest 32-bit boundary. The ECC status + * contains one byte for every ECC chunk, and is also padded to the + * nearest 32-bit boundary. + */ + geo->auxiliary_status_offset = ALIGN(geo->metadata_size, 4); + geo->auxiliary_size = ALIGN(geo->metadata_size, 4) + + ALIGN(geo->ecc_chunk_count, 4); + + if (!this->swap_block_mark) + return 0; + + /* calculate the number of ecc chunk behind the bbm */ + i = (mtd->writesize / geo->ecc_chunkn_size) - bbm_chunk + 1; + + block_mark_bit_offset = mtd->writesize * 8 - + (geo->ecc_strength * geo->gf_len * (geo->ecc_chunk_count - i) + + geo->metadata_size * 8); + + geo->block_mark_byte_offset = block_mark_bit_offset / 8; + geo->block_mark_bit_offset = block_mark_bit_offset % 8; + + dev_dbg(this->dev, "BCH Geometry :\n" + "GF length : %u\n" + "ECC Strength : %u\n" + "Page Size in Bytes : %u\n" + "Metadata Size in Bytes : %u\n" + "ECC Chunk0 Size in Bytes: %u\n" + "ECC Chunkn Size in Bytes: %u\n" + "ECC Chunk Count : %u\n" + "Payload Size in Bytes : %u\n" + "Auxiliary Size in Bytes: %u\n" + "Auxiliary Status Offset: %u\n" + "Block Mark Byte Offset : %u\n" + "Block Mark Bit Offset : %u\n" + "Block Mark in chunk : %u\n" + "Ecc for Meta data : %u\n", + geo->gf_len, + geo->ecc_strength, + geo->page_size, + geo->metadata_size, + geo->ecc_chunk0_size, + geo->ecc_chunkn_size, + geo->ecc_chunk_count, + geo->payload_size, + geo->auxiliary_size, + geo->auxiliary_status_offset, + geo->block_mark_byte_offset, + geo->block_mark_bit_offset, + bbm_chunk, + geo->ecc_for_meta); + + return 0; +} + static int legacy_set_geometry(struct gpmi_nand_data *this) { struct bch_geometry *geo = &this->bch_geometry; @@ -407,6 +567,7 @@ static int legacy_set_geometry(struct gpmi_nand_data *this) unsigned int status_size; unsigned int block_mark_bit_offset; + dev_warn(this->dev, "use legacy bch geometry\n"); /* * The size of the metadata can be changed, though we set it to 10 * bytes now. But it can't be too large, because we have to save @@ -418,13 +579,15 @@ static int legacy_set_geometry(struct gpmi_nand_data *this) geo->gf_len = 13; /* The default for chunk size. */ - geo->ecc_chunk_size = 512; - while (geo->ecc_chunk_size < mtd->oobsize) { - geo->ecc_chunk_size *= 2; /* keep C >= O */ + geo->ecc_chunk0_size = 512; + geo->ecc_chunkn_size = 512; + while (geo->ecc_chunkn_size < mtd->oobsize) { + geo->ecc_chunk0_size *= 2; /* keep C >= O */ + geo->ecc_chunkn_size *= 2; /* keep C >= O */ geo->gf_len = 14; } - geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunk_size; + geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunkn_size; /* We use the same ECC strength for all chunks. */ geo->ecc_strength = get_ecc_strength(this); @@ -514,24 +677,23 @@ static int legacy_set_geometry(struct gpmi_nand_data *this) static int common_nfc_set_geometry(struct gpmi_nand_data *this) { struct nand_chip *chip = &this->nand; + struct mtd_info *mtd = nand_to_mtd(&this->nand); const struct nand_ecc_props *requirements = nanddev_get_ecc_requirements(&chip->base); - if (chip->ecc.strength > 0 && chip->ecc.size > 0) - return set_geometry_by_ecc_info(this, chip->ecc.strength, - chip->ecc.size); - - if ((of_property_read_bool(this->dev->of_node, "fsl,use-minimum-ecc")) - || legacy_set_geometry(this)) { - if (!(requirements->strength > 0 && requirements->step_size > 0)) - return -EINVAL; + /* first check if need to use legacy bch geometry settings */ + if ((!(requirements->strength > 0 && requirements->step_size > 0) && + mtd->oobsize < 1024) || + of_property_read_bool(this->dev->of_node, "fsl,legacy-bch-geometry")) + return legacy_set_geometry(this); - return set_geometry_by_ecc_info(this, - requirements->strength, - requirements->step_size); - } + /* then check if need to set bch geometry for large oob nand */ + if (mtd->oobsize > 1024 || requirements->step_size < mtd->oobsize) + return set_geometry_for_large_oob(this); - return 0; + /* set bch geometry by nand chip minimum required strength & step size*/ + return set_geometry_by_ecc_info(this, requirements->strength, + requirements->step_size); } /* Configures the geometry for BCH. */ @@ -806,7 +968,7 @@ static int gpmi_raw_len_to_len(struct gpmi_nand_data *this, int raw_len) * we are passed in exec_op. Calculate the data length from it. */ if (this->bch) - return ALIGN_DOWN(raw_len, this->bch_geometry.ecc_chunk_size); + return ALIGN_DOWN(raw_len, this->bch_geometry.ecc_chunkn_size); else return raw_len; } @@ -1212,7 +1374,7 @@ static int gpmi_count_bitflips(struct nand_chip *chip, void *buf, int first, /* Read ECC bytes into our internal raw_buffer */ offset = nfc_geo->metadata_size * 8; - offset += ((8 * nfc_geo->ecc_chunk_size) + eccbits) * (i + 1); + offset += ((8 * nfc_geo->ecc_chunkn_size) + eccbits) * (i + 1); offset -= eccbits; bitoffset = offset % 8; eccbytes = DIV_ROUND_UP(offset + eccbits, 8); @@ -1249,16 +1411,16 @@ static int gpmi_count_bitflips(struct nand_chip *chip, void *buf, int first, if (i == 0) { /* The first block includes metadata */ flips = nand_check_erased_ecc_chunk( - buf + i * nfc_geo->ecc_chunk_size, - nfc_geo->ecc_chunk_size, + buf + i * nfc_geo->ecc_chunkn_size, + nfc_geo->ecc_chunkn_size, eccbuf, eccbytes, this->auxiliary_virt, nfc_geo->metadata_size, nfc_geo->ecc_strength); } else { flips = nand_check_erased_ecc_chunk( - buf + i * nfc_geo->ecc_chunk_size, - nfc_geo->ecc_chunk_size, + buf + i * nfc_geo->ecc_chunkn_size, + nfc_geo->ecc_chunkn_size, eccbuf, eccbytes, NULL, 0, nfc_geo->ecc_strength); @@ -1287,20 +1449,21 @@ static void gpmi_bch_layout_std(struct gpmi_nand_data *this) struct bch_geometry *geo = &this->bch_geometry; unsigned int ecc_strength = geo->ecc_strength >> 1; unsigned int gf_len = geo->gf_len; - unsigned int block_size = geo->ecc_chunk_size; + unsigned int block0_size = geo->ecc_chunk0_size; + unsigned int blockn_size = geo->ecc_chunkn_size; this->bch_flashlayout0 = BF_BCH_FLASH0LAYOUT0_NBLOCKS(geo->ecc_chunk_count - 1) | BF_BCH_FLASH0LAYOUT0_META_SIZE(geo->metadata_size) | BF_BCH_FLASH0LAYOUT0_ECC0(ecc_strength, this) | BF_BCH_FLASH0LAYOUT0_GF(gf_len, this) | - BF_BCH_FLASH0LAYOUT0_DATA0_SIZE(block_size, this); + BF_BCH_FLASH0LAYOUT0_DATA0_SIZE(block0_size, this); this->bch_flashlayout1 = BF_BCH_FLASH0LAYOUT1_PAGE_SIZE(geo->page_size) | BF_BCH_FLASH0LAYOUT1_ECCN(ecc_strength, this) | BF_BCH_FLASH0LAYOUT1_GF(gf_len, this) | - BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(block_size, this); + BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(blockn_size, this); } static int gpmi_ecc_read_page(struct nand_chip *chip, uint8_t *buf, @@ -1383,9 +1546,22 @@ static int gpmi_ecc_read_subpage(struct nand_chip *chip, uint32_t offs, } } + /* + * if there is an ECC dedicate for meta: + * - need to add an extra ECC size when calculating col and page_size, + * if the meta size is NOT zero. + * - chunk0 size need to set to the same size as other chunks, + * if the meta size is zero. + */ + meta = geo->metadata_size; if (first) { - col = meta + (size + ecc_parity_size) * first; + if (geo->ecc_for_meta) + col = meta + ecc_parity_size + + (size + ecc_parity_size) * first; + else + col = meta + (size + ecc_parity_size) * first; + meta = 0; buf = buf + first * size; } @@ -1393,19 +1569,27 @@ static int gpmi_ecc_read_subpage(struct nand_chip *chip, uint32_t offs, ecc_parity_size = geo->gf_len * geo->ecc_strength / 8; n = last - first + 1; - page_size = meta + (size + ecc_parity_size) * n; + + if (geo->ecc_for_meta && meta) + page_size = meta + ecc_parity_size + + (size + ecc_parity_size) * n; + else + page_size = meta + (size + ecc_parity_size) * n; + ecc_strength = geo->ecc_strength >> 1; - this->bch_flashlayout0 = BF_BCH_FLASH0LAYOUT0_NBLOCKS(n - 1) | + this->bch_flashlayout0 = BF_BCH_FLASH0LAYOUT0_NBLOCKS( + (geo->ecc_for_meta ? n : n - 1)) | BF_BCH_FLASH0LAYOUT0_META_SIZE(meta) | BF_BCH_FLASH0LAYOUT0_ECC0(ecc_strength, this) | BF_BCH_FLASH0LAYOUT0_GF(geo->gf_len, this) | - BF_BCH_FLASH0LAYOUT0_DATA0_SIZE(geo->ecc_chunk_size, this); + BF_BCH_FLASH0LAYOUT0_DATA0_SIZE((geo->ecc_for_meta ? + 0 : geo->ecc_chunk0_size), this); this->bch_flashlayout1 = BF_BCH_FLASH0LAYOUT1_PAGE_SIZE(page_size) | BF_BCH_FLASH0LAYOUT1_ECCN(ecc_strength, this) | BF_BCH_FLASH0LAYOUT1_GF(geo->gf_len, this) | - BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(geo->ecc_chunk_size, this); + BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(geo->ecc_chunkn_size, this); this->bch = true; @@ -1577,7 +1761,7 @@ static int gpmi_ecc_read_page_raw(struct nand_chip *chip, uint8_t *buf, struct mtd_info *mtd = nand_to_mtd(chip); struct gpmi_nand_data *this = nand_get_controller_data(chip); struct bch_geometry *nfc_geo = &this->bch_geometry; - int eccsize = nfc_geo->ecc_chunk_size; + int eccsize = nfc_geo->ecc_chunkn_size; int eccbits = nfc_geo->ecc_strength * nfc_geo->gf_len; u8 *tmp_buf = this->raw_buffer; size_t src_bit_off; @@ -1662,7 +1846,7 @@ static int gpmi_ecc_write_page_raw(struct nand_chip *chip, const uint8_t *buf, struct mtd_info *mtd = nand_to_mtd(chip); struct gpmi_nand_data *this = nand_get_controller_data(chip); struct bch_geometry *nfc_geo = &this->bch_geometry; - int eccsize = nfc_geo->ecc_chunk_size; + int eccsize = nfc_geo->ecc_chunkn_size; int eccbits = nfc_geo->ecc_strength * nfc_geo->gf_len; u8 *tmp_buf = this->raw_buffer; uint8_t *oob = chip->oob_poi; @@ -2036,7 +2220,7 @@ static int gpmi_init_last(struct gpmi_nand_data *this) ecc->read_oob_raw = gpmi_ecc_read_oob_raw; ecc->write_oob_raw = gpmi_ecc_write_oob_raw; ecc->engine_type = NAND_ECC_ENGINE_TYPE_ON_HOST; - ecc->size = bch_geo->ecc_chunk_size; + ecc->size = bch_geo->ecc_chunkn_size; ecc->strength = bch_geo->ecc_strength; mtd_set_ooblayout(mtd, &gpmi_ooblayout_ops); diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h index fdc5ed7de083..e612f5c22293 100644 --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h @@ -30,9 +30,9 @@ struct resources { * @page_size: The size, in bytes, of a physical page, including * both data and OOB. * @metadata_size: The size, in bytes, of the metadata. - * @ecc_chunk_size: The size, in bytes, of a single ECC chunk. Note - * the first chunk in the page includes both data and - * metadata, so it's a bit larger than this value. + * @ecc_chunk0_size: The size, in bytes, of a first ECC chunk. + * @ecc_chunkn_size: The size, in bytes, of a single ECC chunk after + * the first chunk in the page. * @ecc_chunk_count: The number of ECC chunks in the page, * @payload_size: The size, in bytes, of the payload buffer. * @auxiliary_size: The size, in bytes, of the auxiliary buffer. @@ -42,19 +42,23 @@ struct resources { * which the underlying physical block mark appears. * @block_mark_bit_offset: The bit offset into the ECC-based page view at * which the underlying physical block mark appears. + * @ecc_for_meta: The flag to indicate if there is a dedicate ecc + * for meta. */ struct bch_geometry { unsigned int gf_len; unsigned int ecc_strength; unsigned int page_size; unsigned int metadata_size; - unsigned int ecc_chunk_size; + unsigned int ecc_chunk0_size; + unsigned int ecc_chunkn_size; unsigned int ecc_chunk_count; unsigned int payload_size; unsigned int auxiliary_size; unsigned int auxiliary_status_offset; unsigned int block_mark_byte_offset; unsigned int block_mark_bit_offset; + unsigned int ecc_for_meta; /* ECC for meta data */ }; /**
The code change updates the gpmi driver bch geometry settings, the NAND chips required minimum ecc strength and step size will be the default value. It also proposes a new way to set bch geometry for large oob NAND and provides an option to keep the legacy bch geometry setting for backward compatibility. - For the legacy bch geometry settings The driver uses legacy bch geometry settings if explicitly enabled it in DT with fsl, legacy-bch-geometry flag, or the NAND chips are too old that do NOT provide any required ecc info. The legacy_set_geometry() sets the data chunk size(step_size) larger than oob size to make sure BBM locates in data chunk, then set the maximum ecc stength oob can hold. It always use unbalanced ECC layout, which ecc0 will cover both meta and data0 chunk. This algorithm can NOT provide strong enough ecc for some NAND chips, such as some 8K+744 MLC NAND. We still leave it here just for backward compatibility and als for some quite old version NAND chips support. It should be en/disabled in both u-boot and kernel at the same time. - For the large oob bch geometry settings This type of setting will be used for NAND chips, which oob size is larger than 1024B OR NAND required step size is small than oob size, the general idea is, 1.Try all ECC strength from the minimum value required by NAND chip to the maximum one that works, any ECC makes the BBM locate in data chunk can be eligible. 2.If none of them works, using separate ECC for meta, which will add one extra ecc with the same ECC strength as other data chunks. This extra ECC can guarantee BBM located in data chunk, also we need to check if oob can afford it. - For all other common cases set the bch geometry by chip required strength and step size, which uses the minimum ecc strength chip required. Signed-off-by: Han Xu <han.xu@nxp.com> --- drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 262 ++++++++++++++++++--- drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h | 12 +- 2 files changed, 231 insertions(+), 43 deletions(-)