14:13 <NishanthMenon> pivi https://lore.kernel.org/all/20240703100036.17896-1-francesco@dolcini.it/ i am dropping this off my queue - i assume you will update once the pieces are together.

14:16 <pivi> NishanthMenon: mumble. which pieces are missing?

14:16 <NishanthMenon> https://www.irccloud.com/pastebin/uhRMSfbW/

14:17 <NishanthMenon> the driver fixups haven't made it in - might be good to split the patches up

14:17 <NishanthMenon> second: I think Niklas is suggesting https://lore.kernel.org/all/ZpEILZ2DLhvYYGci@ryzen.lan/ commit message improvements ?

14:18 <pivi> NishanthMenon: no, Niklas is suggesting to drop the series at all

14:18 <pivi> NishanthMenon: or maybe not

14:18 <pivi> and it is just sharing a concern

14:18 <NishanthMenon> i transllated it as concern that should be documented in commit log

14:19 <pivi> let's go one step back

14:20 <pivi> are you ok on breaking the compatibility with old DT blobs for the sake of having a correct solution and saving the pain to new users using this functionality?

14:21 <pivi> because that's a decision that you and vigneshr as maintainer should take, considering also that most of the board affected are from TI

14:21 <pivi> if you are fine taking this in I can split the series, improve the commit message, whatever we consider appropriate

14:22 <NishanthMenon> 1 - it sounds like it is a driver bug

14:22 <NishanthMenon> 2 - if the fixup of driver bug implies incompatible dt change - we should co-ordinate to make sure the integration happens in rc1 cleanly.

14:23 <pivi> ok, I read this as you are fine on doing this change. correct ?

14:24 <NishanthMenon> 3 - in terms of breaking backwards compatibility of DT - it does happen time to time - unfortunately as much as we'd love it never to happen.. as long as there is a just cause, I am not married to DT binary is completely backward compatible change only - there have been instances where this breakage has happened.. but I dont want it to be "free for all" - no. if there is some way to maintain (via quirk) some backward

14:24 <NishanthMenon> compatibility, I'd prefer that

14:25 <pivi> I do not see a way to have a quirk here, both myself and Emanuele looked into it

14:25 <NishanthMenon> i am a bit more adamant of breaking basic boot.. vs a driver alone breaking..

14:25 <pivi> ok, so we move forward.

14:26 <pivi> split the series in 2 separated patches, improve the commit message (on me) and you do coordinate with the PCIe maintainer. ack ?

14:26 <NishanthMenon> either way to merge this, will need a sync between pcie maintainer and dt maintainer with an immutable tag from pcie driver maintainer so that I can merge it in and put the dts change on top.

14:28 <NishanthMenon> You will unfortunately have to request it so that we dont complicate the PR - ideally the patch alone will need to be applied on rc1 and a tag created, tag merged to their working branch and the tag sent to me..

14:28 <NishanthMenon> it is a heck of a headache :(

14:29 <pivi> let's proceed like that, before I send a v2, I ask on the mailing list an opinon from the PCIe people on the topic.

14:29 <NishanthMenon> yes, that will be helpful

14:36 <pivi> if you have only one of the 2 patches applied the end results is very simple. PCIe stays in reset, likewise nothing was inserted into the PCIe slot.

14:37 <pivi> BTW, this is the issue we had with our new HW bring-up. We were testing brand new hardware, PCIe not working, DT correct, and in the end, after debugging everything, we realized that the driver was driving the reset signal with the wrong polarity

14:37 <pivi> We did curse TI a little bit when we found the issue

14:37 <NishanthMenon> i wont be surprised :)