[linux-yocto]: [kernel v5.15]: arch: arm64: dts: remove the dts file with license limitation

2023-10-23 Thread Meng Li via lists.yoctoproject.org
From: Limeng 

Hi Bruce,

This patch is used to remove the dts file with license limitation
Could you please help to merge this patch into linux-yocto kernel, v5.15, 2 
branches as below?
v5.15/standard/bcm-2xxx-rpi
v5.15/standard/preempt-rt/bcm-2xxx-rpi

diffstat info as below.

 arch/arm/boot/dts/overlays/gc9a01-overlay.dts |  151 
---
 b/arch/arm/boot/dts/overlays/Makefile |1
 b/arch/arm/boot/dts/overlays/README   |   20 --
 3 files changed, 172 deletions(-)


thanks,
Limeng

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13227): 
https://lists.yoctoproject.org/g/linux-yocto/message/13227
Mute This Topic: https://lists.yoctoproject.org/mt/102152544/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto] [PATCH] arch: arm64: dts: remove the dts file with license limitation

2023-10-23 Thread Meng Li via lists.yoctoproject.org
Signed-off-by: Meng Li 
---
 arch/arm/boot/dts/overlays/Makefile   |   1 -
 arch/arm/boot/dts/overlays/README |  20 ---
 arch/arm/boot/dts/overlays/gc9a01-overlay.dts | 151 --
 3 files changed, 172 deletions(-)
 delete mode 100644 arch/arm/boot/dts/overlays/gc9a01-overlay.dts

diff --git a/arch/arm/boot/dts/overlays/Makefile 
b/arch/arm/boot/dts/overlays/Makefile
index 4bbe05ed9760..6cf9cd80a5a2 100644
--- a/arch/arm/boot/dts/overlays/Makefile
+++ b/arch/arm/boot/dts/overlays/Makefile
@@ -60,7 +60,6 @@ dtbo-$(CONFIG_ARCH_BCM2835) += \
fbtft.dtbo \
fe-pi-audio.dtbo \
fsm-demo.dtbo \
-   gc9a01.dtbo \
ghost-amp.dtbo \
goodix.dtbo \
googlevoicehat-soundcard.dtbo \
diff --git a/arch/arm/boot/dts/overlays/README 
b/arch/arm/boot/dts/overlays/README
index 3152c2354670..0debfaa70285 100644
--- a/arch/arm/boot/dts/overlays/README
+++ b/arch/arm/boot/dts/overlays/README
@@ -1127,26 +1127,6 @@ Load:   dtoverlay=fsm-demo,=
 Params: fsm_debug   Enable debug logging (default off)
 
 
-Name:   gc9a01
-Info:   Enables GalaxyCore's GC9A01 single chip driver based displays on
-SPI0 as fb1, using GPIOs DC=25, RST=27 and BL=18 (physical
-GPIO header pins 22, 13 and 12 respectively) in addition to the
-SPI0 pins DIN=10, CLK=11 and CS=8 (physical GPIO header pins 19,
-23 and 24 respectively).
-Load:   dtoverlay=gc9a01,=
-Params: speed   Display SPI bus speed
-
-rotate  Display rotation {0,90,180,270}
-
-width   Width of the display
-
-height  Height of the display
-
-fps Delay between frame updates
-
-debug   Debug output level {0-7}
-
-
 Name:   ghost-amp
 Info:   An overlay for the Ghost amplifier.
 Load:   dtoverlay=ghost-amp,=
