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(-)
From: Francesco Dolcini francesco.dolcini@toradex.com
Add fsl,pps-channel property to select where to connect the PPS signal. This depends on the internal SoC routing and on the board, for example on the i.MX8 SoC it can be connected to an external pin (using channel 1) or to internal eDMA as DMA request (channel 0).
Signed-off-by: Francesco Dolcini francesco.dolcini@toradex.com Acked-by: Conor Dooley conor.dooley@microchip.com Signed-off-by: Paolo Abeni pabeni@redhat.com (cherry picked from commit 1aa772be0444a2bd06957f6d31865e80e6ae4244) Signed-off-by: Csókás, Bence csokas.bence@prolan.hu --- Documentation/devicetree/bindings/net/fsl,fec.yaml | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml index b494e009326e..9925563e5e14 100644 --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -182,6 +182,13 @@ properties: description: Register bits of stop mode control, the format is <&gpr req_gpr req_bit>.
+ fsl,pps-channel: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: + Specifies to which timer instance the PPS signal is routed. + enum: [0, 1, 2, 3] + mdio: $ref: mdio.yaml# unevaluatedProperties: false
[ Sasha's backport helper bot ]
Hi,
Found matching upstream commit: 1aa772be0444a2bd06957f6d31865e80e6ae4244
WARNING: Author mismatch between patch and found commit: Backport author: =?UTF-8?q?Cs=C3=B3k=C3=A1s=2C=20Bence?= csokas.bence@prolan.hu Commit author: Francesco Dolcini francesco.dolcini@toradex.com
Status in newer kernel trees: 6.12.y | Present (different SHA1: e8139c66df98) 6.6.y | Not found
Note: The patch differs from the upstream commit: --- 1: 1aa772be0444a ! 1: 0a9ae16b34ceb dt-bindings: net: fec: add pps channel property @@ Commit message Signed-off-by: Francesco Dolcini francesco.dolcini@toradex.com Acked-by: Conor Dooley conor.dooley@microchip.com Signed-off-by: Paolo Abeni pabeni@redhat.com + (cherry picked from commit 1aa772be0444a2bd06957f6d31865e80e6ae4244) + Signed-off-by: Csókás, Bence csokas.bence@prolan.hu
## Documentation/devicetree/bindings/net/fsl,fec.yaml ## @@ Documentation/devicetree/bindings/net/fsl,fec.yaml: properties: ---
Results of testing on various branches:
| Branch | Patch Apply | Build Test | |---------------------------|-------------|------------| | stable/linux-6.6.y | Success | Success |
From: Francesco Dolcini francesco.dolcini@toradex.com
Preparation patch to allow for PPS channel configuration, no functional change intended.
Signed-off-by: Francesco Dolcini francesco.dolcini@toradex.com Reviewed-by: Frank Li Frank.Li@nxp.com Reviewed-by: Csókás, Bence csokas.bence@prolan.hu Signed-off-by: Paolo Abeni pabeni@redhat.com (cherry picked from commit bf8ca67e21671e7a56e31da45360480b28f185f1) Signed-off-by: Csókás, Bence csokas.bence@prolan.hu --- drivers/net/ethernet/freescale/fec_ptp.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c index a4eb6edb850a..37e1c895f1b8 100644 --- a/drivers/net/ethernet/freescale/fec_ptp.c +++ b/drivers/net/ethernet/freescale/fec_ptp.c @@ -84,8 +84,7 @@ #define FEC_CC_MULT (1 << 31) #define FEC_COUNTER_PERIOD (1 << 31) #define PPS_OUPUT_RELOAD_PERIOD NSEC_PER_SEC -#define FEC_CHANNLE_0 0 -#define DEFAULT_PPS_CHANNEL FEC_CHANNLE_0 +#define DEFAULT_PPS_CHANNEL 0
#define FEC_PTP_MAX_NSEC_PERIOD 4000000000ULL #define FEC_PTP_MAX_NSEC_COUNTER 0x80000000ULL @@ -524,8 +523,9 @@ static int fec_ptp_enable(struct ptp_clock_info *ptp, unsigned long flags; int ret = 0;
+ fep->pps_channel = DEFAULT_PPS_CHANNEL; + if (rq->type == PTP_CLK_REQ_PPS) { - fep->pps_channel = DEFAULT_PPS_CHANNEL; fep->reload_period = PPS_OUPUT_RELOAD_PERIOD;
ret = fec_ptp_enable_pps(fep, on); @@ -536,10 +536,9 @@ static int fec_ptp_enable(struct ptp_clock_info *ptp, if (rq->perout.flags) return -EOPNOTSUPP;
- if (rq->perout.index != DEFAULT_PPS_CHANNEL) + if (rq->perout.index != fep->pps_channel) return -EOPNOTSUPP;
- fep->pps_channel = DEFAULT_PPS_CHANNEL; period.tv_sec = rq->perout.period.sec; period.tv_nsec = rq->perout.period.nsec; period_ns = timespec64_to_ns(&period);
From: Francesco Dolcini francesco.dolcini@toradex.com
Depending on the SoC where the FEC is integrated into the PPS channel might be routed to different timer instances. Make this configurable from the devicetree.
When the related DT property is not present fallback to the previous default and use channel 0.
Reviewed-by: Frank Li Frank.Li@nxp.com Tested-by: Rafael Beims rafael.beims@toradex.com Signed-off-by: Francesco Dolcini francesco.dolcini@toradex.com Reviewed-by: Csókás, Bence csokas.bence@prolan.hu Signed-off-by: Paolo Abeni pabeni@redhat.com (cherry picked from commit 566c2d83887f0570056833102adc5b88e681b0c7) Signed-off-by: Csókás, Bence csokas.bence@prolan.hu --- drivers/net/ethernet/freescale/fec_ptp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c index 37e1c895f1b8..7f6b57432071 100644 --- a/drivers/net/ethernet/freescale/fec_ptp.c +++ b/drivers/net/ethernet/freescale/fec_ptp.c @@ -523,8 +523,6 @@ static int fec_ptp_enable(struct ptp_clock_info *ptp, unsigned long flags; int ret = 0;
- fep->pps_channel = DEFAULT_PPS_CHANNEL; - if (rq->type == PTP_CLK_REQ_PPS) { fep->reload_period = PPS_OUPUT_RELOAD_PERIOD;
@@ -706,12 +704,16 @@ void fec_ptp_init(struct platform_device *pdev, int irq_idx) { struct net_device *ndev = platform_get_drvdata(pdev); struct fec_enet_private *fep = netdev_priv(ndev); + struct device_node *np = fep->pdev->dev.of_node; int irq; int ret;
fep->ptp_caps.owner = THIS_MODULE; strscpy(fep->ptp_caps.name, "fec ptp", sizeof(fep->ptp_caps.name));
+ fep->pps_channel = DEFAULT_PPS_CHANNEL; + of_property_read_u32(np, "fsl,pps-channel", &fep->pps_channel); + fep->ptp_caps.max_adj = 250000000; fep->ptp_caps.n_alarm = 0; fep->ptp_caps.n_ext_ts = 0;
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/
Changes in v2: * add upstream hash (pick -x) Changes in v3: * Add S-o-b despite Sasha's complaining bot Changes in v4: * Remove blank line in S-o-b area
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(-)
From: Francesco Dolcini francesco.dolcini@toradex.com
Add fsl,pps-channel property to select where to connect the PPS signal. This depends on the internal SoC routing and on the board, for example on the i.MX8 SoC it can be connected to an external pin (using channel 1) or to internal eDMA as DMA request (channel 0).
Signed-off-by: Francesco Dolcini francesco.dolcini@toradex.com Acked-by: Conor Dooley conor.dooley@microchip.com Signed-off-by: Paolo Abeni pabeni@redhat.com (cherry picked from commit 1aa772be0444a2bd06957f6d31865e80e6ae4244) Signed-off-by: Csókás, Bence csokas.bence@prolan.hu --- Documentation/devicetree/bindings/net/fsl,fec.yaml | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml index 5536c06139ca..24e863fdbdab 100644 --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -183,6 +183,13 @@ properties: description: Register bits of stop mode control, the format is <&gpr req_gpr req_bit>.
+ fsl,pps-channel: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: + Specifies to which timer instance the PPS signal is routed. + enum: [0, 1, 2, 3] + mdio: $ref: mdio.yaml# unevaluatedProperties: false
From: Francesco Dolcini francesco.dolcini@toradex.com
Preparation patch to allow for PPS channel configuration, no functional change intended.
Signed-off-by: Francesco Dolcini francesco.dolcini@toradex.com Reviewed-by: Frank Li Frank.Li@nxp.com Reviewed-by: Csókás, Bence csokas.bence@prolan.hu Signed-off-by: Paolo Abeni pabeni@redhat.com (cherry picked from commit bf8ca67e21671e7a56e31da45360480b28f185f1) Signed-off-by: Csókás, Bence csokas.bence@prolan.hu --- drivers/net/ethernet/freescale/fec_ptp.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c index a4eb6edb850a..37e1c895f1b8 100644 --- a/drivers/net/ethernet/freescale/fec_ptp.c +++ b/drivers/net/ethernet/freescale/fec_ptp.c @@ -84,8 +84,7 @@ #define FEC_CC_MULT (1 << 31) #define FEC_COUNTER_PERIOD (1 << 31) #define PPS_OUPUT_RELOAD_PERIOD NSEC_PER_SEC -#define FEC_CHANNLE_0 0 -#define DEFAULT_PPS_CHANNEL FEC_CHANNLE_0 +#define DEFAULT_PPS_CHANNEL 0
#define FEC_PTP_MAX_NSEC_PERIOD 4000000000ULL #define FEC_PTP_MAX_NSEC_COUNTER 0x80000000ULL @@ -524,8 +523,9 @@ static int fec_ptp_enable(struct ptp_clock_info *ptp, unsigned long flags; int ret = 0;
+ fep->pps_channel = DEFAULT_PPS_CHANNEL; + if (rq->type == PTP_CLK_REQ_PPS) { - fep->pps_channel = DEFAULT_PPS_CHANNEL; fep->reload_period = PPS_OUPUT_RELOAD_PERIOD;
ret = fec_ptp_enable_pps(fep, on); @@ -536,10 +536,9 @@ static int fec_ptp_enable(struct ptp_clock_info *ptp, if (rq->perout.flags) return -EOPNOTSUPP;
- if (rq->perout.index != DEFAULT_PPS_CHANNEL) + if (rq->perout.index != fep->pps_channel) return -EOPNOTSUPP;
- fep->pps_channel = DEFAULT_PPS_CHANNEL; period.tv_sec = rq->perout.period.sec; period.tv_nsec = rq->perout.period.nsec; period_ns = timespec64_to_ns(&period);
[ Sasha's backport helper bot ]
Hi,
Found matching upstream commit: bf8ca67e21671e7a56e31da45360480b28f185f1
WARNING: Author mismatch between patch and found commit: Backport author: =?UTF-8?q?Cs=C3=B3k=C3=A1s=2C=20Bence?= csokas.bence@prolan.hu Commit author: Francesco Dolcini francesco.dolcini@toradex.com
Status in newer kernel trees: 6.12.y | Present (different SHA1: 75d06a0404ee)
Note: The patch differs from the upstream commit: --- Failed to apply patch cleanly, falling back to interdiff... ---
Results of testing on various branches:
| Branch | Patch Apply | Build Test | |---------------------------|-------------|------------| | stable/linux-6.12.y | Failed (series apply) | N/A | | stable/linux-6.6.y | Success | Success | | stable/linux-6.1.y | Failed | N/A | | stable/linux-5.15.y | Failed (series apply) | N/A | | stable/linux-5.10.y | Failed (series apply) | N/A | | stable/linux-5.4.y | Failed (series apply) | N/A |
From: Francesco Dolcini francesco.dolcini@toradex.com
Depending on the SoC where the FEC is integrated into the PPS channel might be routed to different timer instances. Make this configurable from the devicetree.
When the related DT property is not present fallback to the previous default and use channel 0.
Reviewed-by: Frank Li Frank.Li@nxp.com Tested-by: Rafael Beims rafael.beims@toradex.com Signed-off-by: Francesco Dolcini francesco.dolcini@toradex.com Reviewed-by: Csókás, Bence csokas.bence@prolan.hu Signed-off-by: Paolo Abeni pabeni@redhat.com (cherry picked from commit 566c2d83887f0570056833102adc5b88e681b0c7) Signed-off-by: Csókás, Bence csokas.bence@prolan.hu --- drivers/net/ethernet/freescale/fec_ptp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c index 37e1c895f1b8..7f6b57432071 100644 --- a/drivers/net/ethernet/freescale/fec_ptp.c +++ b/drivers/net/ethernet/freescale/fec_ptp.c @@ -523,8 +523,6 @@ static int fec_ptp_enable(struct ptp_clock_info *ptp, unsigned long flags; int ret = 0;
- fep->pps_channel = DEFAULT_PPS_CHANNEL; - if (rq->type == PTP_CLK_REQ_PPS) { fep->reload_period = PPS_OUPUT_RELOAD_PERIOD;
@@ -706,12 +704,16 @@ void fec_ptp_init(struct platform_device *pdev, int irq_idx) { struct net_device *ndev = platform_get_drvdata(pdev); struct fec_enet_private *fep = netdev_priv(ndev); + struct device_node *np = fep->pdev->dev.of_node; int irq; int ret;
fep->ptp_caps.owner = THIS_MODULE; strscpy(fep->ptp_caps.name, "fec ptp", sizeof(fep->ptp_caps.name));
+ fep->pps_channel = DEFAULT_PPS_CHANNEL; + of_property_read_u32(np, "fsl,pps-channel", &fep->pps_channel); + fep->ptp_caps.max_adj = 250000000; fep->ptp_caps.n_alarm = 0; fep->ptp_caps.n_ext_ts = 0;
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
Hi,
On 2024. 12. 13. 12:41, Greg Kroah-Hartman wrote:
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 propertyI see some 6.11 patches (which make no sense as 6.11 is long end-of-life)
Ah, sorry, it seems those were left in my maildir from a previous format-patch as I invoked send-email ./* ...
and a "resubmit?" for 6.6, but no explaination as to _why_ this is being resubmitted here, or in the patches themselves.
I submitted it to 6.6 once here, but it got rejected because it wasn't in 6.11.y and 6.12.y: Link: https://lore.kernel.org/netdev/2024120204-footer-riverbed-0daa@gregkh/
Since then, it got into 6.12.y, and - as you said - 6.11 got EOL, before it could ever get this patch. So I thought to resubmit it for 6.6, as that's the version that is of interest to us.
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
Sorry for the confusion. So, should I submit the series yet again, without "resubmit" (and, obviously, without the left-over 6.11 patches)?
Bence
On Sun, Dec 15, 2024 at 06:15:41PM +0100, Csókás Bence wrote:
Hi,
On 2024. 12. 13. 12:41, Greg Kroah-Hartman wrote:
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 propertyI see some 6.11 patches (which make no sense as 6.11 is long end-of-life)
Ah, sorry, it seems those were left in my maildir from a previous format-patch as I invoked send-email ./* ...
and a "resubmit?" for 6.6, but no explaination as to _why_ this is being resubmitted here, or in the patches themselves.
I submitted it to 6.6 once here, but it got rejected because it wasn't in 6.11.y and 6.12.y: Link: https://lore.kernel.org/netdev/2024120204-footer-riverbed-0daa@gregkh/
Since then, it got into 6.12.y, and - as you said - 6.11 got EOL, before it could ever get this patch. So I thought to resubmit it for 6.6, as that's the version that is of interest to us.
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
Sorry for the confusion. So, should I submit the series yet again, without "resubmit" (and, obviously, without the left-over 6.11 patches)?
What would you want to see if you were on my end? (hint, a resend of the correct things to apply, along with an explaination of what they are and what version they are and what has changed between versions...)
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Csókás Bence -
Csókás, Bence
-
Greg Kroah-Hartman -
Sasha Levin