[PATCH v6 00/13] mtd: rawnand: brcmnand: driver and doc updates

Florian Fainelli florian.fainelli at broadcom.com
Thu Feb 29 09:32:35 PST 2024


Hi Miquel,

On 2/29/24 01:11, Miquel Raynal wrote:
> Hi Florian,
> 
> florian.fainelli at 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!
-- 
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240229/5724fb3f/attachment-0001.p7s>


More information about the linux-arm-kernel mailing list