diff --git a/arch/arm/boot/dts/overlays/gc9a01-overlay.dts 
b/arch/arm/boot/dts/overlays/gc9a01-overlay.dts
deleted file mode 100644
index 3d31030c5564..
--- a/arch/arm/boot/dts/overlays/gc9a01-overlay.dts
+++ /dev/null
@@ -1,151 +0,0 @@
-/*
-Device Tree overlay for Galaxycore GC9A01A single chip driver
-for use on SPI TFT LCD, 240x240 65K RGB
-Based on Galaxycore's GC9A01A datasheet Rev.1.0 (2019/07/02)
-Copyright (C) 2022, Julianno F. C. Silva (@juliannojungle)
-
-This program is free software: you can redistribute it and/or modify
-it under the terms of the GNU Affero General Public License as published
-by the Free Software Foundation, either version 3 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU Affero General Public License for more details.
-
-You should have received a copy of the GNU Affero General Public License
-along with this program.  If not, see 
.
-
-Init sequence partially based on Waveshare team's Arduino LCD_Driver V1.0 
(2020/12/09).
-
-Permission is hereby granted, free of UBYTEge, to any person obtaining a 
copy
-of this software and associated documnetation files (the "Software"), to 
deal
-in the Software without restriction, including without limitation the 
rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
- */
-
-/dts-v1/;
-/plugin/;
-
-/ {
-compatible = "brcm,bcm2835";
-
-fragment@0 {
-target = <>;
-__overlay__ {
-status = "disabled";
-};
-};
-
-fragment@1 {
-target = <>;
-__overlay__ {
-gc9a01_pins: gc9a01_pins {
-brcm,pins = <25 27>;
-brcm,function = <1 1>; /* out */
-brcm,pull = <0 0>; /* none */
-};
-};
-};
-
-fragment@2 {
-target = <>;
-__overlay__ {
-/* needed to avoid dtc warning */
-#address-cells = <1>;
-#size-cells = <0>;
-status = "okay";
-
-gc9a01: gc9a01@0 {
-compatible = "ilitek,ili9340";
-reg = <0>;
-pinctrl-names = "default";
-pinctrl-0 = <_pins>;
-reset-gpios = < 27 1>;
-dc-gpios = < 25 0>;
-led-gpios = < 18 0>;
-spi-max-frequency = <4000>;
-buswidth = <8>;
-width = <240>;
-height = <240>;
-rotate = <0>;
-fps = <50>;

[linux-yocto][yocto-kernel-cache][yocto-6.1][PATCH 1/2] axxiaarm/axxiaarm64: enable axxiaarm and axxiaarm64 in 6.1 kernel

2023-10-23 Thread LiweiSong via lists.yoctoproject.org
This patch is to enable axxiaarm and axxiaarm64 support in 6.1 kernel
to support board AXM55XX and AXM56XX.

Signed-off-by: Liwei Song 
---
 bsp/axxiaarm/axxia-common.cfg|  98 +
 bsp/axxiaarm/axxiaarm-preempt-rt.scc |   7 ++
 bsp/axxiaarm/axxiaarm-standard.scc   |   7 ++
 bsp/axxiaarm/axxiaarm.cfg| 107 +++
 bsp/axxiaarm/axxiaarm.scc|  12 +++
 bsp/axxiaarm/edac.cfg|  17 
 bsp/axxiaarm/edac.scc|   4 +
 bsp/axxiaarm/rapidio.cfg |  26 ++
 bsp/axxiaarm/rapidio.scc |   4 +
 bsp/axxiaarm64/axxiaarm64-preempt-rt.scc |   7 ++
 bsp/axxiaarm64/axxiaarm64-standard.scc   |   7 ++
 bsp/axxiaarm64/axxiaarm64.cfg|  88 +++
 bsp/axxiaarm64/axxiaarm64.scc|  10 +++
 bsp/axxiaarm64/edac.cfg  |  18 
 bsp/axxiaarm64/edac.scc  |   4 +
 15 files changed, 416 insertions(+)
 create mode 100644 bsp/axxiaarm/axxia-common.cfg
 create mode 100644 bsp/axxiaarm/axxiaarm-preempt-rt.scc
 create mode 100644 bsp/axxiaarm/axxiaarm-standard.scc
 create mode 100644 bsp/axxiaarm/axxiaarm.cfg
 create mode 100644 bsp/axxiaarm/axxiaarm.scc
 create mode 100644 bsp/axxiaarm/edac.cfg
 create mode 100644 bsp/axxiaarm/edac.scc
 create mode 100644 bsp/axxiaarm/rapidio.cfg
 create mode 100644 bsp/axxiaarm/rapidio.scc
 create mode 100644 bsp/axxiaarm64/axxiaarm64-preempt-rt.scc
 create mode 100644 bsp/axxiaarm64/axxiaarm64-standard.scc
 create mode 100644 bsp/axxiaarm64/axxiaarm64.cfg
 create mode 100644 bsp/axxiaarm64/axxiaarm64.scc
 create mode 100644 bsp/axxiaarm64/edac.cfg
 create mode 100644 bsp/axxiaarm64/edac.scc

diff --git a/bsp/axxiaarm/axxia-common.cfg b/bsp/axxiaarm/axxia-common.cfg
new file mode 100644
index ..8d311914a36e
--- /dev/null
+++ b/bsp/axxiaarm/axxia-common.cfg
@@ -0,0 +1,98 @@
+CONFIG_ARCH_AXXIA=y
+CONFIG_PHYS_ADDR_T_64BIT=y
+CONFIG_ARCH_DMA_ADDR_T_64BIT=y
+CONFIG_ARM_ARCH_TIMER=y
+CONFIG_PROFILING=y
+
+#
+# Bus support
+#
+CONFIG_ARM_AMBA=y
+CONFIG_PCI=y
+CONFIG_PCI_DOMAINS=y
+CONFIG_PCI_SYSCALL=y
+CONFIG_PCI_MSI=y
+
+
+CONFIG_MTD=y
+CONFIG_MTD_OF_PARTS=y
+#
+# Self-contained MTD device drivers
+#
+CONFIG_MTD_SPI_NOR=y
+
+#
+# Generic Driver Options
+#
+CONFIG_FW_LOADER=y
+CONFIG_REGMAP=y
+CONFIG_REGMAP_MMIO=y
+
+
+#
+# Misc devices
+#
+CONFIG_AXXIA_MTC=y
+CONFIG_ARCH_AXXIA_NCR_RESET_CHECK=y
+CONFIG_AXXIA_NCR=y
+CONFIG_AXXIA_FAULT=y
+CONFIG_AXXIA_MDIO=y
+
+#
+# Non-8250 serial port support
+#
+CONFIG_SERIAL_AMBA_PL011=y
+CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_HW_RANDOM=y
+CONFIG_HW_RANDOM_AXXIA=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MUX=y
+CONFIG_I2C_AXXIA=y
+
+CONFIG_SPI=y
+CONFIG_SPI_PL022=y
+CONFIG_SPI_SPIDEV=y
+
+CONFIG_ATA=y
+#
+# Hardware I/O ports
+#
+CONFIG_SERIO_AMBAKMI=y
+
+#
+# EEPROM support
+#
+CONFIG_EEPROM_AT24=y
+
+#
+# MMC/SD/SDIO Card Drivers
+#
+CONFIG_MMC=y
+CONFIG_MMC_ARMMMCI=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SPI=y
+
+#
+# DMA Devices
+#
+CONFIG_DMADEVICES=y
+CONFIG_AXXIA_DMA=y
+
+#
+# Multifunction device drivers
+#
+CONFIG_MFD_SYSCON=y
+
+#
+# Memory mapped GPIO drivers:
+#
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_AXXIA=y
+CONFIG_GPIO_GENERIC_PLATFORM=y
+
+#
+# Sensors
+#
+CONFIG_SENSORS_ADT7475=y
diff --git a/bsp/axxiaarm/axxiaarm-preempt-rt.scc 
b/bsp/axxiaarm/axxiaarm-preempt-rt.scc
new file mode 100644
index ..642936478445
--- /dev/null
+++ b/bsp/axxiaarm/axxiaarm-preempt-rt.scc
@@ -0,0 +1,7 @@
+define KMACHINE axxiaarm
+define KTYPE preempt-rt
+define KARCH arm
+
+include ktypes/preempt-rt
+
+include axxiaarm.scc
diff --git a/bsp/axxiaarm/axxiaarm-standard.scc 
b/bsp/axxiaarm/axxiaarm-standard.scc
new file mode 100644
index ..a18c4eb78881
--- /dev/null
+++ b/bsp/axxiaarm/axxiaarm-standard.scc
@@ -0,0 +1,7 @@
+define KMACHINE axxiaarm
+define KTYPE standard
+define KARCH arm
+
+include ktypes/standard
+
+include axxiaarm.scc
diff --git a/bsp/axxiaarm/axxiaarm.cfg b/bsp/axxiaarm/axxiaarm.cfg
new file mode 100644
index ..cfdb9eda5ad3
--- /dev/null
+++ b/bsp/axxiaarm/axxiaarm.cfg
@@ -0,0 +1,107 @@
+#.
+#WARNING
+#
+# This file is a kernel configuration fragment, and not a full kernel
+# configuration file.  The final kernel configuration is made up of
+# an assembly of processed fragments, each of which is designed to
+# capture a specific part of the final configuration (e.g. platform
+# configuration, feature configuration, and board specific hardware
+# configuration).  For more information on kernel configuration, please
+# consult the product documentation.
+#
+#.
+
+#
+# Axxia platform type
+#
+CONFIG_ARCH_AXXIA_GIC=y
+CONFIG_ARCH_AXXIA_DT=y
+CONFIG_ARM_TIMER_SP804=y
+
+#
+# Processor Features
+#

[linux-yocto][linux-yocto v6.1][PATCH 0/2] Enable support for AXM55/56XX

2023-10-23 Thread LiweiSong via lists.yoctoproject.org
Hi Bruce,

This pull is to enable support for board AXM55XX/56XX, because the SDK
isn't updated since 5.10, all these patches are from linux-yocto-5.15
Both standard and rt kernel are well tested againest 6.1, boot well and no
obvious error.

There are two parts, kernel-cache and kernel patches, could you help
merge those two kernel-cache patches to yocto-kernel-cache yocto-6.1 branch?

And create two branches as below, and merge those kernel patches to them?

  v6.1/standard/sdkv5.10/axxia
  v6.1/standard/preempt-rt/sdkv5.10/axxia


Thanks,
Liwei.


The following changes since commit 8a449d3428e673be0bdb504dadb666b4ad7208e3:

  Merge tag 'v6.1.57' into v6.1/standard/base (2023-10-11 19:03:27 -0400)

are available in the Git repository at:

  https://github.com/2005songliwei/linux-yocto-pull.git pull-lts23-axxia-231024

for you to fetch changes up to 98ce09bde229d5c24b371beb1f9514f0f098ac6e:

  arm-ccn: use platform_get_irq to get IRQ (2023-10-24 02:57:01 +)


Charlie Paul (6):
  genirq/cpuhotplug: axxia: Enable the force flag
  ARM: dts: axxia: Updated SPI and UART to support DMA
  usb: dwc3: axxia: Add support the core clocks
  spi: pl022: Add enable-dma processing
  net: Use standard MDIO interface for AXXIA FEMAC Driver
  net: ethernet: Add ethtool Stats to NEMAC driver

Daniel Dragomir (3):
  ARM: smp: handle "pen_release" removal
  ARM: mmc: Remove unsupported pdata GPIO numbers
  axxia-mtc: Export MTC ioctl interface to UAPI

David Mercado (1):
  genirq: axxia: Fix irq_set_affinity to allow use with buslocks

Fredrik Gustavsson (1):
  axxia: Fixed Kconfig dependencies betwen PCIe, PEI and NCR

Fredrik Markstrom (2):
  ARM: axxia: Make the dma-zone the full 4G
  ARM: axxia: Enabled ddr retention on all axm5516

John Jacques (50):
  ARM: Enhance platform support for Intel Axxia AXM55xx
  ARM: dts: Add Axxia AXM55xx device tree files
  ARM: head.S: axxia: Set the NS bit since memory is non-secure
  ARM: kmap: axxia: Prevent overlap for 16th core
  ARM64: dts: Add Axxia X9/AXM56xx and XLF/AXC67xx device tree files
  clk: Change Clock Definitions for Axxia AXM55xx
  dt-bindings: clock: remove deprecated LSI AXM5516 clock bindings
  char: hwrng: Add Axxia HW Random number generator
  dmaengine: Add Axxia DMA32 driver support
  edac: Add Axxia Error Detection & Correction support
  gpio: Add custom driver for Axxia SoCs
  gpio: pl061: Readd removed platform data
  misc: Add drivers for Axxia MISC devices
  misc: Add a backward compatibility layer for Axxia MTC
  rapidio: Add support for Axxia AXM55xx and AXM56xx
  power: reset: Add support for Axxia DDR Retention reset
  usb: xhci: Add CI13612A USB driver for Axxia AXM55xx
  usb: dwc3: Add Axxia xHCI DWC3 USB support
  usb: hub: fix over-current race condition
  mtd: spi-nor: add support for Spansion S25FL016K
  net: ethernet: Add Intel Axxia FEMAC driver
  net: ethernet: Add Intel Axxia NEMAC GigE driver
  i2c: axxia: Use BIT(x) macro and fix indentation issues
  tty: serial: pl011: Updated Baud Rate Calcualtion
  pmu: Fix Compiler Warnings
  dt-bindings: axxia: update documentation and convert to yaml
  ARM64: dts: Add Reference to the L2 Cache in CPU Descriptions
  net: Pad SKBs Properly in the AXXIA FEMAC Driver
  net: Use eth_spb_pad() in the AXXIA NEMAC Driver
  net: Set Min/Max MTU for AXXIA 5500 FEMAC Driver
  net: Set Min/Max MTU for AXXIA 5600/6700 NEMAC Driver
  power: reset: Update Axxia DDR Retention Handling
  misc: axxia: Use the new ARM SMC Call Interface
  misc: axxia: Update OEM Handling for backwards compatibility
  i2c: axxia: Add a Lock Around i2c Transfers
  i2c: axxia: Allow Interrupted Transfers
  i2c: axxia: Change the I2C Timeout
  misc: Add a Lock to the Axxia MDIO Bus
  arm: perf: add Cortex-A15 PMU in armv7_pmu_probe_table
  net: ethernet: Clean Up Intel Axxia FEMAC driver
  usb: xhci: Add HCD_DMA flag to CI13612A USB driver
  drivers/watchdog: Check Return Value
  arm-ccn: Check Return Values
  net: Clean Up PHY Handling in Axxia FEMAC
  net: Add Padding for Alignment in Axxia FEMAC
  net: Associate the SKB with the Driver Axxia ACP
  net: Add Tracepoints to the Axxia FEMAC Driver
  ARM: head.S: axxia: Fix Rebase Error
  net: Handle Error in Axxia FEMAC
  net: Add support for "promiscous mode" to Axxia FEMAC

Liwei Song (3):
  Revert "ARM: 9060/1: kexec: Remove unused kexec_reinit callback"
  axxia: use udelay instead of usleep in cpuhotplug routine
  arm-ccn: use platform_get_irq to get IRQ

Marek Bykowski (6):
  firmware: arch64: Add SMC call testing module
  perf: arm-ccn: Allow instrumentation of arm-ccn
  ARM64: dts: axxia: Support CCN (cache coherent network) perf
  edac: axxia: 

[linux-yocto][yocto-kernel-cache][yocto-6.1][PATCH 2/2] axxiaarm: disable CONFIG_KFENCE for axm55xx board

2023-10-23 Thread LiweiSong via lists.yoctoproject.org
CONFIG_KFENCE was enabled by default since kernel 5.17, with this
option enabled, some AXM55xx boards may hang during boot,  disable
it as a temporarily workaround to avoid board hang.

Signed-off-by: Liwei Song 
---
 bsp/axxiaarm/axxiaarm.cfg | 5 +
 1 file changed, 5 insertions(+)

diff --git a/bsp/axxiaarm/axxiaarm.cfg b/bsp/axxiaarm/axxiaarm.cfg
index cfdb9eda5ad3..89f4e1597d1c 100644
--- a/bsp/axxiaarm/axxiaarm.cfg
+++ b/bsp/axxiaarm/axxiaarm.cfg
@@ -105,3 +105,8 @@ CONFIG_PL330_DMA=y
 #
 CONFIG_MAILBOX=y
 CONFIG_PL320_MBOX=y
+
+#
+# Memory Debugging
+#
+CONFIG_KFENCE=n
-- 
2.40.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13226): 
https://lists.yoctoproject.org/g/linux-yocto/message/13226
Mute This Topic: https://lists.yoctoproject.org/mt/102151562/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto][v6.1/standard/nxp-sdk-6.1/nxp-soc & v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc][PATCH] gpu: imx: dpu: Use raw_spin_lock instead of mutex_lock

2023-10-23 Thread Bruce Ashfield
merged.

Bruce

In message: [linux-yocto][v6.1/standard/nxp-sdk-6.1/nxp-soc & 
v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc][PATCH] gpu: imx: dpu: Use 
raw_spin_lock instead of mutex_lock
on 23/10/2023 Xiaolei Wang wrote:

> For Atomic Mode Setting, it is safer to use raw spin lock.
> Mutex may cause scheduling, which avoids the following warning.
> 
> BUG: sleeping function called from invalid context at 
> kernel/locking/mutex.c:283
> in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 191, name: 
> kworker/5:13
> preempt_count: 1, expected: 0
> RCU nest depth: 0, expected: 0
> Preemption disabled at:
> ] dpu_crtc_atomic_flush+0x364/0x62c
>  CPU: 5 PID: 191 Comm: kworker/5:13 Tainted: GWC 
> 6.1.30-yocto-standard #1
>  Hardware name: Freescale i.MX8QM MEK (DT)
>  Workqueue: events drm_mode_rmfb_work_fn
>  Call trace:
>  dump_backtrace.part.0+0xc8/0xd4
>  show_stack+0x20/0x30
>  dump_stack_lvl+0x6c/0x88
>  dump_stack+0x18/0x34
>  __might_resched+0x154/0x1c0
>  __might_sleep+0x54/0xa4
>  mutex_lock+0x2c/0x80
>  fetchunit_is_enabled+0x28/0x70
>  dpu_crtc_atomic_flush+0x198/0x62c
>  drm_atomic_helper_commit_planes+0x158/0x220
>  drm_atomic_helper_commit_tail+0x5c/0xb0
>  commit_tail+0x130/0x17c
>  drm_atomic_helper_commit+0x14c/0x180
>  drm_atomic_commit+0xb0/0xf0
>  drm_framebuffer_remove+0x468/0x4fc
>  drm_mode_rmfb_work_fn+0x84/0xb0
>  process_one_work+0x1f8/0x480
>  worker_thread+0x238/0x450
>  kthread+0x108/0x114
>  ret_from_fork+0x10/0x20
> 
> Signed-off-by: Xiaolei Wang 
> ---
>  drivers/gpu/imx/dpu/dpu-fetchdecode.c | 94 +--
>  drivers/gpu/imx/dpu/dpu-fetcheco.c| 56 
>  drivers/gpu/imx/dpu/dpu-fetchlayer.c  | 48 +++---
>  drivers/gpu/imx/dpu/dpu-fetchunit.c   | 44 ++---
>  drivers/gpu/imx/dpu/dpu-fetchwarp.c   | 48 +++---
>  include/video/dpu.h   |  2 +-
>  6 files changed, 146 insertions(+), 146 deletions(-)
> 
> diff --git a/drivers/gpu/imx/dpu/dpu-fetchdecode.c 
> b/drivers/gpu/imx/dpu/dpu-fetchdecode.c
> index 66d5862fbfa1..cacf3124c7fe 100644
> --- a/drivers/gpu/imx/dpu/dpu-fetchdecode.c
> +++ b/drivers/gpu/imx/dpu/dpu-fetchdecode.c
> @@ -79,15 +79,15 @@ int fetchdecode_pixengcfg_dynamic_src_sel(struct 
> dpu_fetchunit *fu,
>  {
>   int i;
>  
> - mutex_lock(>mutex);
> + raw_spin_lock(>lock);
>   for (i = 0; i < 4; i++) {
>   if (fd_srcs[fu->id][i] == src) {
>   dpu_pec_fu_write(fu, PIXENGCFG_DYNAMIC, src);
> - mutex_unlock(>mutex);
> + raw_spin_unlock(>lock);
>   return 0;
>   }
>   }
> - mutex_unlock(>mutex);
> + raw_spin_unlock(>lock);
>  
>   return -EINVAL;
>  }
> @@ -116,21 +116,21 @@ fetchdecode_set_baseaddress(struct dpu_fetchunit *fu, 
> unsigned int width,
>   baddr += (dma_addr_t)(y_offset % mt_h) * stride;
>   }
>  
> - mutex_lock(>mutex);
> + raw_spin_lock(>lock);
>   dpu_fu_write(fu, BASEADDRESS0, baddr);
> - mutex_unlock(>mutex);
> + raw_spin_unlock(>lock);
>  }
>  
>  static void fetchdecode_set_src_bpp(struct dpu_fetchunit *fu, int bpp)
>  {
>   u32 val;
>  
> - mutex_lock(>mutex);
> + raw_spin_lock(>lock);
>   val = dpu_fu_read(fu, SOURCEBUFFERATTRIBUTES0);
>   val &= ~0x3f;
>   val |= BITSPERPIXEL(bpp);
>   dpu_fu_write(fu, SOURCEBUFFERATTRIBUTES0, val);
> - mutex_unlock(>mutex);
> + raw_spin_unlock(>lock);
>  }
>  
>  static void
> @@ -155,12 +155,12 @@ fetchdecode_set_src_stride(struct dpu_fetchunit *fu,
> baddr, nonzero_mod);
>   }
>  
> - mutex_lock(>mutex);
> + raw_spin_lock(>lock);
>   val = dpu_fu_read(fu, SOURCEBUFFERATTRIBUTES0);
>   val &= ~0x;
>   val |= STRIDE(stride);
>   dpu_fu_write(fu, SOURCEBUFFERATTRIBUTES0, val);
> - mutex_unlock(>mutex);
> + raw_spin_unlock(>lock);
>  }
>  
>  static void
> @@ -175,9 +175,9 @@ fetchdecode_set_src_buf_dimensions(struct dpu_fetchunit 
> *fu,
>  
>   val = LINEWIDTH(w) | LINECOUNT(h);
>  
> - mutex_lock(>mutex);
> + raw_spin_lock(>lock);
>   dpu_fu_write(fu, SOURCEBUFFERDIMENSION0, val);
> - mutex_unlock(>mutex);
> + raw_spin_unlock(>lock);
>  }
>  
>  static void fetchdecode_set_fmt(struct dpu_fetchunit *fu,
> @@ -224,7 +224,7 @@ static void fetchdecode_set_fmt(struct dpu_fetchunit *fu,
>   break;
>   }
>  
> - mutex_lock(>mutex);
> + raw_spin_lock(>lock);
>   val = dpu_fu_read(fu, CONTROL);
>   val &= ~YUV422UPSAMPLINGMODE_MASK;
>   val &= ~INPUTSELECT_MASK;
> @@ -258,7 +258,7 @@ static void fetchdecode_set_fmt(struct dpu_fetchunit *fu,
>   val |= YUVCONVERSIONMODE(YUVCONVERSIONMODE__OFF);
>   }
>   dpu_fu_write(fu, LAYERPROPERTY0, val);
> - mutex_unlock(>mutex);
> + raw_spin_unlock(>lock);
>  
>   for (i = 0; i < 

Re: [yocto] Clang LLVM do_package strip error

2023-10-23 Thread Khem Raj
On Mon, Oct 23, 2023 at 9:29 AM Martin Townsend  wrote:
>
> Hi,
>
> I've updated the project I'm working on to kirkstone and using GCC it
> is working.  We want to move to Clang but I've seen a couple of
> recipes fail in do_package with a similar error.  Here is the output
> for runc-opencontainers, the package tini has something similar
>
>
> ERROR: runc-opencontainers-1.1.4+gitAUTOINC+974efd2dfc-r0 do_package:
> Fatal errors occurred in subprocesses:
> Command '['aarch64-poky-linux-llvm-objcopy', '--only-keep-debug',
> '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/runc',
> '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/.debug/runc']'
> returned non-zero exit status 1.
> Subprocess output:aarch64-poky-linux-llvm-objcopy: error: Link field
> value 47 in section .rela.plt is not a symbol table
>

Its using clang and also binutils from llvm here and there has been
many fixes we had done to llvm
tools and things are better with clang 17, but since you are on
kirkstone, you might be using older clang
and llvm. So you can try if master branch solves the problem and maybe
next LTS you are set other
option which might be immediately useful would be to fall back to
using objcopy from binutils which you
can do via something like below in site.conf

 OBJCOPY:pn-runc-opencontainers:toolchain-clang = "${HOST_PREFIX}objcopy"


> ERROR: Logfile of failure stored in:
> /ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/temp/log.do_package.2936320
> ERROR: Task 
> (/ws/extra/octopus/octave-kirkstone/build-cad-devel/../sources/meta-virtualization/recipes-containers/runc/runc-opencontainers_git.bb:do_package)
> failed with exit code '1'
> Pseudo log:
> inode mismatch:
> '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/image/usr/bin/docker-runc'
> ino 84410787 in db, 84431171 in request.
> Setup complete, sending SIGUSR1 to pid 2936321.
>
> I'm sure these used to compile with Clang in dunfell so could this be
> a toolchain problem?
>
> I'm using the kirkstone branch of meta-clang and have the following in
> my distro conf
> PREFERRED_PROVIDER_llvm = "clang"
> PREFERRED_PROVIDER_llvm-native = "clang-native"
> PREFERRED_PROVIDER_nativesdk-llvm = "nativesdk-clang"
> PROVIDES:pn-clang = "llvm"
> PROVIDES:pn-clang-native = "llvm-native"
> PROVIDES:pn-nativesdk-clang = "nativesdk-llvm"
>
> and this in local.conf
>
> TOOLCHAIN ?= "clang"
> RUNTIME ?= "llvm"
>
> I notice there is a kirkstone-clang12 branch in meta-clang, should I
> be using this?
> If not, any help in debugging this would be appreciated.
>
> Cheers,
> Martin.
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61460): https://lists.yoctoproject.org/g/yocto/message/61460
Mute This Topic: https://lists.yoctoproject.org/mt/102139152/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Clang LLVM do_package strip error

2023-10-23 Thread Martin Townsend
Hi,

I've updated the project I'm working on to kirkstone and using GCC it
is working.  We want to move to Clang but I've seen a couple of
recipes fail in do_package with a similar error.  Here is the output
for runc-opencontainers, the package tini has something similar


ERROR: runc-opencontainers-1.1.4+gitAUTOINC+974efd2dfc-r0 do_package:
Fatal errors occurred in subprocesses:
Command '['aarch64-poky-linux-llvm-objcopy', '--only-keep-debug',
'/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/runc',
'/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/.debug/runc']'
returned non-zero exit status 1.
Subprocess output:aarch64-poky-linux-llvm-objcopy: error: Link field
value 47 in section .rela.plt is not a symbol table

ERROR: Logfile of failure stored in:
/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/temp/log.do_package.2936320
ERROR: Task 
(/ws/extra/octopus/octave-kirkstone/build-cad-devel/../sources/meta-virtualization/recipes-containers/runc/runc-opencontainers_git.bb:do_package)
failed with exit code '1'
Pseudo log:
inode mismatch:
'/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/image/usr/bin/docker-runc'
ino 84410787 in db, 84431171 in request.
Setup complete, sending SIGUSR1 to pid 2936321.

I'm sure these used to compile with Clang in dunfell so could this be
a toolchain problem?

