Messages in this thread | | | Date | Wed, 13 Mar 2024 18:04:43 +0300 | Subject | Re: [PATCH] net: dsa: mt7530: increase reset hold time | From | Arınç ÜNAL <> |
| |
On 13.03.2024 16:13, Justin Swartz wrote: > On 2024-03-13 14:06, Arınç ÜNAL wrote: >> On 13.03.2024 14:52, Justin Swartz wrote: >>> >>> On 2024-03-13 10:59, Arınç ÜNAL wrote: >>>> This ship has sailed anyway. Now the changes the first patch did must be >>>> reverted too. I will deal with this from now on, you can stop sending >>>> patches regarding this. >>> >>> At least if the first patch isn't reverted, the approach used is >>> less likely to result in the problem occuring, IMHO. >> >> I disagree that the previous approach is less likely to result in the >> problem occurring. If you don't like the delay amount we agreed on, feel >> free to express a higher amount. > > I created and tested a patch to entertain your input about what you > thought could be a suitable hold period to address the problem, and it > appeared to work. The criteria being that the crystal frequency selection > was correct over 20 tests. > > So if only the reset hold period is going to change, I'm good with what > you had suggested: 5000 - 5100 usec. > > Ultimately the selection of this period should be guided by the timing > information provided in a datasheet or design guide from the manufacturer.
That's a good point, I agree.
> > If you, or anyone else, has such a document that provides this information > and is able to confirm or deny speculation about any/all timing periods > related to reset, please do so.
These are the documents I use to program this switch family. I did not stumble upon a page going over this.
MT7621 Giga Switch Programming Guide v0.3:
https://github.com/vschagen/documents/blob/main/MT7621_ProgrammingGuide_GSW_v0_3.pdf
MT7531 switch chip datasheet:
https://wiki.banana-pi.org/Banana_Pi_BPI-R64#Documents
> > >> I also disagree on introducing a solution that is in addition to another >> solution, both of which fix the same problem. > > I'm not sure I understand why you say that. These patches were intended > to be applied exclusively, or in other words: in isolation - not together. > > Although if they were applied together, it wouldn't really matter. > > For the record, I've only continued to keep this thread alive in the > hope that some solution to this problem will make it into mainline > eventually. > > I don't care if it was my original patch, the subsequent patch, or a > later patch provided by you or someone else. :)
I think you've missed that your patch is already applied. And it won't be reverted for reasons explained by Paolo in this mail thread.
https://git.kernel.org/netdev/net-next/c/2920dd92b980
So if your patch here were to be applied too, the final mt7530.c would have the LEDs disabled AND before reset deassertion delay increased.
Arınç
| |