- Linux-stable-mirror - lists.linaro.org

Re: [PATCH] ARM64: dts: meson: reduce odroid-c2 eMMC maximum rate

by Kevin Hilman

On Fri, Mar 2, 2018 at 5:44 AM, Jerome Brunet <jbrunet(a)baylibre.com> wrote: > Different modules maybe installed by the user on the eMMC connector > of the odroid-c2. While the red modules are working without an issue, > it seems some black modules (apparently Samsung based) are having > issue at 200MHz > > While the tuning algorithm introduced in v4.14 enables high speed modes > on every other tested designs, it seems a problem remains for this > particular combination of board and eMMC module. > > Lowering the maximum frequency of the eMMC on this board until we can > figure out a better solution. > > Fixes: d341ca88eead ("mmc: meson-gx: rework tuning function") > Suggested-by: Ellie Reeves <ellierevves(a)gmail.com> > Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Now in mainline as commit c04ffa71ff49 upstream. The mainline patch has "Cc: stable(a)vger.kernel.org", but it doesn't seem to have appeared in stable yet, and I've verified that it applies cleanly to linux-4.15.y and linux-4.14.y. Kevin > --- > arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > index 73a030a5ecf3..43475139576c 100644 > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > @@ -311,7 +311,7 @@ > pinctrl-names = "default", "clk-gate"; > > bus-width = <8>; > - max-frequency = <200000000>; > + max-frequency = <100000000>; > non-removable; > disable-wp; > cap-mmc-highspeed; > -- > 2.14.3 >

7 years, 8 months

2
2
0 0

[PATCH] pwm: rcar: fix a condition to prevent mismatch value setting to duty

by Yoshihiro Shimoda

From: Ryo Kodama <ryo.kodama.vz(a)renesas.com> This patch fixes an issue that is possible to set mismatch value to duty for R-Car PWM if we input the following commands: # cd /sys/class/pwm/<pwmchip>/ # echo 0 > export # cd pwm0 # echo 30 > period # echo 30 > duty_cycle # echo 0 > duty_cycle # cat duty_cycle 0 # echo 1 > enable --> Then, the actual duty_cycle is 30, not 0. So, this patch adds a condition into rcar_pwm_config() to fix this issue. Signed-off-by: Ryo Kodama <ryo.kodama.vz(a)renesas.com> [shimoda: revise the commit log and add Fixes and Cc tags] Fixes: ed6c1476bf7f ("pwm: Add support for R-Car PWM Timer") Cc: Cc: <stable(a)vger.kernel.org> # v4.4+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> --- drivers/pwm/pwm-rcar.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c index 1c85ecc..0fcf94f 100644 --- a/drivers/pwm/pwm-rcar.c +++ b/drivers/pwm/pwm-rcar.c @@ -156,8 +156,12 @@ static int rcar_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, if (div < 0) return div; - /* Let the core driver set pwm->period if disabled and duty_ns == 0 */ - if (!pwm_is_enabled(pwm) && !duty_ns) + /* + * Let the core driver set pwm->period if disabled and duty_ns == 0. + * But, this driver should prevent to set the new duty_ns if current + * duty_cycle is not set + */ + if (!pwm_is_enabled(pwm) && !duty_ns && !pwm->state.duty_cycle) return 0; rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR); -- 1.9.1

7 years, 8 months

2
1
0 0

