/openbmc/linux/Documentation/devicetree/bindings/nvmem/layouts/ |
H A D | fixed-layout.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/nvmem/layouts/fixed-layout.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 7 title: NVMEM layout for fixed NVMEM cells 10 Many NVMEM devices have hardcoded cells layout (offset and size of defined 13 This binding allows defining such NVMEM layout with its cells. It can be used 17 - Rafał Miłecki <rafal@milecki.pl> 21 const: fixed-layout 23 "#address-cells": [all …]
|
H A D | nvmem-layout.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/nvmem/layouts/nvmem-layout.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> 11 - Michael Walle <michael@walle.cc> 12 - Miquel Raynal <miquel.raynal@bootlin.com> 18 perform their parsing. The nvmem-layout container is here to describe these. 21 - $ref: fixed-layout.yaml 22 - $ref: kontron,sl28-vpd.yaml [all …]
|
/openbmc/linux/Documentation/devicetree/bindings/nvmem/ |
H A D | nvmem.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) 3 --- 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> 23 "#address-cells": 26 "#size-cells": 29 read-only: 34 wp-gpios: 36 GPIO to which the write-protect pin of the chip is connected. 37 The write-protect GPIO is asserted, when it's driven high [all …]
|
/openbmc/linux/include/linux/ |
H A D | nvmem-provider.h | 1 /* SPDX-License-Identifier: GPL-2.0 */ 6 * Copyright (C) 2013 Maxime Ripard <maxime.ripard@free-electrons.com> 35 #define NVMEM_DEVID_NONE (-1) 36 #define NVMEM_DEVID_AUTO (-2) 39 * struct nvmem_keepout - NVMEM register keepout range. 52 * struct nvmem_cell_info - NVMEM cell description 77 * struct nvmem_config - NVMEM device configuration 83 * @cells: Optional array of pre-defined NVMEM cells. 85 * @add_legacy_fixed_of_cells: Read fixed NVMEM cells from old OF syntax. 91 * @read_only: Device is read-only. [all …]
|
/openbmc/linux/Documentation/arch/arm64/ |
H A D | memory.rst | 2 Memory Layout on AArch64 Linux 7 This document describes the virtual memory layout used by the AArch64 12 with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit 14 64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB) 15 virtual address, are used but the memory layout is the same. 24 mappings while the user pgd contains only user (non-global) mappings. 29 AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit):: 32 ----------------------------------------------------------------------- 38 fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down) 46 AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support):: [all …]
|
/openbmc/webui-vue/src/components/AppNavigation/ |
H A D | AppNavigation.vue | 3 <div class="nav-container" :class="{ open: isNavigationOpen }"> 4 <nav ref="nav" :aria-label="$t('appNavigation.primaryNavigation')"> 5 <b-nav vertical class="mb-4"> 6 <template v-for="navItem in navigationItems"> 7 <!-- Navigation items with no children --> 8 <b-nav-item 9 v-if="!navItem.children" 12 :data-test-id="`nav-item-${navItem.id}`" 16 </b-nav-item> 18 <!-- Navigation items with children --> [all …]
|
/openbmc/phosphor-bmc-code-mgmt/ |
H A D | meson.options | 1 # Supported BMC layout types. Reference: 2 …/github.com/openbmc/docs/blob/master/architecture/code-update/flash-layout.md#supported-filesystem… 3 # - static: NOR flash configured with fixed-sized MTD partitions. 4 # - ubi: NOR flash device configured with UBI volumes. 5 # - mmc: eMMC flash device configured with ext4 filesystems. 7 'bmc-layout', 11 description: 'The BMC layout type.', 16 'host-bios-upgrade', 23 'sync-bmc-files', 32 'verify-signature', [all …]
|
/openbmc/openbmc/meta-nuvoton/wic/ |
H A D | emmc-nuvoton.wks.in | 1 # short-description: Create an image for eMMC 2 # long-description: Creates an eMMC card image for the User Data Area that can 6 # Assumes U-Boot is stored elsewhere, such as an eMMC boot volume or NOR flash. 8 # --- - ---------- -------- -------- -------- -------- ------ ------- 9 # |GPT| | reserved | boot-a | boot-b | rofs-a | rofs-b | rwfs |GPT-sec| 10 # --- - ---------- -------- -------- -------- -------- ------ ------- 17 # First partition (u-boot-env) is 4K-aligned, which puts it at offset 0x5000 22 bootloader --ptable gpt 24 # Hint: bootimg-partition size must be same as MMC_BOOT_PARTITION_SIZE 25 # Note: the partition layout above is SoC default value, it may change by user [all …]
|
/openbmc/linux/Documentation/driver-api/ |
H A D | ioctl.rst | 18 the ioctl system call. While this can be any 32-bit number that uniquely 22 ``include/uapi/asm-generic/ioctl.h`` provides four macros for defining 36 An 8-bit number, often a character literal, specific to a subsystem 37 or driver, and listed in Documentation/userspace-api/ioctl/ioctl-number.rst 40 An 8-bit number identifying the specific command, unique for a give 45 encodes the ``sizeof(data_type)`` value in a 13-bit or 14-bit integer, 74 handler returns either -ENOTTY or -ENOIOCTLCMD, which also results in 75 -ENOTTY being returned from the system call. Some subsystems return 76 -ENOSYS or -EINVAL here for historic reasons, but this is wrong. 79 -ENOIOCTLCMD in order to use the fallback conversion into native [all …]
|
/openbmc/docs/architecture/code-update/ |
H A D | emmc-storage-design.md | 7 Created: 2019-06-20 22 - Security: Ability to enforce read-only, verification of official/signed images 25 - Updatable: Ensure that the filesystem design allows for an effective and 28 - Simplicity: Make the system easy to understand, so that it is easy to develop, 31 - Code reuse: Try to use something that already exists instead of re-inventing 36 - The eMMC image layout and characteristics are specified in a meta layer. This 41 - Code update: Support two versions on flash. This allows a known good image to 44 - GPT partitioning for the eMMC User Data Area: This is chosen over dynamic 48 - Initramfs: An initramfs is needed to run sgdisk on first boot to move the 54 - Read-only and read-write filesystem: ext4. This is a stable and widely used [all …]
|
/openbmc/linux/drivers/gpu/drm/nouveau/dispnv50/ |
H A D | wndwc57e.c | 35 struct nvif_push *push = wndw->wndw.push; in wndwc57e_image_set() 42 NVVAL(NVC57E, SET_PRESENT_CONTROL, MIN_PRESENT_INTERVAL, asyw->image.interval) | in wndwc57e_image_set() 43 NVVAL(NVC57E, SET_PRESENT_CONTROL, BEGIN_MODE, asyw->image.mode) | in wndwc57e_image_set() 47 NVVAL(NVC57E, SET_SIZE, WIDTH, asyw->image.w) | in wndwc57e_image_set() 48 NVVAL(NVC57E, SET_SIZE, HEIGHT, asyw->image.h), in wndwc57e_image_set() 51 NVVAL(NVC57E, SET_STORAGE, BLOCK_HEIGHT, asyw->image.blockh) | in wndwc57e_image_set() 52 NVVAL(NVC57E, SET_STORAGE, MEMORY_LAYOUT, asyw->image.layout), in wndwc57e_image_set() 55 NVVAL(NVC57E, SET_PARAMS, FORMAT, asyw->image.format) | in wndwc57e_image_set() 61 NVVAL(NVC57E, SET_PLANAR_STORAGE, PITCH, asyw->image.blocks[0]) | in wndwc57e_image_set() 62 NVVAL(NVC57E, SET_PLANAR_STORAGE, PITCH, asyw->image.pitch[0] >> 6)); in wndwc57e_image_set() [all …]
|
/openbmc/linux/Documentation/arch/arm/ |
H A D | memory.rst | 2 Kernel Memory Layout on ARM Linux 9 This document describes the virtual memory layout which the Linux 39 in proc-xscale.S to flush the whole data 53 ff800000 ffbfffff Permanent, fixed read-only mapping of the 59 VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space. 68 PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region. 72 PKMAP_BASE PAGE_OFFSET-1 Permanent kernel mappings 76 MODULES_VADDR MODULES_END-1 Kernel module space 80 TASK_SIZE MODULES_VADDR-1 KASAn shadow memory when KASan is in use. 85 00001000 TASK_SIZE-1 User space mappings [all …]
|
/openbmc/linux/Documentation/devicetree/bindings/pwm/ |
H A D | pwm-fsl-ftm.txt | 8 SoC | FTM-PWM endianness 9 --------+------------------- 19 - compatible : should be "fsl,<soc>-ftm-pwm" and one of the following 21 - "fsl,vf610-ftm-pwm" for PWM compatible with the one integrated on VF610 22 - "fsl,imx8qm-ftm-pwm" for PWM compatible with the one integrated on i.MX8QM 23 - reg: Physical base address and length of the controller's registers 24 - #pwm-cells: Should be 3. See pwm.yaml in this directory for a description of 26 - clock-names: Should include the following module clock source entries: 29 "ftm_fix" (fixed counter clock), 30 "ftm_cnt_clk_en" (external and fixed counter clock enable/disable). [all …]
|
/openbmc/linux/Documentation/devicetree/bindings/mtd/partitions/ |
H A D | brcm,bcm963xx-cfe-nor-partitions.txt | 4 Most Broadcom BCM63XX SoC based devices follow the Broadcom reference layout for 6 NVRAM partition, and the remainder in-between for one to two firmware partitions 7 at fixed offsets. A valid firmware partition is identified by the ImageTag 12 - compatible : must be "brcm,bcm963xx-cfe-nor-partitions" 17 compatible = "cfi-flash"; 19 bank-width = <2>; 22 compatible = "brcm,bcm963xx-cfe-nor-partitions";
|
H A D | brcm,bcm963xx-imagetag.txt | 5 partitions or non standard bootloader partition sizes. For these a mixed layout 12 - compatible : must be "brcm,bcm963xx-imagetag" 17 compatible = "cfi-flash"; 19 bank-width = <2>; 22 compatible = "fixed-partitions"; 23 #address-cells = <1>; 24 #size-cells = <1>; 28 read-only; 33 compatible = "brcm,bcm963xx-imagetag"; 38 read-only;
|
/openbmc/linux/Documentation/filesystems/ext4/ |
H A D | blockgroup.rst | 1 .. SPDX-License-Identifier: GPL-2.0 3 Layout chapter 4 ------ 6 The layout of a standard block group is approximately as follows (each 9 .. list-table:: 11 :header-rows: 1 13 * - Group 0 Padding 14 - ext4 Super Block 15 - Group Descriptors 16 - Reserved GDT Blocks [all …]
|
/openbmc/linux/drivers/staging/pi433/ |
H A D | pi433_if.h | 1 /* SPDX-License-Identifier: GPL-2.0+ */ 13 * Copyright (C) 2016 Wolf-Entwicklungen 14 * Marcus Wolf <linux@wolf-entwicklungen.de> 23 /*---------------------------------------------------------------------------*/ 49 * NOTE: struct layout is the same in 64bit and 32bit userspace. 97 * NOTE: struct layout is the same in 64bit and 32bit userspace. 124 /* only operational, if sync on and fixed length or length byte is used */
|
/openbmc/openbmc/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot/corstone1000/ |
H A D | 0024-corstone1000-adjust-boot-bank-and-kernel-location.patch | 7 bootbank with the new gpt layout, and also the 10 offset of the kernel partition is not fixed, 13 Upstream-Status: Pending 14 Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> 15 --- 16 board/armltd/corstone1000/corstone1000.env | 4 ++-- 17 1 file changed, 2 insertions(+), 2 deletions(-) 19 diff --git a/board/armltd/corstone1000/corstone1000.env b/board/armltd/corstone1000/corstone1000.env 21 --- a/board/armltd/corstone1000/corstone1000.env 23 @@ -1,8 +1,8 @@ [all …]
|
/openbmc/linux/sound/aoa/soundbus/i2sbus/ |
H A D | core.c | 1 // SPDX-License-Identifier: GPL-2.0-only 5 * Copyright 2006-2008 Johannes Berg <johannes@sipsolutions.net> 12 #include <linux/dma-mapping.h> 31 " no layout-id property is present"); 45 r->size = (numcmds + 3) * sizeof(struct dbdma_cmd); in alloc_dbdma_descriptor_ring() 46 /* We use the PCI APIs for now until the generic one gets fixed in alloc_dbdma_descriptor_ring() 47 * enough or until we get some macio-specific versions in alloc_dbdma_descriptor_ring() 49 r->space = dma_alloc_coherent(&macio_get_pci_dev(i2sdev->macio)->dev, in alloc_dbdma_descriptor_ring() 50 r->size, &r->bus_addr, GFP_KERNEL); in alloc_dbdma_descriptor_ring() 51 if (!r->space) in alloc_dbdma_descriptor_ring() [all …]
|
/openbmc/linux/tools/perf/Documentation/ |
H A D | intel-hybrid.txt | 2 -------------------- 17 0-15 20 16-23 22 It indicates cpu0-cpu15 are core cpus and cpu16-cpu23 are atom cpus. 24 As before, use perf-list to list the symbolic event. 29 [Fixed Counter: Counts the number of instructions retired. Unit: cpu_atom] 31 [Number of instructions retired. Fixed Counter - architectural event. Unit: cpu_core] 47 perf stat -e cpu_core/cycles/ 56 For hardware events, they have pre-defined configs (e.g. 0 for cycles). 66 The new attr.config layout for PERF_TYPE_HARDWARE: [all …]
|
/openbmc/linux/Documentation/fb/ |
H A D | api.rst | 9 --------------- 12 with frame buffer devices. In-kernel APIs between device drivers and the frame 22 --------------- 24 Device and driver capabilities are reported in the fixed screen information 36 - FB_CAP_FOURCC 40 specifying color components layout. 44 -------------------- 46 Pixels are stored in memory in hardware-dependent formats. Applications need 58 - FB_TYPE_PACKED_PIXELS 64 Padding at end of lines may be present and is then reported through the fixed [all …]
|
/openbmc/linux/drivers/md/ |
H A D | raid5.h | 1 /* SPDX-License-Identifier: GPL-2.0 */ 31 * Empty -> Want - on read or write to get old data for parity calc 32 * Empty -> Dirty - on compute_parity to satisfy write/sync request. 33 * Empty -> Clean - on compute_block when computing a block for failed drive 34 * Want -> Empty - on failed read 35 * Want -> Clean - on successful completion of read request 36 * Dirty -> Clean - on successful completion of write request 37 * Dirty -> Clean - on failed write 38 * Clean -> Dirty - on compute_parity to satisfy write/sync (RECONSTRUCT or RMW) 40 * The Want->Empty, Want->Clean, Dirty->Clean, transitions [all …]
|
/openbmc/linux/drivers/nvmem/ |
H A D | core.c | 1 // SPDX-License-Identifier: GPL-2.0 6 * Copyright (C) 2013 Maxime Ripard <maxime.ripard@free-electrons.com> 16 #include <linux/nvmem-consumer.h> 17 #include <linux/nvmem-provider.h> 64 if (nvmem->reg_read) in __nvmem_reg_read() 65 return nvmem->reg_read(nvmem->priv, offset, val, bytes); in __nvmem_reg_read() 67 return -EINVAL; in __nvmem_reg_read() 75 if (nvmem->reg_write) { in __nvmem_reg_write() 76 gpiod_set_value_cansleep(nvmem->wp_gpio, 0); in __nvmem_reg_write() 77 ret = nvmem->reg_write(nvmem->priv, offset, val, bytes); in __nvmem_reg_write() [all …]
|
/openbmc/linux/Documentation/networking/ |
H A D | xdp-rx-metadata.rst | 20 .. kernel-doc:: net/core/xdp.c 27 metadata available in which case the driver returns ``-ENODATA``. 30 implemented, the default ones that return ``-EOPNOTSUPP`` will be used 34 Within an XDP frame, the metadata layout (accessed via ``xdp_buff``) is 37 +----------+-----------------+------+ 39 +----------+-----------------+------+ 42 xdp_buff->data_meta xdp_buff->data 52 :doc:`af_xdp` use-case implies that there is a contract between the BPF 54 the final consumer. Thus the BPF program manually allocates a fixed number of 57 ``xsk_umem__get_data() - METADATA_SIZE`` to locate that metadata. [all …]
|
/openbmc/linux/arch/xtensa/include/asm/ |
H A D | kmem_layout.h | 2 * Kernel virtual memory layout definitions. 20 * Fixed TLB translations in the processor. 63 #if XCHAL_KSEG_PADDR & (XCHAL_KSEG_ALIGNMENT - 1)
|