Re: [PATCH 6.6 resubmit 0/3] Fix PPS channel routing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 13, 2024 at 12:29:18PM +0100, Csókás, Bence wrote:
> On certain i.MX8 series parts [1], the PPS channel 0
> is routed internally to eDMA, and the external PPS
> pin is available on channel 1. In addition, on
> certain boards, the PPS may be wired on the PCB to
> an EVENTOUTn pin other than 0. On these systems
> it is necessary that the PPS channel be able
> to be configured from the Device Tree.
> 
> [1] https://lore.kernel.org/all/ZrPYOWA3FESx197L@lizhi-Precision-Tower-5810/
> 
> Francesco Dolcini (3):
>   dt-bindings: net: fec: add pps channel property
>   net: fec: refactor PPS channel configuration
>   net: fec: make PPS channel configurable
> 
>  Documentation/devicetree/bindings/net/fsl,fec.yaml |  7 +++++++
>  drivers/net/ethernet/freescale/fec_ptp.c           | 11 ++++++-----
>  2 files changed, 13 insertions(+), 5 deletions(-)

This series is really totally confusing.  Here's what it looks like in
my mbox:

   1   C Dec 13 Csókás, Bence   (0.8K) [PATCH 6.6 resubmit 0/3] Fix PPS channel routing
   2   C Dec 13 Csókás, Bence   (1.9K) ├─>[PATCH 6.11 v4 2/3] net: fec: refactor PPS channel configuration
   3   C Dec 13 Csókás, Bence   (1.8K) ├─>[PATCH 6.11 v4 3/3] net: fec: make PPS channel configurable
   4   C Dec 13 Csókás, Bence   (1.4K) ├─>[PATCH 6.11 v4 1/3] dt-bindings: net: fec: add pps channel property
   5   C Dec 13 Csókás, Bence   (1.9K) ├─>[PATCH 6.6 resubmit 2/3] net: fec: refactor PPS channel configuration
   6   C Dec 13 Csókás, Bence   (1.8K) ├─>[PATCH 6.6 resubmit 3/3] net: fec: make PPS channel configurable
   7   C Dec 13 Csókás, Bence   (0.9K) ├─>[PATCH 6.11 v4 0/3] Fix PPS channel routing
   8   C Dec 13 Csókás, Bence   (1.4K) └─>[PATCH 6.6 resubmit 1/3] dt-bindings: net: fec: add pps channel property

I see some 6.11 patches (which make no sense as 6.11 is long
end-of-life), and a "resubmit?" for 6.6, but no explaination as to _why_
this is being resubmitted here, or in the patches themselves.

Two different branches in the same series is also really really hard for
any type of tooling to tease apart, making this a manual effort on our
side if we want to deal with them.

What would you do if you got a series that looked like this and had to
handle it?  Would you do what I'm doing now and ask, "What in the world
is going on?"   :)

Please be kind to those on the other side of your emails, make it
blindingly obvious, as to what they need to do with them, AND make it
simple for them to handle the patches.

Series is now deleted from my review queue, sorry.

greg k-h




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux