| Message ID | 20230901184136.73b2833e@xps-13 |
|---|---|
| State | New |
| Headers | show |
| Series | [GIT,PULL] mtd: Changes for v6.6-rc1 | expand |
On Fri, 1 Sept 2023 at 09:42, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Core MTD changes: > * Use refcount to prevent corruption > * Call external _get and _put in right order > * Fix use-after-free in mtd release > * Explicitly include correct DT includes > * Clean refcounting with MTD_PARTITIONED_MASTER > * mtdblock: make warning messages ratelimited > * dt-bindings: Add SEAMA partition bindings Ok, so the above list isa fairly reasonable, but then: > MTD device driver changes: > * spear_smi: Use helper function devm_clk_get_enabled() > * maps: fix -Wvoid-pointer-to-enum-cast warning > * docg3: Remove unnecessary (void*) conversions > * physmap-core, spear_smi, st_spi_fsm, lpddr2_nvm, lantiq-flash, plat-ram: > - Use devm_platform_get_and_ioremap_resource() [...] This is not a "summary of changes". The above is basically just a re-organized shortlog. What I want a merge message to be is to be an _overview_ of what the merge brings in, and it's why I ask peopel to summarize what they have worked on in the pull request. But when the "summary" is just a list of every single detail, it's no longer a summary. It doesn't give an overview of what has changed. It's not useful to an outsider as a way to see "this is what the merge brings in". End result: I might as well just use "git shortlog", and it would probably be about as readable as this is. In fact, I get the strong feeling that this was auto-generated from something very much akin to "git shortlog", just edited to combine multiple commits that just did the same thing to several drivers. Please - this is meant for *humans*. If it is just another form of "git shortlog", then the automated version is *better*, because I can use "git shortlog" to look at one particular driver (or a particular set of drivers), so having a static version of "git shortlog" that has been slightly munged to another format is actually _inferior_. No, what the merge message should be is a general overview of "this is the big picture". Not just a list of every single change, just by sub-area. For example, you list "Use devm_platform_get_and_ioremap_resource" not just for individual drivers (nobody cares!), you do it *twice*, because you've split up MTD drivers from raw NAND controller drivers. And then you separately list "Use helper function devm_clk_get_optional_enabled" from that list too, _and_ you then list "Use devm_platform_ioremap_resource_byname()" for the brcm nand driver. Not to mention individually lising "Fix alignment with open parenthesis" and "Fix the spacing" and "Fix wrong indentation" and "Fix a typo" for the Qcom driver. See why I'm frustrated? This has been going on for some time, but it's gett9ing *worse*. This is absolutely ridiculous. I could try to make a summary of it all, but honestly, now it feels like just complete wasted time. So I pulled this, looked at the "summary" in the fag, and decided that it's just not worth it, and unpulled it. Please give me a *summary* of what has changed. A list of *important& things. Not a list of pointless typo fixes. Linus
On Sat, 2 Sept 2023 at 11:59, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > So I pulled this, looked at the "summary" in the fag, and decided that > it's just not worth it, and unpulled it. Bah. I came back to this, and tried to make a summary of my own. I might have missed something worth noting, but at least it's now more of an actual overview than a listing of details. Linus
The pull request you sent on Fri, 1 Sep 2023 18:42:11 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/for-6.6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bac8a20fa39796f5ae5cf73de146c2ba22ad2674
Thank you!
The pull request you sent on Fri, 1 Sep 2023 18:42:11 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/for-6.6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bac8a20fa39796f5ae5cf73de146c2ba22ad2674
Thank you!
The pull request you sent on Fri, 1 Sep 2023 18:42:11 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/for-6.6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bac8a20fa39796f5ae5cf73de146c2ba22ad2674
Thank you!
The pull request you sent on Fri, 1 Sep 2023 18:42:11 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/for-6.6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bac8a20fa39796f5ae5cf73de146c2ba22ad2674
Thank you!
Hi Linus, torvalds@linux-foundation.org wrote on Sat, 2 Sep 2023 11:59:55 -0700: > On Fri, 1 Sept 2023 at 09:42, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Core MTD changes: > > * Use refcount to prevent corruption > > * Call external _get and _put in right order > > * Fix use-after-free in mtd release > > * Explicitly include correct DT includes > > * Clean refcounting with MTD_PARTITIONED_MASTER > > * mtdblock: make warning messages ratelimited > > * dt-bindings: Add SEAMA partition bindings > > Ok, so the above list isa fairly reasonable, but then: > > > MTD device driver changes: > > * spear_smi: Use helper function devm_clk_get_enabled() > > * maps: fix -Wvoid-pointer-to-enum-cast warning > > * docg3: Remove unnecessary (void*) conversions > > * physmap-core, spear_smi, st_spi_fsm, lpddr2_nvm, lantiq-flash, plat-ram: > > - Use devm_platform_get_and_ioremap_resource() > [...] > > This is not a "summary of changes". The above is basically just a > re-organized shortlog. > > What I want a merge message to be is to be an _overview_ of what the > merge brings in, and it's why I ask peopel to summarize what they have > worked on in the pull request. > > But when the "summary" is just a list of every single detail, it's no > longer a summary. It doesn't give an overview of what has changed. > It's not useful to an outsider as a way to see "this is what the merge > brings in". > > End result: I might as well just use "git shortlog", and it would > probably be about as readable as this is. In fact, I get the strong > feeling that this was auto-generated from something very much akin to > "git shortlog", just edited to combine multiple commits that just did > the same thing to several drivers. > > Please - this is meant for *humans*. If it is just another form of > "git shortlog", then the automated version is *better*, because I can > use "git shortlog" to look at one particular driver (or a particular > set of drivers), so having a static version of "git shortlog" that has > been slightly munged to another format is actually _inferior_. > > No, what the merge message should be is a general overview of "this is > the big picture". Not just a list of every single change, just by > sub-area. > > For example, you list "Use devm_platform_get_and_ioremap_resource" not > just for individual drivers (nobody cares!), you do it *twice*, > because you've split up MTD drivers from raw NAND controller drivers. > > And then you separately list "Use helper function > devm_clk_get_optional_enabled" from that list too, _and_ you then list > "Use devm_platform_ioremap_resource_byname()" for the brcm nand > driver. > > Not to mention individually lising "Fix alignment with open > parenthesis" and "Fix the spacing" and "Fix wrong indentation" and > "Fix a typo" for the Qcom driver. > > See why I'm frustrated? This has been going on for some time, but it's > gett9ing *worse*. This is absolutely ridiculous. I could try to make a > summary of it all, but honestly, now it feels like just complete > wasted time. > > So I pulled this, looked at the "summary" in the fag, and decided that > it's just not worth it, and unpulled it. > > Please give me a *summary* of what has changed. A list of *important& > things. Not a list of pointless typo fixes. Back in 2020, you complained about one of my pull requests with: > You didn't even mention the stm32 controller change, which seems to be > the biggest individual thing in here.. And indeed that was a mistake on my side, but I received that comment as a request for a more detailed list of what had been touched. That's likely an over interpretation, but it lead me to be more exhaustive so the "you did not mention <this>" would no longer happen. About your request today, I totally get why you would like something more meaningful, but I don't know how to do it. Sometimes I get series which have a goal and I could definitely try to capture that goal in the summary rather than listing the patches. But then, what about the endless list of miscellaneous patches to fix the style, the W=1 warnings, various robot complains... Because this is what I mostly get currently, and I believe there is no way you'll prefer something like this: * Fix misc typos * Fix misc style fixes * Update to newer API's Or maybe it is as long as the patches are trivial? I believe among the load of PR you receive there must be other subsystems than mtd which receive a lot of miscellaneous changes like that, don't hesitate to share a couple which look useful yet concise enough to you. Thanks anyway for pulling. Kind regards, Miquèl
On Mon, 4 Sept 2023 at 01:28, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Back in 2020, you complained about one of my pull requests with: > > > You didn't even mention the stm32 controller change, which seems to be > > the biggest individual thing in here.. > > And indeed that was a mistake on my side, but I received that comment > as a request for a more detailed list of what had been touched. That's > likely an over interpretation, but it lead me to be more exhaustive so > the "you did not mention <this>" would no longer happen. You went from one extreme to another, and what I really would want is a nice middle ground: mention the important things, summarize the rest, and if something is subtle, please explain it. Now, that "something is subtle" may not even happen most of the time - particularly in drivers - so that is probably almost never an issue. > About your request today, I totally get why you would like something > more meaningful, but I don't know how to do it. Sometimes I get series > which have a goal and I could definitely try to capture that goal in > the summary rather than listing the patches. Exactly. If you have a series with a goal, please mention / explain the goal - not the details of the series. But, as you say: > But then, what about the > endless list of miscellaneous patches to fix the style, the W=1 > warnings, various robot complains... Absolutely. That's generally the bulk of any subsystem, and then all you need to do is mention it as a kind of "this is what happened". When I complained back in 2020, it was bvecause you didn't mention even the big changes. Although quite often "big" changes can also just be "a lot of cleanup", so mentioning it as such is also fine. > Because this is what I mostly get > currently, and I believe there is no way you'll prefer something like > this: > * Fix misc typos > * Fix misc style fixes > * Update to newer API's > Or maybe it is as long as the patches are trivial? Absolutely. That's _exactly_ what I want for trivial patches (including if it's a series of 15 trivial patches that all do the same thing to 15 different drivers). Instead of mentioning the individual patches, just say exactly the above kind of "Update to new helper APIs", or "Fix warnings reported by syzbot". Honestly, for pure "endpoint" drivers, that's kind of the expected explanation. Drivers themselves seldom have any conceptually big changes, and so the above kind of things is normal and expected. So then you have exactly that kind of "Fix W=1 warnings" comment without any more specificity. Then, occasionally you have one driver that gets a lot of work because somebody goes in and cleans up that driver in _particular_, and so if one particular driver stands out because a vendor (or an individual) just decided to do a lot of spring cleaning, then you might have a much more specific "Lots of work on cleaning up the XYZ driver" mention. Just as an example, let's look at some of the recent driver merges I did, and take something like SCSI where not a lot of interesting stuff happened. The mention was just "Updates to the usual drivers (ufs, lpfc, qla2xxx, mpi3mr, libsas) and the usual minor updates and bug fixes but no significant core changes" and that's ok. It was a lot of small patches that didn't do anything that you'd really care about unless you had some specific interest in a driver. But I mention that merge message because it is worth noting that I actually complained a bit to James about it, because that pull also did end up having one thing that stood out if you looked at the diffstat: it removed the UFS HPB support entirely. Nobody *really* cares about it (because it was never used), which was James' argument for not mentioning it, but it's the kind of thing that *does* stand out and might be worth mentioning even if it's just a curiosity. It's a _conceptually_ interesting part of the pull, even if it doesn't actually matter in the real world. So I give that merge message as an example of both a perfectly fine thing in general, but also as an example of "yeah, it could certainly have been better". Just to give you kind of an idea what I'm looking for. And don't get me wrong: sometimes I really appreciate - and want - a lot more. *IF* there are major ABI changes, I not only want them mentioned, I really want them explained. They *probably* don't actually happen for the MTD subsystem very much, if at all, but to give an example of somebody who does do that kind of "ABI changes that can affect a lot of other maintainers", we have things like the VFS layer that then affects multiple different filesystems, and then that shows up in the merge messages as big explanations. Or new system calls, or things like that, which affect not only the internal kernel ABI, but that actually exposes new user-space ABI. Then the explanations can be tens of lines of "this is what's going on". So examples from the VFS layer on *those* kinds of changes: git show 475d4df82719 git show c0a572d9d32f and no, I do not expect the MTD drivers to ever do that. But to give a recent example of a nice middle road from a merge I did yesterday, look at the phy pull from yesterday, or the HID updates from Friday. They have slightly different approaches to the summary, but both of those make me feel like they are explaining what went on in some simple summary without bogging down in excessive detail:" git show db906f0ca6bb git show 29aa98d0fe01 Anyway, all those examples are meant as just that - *examples*. It obviously depends entirely on what has been going on, and different subsystems can have very different rules. And often "core changes" to the subsystem are much more worthy of mention than some cleanup of individual drivers. A merge message of just a single line of "Trivial cleanups to drivers" can be entirely acceptable. But then I do expect to just see pretty much completely mindless one- or few-liners. Or a merge message might be 30+ lines of explanation, but then I do expect it to be some major new feature or re-organization that will affect end-users or other subsystems. So there is no one single "correct" thing. Linus
Hi Linus, torvalds@linux-foundation.org wrote on Mon, 4 Sep 2023 11:22:08 -0700: > On Mon, 4 Sept 2023 at 01:28, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Back in 2020, you complained about one of my pull requests with: > > > > > You didn't even mention the stm32 controller change, which seems to be > > > the biggest individual thing in here.. > > > > And indeed that was a mistake on my side, but I received that comment > > as a request for a more detailed list of what had been touched. That's > > likely an over interpretation, but it lead me to be more exhaustive so > > the "you did not mention <this>" would no longer happen. > > You went from one extreme to another, and what I really would want is > a nice middle ground: mention the important things, summarize the > rest, and if something is subtle, please explain it. > > Now, that "something is subtle" may not even happen most of the time - > particularly in drivers - so that is probably almost never an issue. > > > About your request today, I totally get why you would like something > > more meaningful, but I don't know how to do it. Sometimes I get series > > which have a goal and I could definitely try to capture that goal in > > the summary rather than listing the patches. > > Exactly. If you have a series with a goal, please mention / explain > the goal - not the details of the series. > > But, as you say: > > > But then, what about the > > endless list of miscellaneous patches to fix the style, the W=1 > > warnings, various robot complains... > > Absolutely. That's generally the bulk of any subsystem, and then all > you need to do is mention it as a kind of "this is what happened". > > When I complained back in 2020, it was bvecause you didn't mention > even the big changes. Although quite often "big" changes can also just > be "a lot of cleanup", so mentioning it as such is also fine. > > > Because this is what I mostly get > > currently, and I believe there is no way you'll prefer something like > > this: > > * Fix misc typos > > * Fix misc style fixes > > * Update to newer API's > > Or maybe it is as long as the patches are trivial? > > Absolutely. That's _exactly_ what I want for trivial patches > (including if it's a series of 15 trivial patches that all do the same > thing to 15 different drivers). > > Instead of mentioning the individual patches, just say exactly the > above kind of "Update to new helper APIs", or "Fix warnings reported > by syzbot". > > Honestly, for pure "endpoint" drivers, that's kind of the expected > explanation. Drivers themselves seldom have any conceptually big > changes, and so the above kind of things is normal and expected. So > then you have exactly that kind of "Fix W=1 warnings" comment without > any more specificity. > > Then, occasionally you have one driver that gets a lot of work because > somebody goes in and cleans up that driver in _particular_, and so if > one particular driver stands out because a vendor (or an individual) > just decided to do a lot of spring cleaning, then you might have a > much more specific "Lots of work on cleaning up the XYZ driver" > mention. Clear. > Just as an example, let's look at some of the recent driver merges I > did, and take something like SCSI where not a lot of interesting stuff > happened. The mention was just > > "Updates to the usual drivers (ufs, lpfc, qla2xxx, mpi3mr, libsas) and > the usual minor updates and bug fixes but no significant core changes" > > and that's ok. It was a lot of small patches that didn't do anything > that you'd really care about unless you had some specific interest in > a driver. > > But I mention that merge message because it is worth noting that I > actually complained a bit to James about it, because that pull also > did end up having one thing that stood out if you looked at the > diffstat: it removed the UFS HPB support entirely. Nobody *really* > cares about it (because it was never used), which was James' argument > for not mentioning it, but it's the kind of thing that *does* stand > out and might be worth mentioning even if it's just a curiosity. It's > a _conceptually_ interesting part of the pull, even if it doesn't > actually matter in the real world. > > So I give that merge message as an example of both a perfectly fine > thing in general, but also as an example of "yeah, it could certainly > have been better". Just to give you kind of an idea what I'm looking > for. > > And don't get me wrong: sometimes I really appreciate - and want - a > lot more. *IF* there are major ABI changes, I not only want them > mentioned, I really want them explained. Duly noted. > They *probably* don't actually happen for the MTD subsystem very much, > if at all, but to give an example of somebody who does do that kind of > "ABI changes that can affect a lot of other maintainers", we have > things like the VFS layer that then affects multiple different > filesystems, and then that shows up in the merge messages as big > explanations. Or new system calls, or things like that, which affect > not only the internal kernel ABI, but that actually exposes new > user-space ABI. Then the explanations can be tens of lines of "this is > what's going on". > > So examples from the VFS layer on *those* kinds of changes: > > git show 475d4df82719 > git show c0a572d9d32f > > and no, I do not expect the MTD drivers to ever do that. > > But to give a recent example of a nice middle road from a merge I did > yesterday, look at the phy pull from yesterday, or the HID updates > from Friday. They have slightly different approaches to the summary, > but both of those make me feel like they are explaining what went on > in some simple summary without bogging down in excessive detail:" > > git show db906f0ca6bb > git show 29aa98d0fe01 That one mentions the main authors, I believe there is no added value doing this as it takes time to write and would be easily catch with a git log. But otherwise, I think I get what you expect. > Anyway, all those examples are meant as just that - *examples*. It > obviously depends entirely on what has been going on, and different > subsystems can have very different rules. And often "core changes" to > the subsystem are much more worthy of mention than some cleanup of > individual drivers. > > A merge message of just a single line of "Trivial cleanups to drivers" > can be entirely acceptable. But then I do expect to just see pretty > much completely mindless one- or few-liners. > > Or a merge message might be 30+ lines of explanation, but then I do > expect it to be some major new feature or re-organization that will > affect end-users or other subsystems. > > So there is no one single "correct" thing. I believe I get the idea. I will try to match your expectations in my next pull requests, please do not hesitate to share your thoughts if you think it could be further improved in a specific way. Thanks, Miquèl
Hello Linus, This is the MTD PR for the current merge window preparing the v6.6 cycles. Thanks, Miquèl The following changes since commit 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5: Linux 6.5-rc1 (2023-07-09 13:53:13 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/for-6.6 for you to fetch changes up to 54a3f6e89fbbf12e1e3539a4f977a7536029d780: Merge tag 'nand/for-6.6' into mtd/next (2023-08-28 16:37:38 +0200) ---------------------------------------------------------------- Core MTD changes: * Use refcount to prevent corruption * Call external _get and _put in right order * Fix use-after-free in mtd release * Explicitly include correct DT includes * Clean refcounting with MTD_PARTITIONED_MASTER * mtdblock: make warning messages ratelimited * dt-bindings: Add SEAMA partition bindings MTD device driver changes: * spear_smi: Use helper function devm_clk_get_enabled() * maps: fix -Wvoid-pointer-to-enum-cast warning * docg3: Remove unnecessary (void*) conversions * physmap-core, spear_smi, st_spi_fsm, lpddr2_nvm, lantiq-flash, plat-ram: - Use devm_platform_get_and_ioremap_resource() Raw NAND core changes: * Fix -Wvoid-pointer-to-enum-cast warning * Export 'nand_exit_status_op()' * dt-bindings: Fix nand-controller.yaml license Raw NAND controller driver changes: * Omap, Omap2, Samsung, Atmel, fsl_upm, lpc32xx_slc, lpc32xx_mlc, STM32_FMC2, sh_ftlctl, MXC, Sunxi: - Use devm_platform_get_and_ioremap_resource() * Orion, vf610_nfc, Sunxi, STM32_FMC2, MTK, mpc5121, lpc32xx_slc, Intel, FSMC, Arasan: - Use helper function devm_clk_get_optional_enabled() * Brcmnand: - Use devm_platform_ioremap_resource_byname() - Propagate init error -EPROBE_DEFER up - Propagate error and simplify ternary operators - Fix mtd oobsize - Fix potential out-of-bounds access in oob write - Fix crash during the panic_write - Fix potential false time out warning - Fix ECC level field setting for v7.2 controller * fsmc: Handle clk prepare error in fsmc_nand_resume() * Marvell: Add support for AC5 SoC * Meson: - Support for 512B ECC step size - Fix build error - Use NAND core API to check status - dt-bindings: * Make ECC properties dependent * Support for 512B ECC step size * Drop unneeded quotes * Oxnas: Remove driver and bindings * Qcom: - Conversion to ->exec_op() - Removal of the legacy interface - Two full series of improvements/misc fixes * Use the BIT() macro * Use u8 instead of uint8_t * Fix alignment with open parenthesis * Fix the spacing * Fix wrong indentation * Fix a typo * Early structure initialization * Fix address parsing within ->exec_op() * Remove superfluous initialization of "ret" * Rename variables in qcom_op_cmd_mapping() * Handle unsupported opcode in qcom_op_cmd_mapping() * Fix the opcode check in qcom_check_op() * Use EOPNOTSUPP instead of ENOTSUPP * Wrap qcom_nand_exec_op() to 80 columns * Unmap sg_list and free desc within submic_descs() * Simplify the call to nand_prog_page_end_op() * Do not override the error no of submit_descs() * Sort includes alphabetically * Clear buf_count and buf_start in raw read * Add read/read_start ops in exec_op path * vf610_nfc: Do not check 0 for platform_get_irq() SPI NAND manufacturer driver changes: * gigadevice: Add support for GD5F1GQ{4,5}RExxH * esmt: Add support for F50D2G41KA * toshiba: Add support for T{C,H}58NYG{0,2}S3HBAI4 and TH58NYG3S0HBAI6 SPI NOR core changes: * fix assumption on enabling quad mode in spi_nor_write_16bit_sr_and_check() * avoid setting SRWD bit in SR if WP# signal not connected as it will configure the SR permanently as read only. Add "no-wp" dt property. * clarify the need for spi-nor compatibles in dt-bindings SPI NOR manufacturer driver changes: * Spansion: - Add support for S28HS02GT - Switch methods to use vreg_offset from SFDP instead of hardcoding the register value * Microchip/SST: - Add support for sst26vf032b flash * Winbond: - Correct flags for Winbond w25q128 * NXP spifi: - Use helper function devm_clk_get_enabled() ---------------------------------------------------------------- Alexander Usyskin (2): mtd: call external _get and _put in right order mtd: fix use-after-free in mtd release Amit Kumar Mahapatra (2): dt-bindings: mtd: jedec, spi-nor: Add DT property to avoid setting SRWD bit in status register mtd: spi-nor: Avoid setting SRWD bit in SR if WP# signal not connected Arseniy Krasnov (6): mtd: rawnand: export 'nand_exit_status_op()' mtd: rawnand: meson: use NAND core API to check status dt-bindings: nand: meson: support for 512B ECC step size dt-bindings: nand: meson: make ECC properties dependent mtd: rawnand: meson: support for 512B ECC step size mtd: rawnand: meson: fix build error Chris Packham (2): dt-bindings: mtd: Add AC5 specific binding mtd: rawnand: marvell: add support for AC5 SoC Colin Ian King (1): mtdblock: make warning messages ratelimited Hsin-Yi Wang (1): mtd: spi-nor: Check bus width while setting QE bit Justin Stitt (2): mtd: rawnand: fix -Wvoid-pointer-to-enum-cast warning mtd: maps: fix -Wvoid-pointer-to-enum-cast warning Krzysztof Kozlowski (1): dt-bindings: mtd: amlogic,meson-nand: drop unneeded quotes Li Zetao (13): mtd: rawnand: brcmnand: Use devm_platform_ioremap_resource_byname() mtd: spi-nor: nxp-spifi: Use helper function devm_clk_get_enabled() mtd: rawnand: arasan: Use helper function devm_clk_get_enabled() mtd: rawnand: fsmc: Use helper function devm_clk_get_enabled() mtd: rawnand: intel: Use helper function devm_clk_get_enabled() mtd: rawnand: lpc32xx_slc: Use helper function devm_clk_get_enabled() mtd: rawnand: mpc5121: Use helper function devm_clk_get_enabled() mtd: rawnand: mtk: Use helper function devm_clk_get_enabled() mtd: rawnand: stm32_fmc2: Use helper function devm_clk_get_enabled() mtd: rawnand: sunxi: Use helper function devm_clk_get_enabled() mtd: rawnand: vf610_nfc: Use helper function devm_clk_get_enabled() mtd: rawnand: orion: Use helper function devm_clk_get_optional_enabled() mtd: spear_smi: Use helper function devm_clk_get_enabled() Linus Walleij (2): dt-bindings: mtd: Add SEAMA partition bindings mtd: spi-nor: Correct flags for Winbond w25q128 Manivannan Sadhasivam (10): mtd: rawnand: qcom: Remove superfluous initialization of "ret" mtd: rawnand: qcom: Rename variables in qcom_op_cmd_mapping() mtd: rawnand: qcom: Handle unsupported opcode in qcom_op_cmd_mapping() mtd: rawnand: qcom: Fix the opcode check in qcom_check_op() mtd: rawnand: qcom: Use EOPNOTSUPP instead of ENOTSUPP mtd: rawnand: qcom: Wrap qcom_nand_exec_op() to 80 columns mtd: rawnand: qcom: Unmap sg_list and free desc within submic_descs() mtd: rawnand: qcom: Simplify the call to nand_prog_page_end_op() mtd: rawnand: qcom: Do not override the error no of submit_descs() mtd: rawnand: qcom: Sort includes alphabetically Md Sadre Alam (3): mtd: rawnand: qcom: Implement exec_op() mtd: rawnand: qcom: Remove legacy interface mtd: rawnand: qcom: Clear buf_count and buf_start in raw read Miquel Raynal (14): dt-bindings: mtd: spi-nor: clarify the need for spi-nor compatibles dt-bindings: mtd: Fix nand-controller.yaml license mtd: rawnand: qcom: Use the BIT() macro mtd: rawnand: qcom: Use u8 instead of uint8_t mtd: rawnand: qcom: Fix alignment with open parenthesis mtd: rawnand: qcom: Fix the spacing mtd: rawnand: qcom: Fix wrong indentation mtd: rawnand: qcom: Fix a typo mtd: rawnand: qcom: Early structure initialization mtd: rawnand: qcom: Fix address parsing within ->exec_op() mtd: Clean refcounting with MTD_PARTITIONED_MASTER mtd: spi-nor: Add support for sst26vf032b flash Merge tag 'spi-nor/for-6.6' into mtd/next Merge tag 'nand/for-6.6' into mtd/next Neil Armstrong (2): nand: oxnas_nand: remove obsolete raw nand driver dt-bindings: mtd: oxnas-nand: remove obsolete bindings Rafał Miłecki (1): mtd: rawnand: brcmnand: propagate init error -EPROBE_DEFER up Rob Herring (1): mtd: Explicitly include correct DT includes Ruan Jinjie (1): mtd: rawnand: Propagate error and simplify ternary operators for brcmstb_nand_wait_for_completion() Sricharan Ramabadhran (1): mtd: rawnand: qcom: Add read/read_start ops in exec_op path Sridharan S N (3): mtd: spinand: gigadevice: add support for GD5F1GQ{4,5}RExxH mtd: spinand: esmt: add support for F50D2G41KA mtd: spinand: toshiba: add support for T{C,H}58NYG{0,2}S3HBAI4 and TH58NYG3S0HBAI6 Su Hui (1): mtd: devices: docg3: Remove unnecessary (void*) conversions Takahiro Kuwano (8): mtd: spi-nor: spansion: use CLPEF as an alternative to CLSR mtd: spi-nor: spansion: preserve CFR2V[7] when writing MEMLAT mtd: spi-nor: spansion: prepare octal dtr methods for multi chip support mtd: spi-nor: spansion: switch set_octal_dtr method to use vreg_offset mtd: spi-nor: spansion: switch h28hx's ready() to use vreg_offset mtd: spi-nor: spansion: add MCP support in set_octal_dtr() mtd: spi-nor: spansion: add octal DTR support in RD_ANY_REG_OP mtd: spi-nor: spansion: add support for S28HS02GT Tomas Winkler (1): mtd: use refcount to prevent corruption Tudor Ambarus (5): mtd: spi-nor: rename method for enabling or disabling octal DTR mtd: spi-nor: spansion: return method directly mtd: spi-nor: spansion: let SFDP determine the flash and sector size mtd: spi-nor: spansion: switch s25hx_t to use vreg_offset for quad_enable() mtd: spi-nor: spansion: switch cypress_nor_get_page_size() to use vreg_offset William Zhang (5): mtd: rawnand: brcmnand: Fix ECC level field setting for v7.2 controller mtd: rawnand: brcmnand: Fix potential false time out warning mtd: rawnand: brcmnand: Fix crash during the panic_write mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write mtd: rawnand: brcmnand: Fix mtd oobsize Yangtao Li (17): mtd: rawnand: sunxi: Use devm_platform_get_and_ioremap_resource() mtd: rawnand: lpc32xx_slc: Use devm_platform_get_and_ioremap_resource() mtd: rawnand: mxc: Convert to devm_platform_ioremap_resource() mtd: rawnand: sh_flctl: Use devm_platform_get_and_ioremap_resource() mtd: rawnand: omap2: Use devm_platform_get_and_ioremap_resource() mtd: rawnand: stm32_fmc2: Use devm_platform_get_and_ioremap_resource() mtd: rawnand: lpc32xx_mlc: Use devm_platform_get_and_ioremap_resource() mtd: rawnand: fsl_upm: Use devm_platform_get_and_ioremap_resource() mtd: rawnand: atmel: Use devm_platform_get_and_ioremap_resource() mtd: nand: samsung: Convert to devm_platform_ioremap_resource() and devm_platform_get_and_ioremap_resource() mtd: plat-ram: Use devm_platform_get_and_ioremap_resource() mtd: lantiq-flash: Use devm_platform_get_and_ioremap_resource() mtd: lpddr2_nvm: Convert to devm_platform_ioremap_resource() mtd: st_spi_fsm: Convert to devm_platform_ioremap_resource() mtd: spear_smi: Convert to devm_platform_ioremap_resource() mtd: physmap-core: Use devm_platform_get_and_ioremap_resource() mtd: nand: omap: Use devm_platform_get_and_ioremap_resource() Yi Yang (1): mtd: rawnand: fsmc: handle clk prepare error in fsmc_nand_resume() Zhu Wang (1): mtd: rawnand: vf610_nfc: Do not check 0 for platform_get_irq() Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml | 6 +- Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 21 ++- Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml | 1 + Documentation/devicetree/bindings/mtd/nand-controller.yaml | 2 +- Documentation/devicetree/bindings/mtd/oxnas-nand.txt | 41 ----- Documentation/devicetree/bindings/mtd/partitions/seama.yaml | 44 +++++ drivers/mtd/devices/docg3.c | 8 +- drivers/mtd/devices/mchp23k256.c | 2 +- drivers/mtd/devices/mchp48l640.c | 2 +- drivers/mtd/devices/mtd_dataflash.c | 1 - drivers/mtd/devices/spear_smi.c | 20 +- drivers/mtd/devices/st_spi_fsm.c | 14 +- drivers/mtd/lpddr/lpddr2_nvm.c | 4 +- drivers/mtd/maps/lantiq-flash.c | 11 +- drivers/mtd/maps/physmap-bt1-rom.c | 1 - drivers/mtd/maps/physmap-core.c | 3 +- drivers/mtd/maps/physmap-gemini.c | 2 +- drivers/mtd/maps/physmap-ixp4xx.c | 2 +- drivers/mtd/maps/physmap-ixp4xx.h | 1 + drivers/mtd/maps/physmap-versatile.c | 4 +- drivers/mtd/maps/plat-ram.c | 3 +- drivers/mtd/maps/sun_uflash.c | 2 +- drivers/mtd/mtdblock.c | 2 +- drivers/mtd/mtdblock_ro.c | 2 +- drivers/mtd/mtdcore.c | 97 +++++----- drivers/mtd/mtdcore.h | 1 + drivers/mtd/mtdpart.c | 14 +- drivers/mtd/nand/ecc-mxic.c | 2 +- drivers/mtd/nand/ecc.c | 2 +- drivers/mtd/nand/onenand/onenand_omap2.c | 12 +- drivers/mtd/nand/onenand/onenand_samsung.c | 9 +- drivers/mtd/nand/raw/Kconfig | 9 +- drivers/mtd/nand/raw/Makefile | 1 - drivers/mtd/nand/raw/ams-delta.c | 2 +- drivers/mtd/nand/raw/arasan-nand-controller.c | 29 +-- drivers/mtd/nand/raw/atmel/nand-controller.c | 3 +- drivers/mtd/nand/raw/brcmnand/bcm63138_nand.c | 4 +- drivers/mtd/nand/raw/brcmnand/brcmnand.c | 130 ++++++++----- drivers/mtd/nand/raw/brcmnand/iproc_nand.c | 7 +- drivers/mtd/nand/raw/davinci_nand.c | 1 - drivers/mtd/nand/raw/denali_dt.c | 1 - drivers/mtd/nand/raw/fsl_ifc_nand.c | 1 + drivers/mtd/nand/raw/fsl_upm.c | 6 +- drivers/mtd/nand/raw/fsmc_nand.c | 19 +- drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 2 +- drivers/mtd/nand/raw/ingenic/ingenic_ecc.c | 1 + drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c | 1 - drivers/mtd/nand/raw/intel-nand-controller.c | 15 +- drivers/mtd/nand/raw/lpc32xx_mlc.c | 3 +- drivers/mtd/nand/raw/lpc32xx_slc.c | 15 +- drivers/mtd/nand/raw/marvell_nand.c | 19 +- drivers/mtd/nand/raw/meson_nand.c | 72 +++++--- drivers/mtd/nand/raw/mpc5121_nfc.c | 15 +- drivers/mtd/nand/raw/mtk_nand.c | 63 ++----- drivers/mtd/nand/raw/mxc_nand.c | 10 +- drivers/mtd/nand/raw/nand_base.c | 1 + drivers/mtd/nand/raw/ndfc.c | 3 +- drivers/mtd/nand/raw/omap2.c | 5 +- drivers/mtd/nand/raw/orion_nand.c | 22 +-- drivers/mtd/nand/raw/oxnas_nand.c | 209 --------------------- drivers/mtd/nand/raw/pl35x-nand-controller.c | 4 +- drivers/mtd/nand/raw/qcom_nandc.c | 1003 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------- drivers/mtd/nand/raw/rockchip-nand-controller.c | 1 - drivers/mtd/nand/raw/s3c2410.c | 1 - drivers/mtd/nand/raw/sh_flctl.c | 4 +- drivers/mtd/nand/raw/socrates_nand.c | 3 +- drivers/mtd/nand/raw/stm32_fmc2_nand.c | 21 +-- drivers/mtd/nand/raw/sunxi_nand.c | 33 +--- drivers/mtd/nand/raw/vf610_nfc.c | 35 ++-- drivers/mtd/nand/raw/xway_nand.c | 3 +- drivers/mtd/nand/spi/esmt.c | 9 + drivers/mtd/nand/spi/gigadevice.c | 20 ++ drivers/mtd/nand/spi/toshiba.c | 33 ++++ drivers/mtd/spi-nor/atmel.c | 8 +- drivers/mtd/spi-nor/controllers/nxp-spifi.c | 34 +--- drivers/mtd/spi-nor/core.c | 57 +++--- drivers/mtd/spi-nor/core.h | 9 +- drivers/mtd/spi-nor/debugfs.c | 1 + drivers/mtd/spi-nor/issi.c | 4 +- drivers/mtd/spi-nor/macronix.c | 4 +- drivers/mtd/spi-nor/micron-st.c | 8 +- drivers/mtd/spi-nor/spansion.c | 318 ++++++++++++++++++++------------ drivers/mtd/spi-nor/sst.c | 12 +- drivers/mtd/spi-nor/swp.c | 9 +- drivers/mtd/spi-nor/winbond.c | 9 +- drivers/mtd/spi-nor/xilinx.c | 4 +- include/linux/mtd/mtd.h | 2 +- include/linux/mtd/rawnand.h | 1 + 88 files changed, 1348 insertions(+), 1307 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt create mode 100644 Documentation/devicetree/bindings/mtd/partitions/seama.yaml delete mode 100644 drivers/mtd/nand/raw/oxnas_nand.c