I'm using the kirkstone branch of meta-clang and have the following in
my distro conf
PREFERRED_PROVIDER_llvm = "clang"
PREFERRED_PROVIDER_llvm-native = "clang-native"
PREFERRED_PROVIDER_nativesdk-llvm = "nativesdk-clang"
PROVIDES:pn-clang = "llvm"
PROVIDES:pn-clang-native = "llvm-native"
PROVIDES:pn-nativesdk-clang = "nativesdk-llvm"

and this in local.conf

TOOLCHAIN ?= "clang"
RUNTIME ?= "llvm"

I notice there is a kirkstone-clang12 branch in meta-clang, should I
be using this?
If not, any help in debugging this would be appreciated.

Cheers,
Martin.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61459): https://lists.yoctoproject.org/g/yocto/message/61459
Mute This Topic: https://lists.yoctoproject.org/mt/102139152/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [yocto-autobuilder-helper] [PATCH 3/5] metrics: Pass branchname to scripts

2023-10-23 Thread Richard Purdie
To prepapre to run the scripts per branch, pass the branchname to the scripts.

Signed-off-by: Richard Purdie 
---
 config.json  | 4 ++--
 scripts/run-cvecheck | 1 +
 scripts/run-patchmetrics | 1 +
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index f225148..0c35632 100644
--- a/config.json
+++ b/config.json
@@ -1209,11 +1209,11 @@
 ],
 "step1" : {
 "shortname" : "Generating patch metrics",
-"EXTRACMDS" : 
["../../yocto-autobuilder-helper/scripts/run-patchmetrics ../ ../meta/ 
${HELPERRESULTSDIR}/../../patchmetrics ."]
+"EXTRACMDS" : 
["../../yocto-autobuilder-helper/scripts/run-patchmetrics ../ ../meta/ 
${HELPERRESULTSDIR}/../../patchmetrics . ${HELPERBRANCHNAME}"]
 },
 "step2" : {
 "shortname" : "Running CVE checks",
-"EXTRACMDS" : 
["../../yocto-autobuilder-helper/scripts/run-cvecheck ../ ../meta/ 
${HELPERRESULTSDIR}/../../patchmetrics ."]
+"EXTRACMDS" : 
["../../yocto-autobuilder-helper/scripts/run-cvecheck ../ ../meta/ 
${HELPERRESULTSDIR}/../../patchmetrics . ${HELPERBRANCHNAME}"]
 }
 
 },
diff --git a/scripts/run-cvecheck b/scripts/run-cvecheck
index 35c796b..d48fd68 100755
--- a/scripts/run-cvecheck
+++ b/scripts/run-cvecheck
@@ -6,6 +6,7 @@ PARENTDIR=`realpath $1`
 TARGETDIR=`realpath $2`
 RESULTSDIR=`realpath -m $3`
 BUILDDIR=`realpath $4`
+BRANCH=$5
 OURDIR=`dirname $0`
 
 TIMESTAMP=`date +"%s"`
diff --git a/scripts/run-patchmetrics b/scripts/run-patchmetrics
index e45d463..20e6268 100755
--- a/scripts/run-patchmetrics
+++ b/scripts/run-patchmetrics
@@ -6,6 +6,7 @@ PARENTDIR=`realpath $1`
 TARGETDIR=`realpath $2`
 RESULTSDIR=`realpath -m $3`
 BUILDDIR=`realpath $4`
+BRANCH=$5
 OURDIR=`dirname $0`
 
 TIMESTAMP=`date +"%s"`
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61456): https://lists.yoctoproject.org/g/yocto/message/61456
Mute This Topic: https://lists.yoctoproject.org/mt/102138010/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [yocto-autobuilder-helper] [PATCH 5/5] scripts/run-cvecheck: Remove branch iteration

2023-10-23 Thread Richard Purdie
Rather than running multiple checkouts, lets move this to the autobuilder
to handle and have it trigger the builds with the right checkouts.

Signed-off-by: Richard Purdie 
---
 scripts/run-cvecheck | 52 
 1 file changed, 23 insertions(+), 29 deletions(-)

diff --git a/scripts/run-cvecheck b/scripts/run-cvecheck
index d48fd68..6294fe6 100755
--- a/scripts/run-cvecheck
+++ b/scripts/run-cvecheck
@@ -22,34 +22,28 @@ if [ ! -d $RESULTSDIR ]; then
 mkdir $RESULTSDIR
 fi
 
-for branch in master mickledore langdale kirkstone dunfell; do
-mkdir -p $PARENTDIR/yocto-metrics/cve-check/$branch/
-git -C $PARENTDIR reset origin/$branch --hard
-rm conf/local.conf
-rm conf/bblayers.conf
-rm -f conf/templateconf.cfg
-rm tmp/ -rf
-unset BB_ENV_PASSTHROUGH_ADDITIONS
-unset BB_ENV_EXTRAWHITE
-cd ..
-. oe-init-build-env build
-bitbake world --runall cve_check -R 
conf/distro/include/cve-extra-exclusions.inc
-if [ -e tmp/log/cve/cve-summary.json ]; then
-git -C $PARENTDIR/yocto-metrics rm cve-check/$branch/*.json
-mkdir -p $PARENTDIR/yocto-metrics/cve-check/$branch
-cp tmp/log/cve/cve-summary.json 
$PARENTDIR/yocto-metrics/cve-check/$branch/$TIMESTAMP.json
-git -C $PARENTDIR/yocto-metrics add cve-check/$branch/$TIMESTAMP.json
-git -C $PARENTDIR/yocto-metrics commit -asm "Autobuilder adding new 
CVE data for branch $branch"
-git -C $PARENTDIR/yocto-metrics push
-$OURDIR/cve-report.py tmp/log/cve/cve-summary.json > 
$RESULTSDIR/cve-status-$branch.txt
-fi
-done
+mkdir -p $PARENTDIR/yocto-metrics/cve-check/$BRANCH/
+cd ..
+. oe-init-build-env build
+bitbake world --runall cve_check -R 
conf/distro/include/cve-extra-exclusions.inc
+if [ -e tmp/log/cve/cve-summary.json ]; then
+git -C $PARENTDIR/yocto-metrics rm cve-check/$BRANCH/*.json
+mkdir -p $PARENTDIR/yocto-metrics/cve-check/$BRANCH
+cp tmp/log/cve/cve-summary.json 
$PARENTDIR/yocto-metrics/cve-check/$BRANCH/$TIMESTAMP.json
+git -C $PARENTDIR/yocto-metrics add cve-check/$BRANCH/$TIMESTAMP.json
+git -C $PARENTDIR/yocto-metrics commit -asm "Autobuilder adding new CVE 
data for branch $BRANCH"
+git -C $PARENTDIR/yocto-metrics push
+$OURDIR/cve-report.py tmp/log/cve/cve-summary.json > 
$RESULTSDIR/cve-status-$BRANCH.txt
+fi
+
+if [ "$BRANCH" = "master" ]; then
+mkdir -p $PARENTDIR/yocto-metrics/cve-check/
+$OURDIR/cve-generate-chartdata --json 
$PARENTDIR/yocto-metrics/cve-count-byday.json --resultsdir 
$PARENTDIR/yocto-metrics/cve-check/
+git -C $PARENTDIR/yocto-metrics add cve-count-byday.json
+git -C $PARENTDIR/yocto-metrics commit -asm "Autobuilder updating CVE 
counts"
+git -C $PARENTDIR/yocto-metrics push
 
-mkdir -p $PARENTDIR/yocto-metrics/cve-check/
-$OURDIR/cve-generate-chartdata --json 
$PARENTDIR/yocto-metrics/cve-count-byday.json --resultsdir 
$PARENTDIR/yocto-metrics/cve-check/
-git -C $PARENTDIR/yocto-metrics add cve-count-byday.json
-git -C $PARENTDIR/yocto-metrics commit -asm "Autobuilder updating CVE counts"
-git -C $PARENTDIR/yocto-metrics push
+cp $PARENTDIR/yocto-metrics/cve-count-byday.json $RESULTSDIR
+cp $PARENTDIR/yocto-metrics/cve-count-byday-lastyear.json $RESULTSDIR
+fi
 
-cp $PARENTDIR/yocto-metrics/cve-count-byday.json $RESULTSDIR
-cp $PARENTDIR/yocto-metrics/cve-count-byday-lastyear.json $RESULTSDIR
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61458): https://lists.yoctoproject.org/g/yocto/message/61458
Mute This Topic: https://lists.yoctoproject.org/mt/102138012/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [yocto-autobuilder-helper] [PATCH 4/5] scripts/run-patchmetrics: Only monitor master branch

2023-10-23 Thread Richard Purdie
We only monitor the master branch for patch metrics as we can't really make
improvements to release branches.

Signed-off-by: Richard Purdie 
---
 scripts/run-patchmetrics | 5 +
 1 file changed, 5 insertions(+)

diff --git a/scripts/run-patchmetrics b/scripts/run-patchmetrics
index 20e6268..391ac45 100755
--- a/scripts/run-patchmetrics
+++ b/scripts/run-patchmetrics
@@ -11,6 +11,11 @@ OURDIR=`dirname $0`
 
 TIMESTAMP=`date +"%s"`
 
+# We only monitor patch metrics on the master branch
+if [ "$BRANCH" != "master" ]; then
+exit 0
+fi
+
 #
 # Patch Metrics
 #
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61457): https://lists.yoctoproject.org/g/yocto/message/61457
Mute This Topic: https://lists.yoctoproject.org/mt/102138011/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [yocto-autobuilder-helper] [PATCH 2/5] scripts/run-patchmetrics: Split out CVE checks

2023-10-23 Thread Richard Purdie
Split the CVE checks from the patch metrics script

Signed-off-by: Richard Purdie 
---
 config.json  |  6 +
 scripts/run-cvecheck | 54 
 scripts/run-patchmetrics | 36 ---
 3 files changed, 60 insertions(+), 36 deletions(-)
 create mode 100755 scripts/run-cvecheck

diff --git a/config.json b/config.json
index bebd999..f225148 100644
--- a/config.json
+++ b/config.json
@@ -1208,8 +1208,14 @@
 "BB_SERVER_TIMEOUT = '0'"
 ],
 "step1" : {
+"shortname" : "Generating patch metrics",
 "EXTRACMDS" : 
["../../yocto-autobuilder-helper/scripts/run-patchmetrics ../ ../meta/ 
${HELPERRESULTSDIR}/../../patchmetrics ."]
+},
+"step2" : {
+"shortname" : "Running CVE checks",
+"EXTRACMDS" : 
["../../yocto-autobuilder-helper/scripts/run-cvecheck ../ ../meta/ 
${HELPERRESULTSDIR}/../../patchmetrics ."]
 }
+
 },
 "meta-mingw" : {
 "NEEDREPOS" : ["poky", "meta-mingw"],
diff --git a/scripts/run-cvecheck b/scripts/run-cvecheck
new file mode 100755
index 000..35c796b
--- /dev/null
+++ b/scripts/run-cvecheck
@@ -0,0 +1,54 @@
+#!/bin/bash
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+PARENTDIR=`realpath $1`
+TARGETDIR=`realpath $2`
+RESULTSDIR=`realpath -m $3`
+BUILDDIR=`realpath $4`
+OURDIR=`dirname $0`
+
+TIMESTAMP=`date +"%s"`
+
+#
+# CVE Checks
+#
+if [ ! -e $PARENTDIR/yocto-metrics ]; then
+git clone ssh://g...@push.yoctoproject.org/yocto-metrics 
$PARENTDIR/yocto-metrics
+fi
+
+if [ ! -d $RESULTSDIR ]; then
+mkdir $RESULTSDIR
+fi
+
+for branch in master mickledore langdale kirkstone dunfell; do
+mkdir -p $PARENTDIR/yocto-metrics/cve-check/$branch/
+git -C $PARENTDIR reset origin/$branch --hard
+rm conf/local.conf
+rm conf/bblayers.conf
+rm -f conf/templateconf.cfg
+rm tmp/ -rf
+unset BB_ENV_PASSTHROUGH_ADDITIONS
+unset BB_ENV_EXTRAWHITE
+cd ..
+. oe-init-build-env build
+bitbake world --runall cve_check -R 
conf/distro/include/cve-extra-exclusions.inc
+if [ -e tmp/log/cve/cve-summary.json ]; then
+git -C $PARENTDIR/yocto-metrics rm cve-check/$branch/*.json
+mkdir -p $PARENTDIR/yocto-metrics/cve-check/$branch
+cp tmp/log/cve/cve-summary.json 
$PARENTDIR/yocto-metrics/cve-check/$branch/$TIMESTAMP.json
+git -C $PARENTDIR/yocto-metrics add cve-check/$branch/$TIMESTAMP.json
+git -C $PARENTDIR/yocto-metrics commit -asm "Autobuilder adding new 
CVE data for branch $branch"
+git -C $PARENTDIR/yocto-metrics push
+$OURDIR/cve-report.py tmp/log/cve/cve-summary.json > 
$RESULTSDIR/cve-status-$branch.txt
+fi
+done
+
+mkdir -p $PARENTDIR/yocto-metrics/cve-check/
+$OURDIR/cve-generate-chartdata --json 
$PARENTDIR/yocto-metrics/cve-count-byday.json --resultsdir 
$PARENTDIR/yocto-metrics/cve-check/
+git -C $PARENTDIR/yocto-metrics add cve-count-byday.json
+git -C $PARENTDIR/yocto-metrics commit -asm "Autobuilder updating CVE counts"
+git -C $PARENTDIR/yocto-metrics push
+
+cp $PARENTDIR/yocto-metrics/cve-count-byday.json $RESULTSDIR
+cp $PARENTDIR/yocto-metrics/cve-count-byday-lastyear.json $RESULTSDIR
diff --git a/scripts/run-patchmetrics b/scripts/run-patchmetrics
index abe58c7..e45d463 100755
--- a/scripts/run-patchmetrics
+++ b/scripts/run-patchmetrics
@@ -27,39 +27,3 @@ fi
 $OURDIR/patchmetrics-generate-chartdata --json 
$PARENTDIR/yocto-metrics/patch-status.json --outputdir $RESULTSDIR
 cp $PARENTDIR/yocto-metrics/patch-status.json $RESULTSDIR
 cp $PARENTDIR/yocto-metrics/patch-status/* $RESULTSDIR
-
-#
-# CVE Checks
-#
-for branch in master mickledore langdale kirkstone dunfell; do
-mkdir -p $PARENTDIR/yocto-metrics/cve-check/$branch/
-git -C $PARENTDIR reset origin/$branch --hard
-rm conf/local.conf
-rm conf/bblayers.conf
-rm -f conf/templateconf.cfg
-rm tmp/ -rf
-unset BB_ENV_PASSTHROUGH_ADDITIONS
-unset BB_ENV_EXTRAWHITE
-cd ..
-. oe-init-build-env build
-bitbake world --runall cve_check -R 
conf/distro/include/cve-extra-exclusions.inc
-if [ -e tmp/log/cve/cve-summary.json ]; then
-git -C $PARENTDIR/yocto-metrics rm cve-check/$branch/*.json
-mkdir -p $PARENTDIR/yocto-metrics/cve-check/$branch
-cp tmp/log/cve/cve-summary.json 
$PARENTDIR/yocto-metrics/cve-check/$branch/$TIMESTAMP.json
-git -C $PARENTDIR/yocto-metrics add cve-check/$branch/$TIMESTAMP.json
-git -C $PARENTDIR/yocto-metrics commit -asm "Autobuilder adding new 
CVE data for branch $branch"
-git -C $PARENTDIR/yocto-metrics push
-$OURDIR/cve-report.py tmp/log/cve/cve-summary.json > 
$RESULTSDIR/cve-status-$branch.txt
-fi
-done
-
-mkdir -p $PARENTDIR/yocto-metrics/cve-check/
-$OURDIR/cve-generate-chartdata --json 
$PARENTDIR/yocto-metrics/cve-count-byday.json --resultsdir 

[yocto] [yocto-autobuilder-helper] [PATCH 1/5] scripts/run-patchmetrics: Only clone metrics if it isn't present

2023-10-23 Thread Richard Purdie
To prepare for splitting things up, only clone the metrics repo if it isn't 
present.

Signed-off-by: Richard Purdie 
---
 scripts/run-patchmetrics | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/run-patchmetrics b/scripts/run-patchmetrics
index fc3f214..abe58c7 100755
--- a/scripts/run-patchmetrics
+++ b/scripts/run-patchmetrics
@@ -13,7 +13,9 @@ TIMESTAMP=`date +"%s"`
 #
 # Patch Metrics
 #
-git clone ssh://g...@push.yoctoproject.org/yocto-metrics 
$PARENTDIR/yocto-metrics
+if [ ! -e $PARENTDIR/yocto-metrics ]; then
+git clone ssh://g...@push.yoctoproject.org/yocto-metrics 
$PARENTDIR/yocto-metrics
+fi
 $OURDIR/patchmetrics-update --repo $PARENTDIR --patchscript 
$PARENTDIR/scripts/contrib/patchreview.py --metadata $TARGETDIR --json 
$PARENTDIR/yocto-metrics/patch-status.json
 git -C $PARENTDIR/yocto-metrics commit -asm "Autobuilder adding new patch 
stats"
 git -C $PARENTDIR/yocto-metrics push
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61454): https://lists.yoctoproject.org/g/yocto/message/61454
Mute This Topic: https://lists.yoctoproject.org/mt/102138008/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto][v5.10/standard/preempt-rt/base][PATCH] fix linux-yocto-rt compile error

2023-10-23 Thread Paul Gortmaker via lists.yoctoproject.org
[[linux-yocto][v5.10/standard/preempt-rt/base][PATCH] fix linux-yocto-rt 
compile error] On 22/10/2023 (Sun 19:21) Li Wang via lists.yoctoproject.org 
wrote:

> kernel-source/include/net/sch_generic.h:198:17: error: implicit
> declaration of function 'raw_write_seqcount_t_begin'; did you mean
> 'raw_write_seqcount_begin'? [-Werror=implicit-function-declaration]

Your commit seems reasonable, but it is missing one simple step.

Running "git blame" on the unpatched file, which leads to:

It isn't so much about the "blame" -- but knowing where the issure
originated from, so we can direct it to other development streams if
appropriate.

So in doing so I see afe3f03a84d51:

 -
commit afe3f03a84d5119b8a8af700e8360e4e4e2dc33c
Author: Sebastian Andrzej Siewior 
AuthorDate: Tue Sep 8 16:57:11 2020 +0200
Commit: Bruce Ashfield 
CommitDate: Thu Dec 17 12:35:26 2020 -0500

net: Properly annotate the try-lock for the seqlock
 -

So now we have more questions.

This is an old commit from 2020.  Why is it showing up as compile
breakage today?

Does the commit added to v5.10-yocto match the original in the
linux-stable-rt repo, or did Bruce do a compile tweak for it on the fly
back 3y ago and now upstream fixed the function name to not look like a
typedef?

Are we going to encounter the same issue on v5.15 in another 24 hours?

Your job as submitter is not just to provide the "raw" fix to Bruce, but
to ALSO provide the "how did we get here" story so he has a better idea
of the scope of impact and can perhaps better react in the future by
knowing what happened here so it can be prevented next time.

Thanks,
Paul.
--

> 
> Signed-off-by: Li Wang 
> ---
>  include/net/sch_generic.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
> index 72be68652bb8..4574dd262efd 100644
> --- a/include/net/sch_generic.h
> +++ b/include/net/sch_generic.h
> @@ -195,7 +195,7 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc)
>* Variant of write_seqcount_t_begin() telling lockdep that a
>* trylock was attempted.
>*/
> - raw_write_seqcount_t_begin(s);
> + raw_write_seqcount_begin(s);
>   seqcount_acquire(>dep_map, 0, 1, _RET_IP_);
>   return true;
>   }
> -- 
> 2.25.1
> 

> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13222): 
https://lists.yoctoproject.org/g/linux-yocto/message/13222
Mute This Topic: https://lists.yoctoproject.org/mt/102114616/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] M+ & H bugs with Milestone Movements WW42

2023-10-23 Thread Stephen Jolley
All,

YP M+ or high bugs which moved to a new milestone in WW42 are listed below:
Priority Bug ID Short Description Changer Owner Was Became
High 15243  Patchtest
deletes all local changes when running randy.macl...@windriver.com
tgamb...@baylibre.com 0.0.0 5.0 M1
5.0 M1 4.3 M4
Medium+ 13109 
Implement
CPE to package to Release mapping david.re...@windriver.com
david.re...@windriver.com 4.3 M4 5
14141  devtool
modify fails with submodules randy.macl...@windriver.com
jstep...@baylibre.com 4.3 M4 5.0 M1
15239  cve-check
corruption of cvss3 data randy.macl...@windriver.com rybczyn...@gmail.com
0.0.0 5.0 M1
15240  patchtest
should optionally test mergeability randy.macl...@windriver.com
tgamb...@baylibre.com 0.0.0 5.0 M1
15244  pseudo:
support for io_uring syscalls randy.macl...@windriver.com
unassig...@yoctoproject.org 3.1.28 5.0 M1

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61453): https://lists.yoctoproject.org/g/yocto/message/61453
Mute This Topic: https://lists.yoctoproject.org/mt/102134728/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Enhancements/Bugs closed WW42!

2023-10-23 Thread Stephen Jolley
All,

