| Message ID | 20240223034758.13753-1-william.zhang@broadcom.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mtd: rawnand: brcmnand: driver and doc updates | expand |
On 2/22/2024 7:47 PM, William Zhang wrote: > From: David Regan <dregan@broadcom.com> > > Fix return types for exec_op reset and status helper functions. > > Reported-by: Dan Carpenter <dan.carpenter@linaro.org> > Closes: http://lists.infradead.org/pipermail/linux-mtd/2023-December/102423.html > Fixes: 3c8260ce7663 ("mtd: rawnand: brcmnand: exec_op implementation") > Signed-off-by: David Regan <dregan@broadcom.com> > Signed-off-by: William Zhang <william.zhang@broadcom.com> > Reviewed-by: William Zhang <william.zhang@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
On 2/22/24 19:47, William Zhang wrote: > This patch series is an update from the previous version [1] after > exex_op support and fixes (patch 1 to 4 from the previous version.) > > It updates all the BCMBCA SoC to support the nand controller and add > functions to handle BCMBCA specific needs on ECC and Write Protection > usage. The device tree document is also updated accordingly with the new > properties needed by the driver. > > In addition there is a bug fix for exec_op helper functions, log level > adjustment on uncorrectable ECC error and some coding style fixes. > > [1] https://lore.kernel.org/lkml/20230606231252.94838-1-william.zhang@broadcom.com/ Miquel, thanks for having applied the patches, we should have discussed ahead of time whether you should take the SoC/board-level DTS changes through your tree or mine, but it's fine either way and should not lead to conflicts in Linus' tree.
Hi Florian, florian.fainelli@broadcom.com wrote on Mon, 26 Feb 2024 09:36:02 -0800: > On 2/22/24 19:47, William Zhang wrote: > > This patch series is an update from the previous version [1] after > > exex_op support and fixes (patch 1 to 4 from the previous version.) > > > > It updates all the BCMBCA SoC to support the nand controller and add > > functions to handle BCMBCA specific needs on ECC and Write Protection > > usage. The device tree document is also updated accordingly with the new > > properties needed by the driver. > > > > In addition there is a bug fix for exec_op helper functions, log level > > adjustment on uncorrectable ECC error and some coding style fixes. > > > > [1] https://lore.kernel.org/lkml/20230606231252.94838-1-william.zhang@broadcom.com/ > > Miquel, thanks for having applied the patches, we should have discussed ahead of time whether you should take the SoC/board-level DTS changes through your tree or mine, but it's fine either way and should not lead to conflicts in Linus' tree. I'm sorry for not thinking about this ahead of time, I was also not Cced on the other patches, I noticed it (told Willliam) and just forgot about this when I applied the series. It is currently living in -next so if there is any problem I can still act. However for this kind of change I usually apply the bindings and .c changes independently from the DT patches. I believe there is no problem having one or the other being merged first, or do I overlook something? Cheers, Miquèl
Hi Miquel, On 2/29/24 01:11, Miquel Raynal wrote: > Hi Florian, > > florian.fainelli@broadcom.com wrote on Mon, 26 Feb 2024 09:36:02 -0800: > >> On 2/22/24 19:47, William Zhang wrote: >>> This patch series is an update from the previous version [1] after >>> exex_op support and fixes (patch 1 to 4 from the previous version.) >>> >>> It updates all the BCMBCA SoC to support the nand controller and add >>> functions to handle BCMBCA specific needs on ECC and Write Protection >>> usage. The device tree document is also updated accordingly with the new >>> properties needed by the driver. >>> >>> In addition there is a bug fix for exec_op helper functions, log level >>> adjustment on uncorrectable ECC error and some coding style fixes. >>> >>> [1] https://lore.kernel.org/lkml/20230606231252.94838-1-william.zhang@broadcom.com/ >> >> Miquel, thanks for having applied the patches, we should have discussed ahead of time whether you should take the SoC/board-level DTS changes through your tree or mine, but it's fine either way and should not lead to conflicts in Linus' tree. > > I'm sorry for not thinking about this ahead of time, I was also not > Cced on the other patches, I noticed it (told Willliam) and just forgot > about this when I applied the series. Not a problem. > > It is currently living in -next so if there is any problem I can still > act. > > However for this kind of change I usually apply the bindings and .c > changes independently from the DT patches. I believe there is no > problem having one or the other being merged first, or do I overlook > something? That is totally fine my concern was more with you also applying the DTS changes which could easily conflict with changes queued up in my ARM SoC tree, and also did not have my Signed-off-by/Acked-by tag on them (I was waiting on the bindings patch to be Acked-by before giving my own). Anyway, let's not make this more complicated than it needs to be, and thanks for working with William on these changes!
Hi Florian, miquel.raynal@bootlin.com wrote on Thu, 29 Feb 2024 10:11:01 +0100: > Hi Florian, > > florian.fainelli@broadcom.com wrote on Mon, 26 Feb 2024 09:36:02 -0800: > > > On 2/22/24 19:47, William Zhang wrote: > > > This patch series is an update from the previous version [1] after > > > exex_op support and fixes (patch 1 to 4 from the previous version.) > > > > > > It updates all the BCMBCA SoC to support the nand controller and add > > > functions to handle BCMBCA specific needs on ECC and Write Protection > > > usage. The device tree document is also updated accordingly with the new > > > properties needed by the driver. > > > > > > In addition there is a bug fix for exec_op helper functions, log level > > > adjustment on uncorrectable ECC error and some coding style fixes. > > > > > > [1] https://lore.kernel.org/lkml/20230606231252.94838-1-william.zhang@broadcom.com/ > > > > Miquel, thanks for having applied the patches, we should have discussed ahead of time whether you should take the SoC/board-level DTS changes through your tree or mine, but it's fine either way and should not lead to conflicts in Linus' tree. > > I'm sorry for not thinking about this ahead of time, I was also not > Cced on the other patches, I noticed it (told Willliam) and just forgot > about this when I applied the series. > > It is currently living in -next so if there is any problem I can still > act. > > However for this kind of change I usually apply the bindings and .c > changes independently from the DT patches. I believe there is no > problem having one or the other being merged first, or do I overlook > something? What the heck /o\ I just understand now my mistake, I am very truly sorry for that... You were telling me I should sync with you before taking DT changes, and I was so convinced I _did_not_ take the DT, when I looked at the branch I did not understand your point. But I am totally sorry I actually did take the DTs by mistake and I truly did not notice it. Confirmation bias I suppose. My very sincere apologies. As mentioned previously, I was not CC'ed on the DT patches, but I believe the linux-mtd list was, so the patches didn't appear in my inbox, and once I was happy with the binding/driver changes I applied it all without noticing the DT changes had sneaked in. I'm finally preparing the PR for Linus and I see it now... I believe the SoC tree is closed now so it's up to you what I should do with them. Let me know if you want me to keep them in my tree and forward them to Linus or if I should drop them and you'll take them for the next cycle. Also, if I keep them, shall I add some tag of yours on these 3 patches? For the record I did not review them. Thanks and again, I'm confused. I never apply DT patches like that, your initial remark was more than legitimate. Cheers, Miquèl
On 3/14/24 15:04, Miquel Raynal wrote: > Hi Florian, > > miquel.raynal@bootlin.com wrote on Thu, 29 Feb 2024 10:11:01 +0100: > >> Hi Florian, >> >> florian.fainelli@broadcom.com wrote on Mon, 26 Feb 2024 09:36:02 -0800: >> >>> On 2/22/24 19:47, William Zhang wrote: >>>> This patch series is an update from the previous version [1] after >>>> exex_op support and fixes (patch 1 to 4 from the previous version.) >>>> >>>> It updates all the BCMBCA SoC to support the nand controller and add >>>> functions to handle BCMBCA specific needs on ECC and Write Protection >>>> usage. The device tree document is also updated accordingly with the new >>>> properties needed by the driver. >>>> >>>> In addition there is a bug fix for exec_op helper functions, log level >>>> adjustment on uncorrectable ECC error and some coding style fixes. >>>> >>>> [1] https://lore.kernel.org/lkml/20230606231252.94838-1-william.zhang@broadcom.com/ >>> >>> Miquel, thanks for having applied the patches, we should have discussed ahead of time whether you should take the SoC/board-level DTS changes through your tree or mine, but it's fine either way and should not lead to conflicts in Linus' tree. >> >> I'm sorry for not thinking about this ahead of time, I was also not >> Cced on the other patches, I noticed it (told Willliam) and just forgot >> about this when I applied the series. >> >> It is currently living in -next so if there is any problem I can still >> act. >> >> However for this kind of change I usually apply the bindings and .c >> changes independently from the DT patches. I believe there is no >> problem having one or the other being merged first, or do I overlook >> something? > > What the heck /o\ I just understand now my mistake, I am very truly > sorry for that... > > You were telling me I should sync with you before taking DT changes, > and I was so convinced I _did_not_ take the DT, when I looked at the > branch I did not understand your point. But I am totally sorry I > actually did take the DTs by mistake and I truly did not notice it. > Confirmation bias I suppose. My very sincere apologies. > > As mentioned previously, I was not CC'ed on the DT patches, but I > believe the linux-mtd list was, so the patches didn't appear in my > inbox, and once I was happy with the binding/driver changes I applied > it all without noticing the DT changes had sneaked in. > > I'm finally preparing the PR for Linus and I see it now... > > I believe the SoC tree is closed now so it's up to you what I should do > with them. Let me know if you want me to keep them in my tree and > forward them to Linus or if I should drop them and you'll take them for > the next cycle. Also, if I keep them, shall I add some tag of yours on > these 3 patches? For the record I did not review them. Yes please add my: Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> tag, and it's fine I don't expect that we will get conflicts for those files. > > Thanks and again, I'm confused. I never apply DT patches like that, > your initial remark was more than legitimate. Not a problem!
> >> I'm sorry for not thinking about this ahead of time, I was also not > >> Cced on the other patches, I noticed it (told Willliam) and just forgot > >> about this when I applied the series. > >> > >> It is currently living in -next so if there is any problem I can still > >> act. > >> > >> However for this kind of change I usually apply the bindings and .c > >> changes independently from the DT patches. I believe there is no > >> problem having one or the other being merged first, or do I overlook > >> something? > > > > What the heck /o\ I just understand now my mistake, I am very truly > > sorry for that... > > > > You were telling me I should sync with you before taking DT changes, > > and I was so convinced I _did_not_ take the DT, when I looked at the > > branch I did not understand your point. But I am totally sorry I > > actually did take the DTs by mistake and I truly did not notice it. > > Confirmation bias I suppose. My very sincere apologies. > > > > As mentioned previously, I was not CC'ed on the DT patches, but I > > believe the linux-mtd list was, so the patches didn't appear in my > > inbox, and once I was happy with the binding/driver changes I applied > > it all without noticing the DT changes had sneaked in. > > > > I'm finally preparing the PR for Linus and I see it now... > > > > I believe the SoC tree is closed now so it's up to you what I should do > > with them. Let me know if you want me to keep them in my tree and > > forward them to Linus or if I should drop them and you'll take them for > > the next cycle. Also, if I keep them, shall I add some tag of yours on > > these 3 patches? For the record I did not review them. > > Yes please add my: > > Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> > > tag, and it's fine I don't expect that we will get conflicts for those files. > > > > > Thanks and again, I'm confused. I never apply DT patches like that, > > your initial remark was more than legitimate. > > Not a problem! Thanks :-) Miquèl