On Tue, Apr 25, 2023 at 04:22:32PM -0400, Sean Anderson wrote: > The features which do not work (major protocol changes) are disabled :) > > If it would cause this series to be immediately merged, I would remove > KX/KR and 2.5G which are the only untested link modes. > > That said, PCS support is necessary for these modes, so it is not even > possible to select them. > > > If you do not have the time to fix up the loose ends > > for this patch submission now > > I have time to fix up any loose ends preventing this series from being > applied. However, I am not very sympathetic to larger requests, since > there has been extensive time to supply feedback already. > > > , you won't have the time to debug > > regressions on boards you might not even have access to, which worked > > fine previously due to the static RCW/PBL configuration. > > I have gotten no substantive feedback on this driver. I have been > working on this series since June last year, and no one has commented on > the core algotithms thus far. My capacity for making large changes has > decreased because the project funding the development has ended. I > appreciate that you are taking interest now, but frankly I think it is > rather past time... > > > I have downloaded your patches, and although I have objections to some > > of them already, I will be in the process of evaluating, testing, > > changing them, for the coming weeks, perhaps even more. Please consider > > this a NACK for the current patch set due to the SERDES related material, > > although the unrelated patches (like "dt-bindings: Convert gpio-mmio to > > yaml") can and should have been submitted separately, so they can be > > analyzed by their respective maintainers based on their own merit and > > not as part of an overall problematic set. > > This patchset has been ready to merge for several revisions now. I do > not consider it problematic. However, I do consider the (nonexistant) > review process for this subsystem extremely problematic. To be very clear, the "larger request" which you are unsympathetic to is to wait. I didn't ask you to change anything. I need to catch up with 14 rounds of patches from you and with the discussions that took place on each version, and understand how you responded to feedback like "don't remove PHY interrupts without finding out why they don't work" and "doesn't changing PLL frequencies on the fly affect other lanes that use those PLLs, like PCIe?". The cognitive dissonance between this and you saying that the review process for this subsystem is absent is mind boggling. You are sufficiently averse to feedback that's not the feedback you want to hear, that it's hard to find a common ground. It's naive to expect that the silicon vendor will respond positively to a change of such magnitude as this one, which was written using the "works for me" work ethics, but which the silicon vendor will have to work with, afterwards. The only reason I sent my previous email was to announce you in advance that I have managed to carve out a sufficient amount of time to explore the topic in detail, and to stop you from pushing this forward in this state. I thought you would understand the concept of engineers being unable to easily reserve large chunks of time for a given project, after all, you brought this argument with your own company... Even if the SERDES and PLL drivers "work for you" in the current form, I doubt the usefulness of a PLL driver if you have to disconnect the SoC's reset request signal on the board to not be stuck in a reboot loop. https://lore.kernel.org/linux-arm-kernel/d3163201-2012-6cf9-c798-916bab9c7f72@xxxxxxxx/ Even so, I have not said anything definitive, I have just requested time to take your proposal at face value, and understand whether there is any other alternative. I would advise you to consider whether your follow-up emails on this topic encourage a collaborative atmosphere. I will come back when I have tested the driver in a reasonable amount of setups.
