Low-level is close to the hardware. Think arch. High-level is away from the hardware. Think app. This is a standard industry convention, and it is followed in NuttX too.
> 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 The thing is that this issue is extremely difficult to reproduce in the lab. And it may be specific to the LAN8720A silicon... > If there's not a standard way in NuttX to export R/MII (I haven't looked at > it), maybe you need to create it Unfortunately, I don't have the resources available at the moment to do so. But still, I would like to have the opinion of someone more knowledgeable on this aspect of the kernel. Στις Σάβ, 20 Φεβ 2021 στις 4:04 μ.μ., ο/η Grr <gebbe...@gmail.com> έγραψε: > El sáb, 20 feb 2021 a las 7:49, Fotis Panagiotopoulos (< > f.j.pa...@gmail.com>) > escribió: > > > 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. > > > > We're thinking level in the opposite way. I said > > "The higher the level, the better. If possible, do it at the general level" > > meaning that general level (common to all archs) is the highest. > > Adopting your convention, do it at the lowest, trying to do it at the > general, "common to all archs" level > > 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. > > > > That's what I'm calling for. That's why I talked about SPI and I2C problems > > > > > 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. > > > > No. That's a contradiction of your previous idea. > > Board should export/expose resources in a general way so drivers can use > them in a common, transparent way. That's the point of a portable OS > > If there's not a standard way in NuttX to export R/MII (I haven't looked at > it), maybe you need to create it > > > > > > > > Στις Σάβ, 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? > > > > > > > > > > > > > > >
