[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2025112725-enviably-ground-9342@gregkh>
Date: Thu, 27 Nov 2025 13:20:02 +0100
From: Greg KH <greg@...ah.com>
To: Luca Ceresoli <luca.ceresoli@...tlin.com>
Cc: Théo Lebrun <theo.lebrun@...tlin.com>,
Vinod Koul <vkoul@...nel.org>,
Kishon Vijay Abraham I <kishon@...nel.org>,
Heiko Stuebner <heiko@...ech.de>, William Wu <wulf@...k-chips.com>,
Kever Yang <kever.yang@...k-chips.com>,
Minas Harutyunyan <Minas.Harutyunyan@...opsys.com>,
Alan Stern <stern@...land.harvard.edu>,
Louis Chauvet <louis.chauvet@...tlin.com>,
Hervé Codina <herve.codina@...tlin.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
linux-phy@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
linux-usb@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] phy: rockchip: inno-usb2: fix disconnection in
gadget mode
On Thu, Nov 27, 2025 at 11:18:45AM +0100, Luca Ceresoli wrote:
> Hi Théo,
>
> On Thu Nov 27, 2025 at 10:48 AM CET, Théo Lebrun wrote:
> > On Thu Nov 27, 2025 at 10:22 AM CET, Luca Ceresoli wrote:
> >> On Tue Nov 25, 2025 at 4:28 PM CET, Théo Lebrun wrote:
> >>>> The code already checks for !rport->suspended, so add a guard for VBUS as
> >>>> well to avoid a disconnection when a cable is connected.
> >>>
> >>> Your commit message was clear but I was missing one key point: what
> >>> rport->suspended means. It isn't what I first thought. Instead it means
> >>> phy is powered off. Naming is bad but unrelated to your series. Maybe
> >>> add a comment to your commit message like the following?
> >>>
> >>> The code already checks for !rport->suspended (PHY is powered on), ...
> >>
> >> You are right. I have added a slightly longer text:
> >>
> >> The code already checks for !rport->suspended (which, somewhat
> >> counter-intuitively, means the PHY is powered on), ...
> >>
> >> Still worth your Reviewed-by?
> >
> > Even more so.
>
> Thanks, v2 on its way.
>
> >> I also added the Cc: stable@...r.kernel.org line, which I noticed being
> >> missing.
> >
> > I never add that Cc trailer and only rely on `Fixes:`. I thought it
> > used to be documented as an alternative to that Cc trailer but it does
> > not show up in `git log -p Documentation/process/stable-kernel-rules.rst`
> >
> > There is one indirect mention of "scripts that look for commits
> > containing a 'Fixes:' tag":
> > https://elixir.bootlin.com/linux/v6.17.9/source/Documentation/process/stable-kernel-rules.rst#L132-L134
> >
> > Anyway, you do right by explicitly tagging `Cc: stable@...`.
>
> Theory says Cc: is needed:
>
> > Note: Attaching a Fixes: tag does not subvert the stable kernel rules
> > process nor the requirement to Cc: stable@...r.kernel.org on all stable
> > patch candidates.
> (https://docs.kernel.org/process/submitting-patches.html#reviewer-s-statement-of-oversight)
>
> But in the practice I happened to forget Cc: stable in the past, the patch
> got applied and the Fixes: tag was enough for correct cherry-pick in stable
> branches.
That is never guaranteed, it is a "best effort only when the stable
maintainers are bored" type of thing. Always be explicit, and use cc:
stable, as the documentation has stated for the last 17+ years :)
thanks,
greg k-h
Powered by blists - more mailing lists