On Mon, Jan 10, 2022 at 11:23 AM Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote: > > On Mon, 2022-01-10 at 10:39 +0100, Sergio Paracuellos wrote: > [...] > > > Is this known to work for all possible users, without delay between > > > assert and deassert? > > > > It seems it is. This is based on the original reset implementation for > > ralink. See: > > > > https://elixir.bootlin.com/linux/v5.16/source/arch/mips/ralink/reset.c#L55 > > > > > Are there any users of the reset_control_reset() API at all? This API > > > was added for self-clearing reset bits, so if there are no users that > > > need to pretend this is a reset pulse at the hardware level (there may > > > be), I'd prefer if this was just left out. > > > > I am not following you here. What do you mean? > > Looking at drivers/staging/mt7621-dts/mt7621.dtsi, it appears the > current reset users are: > mediatek,mt7621-i2c > ralink,mt7621-spi > ralink,rt3883-gdma > mediatek,mt7621-hsdma > mediatek,mt7621-eth > mediatek,mt7621 > mediatek,mt7621-pci > > Many of the corresponding drivers use device_reset(), which is a > shorthand for requesting a reset control and calling > reset_control_reset() on it. That will call mt7621_reset_device, so it > is indeed used. > Ok, pretty clear now, thanks for clarification :). > regards > Philipp Best regards, Sergio Paracuellos