+ task_struct-only-use-anon-struct-under-randstruct-plugin.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: task_struct: only use anon struct under randstruct plugin has been added to the -mm tree. Its filename is task_struct-only-use-anon-struct-under-randstruct-plugin.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/task_struct-only-use-anon-struct-u… and later at http://ozlabs.org/~akpm/mmotm/broken-out/task_struct-only-use-anon-struct-u… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Kees Cook <keescook(a)chromium.org> Subject: task_struct: only use anon struct under randstruct plugin The original intent for always adding the anonymous struct in task_struct was to make sure we had compiler coverage. However, this caused pathological padding of 40 bytes at the start of task_struct. Instead, move the anonymous struct to being only used when struct layout randomization is enabled. Link: http://lkml.kernel.org/r/20180327213609.GA2964@beast Fixes: 29e48ce87f1e ("task_struct: Allow randomized") Signed-off-by: Kees Cook <keescook(a)chromium.org> Reported-by: Peter Zijlstra <peterz(a)infradead.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/compiler-clang.h | 3 --- include/linux/compiler-gcc.h | 12 +++--------- 2 files changed, 3 insertions(+), 12 deletions(-) diff -puN include/linux/compiler-clang.h~task_struct-only-use-anon-struct-under-randstruct-plugin include/linux/compiler-clang.h --- a/include/linux/compiler-clang.h~task_struct-only-use-anon-struct-under-randstruct-plugin +++ a/include/linux/compiler-clang.h @@ -17,9 +17,6 @@ */ #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) -#define randomized_struct_fields_start struct { -#define randomized_struct_fields_end }; - /* all clang versions usable with the kernel support KASAN ABI version 5 */ #define KASAN_ABI_VERSION 5 diff -puN include/linux/compiler-gcc.h~task_struct-only-use-anon-struct-under-randstruct-plugin include/linux/compiler-gcc.h --- a/include/linux/compiler-gcc.h~task_struct-only-use-anon-struct-under-randstruct-plugin +++ a/include/linux/compiler-gcc.h @@ -242,6 +242,9 @@ #if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__) #define __randomize_layout __attribute__((randomize_layout)) #define __no_randomize_layout __attribute__((no_randomize_layout)) +/* This anon struct can add padding, so only enable it under randstruct. */ +#define randomized_struct_fields_start struct { +#define randomized_struct_fields_end } __randomize_layout; #endif #endif /* GCC_VERSION >= 40500 */ @@ -256,15 +259,6 @@ */ #define __visible __attribute__((externally_visible)) -/* - * RANDSTRUCT_PLUGIN wants to use an anonymous struct, but it is only - * possible since GCC 4.6. To provide as much build testing coverage - * as possible, this is used for all GCC 4.6+ builds, and not just on - * RANDSTRUCT_PLUGIN builds. - */ -#define randomized_struct_fields_start struct { -#define randomized_struct_fields_end } __randomize_layout; - #endif /* GCC_VERSION >= 40600 */ _ Patches currently in -mm which might be from keescook(a)chromium.org are taint-convert-to-indexed-initialization.patch taint-consolidate-documentation.patch taint-add-taint-for-randstruct.patch kernelh-introduce-const_max-for-vla-removal.patch remove-false-positive-vlas-when-using-max.patch task_struct-only-use-anon-struct-under-randstruct-plugin.patch test_bitmap-do-not-accidentally-use-stack-vla.patch fork-unconditionally-clear-stack-on-fork.patch exec-pass-stack-rlimit-into-mm-layout-functions.patch exec-introduce-finalize_exec-before-start_thread.patch exec-pin-stack-limit-during-exec.patch exofs-avoid-vla-in-structures.patch

7 years, 8 months

1
0
0 0

[PATCH v1] pwm: mediatek: improve precision in rate calculation

by sean.wang＠mediatek.com

