The highest level (and maybe the only available), is the application itself.
This is what I want to avoid. I don't want the application to mess with the specific peculiarities of this hardware. It harms the overall architecture I think, makes porting more difficult. Following this procedure, I would end up with a mess of a code, with lots of conditionals to adapt the logic to every used target board. Of course, I will also not be able upstream this in any way, if it is application logic. This is why I am looking for something at a lower-level. To keep hardware peculiarities transparent to the end application, and to enhance reusability of this logic. In any case, the board level may be the most appropriate generally. Only the board knows how this specific hardware works, for example if there is a hardware reset line, if there are any interrupt lines, if any other hardware initialization is needed after reset etc etc. Στις Σάβ, 20 Φεβ 2021 στις 3:35 μ.μ., ο/η Grr <gebbe...@gmail.com> έγραψε: > I cannot offer you help on the main topic but I'd like to offer an opinion > on the level thing: > > The higher the level, the better. If possible, do it at the general level > > Why? Because that way, your work is useful to most people and you avoid > increasing NuttX fragmentation. Many drivers are created or configured at > board level and that work must be duplicated even when peripherals are > using standard interfaces like SPI or I2C > > I have some old LAN8187 (hopefully I could manage to solder them to an > adapter) and I could do some testing of your work if that helps you > > El sáb, 20 feb 2021 a las 6:45, Fotis Panagiotopoulos (< > f.j.pa...@gmail.com>) > escribió: > > > Anyone on this? > > > > I am using the LAN8720A Ethernet PHY. > > I realized that this IC in some rare cases may get stuck. The Ethernet > LEDs > > blink erratically, and no Ethernet communication is possible. > > The only way to recover from this state is to reset the PHY. (MIIM works > in > > this case) > > > > To diagnose the issue, I monitor the MII_LAN8720_SECR register (symbol > > error count). This register typically contains a very small value. > Usually > > 0, or something close to that. > > When the problem occurs, this value increases very very rapidly > (something > > like thousands of errors per second). > > > > I need to monitor this register for excessive error count, and if the > > problem occurs to reset the PHY. > > I believe that the correct place to do so is in board logic. > > > > 1. Is there a way to do so? > > 2. Would it be more appropriate to do so in the arch low-level driver? I > > could find any function that can monitor this periodically. > > 3. Is it actually needed? Is there any error handling logic anywhere that > > will bring the interface down in case of MII-level errors? (Then I could > > just reset it during ifdown) > > > > > > > > Στις Κυρ, 14 Φεβ 2021 στις 2:36 μ.μ., ο/η Fotis Panagiotopoulos < > > f.j.pa...@gmail.com> έγραψε: > > > > > Hi everybody, > > > > > > I am trying to perform some reads/writes to my Ethernet PHY (LAN8720A) > in > > > board-level. > > > > > > I am pretty confused on what is the correct interface to use for this > > > purpose. > > > As far as I can tell, it is only possible to perform MII read/writes > > > through ioctl's in application code. > > > How can the board logic control the PHY? Is this possible? > > > > > >
