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

[PATCH] crypto:authencesn: Avoid twice completion call in decrypt path

by Harsh Jain

Authencesn template in decrypt path unconditionally calls aead_request_complete after ahash_verify which leads to following kernel panic in after decryption. [ 338.539800] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 [ 338.548372] PGD 0 P4D 0 [ 338.551157] Oops: 0000 [#1] SMP PTI [ 338.554919] CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Tainted: G W I 4.19.7+ #13 [ 338.564431] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0 07/29/10 [ 338.572212] RIP: 0010:esp_input_done2+0x350/0x410 [esp4] [ 338.578030] Code: ff 0f b6 68 10 48 8b 83 c8 00 00 00 e9 8e fe ff ff 8b 04 25 04 00 00 00 83 e8 01 48 98 48 8b 3c c5 10 00 00 00 e9 f7 fd ff ff <8b> 04 25 04 00 00 00 83 e8 01 48 98 4c 8b 24 c5 10 00 00 00 e9 3b [ 338.598547] RSP: 0018:ffff911c97803c00 EFLAGS: 00010246 [ 338.604268] RAX: 0000000000000002 RBX: ffff911c4469ee00 RCX: 0000000000000000 [ 338.612090] RDX: 0000000000000000 RSI: 0000000000000130 RDI: ffff911b87c20400 [ 338.619874] RBP: 0000000000000000 R08: ffff911b87c20498 R09: 000000000000000a [ 338.627610] R10: 0000000000000001 R11: 0000000000000004 R12: 0000000000000000 [ 338.635402] R13: ffff911c89590000 R14: ffff911c91730000 R15: 0000000000000000 [ 338.643234] FS: 0000000000000000(0000) GS:ffff911c97800000(0000) knlGS:0000000000000000 [ 338.652047] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 338.658299] CR2: 0000000000000004 CR3: 00000001ec20a000 CR4: 00000000000006f0 [ 338.666382] Call Trace: [ 338.669051] <IRQ> [ 338.671254] esp_input_done+0x12/0x20 [esp4] [ 338.675922] chcr_handle_resp+0x3b5/0x790 [chcr] [ 338.680949] cpl_fw6_pld_handler+0x37/0x60 [chcr] [ 338.686080] chcr_uld_rx_handler+0x22/0x50 [chcr] [ 338.691233] uldrx_handler+0x8c/0xc0 [cxgb4] [ 338.695923] process_responses+0x2f0/0x5d0 [cxgb4] [ 338.701177] ? bitmap_find_next_zero_area_off+0x3a/0x90 [ 338.706882] ? matrix_alloc_area.constprop.7+0x60/0x90 [ 338.712517] ? apic_update_irq_cfg+0x82/0xf0 [ 338.717177] napi_rx_handler+0x14/0xe0 [cxgb4] [ 338.722015] net_rx_action+0x2aa/0x3e0 [ 338.726136] __do_softirq+0xcb/0x280 [ 338.730054] irq_exit+0xde/0xf0 [ 338.733504] do_IRQ+0x54/0xd0 [ 338.736745] common_interrupt+0xf/0xf Signed-off-by: Harsh Jain <harsh(a)chelsio.com> Cc: stable(a)vger.kernel.org --- crypto/authencesn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/authencesn.c b/crypto/authencesn.c index 80a25cc..4741fe8 100644 --- a/crypto/authencesn.c +++ b/crypto/authencesn.c @@ -279,7 +279,7 @@ static void authenc_esn_verify_ahash_done(struct crypto_async_request *areq, struct aead_request *req = areq->data; err = err ?: crypto_authenc_esn_decrypt_tail(req, 0); - aead_request_complete(req, err); + authenc_esn_request_complete(req, err); } static int crypto_authenc_esn_decrypt(struct aead_request *req) -- 2.1.4

6 years, 8 months

2
1
0 0

genirq: 'HP FlexFabric 554FLB Adapter' not working with the kernel 4.14.88

by Gaoliang

Hi, After upgrading kernel from 4.14.40 to 4.14.88,I found that 'HP FlexFabric 10Gb 2-port 554FLB Adapter' device is not in use. There are erros in dmesg log. The Server is 'HP FlexServer B390'. Device info: lspci -n | grep 04:00 04:00.2 0c04: 19a2:0714 (rev 01) ... 04:00.2 Fibre Channel: Emulex Corporation OneConnect 10Gb FCoE Initiator (be3) (rev 01) Subsystem: Hewlett-Packard Company NC554FLB 10Gb 2-port FlexFabric Converged Network Adapter Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin C routed to IRQ 95 ... Kernel driver in use: lpfc The error info: [ 1046.980480] lpfc 0000:04:00.3: 1:1303 Link Up Event x1 received Data: x1 x0 x4 x0 x0 x0 0 [ 1046.980482] lpfc 0000:04:00.3: 1:(0):2753 PLOGI failure DID:020009 Status:x3/x103 [ 1050.435167] lpfc 0000:04:00.2: 0:(0):2753 PLOGI failure DID:010012 Status:x3/x103 [ 1065.713327] lpfc 0000:04:00.3: 1:(0):2753 PLOGI failure DID:040002 Status:x3/x103 [ 1072.331933] lpfc 0000:04:00.2: 0:(0):2753 PLOGI failure DID:030003 Status:x3/x103 [ 1137.628132] lpfc 0000:04:00.2: 0:(0):0748 abort handler timed out waiting for aborting I/O (xri:x64) to complete: ret 0x2003, ID 2, LUN 0 [ 1137.644257] lpfc 0000:04:00.2: 0:(0):0713 SCSI layer issued Device Reset (2, 0) return x2002 [ 1139.676124] lpfc 0000:04:00.3: 1:(0):0748 abort handler timed out waiting for aborting I/O (xri:x464) to complete: ret 0x2003, ID 4, LUN 0 [ 1139.692242] lpfc 0000:04:00.3: 1:(0):0713 SCSI layer issued Device Reset (4, 0) return x2002 [ 1197.664150] lpfc 0000:04:00.2: 0:(0):0724 I/O flush failure for context LUN : cnt x1 [ 1197.664344] lpfc 0000:04:00.2: 0:(0):0723 SCSI layer issued Target Reset (2, 0) return x2002 [ 1199.704116] lpfc 0000:04:00.3: 1:(0):0724 I/O flush failure for context LUN : cnt x1 [ 1199.704368] lpfc 0000:04:00.3: 1:(0):0723 SCSI layer issued Target Reset (4, 0) return x2002 At the beginning, I thought the lpfc driver itself is the cause of the error.But,the error is still seen when 'lpfc driver' updates to the latest version. To find the root cause and fix it, we checked the kernel version from 4.14.41 to 4.14.88, built and tested the kernel for booting. The commit that caused error after bisect is ef86f3a72adb8a7931f67335560740a7ad696d1d,when I removed the commit the issue went away. Commit info: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… During the test, I also found another issue that the system of 'HP FlexServer B390' server failed to boot by "hpsa driver timeout",basically, looks like the hpsa didn't detect the hard drives and udevd is stalled. After upgrading from v4.14.54 to 4.14.55, hp system didn't boot ,but the system is ok when using the v4.14.55 kernel that has removed the commit. The commit of ef86f3a72adb8a7931f67335560740a7ad696d1d also affects the HP Smart Array P220i RAID device.Because the v4.14.88 kernel is ok, I think that subsequent commits may have fixed the hpsa driver issue, but lpfc driver issue is not. If there is any more info I can provide, just ask what would be useful. Any suggestions? Thanks Liang

6 years, 8 months

2
1
0 0

genirq/affinity: missing fix from the stable branch 4.14.y

by Mihai Carabas

Hello, Is there any reason why the fix with commit id 0211e12dd0a5385ecffd3557bc570dbad7fcf245 [1] was not backported to the stable branch 4.14.y? Thank you, Mihai Carabas [1] https://github.com/torvalds/linux/commit/0211e12dd0a5385ecffd3557bc570dbad7…

6 years, 8 months

2
1
0 0

Re: [PATCH] powerpc/powernv/npu: Fix oops in pnv_try_setup_npu_table_group()

by Greg Kurz

On Wed, 9 Jan 2019 16:13:42 +0100 Frederic Barrat <fbarrat(a)linux.ibm.com> wrote: > With a recent change around IOMMU group, a system with an opencapi > adapter is no longer booting and we get a kernel oops: > > BUG: Kernel NULL pointer dereference at 0x00000028 > Faulting instruction address: 0xc0000000000aa38c > Oops: Kernel access of bad area, sig: 7 [#1] > LE SMP NR_CPUS=2048 NUMA PowerNV > Modules linked in: > CPU: 5 PID: 1 Comm: swapper/4 Not tainted 5.0.0-rc1-fxb-00001-g3bd6e94bec12 > NIP: c0000000000aa38c LR: c0000000000a6608 CTR: c000000000097480 > REGS: c000000005783700 TRAP: 0300 Not tainted (5.0.0-rc1-fxb-00001-g3bd6 > MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 28000228 XER: 20 > CFAR: c0000000000a6604 DAR: 0000000000000028 DSISR: 00080000 IRQMASK: 0 > GPR00: c0000000000a6608 c000000005783990 c000000001036100 c0000007bf761860 > GPR04: 0000000000000000 c000000005783834 0000000000000000 0000000000000000 > GPR08: 69626d2c6e707500 0000000000000000 0000000000000000 9000000002001003 > GPR12: 0000000000000000 c0000007bfff8300 c000000000010450 0000000000000000 > GPR16: c000000000ced938 0000000000000100 c000000000ced948 00000000000a0000 > GPR20: 00000000000bfffe c000000000ced9a8 0000000000000200 c000000000ced978 > GPR24: 00000000006080c0 c000000716d09828 c00000002e6fd000 0000000000000000 > GPR28: c0000007bf4aff68 c0000007bf8d0080 c000000000f23938 c0000007bf761860 > NIP [c0000000000aa38c] pnv_try_setup_npu_table_group+0x1c/0x1a0 > LR [c0000000000a6608] pnv_pci_ioda_fixup+0x1f8/0x660 > Call Trace: > [c000000005783990] [c0000000000aa3d0] pnv_try_setup_npu_table_group+0x60/0x > [c0000000057839d0] [c0000000000a661c] pnv_pci_ioda_fixup+0x20c/0x660 > [c000000005783ab0] [c000000000e1d4c0] pcibios_resource_survey+0x2c8/0x31c > [c000000005783b90] [c000000000e1caf4] pcibios_init+0xb0/0xe4 > [c000000005783c10] [c000000000010054] do_one_initcall+0x64/0x264 > [c000000005783ce0] [c000000000e1132c] kernel_init_freeable+0x36c/0x468 > [c000000005783db0] [c000000000010474] kernel_init+0x2c/0x148 > [c000000005783e20] [c00000000000b794] ret_from_kernel_thread+0x5c/0x68 > > An opencapi device is using a device PE, so the current code breaks > because pe->pbus is not defined. > > More generally, there's no need to define an IOMMU group for opencapi, > as the device sends real addresses directly (admittedly, the > virtualization story is yet to be written). So let's fix it by Current plan is to go for mediated VFIO. The real HW stays under the control of the host ocxl driver, and we still don't need an IOMMU group. > skipping the IOMMU group setup for opencapi PHBs. > > Fixes: 0bd971676e68 ("powerpc/powernv/npu: Add compound IOMMU groups") > Signed-off-by: Frederic Barrat <fbarrat(a)linux.ibm.com> > --- Reviewed-by: Greg Kurz <groug(a)kaod.org> and Cc: stable(a)vger.kernel.org # v4.20 > arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c > index 1d6406a051f1..7db3119f8a5b 100644 > --- a/arch/powerpc/platforms/powernv/pci-ioda.c > +++ b/arch/powerpc/platforms/powernv/pci-ioda.c > @@ -2681,7 +2681,8 @@ static void pnv_pci_ioda_setup_iommu_api(void) > list_for_each_entry(hose, &hose_list, list_node) { > phb = hose->private_data; > > - if (phb->type == PNV_PHB_NPU_NVLINK) > + if (phb->type == PNV_PHB_NPU_NVLINK || > + phb->type == PNV_PHB_NPU_OCAPI) > continue; > > list_for_each_entry(pe, &phb->ioda.pe_list, list) {

6 years, 8 months

4
7
0 0

FAILED: patch "[PATCH] scsi: megaraid_sas: Use 63-bit DMA addressing" failed to apply to 4.20-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.20-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 894169db12463cea08d0e2a9e35f42b291340e5a Mon Sep 17 00:00:00 2001 From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Date: Tue, 18 Dec 2018 05:59:54 -0800 Subject: [PATCH] scsi: megaraid_sas: Use 63-bit DMA addressing Although MegaRAID controllers support 64-bit DMA addressing, as per hardware design, DMA address with all 64-bits set (0xFFFFFFFF-FFFFFFFF) results in a firmware fault. Driver will set 63-bit DMA mask to ensure the above address will not be used. Cc: stable(a)vger.kernel.org Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index d0f4075fe36e..f7bdd783360a 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -6184,13 +6184,13 @@ static int megasas_io_attach(struct megasas_instance *instance) * @instance: Adapter soft state * Description: * - * For Ventura, driver/FW will operate in 64bit DMA addresses. + * For Ventura, driver/FW will operate in 63bit DMA addresses. * * For invader- * By default, driver/FW will operate in 32bit DMA addresses * for consistent DMA mapping but if 32 bit consistent - * DMA mask fails, driver will try with 64 bit consistent - * mask provided FW is true 64bit DMA capable + * DMA mask fails, driver will try with 63 bit consistent + * mask provided FW is true 63bit DMA capable * * For older controllers(Thunderbolt and MFI based adapters)- * driver/FW will operate in 32 bit consistent DMA addresses. @@ -6204,14 +6204,14 @@ megasas_set_dma_mask(struct megasas_instance *instance) pdev = instance->pdev; consistent_mask = (instance->adapter_type >= VENTURA_SERIES) ? - DMA_BIT_MASK(64) : DMA_BIT_MASK(32); + DMA_BIT_MASK(63) : DMA_BIT_MASK(32); if (IS_DMA64) { - if (dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) && + if (dma_set_mask(&pdev->dev, DMA_BIT_MASK(63)) && dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32))) goto fail_set_dma_mask; - if ((*pdev->dev.dma_mask == DMA_BIT_MASK(64)) && + if ((*pdev->dev.dma_mask == DMA_BIT_MASK(63)) && (dma_set_coherent_mask(&pdev->dev, consistent_mask) && dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)))) { /* @@ -6224,7 +6224,7 @@ megasas_set_dma_mask(struct megasas_instance *instance) if (!(scratch_pad_1 & MR_CAN_HANDLE_64_BIT_DMA_OFFSET)) goto fail_set_dma_mask; else if (dma_set_mask_and_coherent(&pdev->dev, - DMA_BIT_MASK(64))) + DMA_BIT_MASK(63))) goto fail_set_dma_mask; } } else if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32))) @@ -6236,8 +6236,8 @@ megasas_set_dma_mask(struct megasas_instance *instance) instance->consistent_mask_64bit = true; dev_info(&pdev->dev, "%s bit DMA mask and %s bit consistent mask\n", - ((*pdev->dev.dma_mask == DMA_BIT_MASK(64)) ? "64" : "32"), - (instance->consistent_mask_64bit ? "64" : "32")); + ((*pdev->dev.dma_mask == DMA_BIT_MASK(64)) ? "63" : "32"), + (instance->consistent_mask_64bit ? "63" : "32")); return 0;

6 years, 8 months

1
0
0 0

Applied "regulator: max77620: Initialize values for DT properties" to the regulator tree

by Mark Brown

The patch regulator: max77620: Initialize values for DT properties has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 0ab66b3c326ef8f77dae9f528118966365757c0c Mon Sep 17 00:00:00 2001 From: Mark Zhang <markz(a)nvidia.com> Date: Thu, 10 Jan 2019 12:11:16 +0800 Subject: [PATCH] regulator: max77620: Initialize values for DT properties If regulator DT node doesn't exist, its of_parse_cb callback function isn't called. Then all values for DT properties are filled with zero. This leads to wrong register update for FPS and POK settings. Signed-off-by: Jinyoung Park <jinyoungp(a)nvidia.com> Signed-off-by: Mark Zhang <markz(a)nvidia.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- drivers/regulator/max77620-regulator.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/regulator/max77620-regulator.c b/drivers/regulator/max77620-regulator.c index b94e3a721721..cd93cf53e23c 100644 --- a/drivers/regulator/max77620-regulator.c +++ b/drivers/regulator/max77620-regulator.c @@ -1,7 +1,7 @@ /* * Maxim MAX77620 Regulator driver * - * Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved. + * Copyright (c) 2016-2018, NVIDIA CORPORATION. All rights reserved. * * Author: Mallikarjun Kasoju <mkasoju(a)nvidia.com> * Laxman Dewangan <ldewangan(a)nvidia.com> @@ -803,6 +803,14 @@ static int max77620_regulator_probe(struct platform_device *pdev) rdesc = &rinfo[id].desc; pmic->rinfo[id] = &max77620_regs_info[id]; pmic->enable_power_mode[id] = MAX77620_POWER_MODE_NORMAL; + pmic->reg_pdata[id].active_fps_src = -1; + pmic->reg_pdata[id].active_fps_pd_slot = -1; + pmic->reg_pdata[id].active_fps_pu_slot = -1; + pmic->reg_pdata[id].suspend_fps_src = -1; + pmic->reg_pdata[id].suspend_fps_pd_slot = -1; + pmic->reg_pdata[id].suspend_fps_pu_slot = -1; + pmic->reg_pdata[id].power_ok = -1; + pmic->reg_pdata[id].ramp_rate_setting = -1; ret = max77620_read_slew_rate(pmic, id); if (ret < 0) -- 2.20.1

6 years, 8 months

1
0
0 0

[PATCH] gpio: pcf857x: Fix interrupts on multiple instances

by Roger Quadros

When multiple instances of pcf857x chips are present, a fix up message [1] is printed during the probe of the 2nd and later instances. The issue is that the driver is using the same irq_chip data structure between multiple instances. Fix this by allocating the irq_chip data structure per instance. [1] fix up message addressed by this patch [ 1.212100] gpio gpiochip9: (pcf8575): detected irqchip that is shared with multiple gpiochips: please fix the driver. Cc: Stable <stable(a)vger.kernel.org> # 4.20+ Signed-off-by: Roger Quadros <rogerq(a)ti.com> --- drivers/gpio/gpio-pcf857x.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c index adf72dd..68a35b6 100644 --- a/drivers/gpio/gpio-pcf857x.c +++ b/drivers/gpio/gpio-pcf857x.c @@ -84,6 +84,7 @@ MODULE_DEVICE_TABLE(of, pcf857x_of_table); */ struct pcf857x { struct gpio_chip chip; + struct irq_chip irqchip; struct i2c_client *client; struct mutex lock; /* protect 'out' */ unsigned out; /* software latch */ @@ -252,18 +253,6 @@ static void pcf857x_irq_bus_sync_unlock(struct irq_data *data) mutex_unlock(&gpio->lock); } -static struct irq_chip pcf857x_irq_chip = { - .name = "pcf857x", - .irq_enable = pcf857x_irq_enable, - .irq_disable = pcf857x_irq_disable, - .irq_ack = noop, - .irq_mask = noop, - .irq_unmask = noop, - .irq_set_wake = pcf857x_irq_set_wake, - .irq_bus_lock = pcf857x_irq_bus_lock, - .irq_bus_sync_unlock = pcf857x_irq_bus_sync_unlock, -}; - /*-------------------------------------------------------------------------*/ static int pcf857x_probe(struct i2c_client *client, @@ -376,8 +365,17 @@ static int pcf857x_probe(struct i2c_client *client, /* Enable irqchip if we have an interrupt */ if (client->irq) { + gpio->irqchip.name = "pcf857x", + gpio->irqchip.irq_enable = pcf857x_irq_enable, + gpio->irqchip.irq_disable = pcf857x_irq_disable, + gpio->irqchip.irq_ack = noop, + gpio->irqchip.irq_mask = noop, + gpio->irqchip.irq_unmask = noop, + gpio->irqchip.irq_set_wake = pcf857x_irq_set_wake, + gpio->irqchip.irq_bus_lock = pcf857x_irq_bus_lock, + gpio->irqchip.irq_bus_sync_unlock = pcf857x_irq_bus_sync_unlock, status = gpiochip_irqchip_add_nested(&gpio->chip, - &pcf857x_irq_chip, + &gpio->irqchip, 0, handle_level_irq, IRQ_TYPE_NONE); if (status) { @@ -392,7 +390,7 @@ static int pcf857x_probe(struct i2c_client *client, if (status) goto fail; - gpiochip_set_nested_irqchip(&gpio->chip, &pcf857x_irq_chip, + gpiochip_set_nested_irqchip(&gpio->chip, &gpio->irqchip, client->irq); gpio->irq_parent = client->irq; } -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

6 years, 8 months

2
1
0 0

v4.19.14 build: 0 failures 2 warnings (v4.19.14)

by Build bot for Mark Brown

Tree/Branch: v4.19.14 Git describe: v4.19.14 Commit: f630d3cc77 Linux 4.19.14 Build Time: 124 min 43 sec Passed: 11 / 11 (100.00 %) Failed: 0 / 11 ( 0.00 %) Errors: 0 Warnings: 2 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : arm64-allmodconfig 1 warnings 0 mismatches : arm-allmodconfig ------------------------------------------------------------------------------- Warnings Summary: 2 1 ../drivers/staging/erofs/unzip_vle.c:186:29: warning: array subscript is above array bounds [-Warray-bounds] 1 ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] ------------------------------------------------------------------------------- arm-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/staging/erofs/unzip_vle.c:186:29: warning: array subscript is above array bounds [-Warray-bounds] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig x86_64-allmodconfig arm64-defconfig

6 years, 8 months

1
0
0 0

[PATCH] arm64: dts: allwinner: a64: Fix USB OTG regulator

by Jernej Skrabec

Currently, AXP803 driver assumes that reg_drivevbus is input which is wrong. Unfortunate consequence of that is that none of the USB ports work on the board, even USB HOST port, because USB PHY driver probing fails due to missing regulator. Fix that by adding "x-powers,drive-vbus-en" property to AXP803 node. Fixes: 14ff5d8f9151 ("arm64: dts: allwinner: a64: Orange Pi Win: Enable USB OTG socket") Cc: stable(a)vger.kernel.org Signed-off-by: Jernej Skrabec <jernej.skrabec(a)siol.net> --- arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts index b0c64f75792c..8974b5a1d3b1 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts @@ -188,6 +188,7 @@ reg = <0x3a3>; interrupt-parent = <&r_intc>; interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */ }; }; -- 2.20.1

6 years, 8 months

2
1
0 0

stable-rc/linux-4.4.y boot: 83 boots: 2 failed, 81 passed (v4.4.169)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 83 boots: 2 failed, 81 passed (v4.4.169) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.169/ Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.169 Git Commit: ba0da581b466dcd333eeb326919a698116926258 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 42 unique boards, 19 SoC families, 12 builds out of 187 Boot Failures Detected: arm: multi_v7_defconfig stih410-b2120: 1 failed lab arm64: defconfig qcom-qdf2400: 1 failed lab --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror