| Message ID | YtGPO5SkMZfN8b/s@shell.armlinux.org.uk (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: dsa: always use phylink | expand |
Hi Russell, On Fri, Jul 15, 2022 at 05:00:59PM +0100, Russell King (Oracle) wrote: > Hi, > > This is a re-hash of the previous RFC series, this time using the > suggestion from Vladimir to create a swnode based fixed-link > specifier. > > Most of the changes are to DSA and phylink code from the previous > series. I've tested on my Clearfog (which has just one Marvell DSA > switch) and it works there - also tested without the fixed-link > specified in DT. I had some comments I wanted to leave on the previous RFC patch set (which in turn is essentially identical to this one, hence they still apply), but I held off because I thought you were waiting for some feedback from Andrew. Has something changed? I'm going to leave my comments anyway now.
On Fri, Jul 15, 2022 at 08:17:19PM +0300, Vladimir Oltean wrote: > Hi Russell, > > On Fri, Jul 15, 2022 at 05:00:59PM +0100, Russell King (Oracle) wrote: > > Hi, > > > > This is a re-hash of the previous RFC series, this time using the > > suggestion from Vladimir to create a swnode based fixed-link > > specifier. > > > > Most of the changes are to DSA and phylink code from the previous > > series. I've tested on my Clearfog (which has just one Marvell DSA > > switch) and it works there - also tested without the fixed-link > > specified in DT. > > I had some comments I wanted to leave on the previous RFC patch set > (which in turn is essentially identical to this one, hence they still > apply), but I held off because I thought you were waiting for some > feedback from Andrew. Has something changed? I've got fed up of waiting for very little feedback on patches I send. Jakub was fully prepared to apply my v2 RFC patches after - as he saw it - everyone that was likely to respond had responded. The only thing that delayed them was your eventual comments about re-working how it was being done. Yet again, posting the RFC series created very little in the way of feedback. I'm getting to the point of thinking its a waste of time posting RFC patches - it's counter productive. RFC means "request for comments" but it seems that many interpret it as "I can ignore it". So, I'm saying sod it now. I'm posting patches that I create without RFC tags. That means reviewers need to be on the ball if they want to comment _before_ they get merged into net-next. Posting RFC is a total waste of time, IMHO. You've proven it as well with some of your comments on this series, which I'll address in a separate reply.
On Fri, 15 Jul 2022 21:59:24 +0100 Russell King (Oracle) wrote: > The only thing that delayed them was your eventual comments about > re-working how it was being done. Yet again, posting the RFC series > created very little in the way of feedback. I'm getting to the point > of thinking its a waste of time posting RFC patches - it's counter > productive. RFC means "request for comments" but it seems that many > interpret it as "I can ignore it". I'm afraid you are correct. Dave used to occasionally apply RFC patches which kept reviewers on their toes a little bit (it kept me for sure). These days patchwork automatically marks patches as RFC based on the subject, tossing them out of "Action required" queue. So they are extremely easy to ignore. Perhaps an alternative way of posting would be to write "RFC only, please don't apply" at the end of the cover letter. Maybe folks will at least get thru reading the cover letter then :S
On Fri, Jul 15, 2022 at 04:03:59PM -0700, Jakub Kicinski wrote: > On Fri, 15 Jul 2022 21:59:24 +0100 Russell King (Oracle) wrote: > > The only thing that delayed them was your eventual comments about > > re-working how it was being done. Yet again, posting the RFC series > > created very little in the way of feedback. I'm getting to the point > > of thinking its a waste of time posting RFC patches - it's counter > > productive. RFC means "request for comments" but it seems that many > > interpret it as "I can ignore it". > > I'm afraid you are correct. Dave used to occasionally apply RFC patches > which kept reviewers on their toes a little bit (it kept me for sure). > These days patchwork automatically marks patches as RFC based on > the subject, tossing them out of "Action required" queue. So they are > extremely easy to ignore. > > Perhaps an alternative way of posting would be to write "RFC only, > please don't apply" at the end of the cover letter. Maybe folks will > at least get thru reading the cover letter then :S Again, expressing complaints to me for responding late is misdirected frustration. The fact that I chose to leave my comments only when Russell gave up on waiting for feedback from Andrew doesn't mean I ignored his RFC patches, it just means I didn't want to add noise and ask for minor changes when it wasn't clear that this is the overall final direction that the series would follow. I still have preferences about the way in which this patch set gets accepted, and now seems like the proper moment to express them.
On Sat, Jul 16, 2022 at 02:15:51PM +0300, Vladimir Oltean wrote: > On Fri, Jul 15, 2022 at 04:03:59PM -0700, Jakub Kicinski wrote: > > On Fri, 15 Jul 2022 21:59:24 +0100 Russell King (Oracle) wrote: > > > The only thing that delayed them was your eventual comments about > > > re-working how it was being done. Yet again, posting the RFC series > > > created very little in the way of feedback. I'm getting to the point > > > of thinking its a waste of time posting RFC patches - it's counter > > > productive. RFC means "request for comments" but it seems that many > > > interpret it as "I can ignore it". > > > > I'm afraid you are correct. Dave used to occasionally apply RFC patches > > which kept reviewers on their toes a little bit (it kept me for sure). > > These days patchwork automatically marks patches as RFC based on > > the subject, tossing them out of "Action required" queue. So they are > > extremely easy to ignore. > > > > Perhaps an alternative way of posting would be to write "RFC only, > > please don't apply" at the end of the cover letter. Maybe folks will > > at least get thru reading the cover letter then :S > > Again, expressing complaints to me for responding late is misdirected > frustration. The fact that I chose to leave my comments only when > Russell gave up on waiting for feedback from Andrew doesn't mean I > ignored his RFC patches, it just means I didn't want to add noise and > ask for minor changes when it wasn't clear that this is the overall > final direction that the series would follow. I still have preferences > about the way in which this patch set gets accepted, and now seems like > the proper moment to express them. In the first RFC series I sent on the 24 June, I explicitly asked the following questions: Obvious questions: 1. Should phylink_get_caps() be augmented in this way, or should it be a separate method? 2. DSA has traditionally used "interface mode for the maximum supported speed on this port" where the interface mode is programmable (via its internal port_max_speed_mode() method) but this is only present for a few of the sub-drivers. Is reporting the current interface mode correct where this method is not implemented? Obvious questions: 1. Should we be allowing half-duplex for this? 2. If we do allow half-duplex, should we prefer fastest speed over duplex setting, or should we prefer fastest full-duplex speed over any half-duplex? 3. How do we sanely switch DSA from its current behaviour to always using phylink for these ports without breakage - this is the difficult one, because it's not obvious which drivers have been coded to either work around this quirk of the DSA implementation. For example, if we start forcing the link down before calling dsa_port_phylink_create(), and we then fail to set max-fixed-link, then the CPU/DSA port is going to fail, and we're going to have lots of regressions. I even stated: "Please look at the patches and make suggestions on how we can proceed to clean up this quirk of DSA." and made no mention of wanting something explicitly from Andrew. Yet, none of those questions were answered. So no, Jakub's comments are *not* misdirected at all. Go back and read my June 24th RFC series yourself: https://lore.kernel.org/all/YrWi5oBFn7vR15BH@shell.armlinux.org.uk/ I've *tried* my best to be kind and collaborative, but I've been ignored. Now I'm hacked off. This could have been avoided by responding to my explicit questions sooner, rather than at the -rc6/-rc7 stage of the show.
On Sat, Jul 16, 2022 at 12:43:00PM +0100, Russell King (Oracle) wrote: > In the first RFC series I sent on the 24 June, I explicitly asked the > following questions: (...) > I even stated: "Please look at the patches and make suggestions on how > we can proceed to clean up this quirk of DSA." and made no mention of > wanting something explicitly from Andrew. > > Yet, none of those questions were answered. > > So no, Jakub's comments are *not* misdirected at all. Go back and read > my June 24th RFC series yourself: > > https://lore.kernel.org/all/YrWi5oBFn7vR15BH@shell.armlinux.org.uk/ I don't believe I need to justify myself any further for why I didn't leave a comment on any certain day. I left my comments when I believed it was most appropriate for me to intervene (as someone who isn't really affected in any way by the changes, except for generally maintaining what's in net/dsa/, and wanting to keep a clean framework structure). Also, to repeat myself, blaming me for leaving comments, but doing so late, is not really fair. I could have not responded at all, and I wouldn't be having this unpleasant discussion. It begs the question whether you're willing to be held accountable in the same way for the dates on which you respond on RFC patches. > I've *tried* my best to be kind and collaborative, but I've been > ignored. Now I'm hacked off. This could have been avoided by responding > to my explicit questions sooner, rather than at the -rc6/-rc7 stage of > the show. I think you should continue to try your best to be kind and collaborative, you weren't provoked or intentionally ignored in any way, and it isn't doing these patches any good.
On Sat, 16 Jul 2022 14:15:51 +0300 Vladimir Oltean wrote: > > I'm afraid you are correct. Dave used to occasionally apply RFC patches > > which kept reviewers on their toes a little bit (it kept me for sure). > > These days patchwork automatically marks patches as RFC based on > > the subject, tossing them out of "Action required" queue. So they are > > extremely easy to ignore. > > > > Perhaps an alternative way of posting would be to write "RFC only, > > please don't apply" at the end of the cover letter. Maybe folks will > > at least get thru reading the cover letter then :S > > Again, expressing complaints to me for responding late is misdirected > frustration. The fact that I chose to leave my comments only when > Russell gave up on waiting for feedback from Andrew doesn't mean I > ignored his RFC patches, it just means I didn't want to add noise and > ask for minor changes when it wasn't clear that this is the overall > final direction that the series would follow. I still have preferences > about the way in which this patch set gets accepted, and now seems like > the proper moment to express them. Oh, sorry, I wasn't commenting on how things played out for this series. I was mostly reflecting on the fact that the automatic patch state updates in patchwork have changed how RFC postings can be used on netdev, and it happened without any of us being asked our opinion.
On Sat, Jul 16, 2022 at 04:13:45PM +0300, Vladimir Oltean wrote: > On Sat, Jul 16, 2022 at 12:43:00PM +0100, Russell King (Oracle) wrote: > > In the first RFC series I sent on the 24 June, I explicitly asked the > > following questions: > (...) > > I even stated: "Please look at the patches and make suggestions on how > > we can proceed to clean up this quirk of DSA." and made no mention of > > wanting something explicitly from Andrew. > > > > Yet, none of those questions were answered. > > > > So no, Jakub's comments are *not* misdirected at all. Go back and read > > my June 24th RFC series yourself: > > > > https://lore.kernel.org/all/YrWi5oBFn7vR15BH@shell.armlinux.org.uk/ > > I don't believe I need to justify myself any further for why I didn't > leave a comment on any certain day. I left my comments when I believed > it was most appropriate for me to intervene (as someone who isn't really > affected in any way by the changes, except for generally maintaining > what's in net/dsa/, and wanting to keep a clean framework structure). > Also, to repeat myself, blaming me for leaving comments, but doing so > late, is not really fair. I could have not responded at all, and I > wouldn't be having this unpleasant discussion. It begs the question > whether you're willing to be held accountable in the same way for the > dates on which you respond on RFC patches. > > > I've *tried* my best to be kind and collaborative, but I've been > > ignored. Now I'm hacked off. This could have been avoided by responding > > to my explicit questions sooner, rather than at the -rc6/-rc7 stage of > > the show. > > I think you should continue to try your best to be kind and collaborative, > you weren't provoked or intentionally ignored in any way, and it isn't > doing these patches any good. And yet again, I don't have answers to many of those questions... which just shows how broken this process is, and how utterly pointless it is 0to ask any questions in this area. My conclusion: you don't care one bit to even answer questions until there's a chance that patches that you disagree with might be merged, and oh my god, you've got to respond to stop that happening because you might disagree with something. You can't do the collaborative thing and respond when someone asks explicit questions about how things should be done. I'm not going to let this go. I'm really pissed off by this and you are the focus of my frustration. Well, its now too late to do anything about this. This is going to miss this cycle. It might get in next cycle, and whoopy do, for a kernel that's very likely to be a LTS. Given the lack of testing that sounds like a complete and utter disaster. One that was entirely avoidable had feedback been given EARLIER in this cycle.
On Mon, Jul 18, 2022 at 09:53:23AM +0100, Russell King (Oracle) wrote: > On Sat, Jul 16, 2022 at 04:13:45PM +0300, Vladimir Oltean wrote: > > On Sat, Jul 16, 2022 at 12:43:00PM +0100, Russell King (Oracle) wrote: > > > In the first RFC series I sent on the 24 June, I explicitly asked the > > > following questions: > > (...) > > > I even stated: "Please look at the patches and make suggestions on how > > > we can proceed to clean up this quirk of DSA." and made no mention of > > > wanting something explicitly from Andrew. > > > > > > Yet, none of those questions were answered. > > > > > > So no, Jakub's comments are *not* misdirected at all. Go back and read > > > my June 24th RFC series yourself: > > > > > > https://lore.kernel.org/all/YrWi5oBFn7vR15BH@shell.armlinux.org.uk/ > > > > I don't believe I need to justify myself any further for why I didn't > > leave a comment on any certain day. I left my comments when I believed > > it was most appropriate for me to intervene (as someone who isn't really > > affected in any way by the changes, except for generally maintaining > > what's in net/dsa/, and wanting to keep a clean framework structure). > > Also, to repeat myself, blaming me for leaving comments, but doing so > > late, is not really fair. I could have not responded at all, and I > > wouldn't be having this unpleasant discussion. It begs the question > > whether you're willing to be held accountable in the same way for the > > dates on which you respond on RFC patches. > > > > > I've *tried* my best to be kind and collaborative, but I've been > > > ignored. Now I'm hacked off. This could have been avoided by responding > > > to my explicit questions sooner, rather than at the -rc6/-rc7 stage of > > > the show. > > > > I think you should continue to try your best to be kind and collaborative, > > you weren't provoked or intentionally ignored in any way, and it isn't > > doing these patches any good. > > And yet again, I don't have answers to many of those questions... which > just shows how broken this process is, and how utterly pointless it is > 0to ask any questions in this area. > > My conclusion: you don't care one bit to even answer questions until > there's a chance that patches that you disagree with might be merged, > and oh my god, you've got to respond to stop that happening because you > might disagree with something. You can't do the collaborative thing and > respond when someone asks explicit questions about how things should be > done. > > I'm not going to let this go. I'm really pissed off by this and you > are the focus of my frustration. The hypothesis that you put forward is that I'm sabotaging you by not responding to RFCs, then leaving comments when you submit the patches proper, just so that they're delayed because I don't agree with them; and that the process is broken because it allows me to do just that and get away with it (for fun, I assume?). So first off, you sent the first RFC towards 2 people in To:, and 19 people in Cc:. I was one of the people in Cc. You didn't ask *me* any explicit question. In fact, when you did, I responded within 5 hours: https://lore.kernel.org/linux-arm-kernel/20220707154303.236xaeape7isracw@skbuf/ Then, why did I not respond earlier to questions I had an opinion on? Based on prior experience, anything I reply to you has a chance of inflaming you for reasons that are outside of my control, and the discussion derails and eventually ends with you saying that I'm being difficult and you're quitting for the day, week, month, kernel release cycle or what not. I'm not saying that's my fault or your fault in general, it's just a statistical observation based on past interactions, and it looks like this one is no different. With regard to this topic, there was ample opportunity for the patch set to come to a resolve without my intervention, and I decided that the best way to maximize the chances of this discussion not going sideways is to not say anything at all, especially when I don't need to. Gradually, the opportunity for the patch set to resolve itself without my intervention diminished, and I started offering my feedback to the code. It's perhaps necessary of me to not let this phrase of yours unaddressed, because it is subtly part of your argument that I'm just trying to delay your patches as part of a sabotage plot: | The only thing that delayed them was your eventual comments about | re-working how it was being done. Let's not forget that I did *not* request you to rework the implementation to use software nodes. I simply went with the code you originally proposed, explained why it is unnaturally structured in my view, asked you why you did not consider an alternative structure if you're not willing to make phylink absorb the logic, then you said you'd be happy to rework using software nodes. https://lore.kernel.org/netdev/20220707193753.2j67ni3or3bfkt6k@skbuf/ My feedback was very actionable, I put forward a working prototype for using software nodes that did consume time for me to write, I was not being handwavy in any way. More importantly, you agreed with it and are using it now. And all of that happened during RFC stages. To ignore these facts when you state that I respond only to non-RFC patches is a lie by omission. I give feedback to code in the order of importance. Now was the time to point out that (a) I don't want to add support for the defaulting mode on CPU ports for drivers that didn't have it previously, and (b) I'd like to keep the current implementation of the defaulting feature as "don't register with phylink" as the default, with just an opt-in to create the software node. Drivers can opt into that behavior as need shows (breakage reports). Again, this is all extremely actionable feedback, and rather minor in the grand scheme of things. So I'm sorry, but your frustration expressed towards me for ignoring RFC patches *is* misdirected and there's nothing I will consider changing. If the discussion derailed now due to me it doesn't mean it wouldn't have derailed earlier. There are still many people who could have said more things than they did, and yet, I'm not even blaming them for not doing that. There is a chapter in a book by Robert Cialdini called "Influence: The Psychology of Persuasion" which discusses social proof, the mechanism through which people tend to do what others do when otherwise unsure. I'm paraphrasing, but there is a paragraph discussing what can be done when social proof works against you, for example you're being attacked on the street, you ask for help and nobody appears to do anything except for passing by. Summarized, you should ask for very specific things, point to people, say names, rather than get frustrated that the crowd does nothing. > Well, its now too late to do anything about this. This is going to miss > this cycle. It might get in next cycle, and whoopy do, for a kernel > that's very likely to be a LTS. Given the lack of testing that sounds > like a complete and utter disaster. One that was entirely avoidable had > feedback been given EARLIER in this cycle. If your patch set was a silver bullet to avoid breakage, that would have maybe changed things a little, but it isn't. For any driver that might boot using a DT blob with the defaulting feature for the CPU port, there is a gamble to be taken whether the better thing to do is to unleash phylink at it unattended or to let it be. Obviously having a driver maintainer assist phylink would be the correct thing, but until the board in question reaches a maintainer, chances are it will probably reach a user. What I'm trying to obtain in terms of changes is that the user can at least correlate the breakage he's seeing with a dmesg warning message that clearly indicates what phylink or DSA tried to do in lack of clear DT description.
On Mon, Jul 18, 2022 at 03:45:12PM +0300, Vladimir Oltean wrote: > On Mon, Jul 18, 2022 at 09:53:23AM +0100, Russell King (Oracle) wrote: > > On Sat, Jul 16, 2022 at 04:13:45PM +0300, Vladimir Oltean wrote: > > > On Sat, Jul 16, 2022 at 12:43:00PM +0100, Russell King (Oracle) wrote: > > > > In the first RFC series I sent on the 24 June, I explicitly asked the > > > > following questions: > > > (...) > > > > I even stated: "Please look at the patches and make suggestions on how > > > > we can proceed to clean up this quirk of DSA." and made no mention of > > > > wanting something explicitly from Andrew. > > > > > > > > Yet, none of those questions were answered. > > > > > > > > So no, Jakub's comments are *not* misdirected at all. Go back and read > > > > my June 24th RFC series yourself: > > > > > > > > https://lore.kernel.org/all/YrWi5oBFn7vR15BH@shell.armlinux.org.uk/ > > > > > > I don't believe I need to justify myself any further for why I didn't > > > leave a comment on any certain day. I left my comments when I believed > > > it was most appropriate for me to intervene (as someone who isn't really > > > affected in any way by the changes, except for generally maintaining > > > what's in net/dsa/, and wanting to keep a clean framework structure). > > > Also, to repeat myself, blaming me for leaving comments, but doing so > > > late, is not really fair. I could have not responded at all, and I > > > wouldn't be having this unpleasant discussion. It begs the question > > > whether you're willing to be held accountable in the same way for the > > > dates on which you respond on RFC patches. > > > > > > > I've *tried* my best to be kind and collaborative, but I've been > > > > ignored. Now I'm hacked off. This could have been avoided by responding > > > > to my explicit questions sooner, rather than at the -rc6/-rc7 stage of > > > > the show. > > > > > > I think you should continue to try your best to be kind and collaborative, > > > you weren't provoked or intentionally ignored in any way, and it isn't > > > doing these patches any good. > > > > And yet again, I don't have answers to many of those questions... which > > just shows how broken this process is, and how utterly pointless it is > > 0to ask any questions in this area. > > > > My conclusion: you don't care one bit to even answer questions until > > there's a chance that patches that you disagree with might be merged, > > and oh my god, you've got to respond to stop that happening because you > > might disagree with something. You can't do the collaborative thing and > > respond when someone asks explicit questions about how things should be > > done. > > > > I'm not going to let this go. I'm really pissed off by this and you > > are the focus of my frustration. > > The hypothesis that you put forward is that I'm sabotaging you by not > responding to RFCs, then leaving comments when you submit the patches > proper, just so that they're delayed because I don't agree with them; > and that the process is broken because it allows me to do just that and > get away with it (for fun, I assume?). > > So first off, you sent the first RFC towards 2 people in To:, and 19 > people in Cc:. I was one of the people in Cc. You didn't ask *me* any > explicit question. In fact, when you did, I responded within 5 hours: > https://lore.kernel.org/linux-arm-kernel/20220707154303.236xaeape7isracw@skbuf/ > > Then, why did I not respond earlier to questions I had an opinion on? In the second RFC, I stated: "Some of the questions from the original RFC remain though, so I've included that text below. I'm guessing as they remain unanswered that no one has any opinions on them?" Clearly, I was soliciting answers from _everyone_ who received this, not just the two people in the To: header. > Based on prior experience, anything I reply to you has a chance of > inflaming you for reasons that are outside of my control, and the > discussion derails and eventually ends with you saying that I'm being > difficult and you're quitting for the day, week, month, kernel release > cycle or what not. I'm not saying that's my fault or your fault in > general, it's just a statistical observation based on past interactions, > and it looks like this one is no different. > > With regard to this topic, there was ample opportunity for the patch set > to come to a resolve without my intervention, and I decided that the > best way to maximize the chances of this discussion not going sideways > is to not say anything at all, especially when I don't need to. > Gradually, the opportunity for the patch set to resolve itself without > my intervention diminished, and I started offering my feedback to the code. > > It's perhaps necessary of me to not let this phrase of yours unaddressed, > because it is subtly part of your argument that I'm just trying to delay > your patches as part of a sabotage plot: > > | The only thing that delayed them was your eventual comments about > | re-working how it was being done. > > Let's not forget that I did *not* request you to rework the implementation > to use software nodes. I simply went with the code you originally proposed, > explained why it is unnaturally structured in my view, asked you why you > did not consider an alternative structure if you're not willing to make > phylink absorb the logic, then you said you'd be happy to rework using > software nodes. > https://lore.kernel.org/netdev/20220707193753.2j67ni3or3bfkt6k@skbuf/ This is _not_ the issue I'm raising. I am complaining about the "default_interface" issue that you've only piped up about, despite (a) an explicit question having been asked about that approach, (b) it appearing in not just one, not two, not three but four RFC series sent, and only finally being raised when a non-RFC series was sent. This whole debarcle could have been avoided with providing feedback at an earlier stage, when I explicitly requested it _several_ times. I will not be doing any further work on this - this can wait a few kernel cycles, because quite honestly, I'm not going to try to submit this for next cycle. And I quite expect a repeat of this shit, with me struggling to get comments on patches, being mostly ignored and then for comments to come at the last minute when there's no reasonable time left in the cycle to action them.
On Mon, Jul 18, 2022 at 02:02:33PM +0100, Russell King (Oracle) wrote: > In the second RFC, I stated: > > "Some of the questions from the original RFC remain though, so I've > included that text below. I'm guessing as they remain unanswered that > no one has any opinions on them?" > > Clearly, I was soliciting answers from _everyone_ who received this, > not just the two people in the To: header. (...) > This is _not_ the issue I'm raising. I am complaining about the > "default_interface" issue that you've only piped up about, despite > (a) an explicit question having been asked about that approach, (b) it > appearing in not just one, not two, not three but four RFC series sent, > and only finally being raised when a non-RFC series was sent. > > This whole debarcle could have been avoided with providing feedback at > an earlier stage, when I explicitly requested it _several_ times. Please stop shoving quotes of your questions in my face, I'm still glad I deleted my draft responses to them when they were originally asked, because *when* (not *if*) things will have went sideways, I would have blamed myself for people wanting to test/respond but not having whom to talk to, because you rage quit. You need to understand that a voluntary reviewer doesn't have a duty to respond to you on any certain date, and that I'm not obliged to shut up about where to place "default_interface" because I haven't said anything about it in the first N series. I was on the fence whether it was even worth saying anything about it at all, and the only reason I decided to do it was because the patch to change every DSA driver's phylink_get_caps() prototype now conflicts with concurrent changes done to drivers, and doesn't apply to net-next anyway: https://patchwork.kernel.org/project/netdevbpf/patch/E1oCNl3-006e3n-PT@rmk-PC.armlinux.org.uk/ So I really can't be reasonably accused of wanting to stall this series. You have no reason whatsoever to pick a fight with me, so please stop it.
Dear Vladimir, am I understanding correctly that your main objection to this series is that it may break other drivers? Do you think it would be okay if I changed it so that only mv88e6xxx driver would ask for phylink for CPU/DSA ports? I would really like to have phylink's PCS code taking care of mv88e6xxx CPU and DSA ports. Marek
Hello Marek, On Wed, Jul 27, 2022 at 11:00:51AM +0200, Marek Behún wrote: > Dear Vladimir, > > am I understanding correctly that your main objection to this series is > that it may break other drivers? Yes, but I'm not saying this in a way that tries to make it impossible to make progress. But rather, I've identified 8 drivers which may lack complete device tree descriptions: https://patchwork.kernel.org/project/netdevbpf/patch/20220723164635.1621911-1-vladimir.oltean@nxp.com/ Simply put, I have no indication that the changes presented here are a step in the right direction for the remaining 7 drivers. Each and every single one of them needs to be studied and discussed separately; the discussion has already started for some. > Do you think it would be okay if I changed it so that only mv88e6xxx > driver would ask for phylink for CPU/DSA ports? It would be a good start, yes. What I could do is I could move my validation logic from the patch linked above into dsa_port_link_register_of(). Running that logic would let DSA know which properties are missing. Then, for drivers that don't enforce validation, we could add new dsa_switch_ops that separately ask the driver what phy-mode to use (if missing) and what speed/duplex to use (if missing). Drivers can use whatever heuristic is appropriate for their deployments to respond to this. If the phy-mode and speed/duplex are finally resolved, DSA can create a software_node and register with phylink that way. Otherwise, DSA will continue to do what it does today, i.e. skip phylink registration. How does that sound?