The below were the owners of enhancements or bugs closed during the last
week!
Who Count
david.re...@windriver.com 6
randy.macl...@windriver.com 2
alexandre.bell...@bootlin.com 2
ross.bur...@arm.com 1
michael.opdenac...@bootlin.com 1
Grand Total 12

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61452): https://lists.yoctoproject.org/g/yocto/message/61452
Mute This Topic: https://lists.yoctoproject.org/mt/102134669/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Current high bug count owners for Yocto Project 4.3

2023-10-23 Thread Stephen Jolley
All,

Below is the list of top 24 bug owners as of the end of WW42 who have open
medium or higher bugs and enhancements against YP 4.3. There are 1 possible
workday left until the final release candidates for YP 4.3 needs to be
released.
Who Count
michael.opdenac...@bootlin.com 34
ross.bur...@arm.com 29
richard.pur...@linuxfoundation.org 22
randy.macl...@windriver.com 16
bruce.ashfi...@gmail.com 13
david.re...@windriver.com 12
jpewhac...@gmail.com 10
pi...@pidge.org 7
yash.shi...@windriver.com 3
tim.orl...@konsulko.com 2
jon.ma...@arm.com 2
alexandre.bell...@bootlin.com 2
yoann.con...@smile.fr 1
tvgamb...@gmail.com 1
thr...@amazon.de 1
thomas.per...@bootlin.com 1
sundeep.kokko...@windriver.com 1
sakib.sa...@windriver.com 1
p.lob...@welotec.com 1
mark.asselst...@windriver.com 1
louis.ran...@syslinbit.com 1
jens.ge...@desy.de 1
fathi.bou...@linaro.org 1
alexis.loth...@bootlin.com 1
Grand Total 164

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61451): https://lists.yoctoproject.org/g/yocto/message/61451
Mute This Topic: https://lists.yoctoproject.org/mt/102134462/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2023-10-23 Thread Stephen Jolley
All,

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means
people can find them. They're being listed on the triage page under the
appropriate heading:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:
https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project. If anyone can help,
please take ownership of the bug and send patches! If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 414
unassigned or newcomer bugs.

We're hoping people may be able to spare some time now and again to help
out with these. Bugs are split into two types, "true bugs" where things
don't work as they should and "enhancements" which are features we'd want
to add to the system. There are also roughly four different "priority"
classes right now, “4.3”, “4.4”, "4.99" and "Future", the more
pressing/urgent issues being in "4.3" and then “4.4”.

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com)
an e-mail with the bug number you would like and I will assign it to you
(please make sure you have a Bugzilla account). The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61450): https://lists.yoctoproject.org/g/yocto/message/61450
Mute This Topic: https://lists.yoctoproject.org/mt/102134422/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [auh][PATCH v2] upgrade-helper.py: Add layer command line option

2023-10-23 Thread Alexander Kanavin
Thanks for working on this. Some comments below.

On Fri, 20 Oct 2023 at 16:02, David Pierret  wrote:
> +parser.add_argument("-l", "--layer-names", nargs='*', action="store", 
> default='',
> +help="layers to include in the upgrade research")
> +parser.add_argument("-L", "--layer-dir", action="store", default='',
> +help="the layers root directory")
> +parser.add_argument("-m", "--layer-machines", nargs='*', action="store", 
> default='',
> +help="machine to build for the layers")

Can the one-letter options be dropped, and only full options provided
(for these three new options)? Otherwise command line is going to be
rather non-self-descriptive.

> -if self.recipes and pn in self.recipes:
> -pkgs_list.append((pn, cur_ver, next_ver, maintainer, 
> revision))
> -elif self._pkg_upgradable(pn, next_ver, maintainer):
> -pkgs_list.append((pn, cur_ver, next_ver, maintainer, 
> revision))
...
> +if layer_recipes and pn in layer_recipes:
> +pkgs_list.append((layer_name, pn, cur_ver, next_ver, 
> maintainer, revision))
> +elif self._pkg_upgradable(pn, next_ver, maintainer):
> +pkgs_list.append((layer_name, pn, cur_ver, next_ver, 
> maintainer, revision))
...
>  return pkgs_list

I think it's time this function is refactored to return a dict, and
not a tuple. Can you make it so with a separate commit coming ahead of
this commit?

I would also prefer to avoid adding an extra nested for loop in it,
with the awkward shift in indentation. Can the outer and inner loop be
in separate functions?

weeklyjob-oe.sh should be folded into weeklyjob.sh, rather than be a
separate copy-paste-tweak script. List of layers can be passed in via
command line perhaps, defaulting to just poky/meta/. It also still
contains the sed MACHINE invocation which should not be needed?

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61449): https://lists.yoctoproject.org/g/yocto/message/61449
Mute This Topic: https://lists.yoctoproject.org/mt/102081611/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [Poky - Kirstone] About supporting kernel 6.1.

2023-10-23 Thread Alexander Kanavin
Note that the SLTS support is not coming from the actual kernel
upstream, but from a separate project called 'Civil Infrastructure
Platform':

https://www.linuxfoundation.org/press/civil-infrastructure-platform-expands-slt-stable-kernel-program

I think the right place for their kernels would be in a
meta-cip-kernel layer or similar, which you are welcome to create and
maintain.

Kirkstone has 5.10 and 5.15, both will continue to receive upstream
support for the duration of kirkstone support window.

Personally I think ultra-long support windows are bad. It's an
indicator of one's inability to do software updates properly, which
usually comes from poor testing and qa practices.

Alex

On Mon, 23 Oct 2023 at 12:17, Ming Wen  wrote:
>
> Hi YOCTOers:
>
> As you may know, according to the recent news update from Linux community, 
> Linux Kernel V6.1 will be the SLTS being supported as LTS till 2033.
> I'm wondering what your plan is to support Kernel 6.1 on Poky - Kirstone.
>
> Thanks~~
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61448): https://lists.yoctoproject.org/g/yocto/message/61448
Mute This Topic: https://lists.yoctoproject.org/mt/102132074/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [Poky - Kirstone] About supporting kernel 6.1.

2023-10-23 Thread Ming Wen
Hi YOCTOers:

As you may know, according to the recent news update from Linux community, 
Linux Kernel V6.1 will be the *SLTS* being supported as LTS till 2033.
I'm wondering what your plan is to support Kernel 6.1 on Poky - Kirstone.

Thanks~~

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61447): https://lists.yoctoproject.org/g/yocto/message/61447
Mute This Topic: https://lists.yoctoproject.org/mt/102132074/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto][v6.1/standard/nxp-sdk-6.1/nxp-soc & v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc][PATCH] gpu: imx: dpu: Use raw_spin_lock instead of mutex_lock

2023-10-23 Thread Xiaolei Wang via lists.yoctoproject.org
For Atomic Mode Setting, it is safer to use raw spin lock.
Mutex may cause scheduling, which avoids the following warning.

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 191, name: kworker/5:13
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
Preemption disabled at:
] dpu_crtc_atomic_flush+0x364/0x62c
 CPU: 5 PID: 191 Comm: kworker/5:13 Tainted: GWC 
