ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
LainExperiments has joined #armlinux
pikapika_lunar has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
pikapika_lunar has joined #armlinux
apritzel has quit [Ping timeout: 260 seconds]
nsaenz has joined #armlinux
nsaenz has quit [Ping timeout: 260 seconds]
jclsn has quit [Ping timeout: 252 seconds]
jclsn has joined #armlinux
ellyq has quit [Ping timeout: 245 seconds]
ellyq has joined #armlinux
pikapika_lunar has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
pikapika_lunar has joined #armlinux
LainExperiments has quit [Ping timeout: 256 seconds]
heat has quit [Ping timeout: 248 seconds]
siak has joined #armlinux
lain6141 has quit [Remote host closed the connection]
lain6141 has joined #armlinux
cbeznea has joined #armlinux
monstr has joined #armlinux
gclement has joined #armlinux
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 252 seconds]
iivanov has joined #armlinux
luispm has joined #armlinux
clegoffic_ has quit [Read error: Connection reset by peer]
siak has quit [Remote host closed the connection]
headless has joined #armlinux
pikapika_lunar is now known as militantorc
frieder has joined #armlinux
militantorc has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
pikapika_lunar has joined #armlinux
pikapika_lunar is now known as militantorc
nsaenz has joined #armlinux
heat has joined #armlinux
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #armlinux
sszy has joined #armlinux
headless has quit [Quit: Konversation terminated!]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
biju has joined #armlinux
apritzel has joined #armlinux
System_Error has quit [*.net *.split]
rvalue has quit [Ping timeout: 276 seconds]
rvalue has joined #armlinux
System_Error has joined #armlinux
<ardb>
linusw__: is the 3-4% perf impact of generic entry due to the removal of the fast syscall restart?
<ardb>
could you benchmark just the removal of that part?
heat has quit [Read error: Connection reset by peer]
heat has joined #armlinux
siak has joined #armlinux
bjoto has joined #armlinux
luispm has quit [Ping timeout: 276 seconds]
morpheus has joined #armlinux
frieder has quit [Ping timeout: 265 seconds]
mripard has joined #armlinux
morpheus has quit [Quit: morpheus]
frieder has joined #armlinux
morpheus has joined #armlinux
<milkylainen>
hmm. Every ethernet driver has to explicitly select MII to get it? Ugh. Can't it just be under ethernet and be done with it? Like how many configred kernels make do without MII?
<linusw__>
ardb: hm good point! I'll make a quick test.
<geertu>
milkylainen: Most m68k Ethernet drivers don't?
<geertu>
In fact I'm surprised by how few drivers do select MII
<milkylainen>
geertu: don't as in they don't have it or they haven't explicitly selected it because they couldn't care about the existing interface?
<geertu>
milkylainen: Dunno. But E100 is the only one from the Intel ones that does.
<milkylainen>
geertu: I was surprised by the same, but I came to the conclusion that if you're using ethernet on this side of anything usable on this side of 1995 you probably should have MII built in to the kernel.
<milkylainen>
Actively selecting MII everywhere seems a bit overkill.
<milkylainen>
Sorry for that confusing scentence.
<biju>
milkylainen: I know some Renesas customers are still using MII. But on Renesas it is is just a register option to select MII/RGMII and then rest are wiring on the specific platform to support MII.
<milkylainen>
biju: I wasn't meaning it is deprecated. On the opposite. I mean, "In what normal kernel with ethernet support don't you want MII built in?"
<milkylainen>
imo, CONFIG_ETHERNET should just select MII and then clear out the bunch of select MII spread on various places.
<biju>
Some vendors just support RGMII
<milkylainen>
register access etc should be the same?
morpheus has quit [Quit: morpheus]
<milkylainen>
Maybe this is better called as "Legacy MII access" or something?
<milkylainen>
maybe a lot of drivers prefer using some other interface externally these days.
frieder has quit [Remote host closed the connection]
<linusw__>
ardb: the fast syscall restart does not seem to affect performance at all.
<ardb>
interesting
<ardb>
perhaps the ppid syscall doesn't trigger it?
<linusw__>
Yeah that's what I thought, it probably only improves complex syscalls.
<linusw__>
Not that I have any intuitive feeling to what syscalls usually return -EAGAIN...
<linusw__>
I'm testing after the ret_fast_syscall removal to see if that is significant
<linusw__>
It's one of those things I know rmk worked hard to optimize
LainExperiments has joined #armlinux
<linusw__>
This one definitely gives the performance cut ... also the one that is just impossible to combine with generic entry.
<linusw__>
Hm it actually seems to be something before that patch :/
<linusw__>
I will take one patch at the time and see where the performance cut somes
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
luispm has joined #armlinux
<cambrian_invader>
biju: MII actually means MDIO
<cambrian_invader>
milkylainen: actually, most modern drivers use phylib (or phylink, which uses phylib)
<cambrian_invader>
CONFIG_MII is sort of from a transitional period where it was recognized that NICs with MDIO busses have a lot of code to reuse, but phys were not yet modeled as separate devices
<geertu>
biju: Do the Renesas Ethernet driver actually need MII? I dropped "select MII", and nfsroot booted fine on Gray Hawk Single
<geertu>
paulbarker: ^
<arnd>
geertu: CONFIG_MII only controls a couple of helper functions, I think CONFIG_MDIO controls a few others, but CONFIG_PHYLIB is the big one
<paulbarker>
geertu: I don't think we need CONFIG_MII. We don't call any of the functions in drivers/net/mii.c.
<paulbarker>
The config symbol naming is very confusing!
<arnd>
As an experiment, I turned off MII, MDIO, PHYLIB, MDIO_BUS and MDIO_DEVICE. These are the drivers that still build without those: https://www.irccloud.com/pastebin/orSFuprh/
<arnd>
A number of them have their own implementation of the mii code, others are just stub drivers for hardware that is shared by a scsi or rdma driver, so the module doesn't actually provide ethernet
<paulbarker>
geertu: I suspect for ravb the config should be depending on MDIO_BUS not MII, I haven't tested though
System_Error has quit [Remote host closed the connection]
mripard has quit [Quit: WeeChat 4.4.2]
<geertu>
arnd: shmobile_defconfig still builds fine after removing "select MII" from drivers/net/ethernet/renesas/Kconfig, SMSC911X, and STMMAC_ETH
<geertu>
There don
<geertu>
There don't seem to be any dummies for the !CONFIG_MII case, so I guess none of these drivers need it at all?
<arnd>
geertu: agreed, it looks like there are a few more, and none that are missing a 'select MII'
<cambrian_invader>
again, MII actually means something like "mdio library"
<cambrian_invader>
and all the drivers using this are from before phylib was a thing
<cambrian_invader>
(of course MDIO is not really the best name either, but it avoids confusion regarding RMII etc.)
LainExperiments has quit [Quit: Client closed]
<milkylainen>
arnd: I'm for the removal. But I think the ioctl might still be a legacy thing for a bunch of userspace, not the kernel internally.
<milkylainen>
Maybe remove it and hang it on a legacy knob?
<cambrian_invader>
the ioctl is used by userspace since forever
<cambrian_invader>
so it can't be removed
<arnd>
milkylainen: removing CONFIG_MII is not an option as long as there are drivers that use it, my patch only changes the references from the drivers that don't
<milkylainen>
arnd: ah. my bad.
balrog has quit [Quit: Bye]
<arnd>
cambrian_invader: I'm still struggling to understand where CONFIG_MDIO came from. This looks slightly more modern than CONFIG_MII is bus is even less common and still incompatible with PHYLIB, right?
<cambrian_invader>
so the original way to write ethernet drivers was to just do everything in the NIC driver
<cambrian_invader>
then someone said, "well, the MII management interface is standard, so lets make a library so we can reuse all the phy configuration stuff"
<cambrian_invader>
and this was CONFIG_MII
<cambrian_invader>
CONFIG_MII is basically just a set of library routines, and you have to provide some callbacks to access the MII management interfaces (AKA the MDIO bus)
<cambrian_invader>
but not all phys are standard, so eventually someone came up with CONFIG_PHYLIB, which models PHYs as real `struct device`s
<cambrian_invader>
and devices have to live on a bus, so that's what CONFIG_MDIO is for
<arnd>
yes, I get the parts about MII, PHYLIB, MDIO_BUS and MDIO_DEVICE
<cambrian_invader>
err
<cambrian_invader>
I forgot that MDIO is *also* different
<cambrian_invader>
ugh
<cambrian_invader>
I think CONFIG_MDIO is like CONFIG_MII but for c45 busses instead of c22
<arnd>
There is also SUNGEM_PHY, which was a step between mii and phylib, but only used by two remaining drivers it seems
<cambrian_invader>
so also legacy stuff
<arnd>
ah, I see
<cambrian_invader>
just a very long tail of drivers for obselete hardware that no one has bothered to convert
headless has joined #armlinux
balrog has joined #armlinux
<milkylainen>
I think I'm confused by what I actually think it is and what you say the kernel calls it. To me the MDIO has always been the classical c22 bus transfer and MII is the standard register definition, before even extensions became popular. MDIO can be used for other things as well afaiu.
<milkylainen>
Sure. MDIO now has a c45 transfer protocol too.
<arnd>
milkylainen: for the purpose of the last page of discussions above, MII refers to the implementation in drivers/net/mii.c, while MDIO refers to drviers/net/mdio.c, both of which are just a bunch of helper functions that can be called by ethernet drivers
<cambrian_invader>
MII is the medium independent interface in c22, which includes PHY_INTERFACE_MODE_MII, the "MDIO" management interface, and the MII_XXX register set
<milkylainen>
cambrian_invader: Yes. It doesn't matter much. I get it. I was confused by the "MII actually means MDIO".
<cambrian_invader>
CONFIG_MII is all about "mdio"
<cambrian_invader>
but it's not about PHY_INTERFACE_MODE_MII
<cambrian_invader>
but biju had mentioned RMII in the context of renesas drivers, which is why I was trying to clear that up
LainExperiments has joined #armlinux
<milkylainen>
ah. ok.
psydroid has quit [Read error: Connection reset by peer]
<maz>
robmur01: is there a way for SW to discover the DeviceID used by an MMU-700? I can't seem to find anything of the sort in the TRM...