drivers/reset/Kconfig | 1 + drivers/reset/core.c | 8 +++++--- 2 files changed, 6 insertions(+), 3 deletions(-)
After the discussion[1] (Thanks, Philipp!), here is the updated series. Details are in the commit messages. Please let me know what you think. [1] https://lore.kernel.org/r/20251015112921.19535-2-wsa+renesas@sang-engineering.com Wolfram Sang (2): reset: always bail out on missing RESET_GPIO driver reset: always include RESET_GPIO driver if possible drivers/reset/Kconfig | 1 + drivers/reset/core.c | 8 +++++--- 2 files changed, 6 insertions(+), 3 deletions(-) -- 2.47.2
On 15/10/2025 22:59, Wolfram Sang wrote: > After the discussion[1] (Thanks, Philipp!), here is the updated series. > Details are in the commit messages. Please let me know what you think. > > [1] https://lore.kernel.org/r/20251015112921.19535-2-wsa+renesas@sang-engineering.com > You removed RFC and entire rationale. Your earlier commit - 690de2902dca - is broken. You must not do that. Broken 690de2902dca leads to this broken patchset, but that is not a correct fix. You need to fix the source - revert 690de2902dca, because it is obviously wrong. You MUST ave fallback to reset-gpios, that was the entire concept how this driver was written. Best regards, Krzysztof
> You removed RFC and entire rationale. Your earlier commit - 690de2902dca > - is broken. You must not do that. Wojciech was told to do exactly what he did. Dunno by whom, I trusted that after seeing the handling code in reset core. Is the required fallback documented somewhere? > Broken 690de2902dca leads to this broken patchset, but that is not a > correct fix. You need to fix the source - revert 690de2902dca, because > it is obviously wrong. You MUST ave fallback to reset-gpios, that was > the entire concept how this driver was written. What is the benefit of having reset-gpios handling in the reset core optionally and required as a fallback? What is the drawback of having this tiny driver in the core and provide the core-based reset-gpios handling as a way to prevent open coded solutions? Sure, I can revert the changes to avoid problems for users, and will probably do so, but it still feels all very strange to me.
On 03/11/2025 16:23, Wolfram Sang wrote: > >> You removed RFC and entire rationale. Your earlier commit - 690de2902dca >> - is broken. You must not do that. > > Wojciech was told to do exactly what he did. Dunno by whom, I trusted > that after seeing the handling code in reset core. Is the required > fallback documented somewhere? Yes, by stable ABI document and by standard rule - we never break the users. That commit for which I sent revert effectively breaks that rule - affects the users. > >> Broken 690de2902dca leads to this broken patchset, but that is not a >> correct fix. You need to fix the source - revert 690de2902dca, because >> it is obviously wrong. You MUST ave fallback to reset-gpios, that was >> the entire concept how this driver was written. > > What is the benefit of having reset-gpios handling in the reset core > optionally and required as a fallback? Stable ABI rules require that, it is not about "benefits". Please send email to Linus and ask him: "can I make a change which breaks users of ABI". > > What is the drawback of having this tiny driver in the core and provide If you have squashed the patchset, instead of making this non-bisectable mess, it would be fine. But because you made it non-bisectable and only one part got to the kernel - ALL USERS are affected and their boards broken. See four reports from Marek Szyprowski. Best regards, Krzysztof
> > What is the benefit of having reset-gpios handling in the reset core > > optionally and required as a fallback? > > Stable ABI rules require that, it is not about "benefits". Please send > email to Linus and ask him: "can I make a change which breaks users of ABI". I don't get it. If a driver already depends on RESET, then only the handling code is moved from the driver to the reset core. Where is an ABI breakage there? > See four reports from Marek Szyprowski. I am talking about the original i2c-mux patch here. Not the failed attempt to get it working.
Hi Wolfram > After the discussion[1] (Thanks, Philipp!), here is the updated series. > Details are in the commit messages. Please let me know what you think. Thank you for your help !! My board started works again (without .config manual update !) Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Best regards --- Kuninori Morimoto
On 16/10/2025 02:02, Kuninori Morimoto wrote: > > Hi Wolfram > >> After the discussion[1] (Thanks, Philipp!), here is the updated series. >> Details are in the commit messages. Please let me know what you think. > > Thank you for your help !! > My board started works again (without .config manual update !) > > Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Started to work? So was it broken? By what? This driver was always OPTIONAL, was never meant to be required and there was no code which was converted to usage of this driver. I have doubts how this was tested - what exactly problem is being here solved (except breaking all possible platforms by making this non-bisectable...). Best regards, Krzysztof
> Started to work? So was it broken? By what? I explained all this in the RFC version of the patch which was linked in the cover letter of this series.
On 03/11/2025 16:25, Wolfram Sang wrote: > >> Started to work? So was it broken? By what? > > I explained all this in the RFC version of the patch which was linked in > the cover letter of this series. > Should be explained here. That's the reason why you are doing change. The most important information. Best regards, Krzysztof
© 2016 - 2025 Red Hat, Inc.