Re: [PATCH 6.6 & 5.10] usb: typec: ucsi: validate connector number in ucsi_connector_change

[Greg KH]

On Sat, May 09, 2026 at 11:32:08AM +0800, Hongbo Li wrote:
> Hi Greg,
> 
> On 2026/5/8 21:04, Greg KH wrote:
> > On Fri, May 08, 2026 at 08:59:06PM +0800, Hongbo Li wrote:
> > > Hi Greg,
> > > 
> > > On 2026/5/8 19:03, Greg KH wrote:
> > > > On Fri, May 08, 2026 at 05:20:26PM +0800, Hongbo Li wrote:
> > > > > Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector
> > > > > number in ucsi_notify_common()") and commit 5a1140404cbf ("usb:
> > > > > typec: ucsi: skip connector validation before init") add the bounds
> > > > > check when do the connector change both in pre-init notification and
> > > > > the forward notifications. But they are difficult to backport to
> > > > > early stable branch such as LTS 6.6, LTS 5.10 due to many dependencies.
> > > > > Instead, we choose to validate connector number in ucsi_connector_change
> > > > > directly to avoid out-of-range issue.
> > > > 
> > > > Why just these 2 branches?
> > > 
> > > I only noticed these two branches, but in fact, there are more.
> > > 
> > > > 
> > > > And what specific commits are needed exactly?  Why not just backport
> > > > them all?  that will make future changes apply properly as well, making
> > > 
> > > Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector number in
> > > ucsi_notify_common()") use the ucsi_notify_common helper which is introduced
> > > in 584e8df58942 ("usb: typec: ucsi: extract common code for command
> > > handling"). This commit refactored part of the code and involves many
> > > modifications to USB ucsi controllers (such as stm32g0...), which were
> > > introduced after 6.6.
> > 
> > So just 2 commits?  that's nothing, we have taken hundreds of commits of
> 
> No. This is not an issue of the number of backport patches.
> 
> For commit 584e8df58942, it refractored the logic based on a higher version
> (higher than 6.6) which introduced new ucsi controllers (yoga_c630 for 6.6,
> yoga_c630, glink and stm32g0 for 5.10). So we should remove some extra code
> and resolve conflicts if we backport this patch to the target branch like
> the first way I mentioned.
> 
> But I looked at the modification logic of the commit d2d8c17ac01a and commit
> 5a1140404cbf, and I think it can be made simpler (like the patch I post), of
> course, this requires the maintainer to help review it.
> 
> And we need Krogerus and Rebello to take a look.

There is no requirement for any maintainers to deal with stable
backports if they do not want to.  As you feel you are stuck with these
old kernel versions, I suggest you make up the patch series and post
them for review, as you can test them the best.

thanks,

greg k-h