* Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. [not found] ` <35add8df33b17e2354d9496eba8597d9d8488f30.1430430153.git.hramrach@gmail.com> @ 2015-04-30 23:13 ` Marek Vasut 2015-05-01 7:05 ` Michal Suchanek 2015-05-01 21:56 ` Rafał Miłecki 1 sibling, 1 reply; 16+ messages in thread From: Marek Vasut @ 2015-04-30 23:13 UTC (permalink / raw) To: Michal Suchanek Cc: David Woodhouse, Brian Norris, zajec5, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, linux-kernel On Thursday, April 30, 2015 at 11:13:12 PM, Michal Suchanek wrote: > The sector size of the flash memory is unclear from datasheet or may > possibly vary between chips so add a flag to always use 4k blocks. > > Currently 4k blocks are always used when possible but in the future > somebody might want to do some optimizations with sector erase. > > Signed-off-by: Michal Suchanek <hramrach@gmail.com> I _think_ you might be able to determine the size, no ? One way is to ask the vendor, but you can also try something like: 1) erase the whole SPI NOR 2) overwrite it with zeroes (or ones ? I think it should be all ones after erasing). 3) Erase sector 0 4) Read some 128 KiB back 5) Observe what is the difference. Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. 2015-04-30 23:13 ` [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase Marek Vasut @ 2015-05-01 7:05 ` Michal Suchanek 2015-05-01 10:50 ` Jonas Gorski 2015-05-01 14:20 ` Marek Vasut 0 siblings, 2 replies; 16+ messages in thread From: Michal Suchanek @ 2015-05-01 7:05 UTC (permalink / raw) To: Marek Vasut Cc: David Woodhouse, Brian Norris, Rafa?? Mi??ecki, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, Linux Kernel Mailing List On 1 May 2015 at 01:13, Marek Vasut <marex@denx.de> wrote: > On Thursday, April 30, 2015 at 11:13:12 PM, Michal Suchanek wrote: >> The sector size of the flash memory is unclear from datasheet or may >> possibly vary between chips so add a flag to always use 4k blocks. >> >> Currently 4k blocks are always used when possible but in the future >> somebody might want to do some optimizations with sector erase. >> >> Signed-off-by: Michal Suchanek <hramrach@gmail.com> > > I _think_ you might be able to determine the size, no ? > > One way is to ask the vendor, but you can also try something like: > 1) erase the whole SPI NOR > 2) overwrite it with zeroes (or ones ? I think it should be all ones after > erasing). > 3) Erase sector 0 > 4) Read some 128 KiB back > 5) Observe what is the difference. > I can determine it for this particular chip. However, when the vendor datasheet says the block is 64/32K it might mean that chips with this ID can have either block size. It's a value that we don't use anyway so I just mark it as unknown here for future reference. Thanks Michal ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. 2015-05-01 7:05 ` Michal Suchanek @ 2015-05-01 10:50 ` Jonas Gorski 2015-05-01 14:20 ` Marek Vasut 1 sibling, 0 replies; 16+ messages in thread From: Jonas Gorski @ 2015-05-01 10:50 UTC (permalink / raw) To: Michal Suchanek Cc: Marek Vasut, Geert Uytterhoeven, David Woodhouse, Rafa?? Mi??ecki, Linux Kernel Mailing List, MTD Maling List, grmoore, Brian Norris, Ben Hutchings, Alison Chaiken, Bean Huo (beanhuo) Hi, On Fri, May 1, 2015 at 9:05 AM, Michal Suchanek <hramrach@gmail.com> wrote: > On 1 May 2015 at 01:13, Marek Vasut <marex@denx.de> wrote: >> On Thursday, April 30, 2015 at 11:13:12 PM, Michal Suchanek wrote: >>> The sector size of the flash memory is unclear from datasheet or may >>> possibly vary between chips so add a flag to always use 4k blocks. >>> >>> Currently 4k blocks are always used when possible but in the future >>> somebody might want to do some optimizations with sector erase. >>> >>> Signed-off-by: Michal Suchanek <hramrach@gmail.com> >> >> I _think_ you might be able to determine the size, no ? >> >> One way is to ask the vendor, but you can also try something like: >> 1) erase the whole SPI NOR >> 2) overwrite it with zeroes (or ones ? I think it should be all ones after >> erasing). >> 3) Erase sector 0 >> 4) Read some 128 KiB back >> 5) Observe what is the difference. >> > > I can determine it for this particular chip. However, when the vendor > datasheet says the block is 64/32K it might mean that chips with this > ID can have either block size. > > It's a value that we don't use anyway so I just mark it as unknown > here for future reference. It will be used if MTD_SPI_NOR_USE_4K_SECTORS is unset, so you should add some code to properly handle that case. Also I'd suggest switching the order of 2 and 3, so you add the flag handling first and then add support for a flash chip with this issue. Regards Jonas ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. 2015-05-01 7:05 ` Michal Suchanek 2015-05-01 10:50 ` Jonas Gorski @ 2015-05-01 14:20 ` Marek Vasut 2015-05-04 11:11 ` Michal Suchanek 1 sibling, 1 reply; 16+ messages in thread From: Marek Vasut @ 2015-05-01 14:20 UTC (permalink / raw) To: Michal Suchanek Cc: David Woodhouse, Brian Norris, Rafa?? Mi??ecki, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, Linux Kernel Mailing List On Friday, May 01, 2015 at 09:05:15 AM, Michal Suchanek wrote: > On 1 May 2015 at 01:13, Marek Vasut <marex@denx.de> wrote: > > On Thursday, April 30, 2015 at 11:13:12 PM, Michal Suchanek wrote: > >> The sector size of the flash memory is unclear from datasheet or may > >> possibly vary between chips so add a flag to always use 4k blocks. > >> > >> Currently 4k blocks are always used when possible but in the future > >> somebody might want to do some optimizations with sector erase. > >> > >> Signed-off-by: Michal Suchanek <hramrach@gmail.com> > > > > I _think_ you might be able to determine the size, no ? > > > > One way is to ask the vendor, but you can also try something like: > > 1) erase the whole SPI NOR > > 2) overwrite it with zeroes (or ones ? I think it should be all ones > > after erasing). > > 3) Erase sector 0 > > 4) Read some 128 KiB back > > 5) Observe what is the difference. > > I can determine it for this particular chip. However, when the vendor > datasheet says the block is 64/32K it might mean that chips with this > ID can have either block size. http://www.chingistek.com/img/Product_Files/Pm25LD010020datasheet%20v04.pdf page 21: SECTOR_ER (20h) erases 4kByte sector. BLOCK_ER (d8h) erases 64kByte sector. http://www.gigadevice.com/product/download/366.html?locale=en_US page 27-28: Sector Erase (SE) (20h) erases 4kByte sector 64KB Block Erase (BE) (d8h) erases 64kByte sector > It's a value that we don't use anyway so I just mark it as unknown > here for future reference. Looks like standard SPI NOR opcodes [1], nothing unknown there ;-) [1] include/linux/mtd/spi-nor.h Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. 2015-05-01 14:20 ` Marek Vasut @ 2015-05-04 11:11 ` Michal Suchanek 2015-05-04 12:12 ` Marek Vasut 0 siblings, 1 reply; 16+ messages in thread From: Michal Suchanek @ 2015-05-04 11:11 UTC (permalink / raw) To: Marek Vasut Cc: David Woodhouse, Brian Norris, Rafa?? Mi??ecki, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, Linux Kernel Mailing List Hello, On 1 May 2015 at 16:20, Marek Vasut <marex@denx.de> wrote: > On Friday, May 01, 2015 at 09:05:15 AM, Michal Suchanek wrote: >> On 1 May 2015 at 01:13, Marek Vasut <marex@denx.de> wrote: >> I can determine it for this particular chip. However, when the vendor >> datasheet says the block is 64/32K it might mean that chips with this >> ID can have either block size. > > http://www.chingistek.com/img/Product_Files/Pm25LD010020datasheet%20v04.pdf > page 21: > > SECTOR_ER (20h) erases 4kByte sector. > BLOCK_ER (d8h) erases 64kByte sector. > > http://www.gigadevice.com/product/download/366.html?locale=en_US > page 27-28: > > Sector Erase (SE) (20h) erases 4kByte sector > 64KB Block Erase (BE) (d8h) erases 64kByte sector > It's pretty much the same as the datasheet I used http://www.elm-tech.com/en/products/spi-flash-memory/gd25q41/gd25q41.pdf It mentions both 32KB Block Erase (BE) (52H) and 64KB Block Erase (BE) (D8H) So the chip probably tries its best to be compatible with any command set and this last patch is not needed. The memory organization table on page 7 is not all that reassuring, though. Thanks Michal ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. 2015-05-04 11:11 ` Michal Suchanek @ 2015-05-04 12:12 ` Marek Vasut 2015-05-04 13:18 ` Michal Suchanek 0 siblings, 1 reply; 16+ messages in thread From: Marek Vasut @ 2015-05-04 12:12 UTC (permalink / raw) To: Michal Suchanek Cc: David Woodhouse, Brian Norris, Rafa?? Mi??ecki, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, Linux Kernel Mailing List On Monday, May 04, 2015 at 01:11:03 PM, Michal Suchanek wrote: > Hello, Hi! > On 1 May 2015 at 16:20, Marek Vasut <marex@denx.de> wrote: > > On Friday, May 01, 2015 at 09:05:15 AM, Michal Suchanek wrote: > >> On 1 May 2015 at 01:13, Marek Vasut <marex@denx.de> wrote: > >> I can determine it for this particular chip. However, when the vendor > >> datasheet says the block is 64/32K it might mean that chips with this > >> ID can have either block size. > > > > http://www.chingistek.com/img/Product_Files/Pm25LD010020datasheet%20v04.p > > df page 21: > > > > SECTOR_ER (20h) erases 4kByte sector. > > BLOCK_ER (d8h) erases 64kByte sector. > > > > http://www.gigadevice.com/product/download/366.html?locale=en_US > > page 27-28: > > > > Sector Erase (SE) (20h) erases 4kByte sector > > 64KB Block Erase (BE) (d8h) erases 64kByte sector > > It's pretty much the same as the datasheet I used > http://www.elm-tech.com/en/products/spi-flash-memory/gd25q41/gd25q41.pdf > > It mentions both > 32KB Block Erase (BE) (52H) > and > 64KB Block Erase (BE) (D8H) The SPI NOR framework will use 0xbe opcode, no problem. > So the chip probably tries its best to be compatible with any command > set and this last patch is not needed. The memory organization table > on page 7 is not all that reassuring, though. Which exact part do you refer to please ? Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. 2015-05-04 12:12 ` Marek Vasut @ 2015-05-04 13:18 ` Michal Suchanek 2015-05-04 13:35 ` Marek Vasut 0 siblings, 1 reply; 16+ messages in thread From: Michal Suchanek @ 2015-05-04 13:18 UTC (permalink / raw) To: Marek Vasut Cc: David Woodhouse, Brian Norris, Rafa?? Mi??ecki, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, Linux Kernel Mailing List On 4 May 2015 at 14:12, Marek Vasut <marex@denx.de> wrote: > On Monday, May 04, 2015 at 01:11:03 PM, Michal Suchanek wrote: >> Hello, > > Hi! > >> On 1 May 2015 at 16:20, Marek Vasut <marex@denx.de> wrote: >> > On Friday, May 01, 2015 at 09:05:15 AM, Michal Suchanek wrote: >> >> On 1 May 2015 at 01:13, Marek Vasut <marex@denx.de> wrote: >> >> I can determine it for this particular chip. However, when the vendor >> >> datasheet says the block is 64/32K it might mean that chips with this >> >> ID can have either block size. >> > >> > http://www.chingistek.com/img/Product_Files/Pm25LD010020datasheet%20v04.p >> > df page 21: >> > >> > SECTOR_ER (20h) erases 4kByte sector. >> > BLOCK_ER (d8h) erases 64kByte sector. >> > >> > http://www.gigadevice.com/product/download/366.html?locale=en_US >> > page 27-28: >> > >> > Sector Erase (SE) (20h) erases 4kByte sector >> > 64KB Block Erase (BE) (d8h) erases 64kByte sector >> >> It's pretty much the same as the datasheet I used >> http://www.elm-tech.com/en/products/spi-flash-memory/gd25q41/gd25q41.pdf >> >> It mentions both >> 32KB Block Erase (BE) (52H) >> and >> 64KB Block Erase (BE) (D8H) > > The SPI NOR framework will use 0xbe opcode, no problem. > >> So the chip probably tries its best to be compatible with any command >> set and this last patch is not needed. The memory organization table >> on page 7 is not all that reassuring, though. > > Which exact part do you refer to please ? Start of page 7 where it says sector size 32/64K in either datasheet. It can refer to both BE opcode variants being supported but it's quite unclear. Write protection seems to be calculated in 4k sectors and not blocks so the block size does not seem very relevant. Thanks Michal ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. 2015-05-04 13:18 ` Michal Suchanek @ 2015-05-04 13:35 ` Marek Vasut 2015-05-04 13:39 ` Michal Suchanek 0 siblings, 1 reply; 16+ messages in thread From: Marek Vasut @ 2015-05-04 13:35 UTC (permalink / raw) To: Michal Suchanek Cc: David Woodhouse, Brian Norris, Rafa?? Mi??ecki, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, Linux Kernel Mailing List On Monday, May 04, 2015 at 03:18:56 PM, Michal Suchanek wrote: > On 4 May 2015 at 14:12, Marek Vasut <marex@denx.de> wrote: > > On Monday, May 04, 2015 at 01:11:03 PM, Michal Suchanek wrote: > >> Hello, > > > > Hi! > > > >> On 1 May 2015 at 16:20, Marek Vasut <marex@denx.de> wrote: > >> > On Friday, May 01, 2015 at 09:05:15 AM, Michal Suchanek wrote: > >> >> On 1 May 2015 at 01:13, Marek Vasut <marex@denx.de> wrote: > >> >> I can determine it for this particular chip. However, when the vendor > >> >> datasheet says the block is 64/32K it might mean that chips with this > >> >> ID can have either block size. > >> > > >> > http://www.chingistek.com/img/Product_Files/Pm25LD010020datasheet%20v0 > >> > 4.p df page 21: > >> > > >> > SECTOR_ER (20h) erases 4kByte sector. > >> > BLOCK_ER (d8h) erases 64kByte sector. > >> > > >> > http://www.gigadevice.com/product/download/366.html?locale=en_US > >> > page 27-28: > >> > > >> > Sector Erase (SE) (20h) erases 4kByte sector > >> > 64KB Block Erase (BE) (d8h) erases 64kByte sector > >> > >> It's pretty much the same as the datasheet I used > >> http://www.elm-tech.com/en/products/spi-flash-memory/gd25q41/gd25q41.pdf > >> > >> It mentions both > >> 32KB Block Erase (BE) (52H) > >> and > >> 64KB Block Erase (BE) (D8H) > > > > The SPI NOR framework will use 0xbe opcode, no problem. > > > >> So the chip probably tries its best to be compatible with any command > >> set and this last patch is not needed. The memory organization table > >> on page 7 is not all that reassuring, though. > > > > Which exact part do you refer to please ? > > Start of page 7 where it says sector size 32/64K in either datasheet. > > It can refer to both BE opcode variants being supported but it's quite > unclear. My guess here would be that the internal organisation of the SPI NOR is in 4k blocks, which is no surprise really. My understanding is that opcode 0x52 erases 8x4k sector (ie. 32k of data) while 0xd8 erases 16x4k sector (ie. 64k of data). I don't see any problem here -- there are two different opcodes which do two different things and their behavior matches the one on various other SPI NORs. > Write protection seems to be calculated in 4k sectors and not blocks > so the block size does not seem very relevant. See above. Does it make sense now please ? Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. 2015-05-04 13:35 ` Marek Vasut @ 2015-05-04 13:39 ` Michal Suchanek 2015-05-04 14:11 ` Marek Vasut 0 siblings, 1 reply; 16+ messages in thread From: Michal Suchanek @ 2015-05-04 13:39 UTC (permalink / raw) To: Marek Vasut Cc: David Woodhouse, Brian Norris, Rafa?? Mi??ecki, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, Linux Kernel Mailing List On 4 May 2015 at 15:35, Marek Vasut <marex@denx.de> wrote: > On Monday, May 04, 2015 at 03:18:56 PM, Michal Suchanek wrote: >> On 4 May 2015 at 14:12, Marek Vasut <marex@denx.de> wrote: >> > On Monday, May 04, 2015 at 01:11:03 PM, Michal Suchanek wrote: >> >> >> >> It mentions both >> >> 32KB Block Erase (BE) (52H) >> >> and >> >> 64KB Block Erase (BE) (D8H) >> > >> > The SPI NOR framework will use 0xbe opcode, no problem. >> > >> >> So the chip probably tries its best to be compatible with any command >> >> set and this last patch is not needed. The memory organization table >> >> on page 7 is not all that reassuring, though. >> > >> > Which exact part do you refer to please ? >> >> Start of page 7 where it says sector size 32/64K in either datasheet. >> >> It can refer to both BE opcode variants being supported but it's quite >> unclear. > > My guess here would be that the internal organisation of the SPI NOR is > in 4k blocks, which is no surprise really. My understanding is that opcode > 0x52 erases 8x4k sector (ie. 32k of data) while 0xd8 erases 16x4k sector > (ie. 64k of data). I don't see any problem here -- there are two different > opcodes which do two different things and their behavior matches the one on > various other SPI NORs. > >> Write protection seems to be calculated in 4k sectors and not blocks >> so the block size does not seem very relevant. > > See above. Does it make sense now please ? > Yes, makes sense. Thanks Michal ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. 2015-05-04 13:39 ` Michal Suchanek @ 2015-05-04 14:11 ` Marek Vasut 0 siblings, 0 replies; 16+ messages in thread From: Marek Vasut @ 2015-05-04 14:11 UTC (permalink / raw) To: Michal Suchanek Cc: David Woodhouse, Brian Norris, Rafa?? Mi??ecki, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, Linux Kernel Mailing List On Monday, May 04, 2015 at 03:39:44 PM, Michal Suchanek wrote: > On 4 May 2015 at 15:35, Marek Vasut <marex@denx.de> wrote: > > On Monday, May 04, 2015 at 03:18:56 PM, Michal Suchanek wrote: > >> On 4 May 2015 at 14:12, Marek Vasut <marex@denx.de> wrote: > >> > On Monday, May 04, 2015 at 01:11:03 PM, Michal Suchanek wrote: > >> >> It mentions both > >> >> 32KB Block Erase (BE) (52H) > >> >> and > >> >> 64KB Block Erase (BE) (D8H) > >> > > >> > The SPI NOR framework will use 0xbe opcode, no problem. > >> > > >> >> So the chip probably tries its best to be compatible with any command > >> >> set and this last patch is not needed. The memory organization table > >> >> on page 7 is not all that reassuring, though. > >> > > >> > Which exact part do you refer to please ? > >> > >> Start of page 7 where it says sector size 32/64K in either datasheet. > >> > >> It can refer to both BE opcode variants being supported but it's quite > >> unclear. > > > > My guess here would be that the internal organisation of the SPI NOR is > > in 4k blocks, which is no surprise really. My understanding is that > > opcode 0x52 erases 8x4k sector (ie. 32k of data) while 0xd8 erases 16x4k > > sector (ie. 64k of data). I don't see any problem here -- there are two > > different opcodes which do two different things and their behavior > > matches the one on various other SPI NORs. > > > >> Write protection seems to be calculated in 4k sectors and not blocks > >> so the block size does not seem very relevant. > > > > See above. Does it make sense now please ? > > Yes, > > makes sense. I'm glad to hear this got cleared up, thanks ! :) Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. [not found] ` <35add8df33b17e2354d9496eba8597d9d8488f30.1430430153.git.hramrach@gmail.com> 2015-04-30 23:13 ` [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase Marek Vasut @ 2015-05-01 21:56 ` Rafał Miłecki 1 sibling, 0 replies; 16+ messages in thread From: Rafał Miłecki @ 2015-05-01 21:56 UTC (permalink / raw) To: Michal Suchanek Cc: David Woodhouse, Brian Norris, Marek Vasut, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, Linux Kernel Mailing List On 30 April 2015 at 23:13, Michal Suchanek <hramrach@gmail.com> wrote: > The sector size of the flash memory is unclear from datasheet or may > possibly vary between chips so add a flag to always use 4k blocks. > > Currently 4k blocks are always used when possible but in the future > somebody might want to do some optimizations with sector erase. AFAIK most sources call 4K a sector and 64K a block. I think we should try to stick to that (even if some current code doesn't). So it would be nice to call 4K a sector (instead of block). ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <02f7510acb9b6dbb3a5a6cd5bb287762eb4d22c1.1430430153.git.hramrach@gmail.com>]
* Re: [PATCH 1/3] MTD: m25p80: fix write return value. [not found] ` <02f7510acb9b6dbb3a5a6cd5bb287762eb4d22c1.1430430153.git.hramrach@gmail.com> @ 2015-04-30 23:09 ` Marek Vasut 2015-05-20 23:45 ` Brian Norris 1 sibling, 0 replies; 16+ messages in thread From: Marek Vasut @ 2015-04-30 23:09 UTC (permalink / raw) To: Michal Suchanek Cc: David Woodhouse, Brian Norris, zajec5, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, linux-kernel On Thursday, April 30, 2015 at 03:33:47 PM, Michal Suchanek wrote: > The 'retlen' points to a variable representing the number of data bytes > written/read (see include/linux/mtd/mtd.h) by the current invocation of > the function. This variable must be set, not incremented. > > v2: clearer commit message This V2 goes past the diffstat, so that when the patch is applied, it doesn't end up in the log. > Signed-off-by: Michal Suchanek <hramrach@gmail.com> > Acked-by: Marek Vasut <marex@denx.de> > --- > drivers/mtd/devices/m25p80.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Aka. V<n> changes go here. I don't think there's a need to repost tho :) > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c > index 7c8b169..0b2bc21 100644 > --- a/drivers/mtd/devices/m25p80.c > +++ b/drivers/mtd/devices/m25p80.c > @@ -102,7 +102,7 @@ static void m25p80_write(struct spi_nor *nor, loff_t > to, size_t len, > > spi_sync(spi, &m); > > - *retlen += m.actual_length - cmd_sz; > + *retlen = m.actual_length - cmd_sz; > } > > static inline unsigned int m25p80_rx_nbits(struct spi_nor *nor) Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] MTD: m25p80: fix write return value. [not found] ` <02f7510acb9b6dbb3a5a6cd5bb287762eb4d22c1.1430430153.git.hramrach@gmail.com> 2015-04-30 23:09 ` [PATCH 1/3] MTD: m25p80: fix write return value Marek Vasut @ 2015-05-20 23:45 ` Brian Norris 2015-05-21 8:33 ` Michal Suchanek 1 sibling, 1 reply; 16+ messages in thread From: Brian Norris @ 2015-05-20 23:45 UTC (permalink / raw) To: Michal Suchanek Cc: David Woodhouse, zajec5, Marek Vasut, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, linux-kernel On Thu, Apr 30, 2015 at 03:33:47PM +0200, Michal Suchanek wrote: > The 'retlen' points to a variable representing the number of data bytes > written/read (see include/linux/mtd/mtd.h) by the current invocation of > the function. This variable must be set, not incremented. > > v2: clearer commit message > > Signed-off-by: Michal Suchanek <hramrach@gmail.com> > Acked-by: Marek Vasut <marex@denx.de> > --- > drivers/mtd/devices/m25p80.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c > index 7c8b169..0b2bc21 100644 > --- a/drivers/mtd/devices/m25p80.c > +++ b/drivers/mtd/devices/m25p80.c > @@ -102,7 +102,7 @@ static void m25p80_write(struct spi_nor *nor, loff_t to, size_t len, > > spi_sync(spi, &m); > > - *retlen += m.actual_length - cmd_sz; > + *retlen = m.actual_length - cmd_sz; This is very wrong. It gets a little better once you add your next patches (which are also not good) since those patches reinterpret the usage of retlen, but this one definitely does *not* stand a lone. I'll admit the API is a little odd here, but the callers of this function (see spi_nor_write()) actually depend on calling this multiple times, with the value incrementing each time so we get a summary total. You're now clobbering this value. I'm willing to accept patches to improve this API, if you think that would help. Or to add comments that document this. > } > > static inline unsigned int m25p80_rx_nbits(struct spi_nor *nor) Also, I'm a little confused because you sent two different patch series very close to each other, and this patch is in both of them. Please don't do that. Either send a single patch series that contains all patches (and is versions v2, v3, etc., as you revise the whole thing) or send completely independent patch series. Don't include the same patch in different series. Anyway, please consider my comments, and when you have something better, please resend everything. I'm not going to take either series as-is. Thanks, Brian ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] MTD: m25p80: fix write return value. 2015-05-20 23:45 ` Brian Norris @ 2015-05-21 8:33 ` Michal Suchanek 0 siblings, 0 replies; 16+ messages in thread From: Michal Suchanek @ 2015-05-21 8:33 UTC (permalink / raw) To: Brian Norris Cc: David Woodhouse, Rafa?? Mi??ecki, Marek Vasut, Alison Chaiken, Ben Hutchings, Geert Uytterhoeven, Bean Huo (beanhuo), grmoore, linux-mtd, Linux Kernel Mailing List Hello, On 21 May 2015 at 01:45, Brian Norris <computersforpeace@gmail.com> wrote: > On Thu, Apr 30, 2015 at 03:33:47PM +0200, Michal Suchanek wrote: >> The 'retlen' points to a variable representing the number of data bytes >> written/read (see include/linux/mtd/mtd.h) by the current invocation of >> the function. This variable must be set, not incremented. >> >> v2: clearer commit message >> >> Signed-off-by: Michal Suchanek <hramrach@gmail.com> >> Acked-by: Marek Vasut <marex@denx.de> >> --- >> drivers/mtd/devices/m25p80.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c >> index 7c8b169..0b2bc21 100644 >> --- a/drivers/mtd/devices/m25p80.c >> +++ b/drivers/mtd/devices/m25p80.c >> @@ -102,7 +102,7 @@ static void m25p80_write(struct spi_nor *nor, loff_t to, size_t len, >> >> spi_sync(spi, &m); >> >> - *retlen += m.actual_length - cmd_sz; >> + *retlen = m.actual_length - cmd_sz; > > This is very wrong. It gets a little better once you add your next > patches (which are also not good) since those patches reinterpret the > usage of retlen, but this one definitely does *not* stand a lone. > > I'll admit the API is a little odd here, but the callers of this > function (see spi_nor_write()) actually depend on calling this multiple > times, with the value incrementing each time so we get a summary total. > You're now clobbering this value. > > I'm willing to accept patches to improve this API, if you think that > would help. Or to add comments that document this. Yes, the only user of the retlen value ignores it but passes it on so without the following patch this one makes the passed on value different from before. For m25p80 this would be fixed by truncating the write in the driver and setting actual_length appropriately rather than returning an error when the message is too long. It might possibly break other drivers, though. Thanks Michal ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <cover.1430403750.git.hramrach@gmail.com>]
[parent not found: <55132b4496e7fe73f949186c0f140f3e4fd4e2c7.1430403750.git.hramrach@gmail.com>]
* Re: [PATCH 1/3] MTD: m25p80: fix write return value. [not found] ` <55132b4496e7fe73f949186c0f140f3e4fd4e2c7.1430403750.git.hramrach@gmail.com> @ 2015-04-30 18:43 ` Marek Vasut 2015-04-30 21:37 ` Michal Suchanek 0 siblings, 1 reply; 16+ messages in thread From: Marek Vasut @ 2015-04-30 18:43 UTC (permalink / raw) To: Michal Suchanek Cc: linux-sunxi, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, David Woodhouse, Brian Norris, Huang Shijie, Rafał Miłecki, Ben Hutchings, Alison Chaiken, Mika Westerberg, Bean Huo 霍斌斌 (beanhuo), grmoore, devicetree, linux-kernel, linux-mtd On Thursday, April 30, 2015 at 03:33:47 PM, Michal Suchanek wrote: > The size of written data was added to user supplied value rather than > written at the provided address. You might want to work on the commit message a little, something like the following, but feel free to reword as seen fit. The 'retlen' points to a variable representing the number of data bytes written/read (see include/linux/mtd/mtd.h) by the current invocation of the function. This variable must be set, not incremented. Otherwise, the patch is correct I believe: Acked-by: Marek Vasut <marex@denx.de> > Signed-off-by: Michal Suchanek <hramrach@gmail.com> > --- > drivers/mtd/devices/m25p80.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c > index 7c8b169..0b2bc21 100644 > --- a/drivers/mtd/devices/m25p80.c > +++ b/drivers/mtd/devices/m25p80.c > @@ -102,7 +102,7 @@ static void m25p80_write(struct spi_nor *nor, loff_t > to, size_t len, > > spi_sync(spi, &m); > > - *retlen += m.actual_length - cmd_sz; > + *retlen = m.actual_length - cmd_sz; > } > > static inline unsigned int m25p80_rx_nbits(struct spi_nor *nor) Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] MTD: m25p80: fix write return value. 2015-04-30 18:43 ` Marek Vasut @ 2015-04-30 21:37 ` Michal Suchanek 0 siblings, 0 replies; 16+ messages in thread From: Michal Suchanek @ 2015-04-30 21:37 UTC (permalink / raw) To: Marek Vasut Cc: linux-sunxi, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, David Woodhouse, Brian Norris, Huang Shijie, Rafał Miłecki, Ben Hutchings, Alison Chaiken, Mika Westerberg, Bean Huo 霍斌斌 (beanhuo), grmoore, devicetree, Linux Kernel Mailing List, linux-mtd On 30 April 2015 at 20:43, Marek Vasut <marex@denx.de> wrote: > On Thursday, April 30, 2015 at 03:33:47 PM, Michal Suchanek wrote: >> The size of written data was added to user supplied value rather than >> written at the provided address. > > You might want to work on the commit message a little, something like > the following, but feel free to reword as seen fit. > > The 'retlen' points to a variable representing the number of data bytes > written/read (see include/linux/mtd/mtd.h) by the current invocation of > the function. This variable must be set, not incremented. > > Otherwise, the patch is correct I believe: > > Acked-by: Marek Vasut <marex@denx.de> > ok, I will send an updated version. Thanks Michal ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2015-05-21 8:35 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <cover.1430430153.git.hramrach@gmail.com> [not found] ` <35add8df33b17e2354d9496eba8597d9d8488f30.1430430153.git.hramrach@gmail.com> 2015-04-30 23:13 ` [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase Marek Vasut 2015-05-01 7:05 ` Michal Suchanek 2015-05-01 10:50 ` Jonas Gorski 2015-05-01 14:20 ` Marek Vasut 2015-05-04 11:11 ` Michal Suchanek 2015-05-04 12:12 ` Marek Vasut 2015-05-04 13:18 ` Michal Suchanek 2015-05-04 13:35 ` Marek Vasut 2015-05-04 13:39 ` Michal Suchanek 2015-05-04 14:11 ` Marek Vasut 2015-05-01 21:56 ` Rafał Miłecki [not found] ` <02f7510acb9b6dbb3a5a6cd5bb287762eb4d22c1.1430430153.git.hramrach@gmail.com> 2015-04-30 23:09 ` [PATCH 1/3] MTD: m25p80: fix write return value Marek Vasut 2015-05-20 23:45 ` Brian Norris 2015-05-21 8:33 ` Michal Suchanek [not found] <cover.1430403750.git.hramrach@gmail.com> [not found] ` <55132b4496e7fe73f949186c0f140f3e4fd4e2c7.1430403750.git.hramrach@gmail.com> 2015-04-30 18:43 ` Marek Vasut 2015-04-30 21:37 ` Michal Suchanek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).