On Thu, Mar 28, 2024 at 06:00:03PM +0100, Alban Browaeys wrote: > Le mardi 26 mars 2024 à 19:46 +0000, Conor Dooley a écrit : > > On Tue, Mar 26, 2024 at 07:54:35PM +0100, Folker Schwesinger via B4 > > Relay wrote: > > > From: Folker Schwesinger <dev@xxxxxxxxxxxxxxxxxxxxx> > > > - if (of_property_read_bool(dev->of_node, "rockchip,enable- > > > strobe-pulldown")) > > > - rk_phy->enable_strobe_pulldown = > > > PHYCTRL_REN_STRB_ENABLE; > > > + if (of_property_read_bool(dev->of_node, "rockchip,disable- > > > strobe-pulldown")) > > > + rk_phy->enable_strobe_pulldown = > > > PHYCTRL_REN_STRB_DISABLE; > > > > Unfortunately you cannot do this. > > Previously no property at all meant disabled and a property was > > required > > to enable it. With this change the absence of a property means that > > it > > will be enabled. > > An old devicetree is that wanted this to be disabled would have no > > property and will now end up with it enabled. This is an ABI break > > and is > > clearly not backwards compatible, that's a NAK unless it is > > demonstrable > > that noone actually wants to disable it at all. > > > But the patch that introduced the new default to disable the pulldown > explicitely introduced a regression for at least 4 boards. > It took time to sort out that the default to disable pulldown was the > culprit but still. > Will we carry this new behavor that breaks the default design for > rk3399 because since the regression was introduced new board definition > might have expceted this new behavior. > > Could the best option be to revert to énot set a default enable/disable > pulldown" (as before the commit that introduced the regression) and > allow one to force the pulldown via the enable/disable pulldown > property? > I mean the commit that introduced a default value for the pulldown did > not seem to be about fixing anything. But it broke a lot. ANd it was > really really hard to find the description of this commit to understand > that one had to enable pulldown to restore hs400. > > In more than 3 years, only one board maintainer noticed that this > property was required to get back HS400 and thanks to a user telling > me that this board was working I found from this board that this > property was "missing" from most board definitions (while it was not > required before). > > > I am all for not breaking ABI. But what about not reverting a patch > that already broke ABI because this patch introduced a new ABI that we > don't want to break? > I mean shouldn't a new commit with a new ABI that regressed the kernel > be reverted? I think I said it after OP replied to me yesterday, but this is a pretty shitty situation in that the original default picked for the property was actually incorrect. Given it's been like this for four years before anyone noticed, and others probably depend on the current behaviour, that's hard to justify. > Mind fixing the initial regression 8b5c2b45b8f0 "phy: rockchip: set > pulldown for strobe line in dts" does not necessarily mean changing the > default to the opposite value but could also be reverting to not > setting a default. That's also problematic, as the only way to do this is make setting one of the enabled or disabled properties required, which is also an ABI break, since you'd then be rejecting probe if one is not present. > Though I don't know if there are pros to setting a default. What you probably have to weigh up is the cons of each side. If what you lose is HS400 mode with what's in the kernel right now but switching to what's been proposed would entirely break some boards, I know which I think the lesser of two evils is. It's probably up to the platform maintainer to weigh in at this point. Hope that helps? Conor.
Attachment:
signature.asc
Description: PGP signature