6.1.30-yocto-standard #1
 Hardware name: Freescale i.MX8QM MEK (DT)
 Workqueue: events drm_mode_rmfb_work_fn
 Call trace:
 dump_backtrace.part.0+0xc8/0xd4
 show_stack+0x20/0x30
 dump_stack_lvl+0x6c/0x88
 dump_stack+0x18/0x34
 __might_resched+0x154/0x1c0
 __might_sleep+0x54/0xa4
 mutex_lock+0x2c/0x80
 fetchunit_is_enabled+0x28/0x70
 dpu_crtc_atomic_flush+0x198/0x62c
 drm_atomic_helper_commit_planes+0x158/0x220
 drm_atomic_helper_commit_tail+0x5c/0xb0
 commit_tail+0x130/0x17c
 drm_atomic_helper_commit+0x14c/0x180
 drm_atomic_commit+0xb0/0xf0
 drm_framebuffer_remove+0x468/0x4fc
 drm_mode_rmfb_work_fn+0x84/0xb0
 process_one_work+0x1f8/0x480
 worker_thread+0x238/0x450
 kthread+0x108/0x114
 ret_from_fork+0x10/0x20

Signed-off-by: Xiaolei Wang 
---
 drivers/gpu/imx/dpu/dpu-fetchdecode.c | 94 +--
 drivers/gpu/imx/dpu/dpu-fetcheco.c| 56 
 drivers/gpu/imx/dpu/dpu-fetchlayer.c  | 48 +++---
 drivers/gpu/imx/dpu/dpu-fetchunit.c   | 44 ++---
 drivers/gpu/imx/dpu/dpu-fetchwarp.c   | 48 +++---
 include/video/dpu.h   |  2 +-
 6 files changed, 146 insertions(+), 146 deletions(-)

diff --git a/drivers/gpu/imx/dpu/dpu-fetchdecode.c 
b/drivers/gpu/imx/dpu/dpu-fetchdecode.c
index 66d5862fbfa1..cacf3124c7fe 100644
--- a/drivers/gpu/imx/dpu/dpu-fetchdecode.c
+++ b/drivers/gpu/imx/dpu/dpu-fetchdecode.c
@@ -79,15 +79,15 @@ int fetchdecode_pixengcfg_dynamic_src_sel(struct 
dpu_fetchunit *fu,
 {
int i;
 
-   mutex_lock(>mutex);
+   raw_spin_lock(>lock);
for (i = 0; i < 4; i++) {
if (fd_srcs[fu->id][i] == src) {
dpu_pec_fu_write(fu, PIXENGCFG_DYNAMIC, src);
-   mutex_unlock(>mutex);
+   raw_spin_unlock(>lock);
return 0;
}
}
-   mutex_unlock(>mutex);
+   raw_spin_unlock(>lock);
 
return -EINVAL;
 }
@@ -116,21 +116,21 @@ fetchdecode_set_baseaddress(struct dpu_fetchunit *fu, 
unsigned int width,
baddr += (dma_addr_t)(y_offset % mt_h) * stride;
}
 
-   mutex_lock(>mutex);
+   raw_spin_lock(>lock);
dpu_fu_write(fu, BASEADDRESS0, baddr);
-   mutex_unlock(>mutex);
+   raw_spin_unlock(>lock);
 }
 
 static void fetchdecode_set_src_bpp(struct dpu_fetchunit *fu, int bpp)
 {
u32 val;
 
-   mutex_lock(>mutex);
+   raw_spin_lock(>lock);
val = dpu_fu_read(fu, SOURCEBUFFERATTRIBUTES0);
val &= ~0x3f;
val |= BITSPERPIXEL(bpp);
dpu_fu_write(fu, SOURCEBUFFERATTRIBUTES0, val);
-   mutex_unlock(>mutex);
+   raw_spin_unlock(>lock);
 }
 
 static void
@@ -155,12 +155,12 @@ fetchdecode_set_src_stride(struct dpu_fetchunit *fu,
  baddr, nonzero_mod);
}
 
-   mutex_lock(>mutex);
+   raw_spin_lock(>lock);
val = dpu_fu_read(fu, SOURCEBUFFERATTRIBUTES0);
val &= ~0x;
val |= STRIDE(stride);
dpu_fu_write(fu, SOURCEBUFFERATTRIBUTES0, val);
-   mutex_unlock(>mutex);
+   raw_spin_unlock(>lock);
 }
 
 static void
@@ -175,9 +175,9 @@ fetchdecode_set_src_buf_dimensions(struct dpu_fetchunit *fu,
 
val = LINEWIDTH(w) | LINECOUNT(h);
 
-   mutex_lock(>mutex);
+   raw_spin_lock(>lock);
dpu_fu_write(fu, SOURCEBUFFERDIMENSION0, val);
-   mutex_unlock(>mutex);
+   raw_spin_unlock(>lock);
 }
 
 static void fetchdecode_set_fmt(struct dpu_fetchunit *fu,
@@ -224,7 +224,7 @@ static void fetchdecode_set_fmt(struct dpu_fetchunit *fu,
break;
}
 
-   mutex_lock(>mutex);
+   raw_spin_lock(>lock);
val = dpu_fu_read(fu, CONTROL);
val &= ~YUV422UPSAMPLINGMODE_MASK;
val &= ~INPUTSELECT_MASK;
@@ -258,7 +258,7 @@ static void fetchdecode_set_fmt(struct dpu_fetchunit *fu,
val |= YUVCONVERSIONMODE(YUVCONVERSIONMODE__OFF);
}
dpu_fu_write(fu, LAYERPROPERTY0, val);
-   mutex_unlock(>mutex);
+   raw_spin_unlock(>lock);
 
for (i = 0; i < ARRAY_SIZE(dpu_pixel_format_matrix); i++) {
if (dpu_pixel_format_matrix[i].pixel_format == fmt) {
@@ -270,10 +270,10 @@ static void fetchdecode_set_fmt(struct dpu_fetchunit *fu,
shift &= ~(U_SHIFT_MASK | V_SHIFT_MASK);
}
 
-   mutex_lock(>mutex);
+   raw_spin_lock(>lock);

[yocto] CVE management and SRTool test update

2023-10-23 Thread Marta Rybczynska
Dear all,
Here's the update on our CVE management research work for YP.

Contest: a frequent request is to be able to answer "is YP affected by
this particular CVE". We have a part of an answer in the cve-check,
but not the triage of issues YP is not affected at all.

This research includes two elements:
Manual CVE triage tests
SRTool investigation

Manual CVE triage tests
===
Marta has done manual triage of two sets of two days: one manual
(download from CVE JSON5 database) and one via SRTool.

Manual triage: 2h
SRTool triage: 1.5h (but manual triage was done earlier)

Take-aways:
- a huge majority of issues does not affect YP
- those that do are most of the time already listed in cve-check results
- the effective procedure to check was "git grep" to find if we have a
recipe (Layer index could be used too), then checking a "world" run of
cve-check. Only rarely manual verifications are needed.
- found some CPE mismatches etc (patches will come)
- if we want to set up triage, we need to clearly define which layers
we take care of. For example, in one of the sets there were numerous
Java runtime issues. Also other issues in packages from various
layers.

To sum up, the triage takes around 1h/day without automation. However,
it should be way sgorter if pre-triaged with cve-check result and
package list from supported layers.

Open questions: who will be willing to participate in the effort?

SRTool investigation


We have had a call on October 19th (people present in CC).

Subjects discussed:
1. Installing SRTool
Marta has a running instance, Alex plans to set up one
2. Workflow
David explained how the investigation is done at WR. "Vulnerability"
describes a problem, can link to multiple CVEs (for example from
multiple researchers). From Vulnerabilities they create Investigations
(1:1 for each product - in our case YP releases).
Defects are handles in the bug tracker.

A proposal of David was to integrate Bugzilla and trace CVE entries,
import them into investigations. This would mean to use bugs to
populate CVE statuses.

However, we could not use that approach with YP right now, as CVE
entries aren't managed in Bugzilla. There's another subject on CVE
patches synchronization work, see
https://lists.yoctoproject.org/g/yocto-security/message/964

We have information on what version is affected/not affected from the cve-check.

Then David has shown the "Audit" functionality. It can be populated
from cve-check. Agreed to do a PoC implementation (David will work on
it).

When CVEs are filled from cve-check, only a certain number of CVEs
will be left with unknown status. Marta hopes they will be easy to
handle.

3. Result sharing

We discussed how triage results from YP can be used by other vendors.
It seems possible to do that via "audit" sources.

Next meeting planned on Nov 2nd.

Everyone willing to participate is welcome (send me or David a message
to be added to the invitation).

Kind regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61446): https://lists.yoctoproject.org/g/yocto/message/61446
Mute This Topic: https://lists.yoctoproject.org/mt/102131075/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-