From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Walle Date: Wed, 24 Feb 2021 18:29:39 +0100 Subject: [PATCH 4/4] net: dsa: remove master santiy check In-Reply-To: <20210224171111.lqzq3gpiqf4fkm4e@skbuf> References: <20210224164042.21747-1-michael@walle.cc> <20210224164042.21747-5-michael@walle.cc> <20210224171111.lqzq3gpiqf4fkm4e@skbuf> Message-ID: <46b918d16c0e79f1b0bff538c9b28f69@walle.cc> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Am 2021-02-24 18:11, schrieb Vladimir Oltean: > On Wed, Feb 24, 2021 at 05:40:42PM +0100, Michael Walle wrote: >> Because we probe the master ourselves (and fail if there is no >> master), >> it is not possible that we don't have a master device. >> >> There is one catch though: device removal. We don't support that. It >> wasn't supported neither before this patch. Because the master device >> was only set in .pre_probe(), if a device was removed master_dev was a >> dangling pointer and transmitting a frame cause a panic. I don't see a >> good solution without having some sort of notify machanism when a >> udevice is removed. >> >> Signed-off-by: Michael Walle >> --- > > Ha, this is a tough one. > So the DSA master is not a parent of the DSA switch, instead the SPI > bus/whatever is. Additionally, the checks for NULL are pointless, > because the master is not NULL, just deallocated. > > In Linux we solved this by using device links: > https://github.com/torvalds/linux/commit/07b90056cb15ff9877dca0d8f1b6583d1051f724 > > However it doesn't seem like we have such a generic dependency graph > between udevices in U-Boot, do we? I could just find device_reparent, > which is definitely not what we want. I didn't find anything else either. Thus I just ignored it for the moment. > My best guess as to how to solve the DSA master removal scenario would > be to: > (a) scatter all DSA callbacks with device_probe(master), so even if it > was unbound, it will be rebound. > (b) introduce DSA specific code in eth_pre_remove and a DSA-specific > pointer in eth_pdata to manually call device_remove for an attached > DSA switch, if that exists. > > Other ideas are welcome, of course. What is the reason to remove that device in the first place? Like is this really a valid scenario? I really don't know when a device is removed and if its remove, will it still be there or is it rather a hot-plug type and rebinding it won't work anyways. I also had (b) in mind, but again. Does it really apply? After all, this is a bootloader ;) -- -michael