lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 4 Dec 2020 16:41:01 -0800 From: Jakub Kicinski <kuba@...nel.org> To: Vladimir Oltean <vladimir.oltean@....com> Cc: "David S . Miller" <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>, Alexandre Belloni <alexandre.belloni@...tlin.com>, Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, Vivien Didelot <vivien.didelot@...il.com>, Horatiu Vultur <horatiu.vultur@...rochip.com>, "Allan W . Nielsen" <allan.nielsen@...rochip.com>, Claudiu Manoil <claudiu.manoil@....com>, Steen Hegelund <steen.hegelund@...rochip.com> Subject: Re: [PATCH v2 net] net: mscc: ocelot: install MAC addresses in .ndo_set_rx_mode from process context On Fri, 4 Dec 2020 19:23:11 +0000 Vladimir Oltean wrote: > > > > What's the expected poll time? maybe it's not that bad to busy wait? > > > > Clearly nobody noticed the issue in 2 years (you mention lockdep so > > > > not a "real" deadlock) which makes me think the wait can't be that long? > > > > > > Not too much, but the sleep is there. > > > Also, all 3 of ocelot/felix/seville are memory-mapped devices. But I > > > heard from Alex a while ago that he intends to add support for a switch > > > managed over a slow bus like SPI, and to use the same regmap infrastructure. > > > That would mean that this problem would need to be resolved anyway. > > > > So it's MMIO but the other end is some firmware running on the device? > > No. It's always register-based access, just that in some cases the > registers are directly memory-mapped for Linux, while in other cases > they are beyond an SPI bus. But there isn't any firmware in any case. I see, so ocelot_mact_wait_for_completion() waits for some hardware engine to process the command? It looked like FW is hiding behind that register at a glance. 100ms sounds very high for hardware processing.
Powered by blists - more mailing lists