From: Sean Wang <sean.wang(a)mediatek.com> Add a way that turning resolution from in nanosecond into in picosecond to improve noticeably almost 4.5% precision. It's necessary to hold the new resolution with type u64 and thus related operations on u64 are applied instead in those rate calculations. And the patch has a dependency on [1]. [1] http://lists.infradead.org/pipermail/linux-mediatek/2018-March/012225.html Cc: stable(a)vger.kernel.org Fixes: caf065f8fd58 ("pwm: Add MediaTek PWM support") Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> --- drivers/pwm/pwm-mediatek.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c index 796baea..98b0a93 100644 --- a/drivers/pwm/pwm-mediatek.c +++ b/drivers/pwm/pwm-mediatek.c @@ -135,19 +135,25 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, { struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip); struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]; - u32 resolution, clkdiv = 0, reg_width = PWMDWIDTH, + u32 clkdiv = 0, cnt_period, cnt_duty, reg_width = PWMDWIDTH, reg_thres = PWMTHRES; + u64 resolution; int ret; ret = mtk_pwm_clk_enable(chip, pwm); if (ret < 0) return ret; - resolution = NSEC_PER_SEC / clk_get_rate(clk); + /* Using resolution in picosecond gets accuracy higher */ + resolution = (u64)NSEC_PER_SEC * 1000; + do_div(resolution, clk_get_rate(clk)); - while (period_ns / resolution > 8191) { + cnt_period = DIV_ROUND_CLOSEST_ULL((u64)period_ns * 1000, resolution); + while (cnt_period > 8191) { resolution *= 2; clkdiv++; + cnt_period = DIV_ROUND_CLOSEST_ULL((u64)period_ns * 1000, + resolution); } if (clkdiv > PWM_CLK_DIV_MAX) { @@ -165,9 +171,10 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, reg_thres = PWM45THRES_FIXUP; } + cnt_duty = DIV_ROUND_CLOSEST_ULL((u64)duty_ns * 1000, resolution); mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv); - mtk_pwm_writel(pc, pwm->hwpwm, reg_width, period_ns / resolution); - mtk_pwm_writel(pc, pwm->hwpwm, reg_thres, duty_ns / resolution); + mtk_pwm_writel(pc, pwm->hwpwm, reg_width, cnt_period); + mtk_pwm_writel(pc, pwm->hwpwm, reg_thres, cnt_duty); mtk_pwm_clk_disable(chip, pwm); -- 2.7.4

7 years, 8 months

2
1
0 0

Re: [PATCH v3] pwm: mediatek: fix up PWM4 and PWM5 malfunction on MT7623

by Sean Wang

On Fri, 2018-03-02 at 11:57 +0100, Thierry Reding wrote: > On Thu, Mar 01, 2018 at 04:19:12PM +0800, sean.wang(a)mediatek.com wrote: > > From: Sean Wang <sean.wang(a)mediatek.com> > > > > Since the offset for both registers, PWMDWIDTH and PWMTHRES, used to > > control PWM4 or PWM5 are distinct from the other PWMs, whose wrong > > programming on PWM hardware causes waveform cannot be output as expected. > > Thus, the patch adds the extra condition for fixing up the weird case to > > let PWM4 or PWM5 able to work on MT7623. > > > > v1 -> v2: use pwm45_fixup naming instead of pwm45_quirk > > v2 -> v3: add more tags for Reviewed-by, Fixes, and Cc stable > > > > Cc: stable(a)vger.kernel.org > > Fixes: caf065f8fd58 ("pwm: Add MediaTek PWM support") > > Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> > > Reviewed-by: Matthias Brugger <matthias.bgg(a)gmail.com> > > Cc: Zhi Mao <zhi.mao(a)mediatek.com> > > Cc: John Crispin <john(a)phrozen.org> > > Cc: Matthias Brugger <matthias.bgg(a)gmail.com> > > --- > > drivers/pwm/pwm-mediatek.c | 24 +++++++++++++++++++++--- > > 1 file changed, 21 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c > [...] > > @@ -151,9 +156,18 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, > > return -EINVAL; > > } > > > > + if (pc->soc->pwm45_fixup && pwm->hwpwm > 2) { > > + /* > > + * PWM[4,5] has distinct offset for PWMDWIDTH and PWMTHRES > > + * from the other PWMs on MT7623. > > + */ > > + reg_width = PWM45DWIDTH_FIXUP; > > + reg_thres = PWM45THRES_FIXUP; > > + } > > I don't understand this. According to the condition above the above > would also use the PWM[4,5] "fixup" register offsets with PWM[3]. Should > the condition be pwm->hwpwm > 3? > > Thierry PWM[4,5] are the naming specified in datasheet and kept it as is here and driver or userspace would use index 3 and 4 to have a reference to them respectively.

7 years, 8 months

2
1
0 0

[PATCH] x86/platform/uv/BAU: add APIC idt entry

by Andrew Banman

BAU uses the old alloc_initr_gate method to setup its interrupt. This fails silently as the BAU vector is in the range of APIC vectors that are registerted to the spurious interrupt handler. Then BAU broadcasts are not handled, and the broadcast source CPU hangs. Fixed by updating BAU to use new idt structure. Signed-off-by: Andrew Banman <abanman(a)hpe.com> Acked-by: Mike Travis <mike.travis(a)hpe.com> --- arch/x86/include/asm/hw_irq.h | 1 + arch/x86/kernel/idt.c | 3 +++ arch/x86/platform/uv/tlb_uv.c | 2 -- 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h index 6dfe366..a56cd0b 100644 --- a/arch/x86/include/asm/hw_irq.h +++ b/arch/x86/include/asm/hw_irq.h @@ -33,6 +33,7 @@ extern asmlinkage void kvm_posted_intr_nested_ipi(void); extern asmlinkage void error_interrupt(void); extern asmlinkage void irq_work_interrupt(void); +extern asmlinkage void uv_bau_message_intr1(void); extern asmlinkage void spurious_interrupt(void); extern asmlinkage void thermal_interrupt(void); diff --git a/arch/x86/kernel/idt.c b/arch/x86/kernel/idt.c index 99f93a6..c5da34e 100644 --- a/arch/x86/kernel/idt.c +++ b/arch/x86/kernel/idt.c @@ -138,6 +138,9 @@ struct idt_data { # ifdef CONFIG_IRQ_WORK INTG(IRQ_WORK_VECTOR, irq_work_interrupt), # endif +#ifdef CONFIG_X86_UV + INTG(UV_BAU_MESSAGE, uv_bau_message_intr1), +#endif INTG(SPURIOUS_APIC_VECTOR, spurious_interrupt), INTG(ERROR_APIC_VECTOR, error_interrupt), #endif diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c index f44c0bc..5e22845 100644 --- a/arch/x86/platform/uv/tlb_uv.c +++ b/arch/x86/platform/uv/tlb_uv.c @@ -2254,8 +2254,6 @@ static int __init uv_bau_init(void) init_uvhub(uvhub, vector, uv_base_pnode); } - alloc_intr_gate(vector, uv_bau_message_intr1); - for_each_possible_blade(uvhub) { if (uv_blade_nr_possible_cpus(uvhub)) { unsigned long val; -- 1.8.2.1

7 years, 8 months

1
0
0 0

[PATCH 2/4] Drivers: hv: vmbus: do not mark HV_PCIE as perf_device

by kys＠linuxonhyperv.comi

From: Dexuan Cui <decui(a)microsoft.com> The pci-hyperv driver's channel callback hv_pci_onchannelcallback() is not really a hot path, so we don't need to mark it as a perf_device, meaning with this patch all HV_PCIE channels' target_cpu will be CPU0. Signed-off-by: Dexuan Cui <decui(a)microsoft.com> Cc: stable(a)vger.kernel.org Cc: Stephen Hemminger <sthemmin(a)microsoft.com> Cc: K. Y. Srinivasan <kys(a)microsoft.com> Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com> --- drivers/hv/channel_mgmt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index c6d9d19bc04e..ecc2bd275a73 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -71,7 +71,7 @@ static const struct vmbus_device vmbus_devs[] = { /* PCIE */ { .dev_type = HV_PCIE, HV_PCIE_GUID, - .perf_device = true, + .perf_device = false, }, /* Synthetic Frame Buffer */ -- 2.15.1

7 years, 8 months

1
0
0 0

[PATCH v3 1/6] PCI: aardvark: introduce an advk_pcie_valid_device() helper

by Thomas Petazzoni

From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> In other to mimic other PCIe host controller drivers, introduce an advk_pcie_valid_device() helper, used in the configuration read/write functions. This patch by itself is not a fix, but it is required for a follow-up patch that is a fix, hence the Fixes tag and the Cc to stable. Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> --- Changes since v2: - New patch --- drivers/pci/host/pci-aardvark.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c index b04d37b3c5de..ccd0304a0c21 100644 --- a/drivers/pci/host/pci-aardvark.c +++ b/drivers/pci/host/pci-aardvark.c @@ -430,6 +430,15 @@ static int advk_pcie_wait_pio(struct advk_pcie *pcie) return -ETIMEDOUT; } +static int advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, + int devfn) +{ + if (PCI_SLOT(devfn) != 0) + return false; + + return true; +} + static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val) { @@ -437,7 +446,7 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn, u32 reg; int ret; - if (PCI_SLOT(devfn) != 0) { + if (!advk_pcie_valid_device(pcie, bus, devfn)) { *val = 0xffffffff; return PCIBIOS_DEVICE_NOT_FOUND; } @@ -491,7 +500,7 @@ static int advk_pcie_wr_conf(struct pci_bus *bus, u32 devfn, int offset; int ret; - if (PCI_SLOT(devfn) != 0) + if (!advk_pcie_valid_device(pcie, bus, devfn)) return PCIBIOS_DEVICE_NOT_FOUND; if (where % size) -- 2.14.3

7 years, 8 months

2
1
0 0

[PATCHv2] irqchip: arm-gic: take gic_lock when updating irq type

by Aniruddha Banerjee

The kernel documentation states that the locking of the irq-chip registers should be handled by the irq-chip driver. In the irq-gic, the accesses to the irqchip are seemingly not protected and multiple writes to SPIs from different irq descriptors do RMW requests without taking the irq-chip lock. When multiple irqs call the request_irq at the same time, there can be a simultaneous write at the gic distributor, leading to a race. Acquire the gic_lock when the irq_type is updated. Signed-off-by: Aniruddha Banerjee <aniruddha.nitd(a)gmail.com> --- drivers/irqchip/irq-gic-common.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c index 9ae71804b5dd..73dd39959e6e 100644 --- a/drivers/irqchip/irq-gic-common.c +++ b/drivers/irqchip/irq-gic-common.c @@ -21,6 +21,8 @@ #include "irq-gic-common.h" +static DEFINE_RAW_SPINLOCK(irq_controller_lock); + static const struct gic_kvm_info *gic_kvm_info; const struct gic_kvm_info *gic_get_kvm_info(void) @@ -57,6 +59,7 @@ int gic_configure_irq(unsigned int irq, unsigned int type, * Read current configuration register, and insert the config * for "irq", depending on "type". */ + raw_spin_lock(&irq_controller_lock); val = oldval = readl_relaxed(base + GIC_DIST_CONFIG + confoff); if (type & IRQ_TYPE_LEVEL_MASK) val &= ~confmask; @@ -64,8 +67,10 @@ int gic_configure_irq(unsigned int irq, unsigned int type, val |= confmask; /* If the current configuration is the same, then we are done */ - if (val == oldval) + if (val == oldval) { + raw_spin_unlock(&irq_controller_lock); return 0; + } /* * Write back the new configuration, and possibly re-enable @@ -83,6 +88,7 @@ int gic_configure_irq(unsigned int irq, unsigned int type, pr_warn("GIC: PPI%d is secure or misconfigured\n", irq - 16); } + raw_spin_unlock(&irq_controller_lock); if (sync_access) sync_access(); -- 2.16.2

7 years, 8 months

1
0
0 0

[PATCH v3 2/6] phy: qcom-qusb2: Fix crash if nvmem cell not specified

by Manu Gautam

Driver currently crashes due to NULL pointer deference while updating PHY tune register if nvmem cell is NULL. Since, fused value for Tune1/2 register is optional, we'd rather bail out. Fixes: ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips") Reviewed-by: Vivek Gautam <vivek.gautam(a)codeaurora.org> Cc: stable <stable(a)vger.kernel.org> # 4.14+ Signed-off-by: Manu Gautam <mgautam(a)codeaurora.org> --- drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c index 94afeac..40fdef8 100644 --- a/drivers/phy/qualcomm/phy-qcom-qusb2.c +++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c @@ -315,6 +315,10 @@ static void qusb2_phy_set_tune2_param(struct qusb2_phy *qphy) const struct qusb2_phy_cfg *cfg = qphy->cfg; u8 *val; + /* efuse register is optional */ + if (!qphy->cell) + return; + /* * Read efuse register having TUNE2/1 parameter's high nibble. * If efuse register shows value as 0x0, or if we fail to find -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

7 years, 8 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror